Comment 27 for bug 84958

@Ralf Nieuwenhuijsen

"Well winefile may have its uses, but wine-mine and wine-notepad are _nothing_ like Java Web Start, or Java Control Utils. In line of that analogy, Java would be installing eclips, and some java-games, not to mention the java-docs including a desktop shortcut to them. Not to mention the fact that java programs actually integrate into their desktop environment. They don't need a special file-browser. They don't need a special registry editor."

winemine is a demo app which is why it probably shouldn't be included. But it is and it acts just like any other game which is why I put it in the games section. You may not like it but there's a dozen versions of Tetris and Solitaire because nobody has the same tastes.

Java Web Start just loads Java Control Panel but for some reason one is under Applications > Internet and the other is under System > Preferences. What is the point of that? Regardless, they are exactly like winecfg and regedit in that neither is critical to the user directly in most usage scenarios but they are still needed to resolve problems with specific applications. Having their menu entries in the Wine menu just adds more clutter the users have to go through to get to their Windows apps. This is why they belong in the Preferences menu with the rest of the seldom-used apps.

Some Windows apps depend on notepad for showing readme files during installs (and look for the notepad window title to verify it's successful execution). I've encountered failures and spurious error messages on Windows just by associating txt files with another editor. This is a diminishing issue however as it's mostly older apps that work this way. It probably will be removed at some point unless there are other dependencies I'm not aware of.

"You bring up the technical point of view that it is a packaging issue. But I don't think that space is the issue here: it's the clutter of uniting two worlds into one menu. Two worlds that do not integrate. Wine does not respect the gnome nor kde file-associations. Visa versa they don't respect the wine file associations."

They never will. Windows apps expect other Windows apps to handle specific file types by default. From a Gnome or KDE perspective, Windows apps are just documents that Wine opens. The Gnome/KDE file managers can open Windows docs and media files by using Windows apps through Wine but there are usually better native apps for those tasks. But it's ridiculous to think that Wine will be able to wrap native Linux apps to look like Windows components to Windows applications. The Wine team has enough work to do with just the basic API and DirectX. They don't even support the database APIs yet and that has more significant value to them especially since most of them work for Codeweavers whose business model is based on getting Microsoft Office to work on Linux.

"To run steam.exe on ubuntu we get 8 links to manage all that."

Happens with a lot of Windows app installs on Wine. Probably a bug or incomplete function.

"We end up with two package-managers (instead of just one)."

Wine has to support the Windows install system which really isn't much of a system and many apps use their own or don't have one at all. It may be possible to have Synaptic act as a front-end to Wine's installer but I'm not expecting it anytime soon and it's probably not worth the added code complexity. Besides, Synaptic is a system-wide package manager that requires admin access to use. Wine's install system is local to each user. I hope nobody is stupid enough to install Windows apps in Wine as root in a system-wide configuration.

"It's a desktop-environment"

File managers, e-mail apps, games, and web browsers are available with mouse support (through GPM) in any text terminal. Does that make them desktop environments? If so, they should be removed to reduce overhead since the average user will never use them.

"Java does not create its own java menu for user installed java programs."

Java app packages included with the distribution either include a menu entry or none at all. Java apps installed from outside the package management system generally don't have anything (I've never seen one). Wine apps installed with the package management system (like winemine or Google Picasa) include menu entries. Wine provides menu entries for Windows apps installed through it. So the fact that Java doesn't create menu entires for Java apps installed outside of the package management system is a limitation that needs to be addressed.

"The help files concerning java are part of the standard ubuntu help system."

Java doesn't have to support legacy applications written for a completely different platform. Windows apps with integrated help are dependent on Internet Explorer and the Windows help components. There has been some progress towards creating a wrapper for the Mozilla Gecko engine. Gnome CHM can be used to open CHM help files but Windows apps are usually written to call the Windows help system directly. It's a feature of the Internet Explorer-integrated desktop that Microsoft pushed years ago to the benefit of countless malware writers.

"Java programs respect the file-associations of the desktop-environment. It puts programs into the correct category. Java programs do not mangle the path and filenames of files on your hardrive. It does not need a virtual drive like wine does.

It's nothing like Java."

You seem to have this habit of overreaching into fringe topics in an attempt to bolster your argument. Since when does path/filename mangling have anything to do with presenting a simple menu system for a system-wide application platform?

I have yet to see a Java app that creates a local menu entry for a locally installed Java application.

"Now to add to the inconsistency: we put certain wine stuff in other menu's.
Stuff like file-managers, package management. But is not general package-management. It's not a general file-managers. It's not a general package-managers. It all deals only with the wine-world."

Java Web Start, Control Panel, and the Policy Tool only deal with the java-world.

"Now when we already have this menu anyway, why not put _all_ wine stuff there?
Seems a whole lot less confusing to me.
It emphasizes this the separation between the two worlds. The separation users will experience anyway."

I have CD/DVD burning apps in Applications > Sound & Video, a "CD/DVD Creator item in Places, and a Removable Drives and Media item in System > Preferences. Maybe they should all go in one menu too.

"We don't install konqueror to open a mp3 with amarok, just because nautilus file-associates might have been changed by the user!"

Bad example. That would be an intentional change, not an accidental one.

"When you install amarok (and with that kde-support) you don't install konqueror, so why do we install wine-file when we just want to install wine-support? Because amarok actually integrates into the system, even when its a kde app. Wine apps do not."

Does Konqueror require Amarok? What's your point?

"I actually understand why somebody would prefer wine-file to force something to open with a windows program.
This is not the point. People would be less annoyed by all those desktop links if they are just united into one menu. When to use which file manager would be clear.

I still prefer to use nautilus for everything and I think its important people can easily use nautilus/konqueror to access their wine-drives. Creating a menu link to that as Darkegel suggested would be a perfect solution to that particular problem. But this menu link too should be in that one and only wine-menu."

In my usage cases winefile is not being used to open a document or media file with a Windows program. It's being used to launch a Windows executable with Wine, usually a setup file on a CD or an application without an installer that is required to be located within the Windows directory hierarchy.

If a user needs to open a specific file with a Windows app, It's usually easier for them to launch the app first with Wine and use File >Open to access the file. This is more likely to happen with multimedia files because most of them are containers for multiple media formats only some of which are supported by native Linux apps. For example, if the desktop has AVI files associated with Totem but it can't play a particular AVI due to a contained video object in a unsupported format, Windows Media Player can be launched through Wine to play the file. It would be nice if Nautilus could be configured to launch WMP through Wine but it's easier to just launch WMP directly.

My user base, which consists of a wide variety of non-tech types of all ages (4-70+), doesn't have any problems with the current arrangement. I put links to Wine's drive directory on the desktop and in Nautilus also. Some prefer Wine File and some Nautilus for accessing the Wine drive. You're complaining a lot more about it than any of them did.

"I really don't think i'm alone in thinking that in the particular case of wine, one united menu would be the way to go. Esspecially when there already is a wine menu containing the wine-installed-programs."

I think that is the wrong way to go because it clutters up the Wine menu with critical but seldom used items. Anyways, I'm not sure if the Gnome or KDE desktops handle combining a system-wide submenu and a local one. It might end up with two Wine menus. But that's a question for the developers.