@Ralf Nieuwenhuijsen

"Well, I compliment you for that effort. Some of these links are handy. Unfortunately you forgot one of the most important links: a wine-boot entry!"

Before I submitted them there weren't any.  Wine was launched from opening exe files in Nautilus or from a terminal.

"Since when do Mono or Java install their default file-browser, minesweeper game or registry editor? They don't.
I completely agree with the analogy. I just wish that wine would be more _like_ that. Instead it acts like a desktop-enviroment. But even installing a kde app, doesn't create links to kde-control-center, konqueror and kate by default. That would be insane. Why is it more sane when wine acts like that?"

Again, this is a packaging issue.  If they are not useful then they should not be part of the package in order to save space.  I fail to see any difference between winefile and the Java Web Start or regedit and the Java control utils.

"Again, its not about idealogy. Its about wanting to run windows apps, without installing a windows-like desktop envirnoment on top on my gnome-desktop."

Wine's basic apps hardly constitute a desktop environment.

"Also, the requests about icon's have to do with the fact that they currently have no icons. If anything, i would prefer more task-specific icons, rather than just a wine bottle. But any icon is better than no icon. But using the default registry-editor icon for the wine-registry and such seems logical to me. Feel free to go that way!"

This is already noted in bug #88285

"Ehm, when I install steam.exe on wine, it doesn't go into the games menu. When I install photoshop it doesn't go into the graphics menu. They go into the wine-menu. So there already is a wine-menu. Its just the crap i didn't _choose_ to install (wine minesweeper, wine notepad, wine file browser, etc.) that is spread all over the place. The desktop-environment-like stuff that comes with the support. We want wine-support (including configuration and administraiton, we do not want wine-desktop-environment, with its own filebrowser, games and text-editor)"

First you are confusing two different aspects of Wine.  The desktop files that control the default menu entries are global and part of the package.  The Wine menu is added to Gnome by Wine and is local, stored in ~/.config/menus/applications-merged and ~/.local/share/applications/wine and thus are per-user.  Change requests to Wine's app install behavior need to be made upstream at bugs.winehq.org.  If you don't like the apps in the current package you can always compile it yourself.

"Using the ugly wine-file manager makes as much sense as using konqueror to open files that I want to launch with a kde app. None."

Using an app-centric or file-centric approach to tasks on a GUI is a matter of preference.  While you may prefer the former many prefer the latter.  I'm about 50%-50% depending on what I am doing.

"Nautilus is the default file-manager on gnome, konqueror on KDE. Users don't need to learn different file-managers just because they want to use a mono, java or wine app."

Using winefile is an option, not a requirement.  I find it useful because it presents a Windows-like view of the file system which is more familiar to n00bs.  And as I stated previously it's also useful for launching Windows exe files when the file association in Nautilus is broken by user error.

"Not even going into the weird situation where somebody tries to open a linux application with the wine-file-manager. It won't work. They get all confused."

Why would a basic user browse to /bin or /usr/bin to launch a Linux app when menu entries are available for anything they would want to use?  Most Windows n00bs don't have a clue about the Linux directory hierarchy wouldn't even know where to look.  This is an unlikely scenario.

"And for the record: nautilus is way more like explorer (esspecially vista's explorer) than wine file-browser is."

It's a clone of Windows File Manager.  Probably before your time, young fella. :D  It's the c: relative file structure that is important.

"I agree that users should be able to easily access their wine c-drive. This is important. But the nautilus bookmarks are THEIRS. Why not just symlink to it, from the home-folder of the user?

That is the correct way. One file-manager, easy access to c-drive. If users go there very often, they are free to create a nautilus/places bookmark like they already do with other popular folders. This does not require terminal or anything. All users create and manager their own bookmarks. Its very intuitive for them.

Just make sure they can _find_ drive-c. Which is why i say: symlink it from the home-folder."

I don't care about the technical implementation, just the c: relative file structure.  I'd prefer anything over having users messing with hidden directories.  Too much potential for damage.

"No we want some menu-entries and we want them in a specific place. Either all wine links should go into the correct category (including custom installed stuff!), or they should all go into the wine menu."

I don't think that is possible automatically.  Wine can't determine what kind of Windows application it installs.  There is no data in the apps that indicates a category.  Either it would have to look it up in a table or ask the user.

"And there shouldn't be links to minesweeper, nor notepad, nor the filebrowser. The configuration tool and the registry editor should still have links though! But not spread around the system. This will confuse users when there already exists a wine menu. This will be the first place they look.

Putting everything in one menu communicates "this administration tools deal with these programs and not with the rest of the system". It has got nothing to do with marking evil sofware as evil.""

Again it's a packaging issue.  The basis for their menu locations is the same as for Java.  Either the current Wine configuration is wrong or Java and other apps' configurations are wrong.  It's a matter of consistency.