Consider hiding menu entries

[magilus]

Binary package hint: wine

As of the latest Feisty wine version, some menu entries were added.

Among these are:
Winemine
Wine Software Uninstaller
Wine File
Wine Help Browser
Wine Notepad

It should be considered to hide some of them as they may confuse users and are worthless.

Winemine can be hidden as there is already a much nicer Mines shipped with Ubuntu (I don't know about Kubuntu)

Wine Software Uninstaller is useful and should be left there. Maybe a nice icon should be added ;-)

Winefile can be hidden as there are already Nautilus / Konqueror and the .wine/drive_c directory.

Wine Help Browser can be hidden as most people probably don't open Windows help files and if they would, they would do via double click / right click.

Wine Notepad can be hidden as there are already Gedit / Kate.

Martin :-)

[magilus (magilus)]

Sorry for the double-posting.

I created an icon for the Wine Software Uninstaller, which is attached. (not that nice ;-))

Also, I noticed that there are two preferences entries:

- Wine Regedit
- Wine Config

I think that Wine Config is okay, but I don't know what to do with Regedit. On the one hand, it is +1 menu entry, on the other hand, people may want to use it.

[Tormod Volden (tormodvolden)]

All the wine entries are missing icons.

[jhansonxi (jhansonxi)]

I submitted the *.desktop files that added the entries.

wine.xpm icon: See bug #88285

Winemine, Notepad: Entries should not be hidden unless they are Admin-only. If an included app is optional and inferior to other similar ones already included in the distro then it should not be included in the package.

Help Browser: Some reference books are distributed as hlp files.

Notepad: Not really useful as a standalone app but is probably required by other Windows apps. It is a familiar interface to new Linux converts.

File: Ugly but presents a Windows-like file structure to the user. Makes more sense to newbies than having them visualize a hidden .wine/drive_c path as C:.

Regedit: Manual registry hacking is still required to get some apps to function.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

I don't think the icons should be hidden.

What I want:
  1. one wine menu contraining all entries
  2. user-stuff in the programs sub-menu
  3. system-stuff in a system sub-menu
  4. a desktop entry to reboot wine
  5. a desktop entry that links to the winehq website
  6. drop Wine in the name of the desktop-entries
  7. give them correct icons (from the currently installed theme) instead of them all having the default wine-icon

Note to point 7: the file browser has nautilus icon, notepad has the gedit icon, etc.

Example menu structure:

Applications
  -> Wine
         -> Programs
            -> user installed program 1
            -> user installed program 2
            -> Mines
            -> NotePad
         -> System
             -> Configuration
             -> Registry Editor
             -> Software Uninstaller
             -> Reboot WINE
         -> File Browser
         -> Help Browser
         -> About Wine

That would be perfect.
I think I can help supply the desktop-entries.
But how do you create a menu? What kind of file is needed?

If the package maintainer would tell me... I will post them here.
And who takes care of the translations?

[jhansonxi (jhansonxi)]

I like the idea.

Wine is in Universe and is under the jurisdiction of the Masters Of The Universe (MOTU). The NoDesktopFile page is where packages without the config files are listed:
https://wiki.ubuntu.com/MOTU/Packages/NoDesktopFile
Note that it is not in alphabetical order. The files are located in /usr/share/applications and the icons in /usr/share/pixmaps.

If you want to propose a change to an existing one, file a bug for each app and include your modified desktop file.

Location in the menu hierarchy is controlled by the Category entry but I am uncertain as to how submenus are defined.

Some of your ideas like Reboot and About would require scripts.

[Philip A. Marshall (philip-philipamarshall)]

"Reboot" is just "wineboot" (though you may want to add some kind of feedback to let the user know something happened)
"About Wine" is just "wine winver"

I'm curious as to why you think that scripts would be needed...

[jhansonxi (jhansonxi)]

I wasn't aware those two commands existed so scripts unnecessary.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

Still valid in Gutsy. Wine entries are spread everywhere! Yuck!

[Scott Ritchie (scottritchie)]

Most users will want to install Wine to run Windows apps. Very few have any interest in running the test applications that come with Wine (notepad and minesweeper), especially as replacements to normal applications (gedit and gnome mines).

The winecfg and uninstaller entries are important. Wine already makes its own program folder when the user installs a Windows application, so we should consider putting everything Wine related in there. Notepad and minesweeper can go into a default Wine->Program Files->Applications; even if users don't run them this will make it clear that Wine will add start menu entries alongside them.

Some applications users will almost never want to run, even accidentally. Even Microsoft makes users run regedit from the terminal. Showing it to every Wine user is needlessly confusing; if a user has to edit the registry something is broken anyway.

Wine file isn't meant to be run by itself, except sometimes as a launcher script requiring additional terminal arguments. We can hide it for the same reason we don't have an application menu link to the grep command.

We do, however, need a link for users to browse their ~/.wine/drive_c/ folder in nautilus. I'm a bit torn whether it should be in places or in the Wine folder itself, though.

I'm not sure what to do with the help file browser though. Users should be able to click a help file and have it open automatically; running the help browser outside of this feature isn't going to be helpful (Wine's help files, meanwhile, should be like every other native helpfile on the system.)

[jhansonxi (jhansonxi)]

Regedit is more useful to end users on Wine than in Windows. Some applications need to have entries added to enable functions that improve performance or compatibility that can't be enabled from the applications themselves and are not added by their installer, For example, Warcraft3 needs registry entries to force the game to use OpenGL instead of DirectX else it's ugly and slow. There is no option within the game itself to enable it. While it's possible to enable it from the game's command line, Wine doesn't add it for the default menu entry. There have been some attempts at third-party installers for popular apps to handle these details but until they achieve support for a wide range of applications manual registry editing will be needed.

Wine File is still needed as it provides a standard Widows C: view of the file system that users understand. It is useful for gamers who want to install third-party add-ons or levels that require files to be copied to specific directories and are following instructions written for Windows Explorer. It also can be used as a workaround for broken desktop configurations that don't launch Wine correctly when a Windows exe file is opened. It's an ugly app but until someone comes up with a view template that allows Nautilus and other file managers to show a similar view of the .wine directory structure it's better than nothing.

Another issue is that Wine only adds menu entries for apps that actually create Windows menu or desktop lnk files. There are a lot of small games and apps that don't have installers. Wine File (or the desktop file managers) need an option to add a Wine link for a selected exe.

I agree that putting Notepad and Minesweeper in the same menu structure as other Windows app shortcuts makes sense. The help browser doesn't need an entry as long as it launches correctly when an hlp file is opened. CHM files can be handled by Gnome CHM (Vista doesn't support CHM anymore, LOL).

[Scott Ritchie (scottritchie)]

Wine file has all sorts of problems with it that simply opening a nautilus window at ~/.wine/drive_c doesn't have though. For example, you can drag and drop files to your desktop, or another nautilus window.

What benefit does browsing this with wine file actually give? "Instructions for explorer" are limited to just opening, copying, and renaming files, all of which nautilus can do already. The only leap for the user is that they need to understand where their C:\ drive is, and if we name the shortcut "Browse virtual C:\ drive" and put it in the Wine folder it'll be pretty obvious.

You have a good point about the need for an analog to Windows "create shortcut" command for apps to be run with Wine, though. It should be doable on the right click menu. We may not even need to do anything too creative to handle it.

[Dan Kegel (dank)]

Scott wrote:
[ The user needs a way to easily get to their virtual C: drive.
Let's use Nautilus, name the shortcut "Browse virtual C:\ drive",
and put it in the Wine folder]

For KDE users, it should be Konqueror instead of Nautilus, of course.

The easiest way to do that is to use "xdg-open $HOME/.wine"
as the command to open the directory.

Mind you, we should also consider putting it in Places rather than
in the Wine folder. Or both. That would be a bit more complicated, though.

[jhansonxi (jhansonxi)]

Probably should be .wine/dosdevices/c: but that is the general idea. On Ubuntu Feisty xdg-utils is not installed by default. II agree that an entry in the Places section is better. There is the problem of handling entries for multiple wine homes but this is an edge case that only pops up occasionally.

[Dan Kegel (dank)]

(Yeah, I got the path wrong.)

It might be good to handle multiple wine homes. Some people use
separate wine homes for different tasks. The UI design for this
would take some thought, though. (For inspiration, maybe look
at how Crossover does bottles?)

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

People, please! This bug is about REMOVING menu entries. Not about ADDING THEM.

The whole problem with wine is that it thinks its so importanted it should clutter all my menu's and turn Ubuntu into some sort of Fake Windows (tm).

_That_ is what _this bug_ was about. You people are anti-fixing it. Making it worse. Not only should it puke all over my applications and system menu, people are now suggesting that it also creates links in the places menu. The only place where the current wine package did not yet take a dump.

And they want this for 'theoretical average joe' users! I assume they themselves are well capable of creating such a bookmark, yet i'm also quite confident that none of you did. (dokter, please start taking your own medicine)

Please stop polluting the menu's. Wine is not a half-baked operating system. Its a program to run windows programs. No program should install shortcuts _all over the place_. Wine can have one complete sub-menu of applications for itself. It may not add any entries anywhere else, including system and places menu. Nobody uses wine to run more than 1 or 2 programs. Nobody wants to turn their Ubuntu into puke-buntu just to play world-of-warcraft.

So please keep all the wine related links contained within one menu. Please do not suggest to the package maintainer to also pollute the places menu.

And @dankegel: people that use more than one wine bottle are not the type of people that need _you_ to create bookmarks for them in their places menu. They are intelligent enough to do that themselves in that particular case they would actually want that.

[Dan Kegel (dank)]

Ralf, if you want to drive me away from the wine-team, that's a great way to start.
After reading your post, I just want to run away and not come back...

[magilus (magilus)]

Just for the records, I agree with Ralf. The menu entries should all go to the Wine menu, otherwise the menus are full of Wine entries which the user does not want.

Also, bookmarks could be made available at a point where they do not confuse the user, namely the Wine menu. From the users perspective, I think that an entry in Places would be much more confusing.

*If* there is someone who wants to support menu entries for multiple bottles, go for it and write a clean implention (probably should happen upstream), but otherwise an acceptable solution would be to put a link to the .wine/drive_c directory to the Wine menu.

[Tomas Zijdemans (tzi063)]

I agree, that was a bit harsh (and not exactly in the spirit of our code of conduct).

Ralph: I mostly agree with your non-personal-attacking points, but consider letting out steam elsewhere.

dankegel: Ralph made a valid point regarding the purpose of this thread, but expressed himself in an abusive way. Please ignore the outburst.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

I am sorry if I what I said was not diplomatic enough.
@darkegel, I apoligize if I make you run away from anything.
I know i was expression frustration, but if for someway you experienced that as a personal attack, then I am very sorry. That was not my intention.

[jhansonxi (jhansonxi)]

@Ralf Nieuwenhuijsen: I think it is perfectly reasonable to discuss adding and removing Wine menu entries here - or should I submit a new bug requesting more of them and turning this discussion into a cross-posting mess?

@dankegel: It's just text. I've found that discussing bugs with the Wine developers is a lot more irritating.

Since I'm entirely responsible for the current *.desktop files which dictate where the menu entries landed I think it would help to show my rationale for the placement.

Wine may be the unwanted bastard stepchild in the land of FOSS, especially with Mark Shuttleworth's attitude towards it in regards to Ubuntu. But I have found it to be rather critical for migrating my customers over to Linux, especially since most of them are Windows gamers. They can barely handle installing apps on Windows so any additional difficulty (like terminals) isn't going to improve the transition. They can make backups of their game saves and install add-ons following simple instructions but they mostly operate by simple repetition with a minimal understanding of the underlying processes. It reminds me of my early experience with WordPerfect users in MS-DOS. They knew what to type at a command prompt to start the app but they didn't really understand anything about what they were typing. Once they were in WordPerfect they were experts however. A large majority of the current PC consumers are in this category.

I view Wine as an application platform. To me its no different than Mono or Java. If I install apps that use Mono or Java should they be in a Mono or Java menu? Why is "Java Web Start" in the Internet menu and the "Plugin Control Panel" and "Policy Tool" in the Preference menu? Some of you may be biased towards one technology or the other and want to hide the menu entries in an submenu and give it an icon to remind everyone that it's the "evil" section but my users just want to find their games and they don't care about the underlying system. This is why I set the Wine app categories the way they are.

I'm all for improving the user experience and I'm not picky as to the exact method of doing it. Fixing Wine File so it's more usable or adding a Windows-like view of the .wine/drive_c to the default file managers both seem like good solutions to me.

Maybe the solution is to have the menu entires in a different package with a "recommend" for them on the Wine package.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

@jhansonxi

"Since I'm entirely responsible for the current *.desktop files which dictate where the menu entries landed I think it would help to show my rationale for the placement."

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!

"But I have found it to be rather critical for migrating my customers over to Linux, especially since most of them are Windows gamers. They can barely handle installing apps on Windows so any additional difficulty (like terminals) isn't going to improve the transition."

For me, this has nothing to do with ideology. I too find it critical to be able to run a windows app in a linux-environemt. I don't want the windows support to take over my default desktop enviroment though.

"I view Wine as an application platform. To me its no different than Mono or Java. "

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?

"an icon to remind everyone that it's the "evil" section"

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. 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!

"want to find their games and they don't care about the underlying system. This is why I set the Wine app categories the way they are."

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)

"I'm all for improving the user experience and I'm not picky as to the exact method of doing it. Fixing Wine File so it's more usable or adding a Windows-like view of the .wine/drive_c to the default file managers both seem like good solutions to me."

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. 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.

Not even going into the weird situation where somebody tries to open a linux appli...

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

Small refinement:

Here is my proposol again:
  - create a symlink (ln -s ".wine/drive_c" "~/Wine Drive")
  - remove wine-minesweeper, wine-notepad, wine file-browser .deskop files
  - move all remaining wine links to Applications -> Wine menu
  - add a wineboot entry to that menu as well
  - give all the apps specific and clear icons:
          - add/remove icon for the software uninstaller
          - a help icon for the help browser,
          - gnome-registry-editor icon the for the registry-editor
          - preferences icon for the wine configuration tool
          - reboot icon for the wineboot entry

[Dan Kegel (dank)]

Creating a symlink (ln -s ".wine/drive_c" "~/Wine Drive") would IMHO be bad,
as it's just clutter in the user's home directory. I'd rather see a
"Browse Wine C: drive" menu entry that invoked xdg-open $HOME/.wine/drive_c,
and adding a dependency on xdg-utils (so we can use xdg-open).

[jhansonxi (jhansonxi)]

@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...

[Scott Ritchie (scottritchie)]

On the subject of icons, I already have a bunch that I still need to integrate into the package. They were sent to the wine-devel list a while back, but the website where they were put is down. I still have a local copy, though.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

"First you are confusing two different aspects of Wine. ... If you don't like the apps in the current package you can always compile it yourself."

Yeah, if I had even more free time I could compile my own distrobution. But that's not the point of a bug-report on Ubuntu is it? That would be a nice 'go away' response to any bug-report.

"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."

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.

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.

The fact is, although we _want_ wine to be like Java, it is not. To run steam.exe on ubuntu we get 8 links to manage all that. We end up with two text-editors instead of just one. (confusing). We end up with two file-browsers instead of just one (confusing). We end up with two package-managers (instead of just one). We end up with two minesweeper games. How the hell did minesweeper become a dependency of steam.exe? Then we see the light:

*It's a desktop-environment*

It has its own tools, its own file-browser, its own package-management. Wether we like it or not, its a completely separate world. We don't want to use wine-notepad to open files on our gnome-desktop. We don't want wine-file to browse our normal home-directory. Unfortunately we may need those tools. But because it is a separate world, it should be in one united menu.

"Change requests to Wine's app install behavior need to be made upstream at bugs.winehq.org"
"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."

Exactly. So we have to have a wine menu anyway! The menu is already there!
Yet it does not contain all wine links. Just some of them. The wine world has its own little planet, with its own rules, its own menu, but certain stuff is located on the gnome/kde planet. Isn't the situation confusing enough without that mess?

"The basis for their menu locations is the same as for Java."

No it's not! Java does not create its own java menu for user installed java programs.
It does not require its own file-manager. It does not require its own text-editor. The help files concerning java are part of the standard ubuntu help system. Java programs respect the file-associations of the...

[jhansonxi (jhansonxi)]

@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 app...

[Dan Kegel (dank)]

I want to unsubscribe from the discussion forum this bug report is
degenerating into, but I don't think there's a way short of
me leaving the wine team. Can you folks take the big long
arguments elsewhere?

[Loye Young (loyeyoung)]

"Is this a bug report or a discussion forum?"

It's both in a sense. The "bug" or issue reported was to consider hiding menu entries, which has been regarded as a reasonable request. The thread following has been a discussion attempting to find a consensus on how to solve the issue. You and others have provided input, the net effect of which input has been a sharpening of the relevant considerations and potential options. Opinions have been offered passionately at times, but the overall effect has been positive.

As you are well aware from your extensive involvement in the open source community, reaching consensus is not always easy. Strongly held and articulated views are commonplace, and in fact necessary to propel an essentially volunteer effort. The wine package in particular has a wide range of users and applicability, so it is to be expected that discussions will often be lengthy, heated, or even tedious at times. This thread in particular is typical in that everyone has the interests of the project at heart and is trying to build a world-class product for all.

Your input has been especially helpful, in my opinion. Although I do not agree with everything you say, your input is advancing the discussion and I personally appreciate your participation. However, you must decide for yourself what your priorities are and whether you have the time or inclination to participate. If you decide to withdraw from the conversation, you will be missed, but it's entirely up to you.

You have several options on how to minimize the email from the discussion. One is to set up a filter on your email client that moves everything containing "[Bug 84958]" to the trash bin or elsewhere. Another is to direct launchpad to send your email to a separate email address for that purpose. Still another is, as you mentioned, to unsubscribe. However, it is unreasonable to expect the community to "take [it] elsewhere" because you have tired of the discussion.

I hope to read more from you on this and other threads.

Happy trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

You are right dankegel. It shouldn't be like this. But it is _on topic_. The clutter of the wine-desktop-links is what this bug is about. I guess most developpers won't have the patience of jhansonxi to argue and would just put the bug on 'wont fix'. You don't have to unsubscribe. This is my last comment on this bug-report.

I've tried making a case for a clean menu. But i never actually get the feeling my argument got accross. I keep getting technical explenations of stuff I already understand. Which to me seems completely irrelevant.

Steps to reproduce:
 - install wine
 - installing firefox, java and windows-media-player on wine.
 - you end up with a [firefox launcher, a java configuration tool, a java update tool] in the wine menu
 - in the system -> confiugration menu you end up with a [a wine configuration tool, java configuration tool]
 - you already had a firefox link in the internet menu

Now ask this theoretical user the following questions:
  - which java configuration tools configures which java and affects which browsers?
  - what is the difference between the two firefoxes?
  - why does a .wmv correctly open in applications -> tools -> Wine File Browser?
  - why does the same .wmv not correctly open when you open it from your home-folder?
  - if you go to applications -> system -> software uninstaller .. which of the two firefoxes do you uninstall?
  - if you go to applications -> add/remove .. which of the two firefoxes do you uninstall?

Would the user be less confused if all wine stuff was in the same menu? I think so.
And if you do not, you are free to just put it on 'wont fix'.

But please don't come with techincal reasons, analogies with java or how wine is just a document-viewer.
You also don't have to educate me about the technical details. I am quite aware of why it is, like it is. (I work as linux system administrator, and install ubuntu on about 30+ different workplaces of about 5 different clients of mine, not counting the servers).

[Loye Young (loyeyoung)]

Scott,

I suspect that no perfect solution exists but that everyone is ready to move on. I for one would be willing to go with any sane approach, understanding that trade-offs must be made. Would you be willing to suggest a solution, mindful of the discussion?

Thanks,

Loye

[Dan Kegel (dank)]

Hi Ralf,
your message just now was very good, actually.

On 9/14/07, Ralf Nieuwenhuijsen <email address hidden> wrote:
> You are right dankegel. It shouldn't be like this. But it is _on topic_.
> The clutter of the wine-desktop-links is what this bug is about. I guess
> most developpers won't have the patience of jhansonxi to argue and would
> just put the bug on 'wont fix'. You don't have to unsubscribe. This is
> my last comment on this bug-report.
>
> I've tried making a case for a clean menu. But i never actually get the
> feeling my argument got accross. I keep getting technical explenations
> of stuff I already understand. Which to me seems completely irrelevant.
>
> Steps to reproduce:
> - install wine
> - installing firefox, java and windows-media-player on wine.
> - you end up with a [firefox launcher, a java configuration tool, a java update tool] in the wine menu
> - in the system -> confiugration menu you end up with a [a wine configuration tool, java configuration tool]
> - you already had a firefox link in the internet menu
>
> Now ask this theoretical user the following questions:
> - which java configuration tools configures which java and affects which browsers?
> - what is the difference between the two firefoxes?
> - why does a .wmv correctly open in applications -> tools -> Wine File Browser?
> - why does the same .wmv not correctly open when you open it from your home-folder?
> - if you go to applications -> system -> software uninstaller .. which of the two firefoxes do you uninstall?
> - if you go to applications -> add/remove .. which of the two firefoxes do you uninstall?
>
> Would the user be less confused if all wine stuff was in the same menu? I think so.
> And if you do not, you are free to just put it on 'wont fix'.
>
> But please don't come with techincal reasons, analogies with java or how wine is just a document-viewer.
> You also don't have to educate me about the technical details. I am quite aware of why it is, like it is. (I work as linux system administrator, and install ubuntu on about 30+ different workplaces of about 5 different clients of mine, not counting the servers).
>
> --
> Consider hiding menu entries
> https://bugs.launchpad.net/bugs/84958
> You received this bug notification because you are a member of Ubuntu
> Wine Team, which is a bug assignee.
>

--
Wine for Windows ISVs: http://kegel.com/wine/isv

[jhansonxi (jhansonxi)]

@Ralf Nieuwenhuijsen

"I guess most developpers won't have the patience of jhansonxi to argue and would just put the bug on 'wont fix'."

I'm not a developer. I just posted the *.desktop files I created for my users and posted them here. The MOTU team decided they were worth adding.

"I've tried making a case for a clean menu. But i never actually get the feeling my argument got accross. I keep getting technical explenations of stuff I already understand. Which to me seems completely irrelevant."

You keep posting irrelevant comparisons to scenarios which almost never occur in practice. The following is a perfect example:

" - installing firefox, java and windows-media-player on wine.
 - you end up with a [firefox launcher, a java configuration tool, a java update tool] in the wine menu
 - in the system -> confiugration menu you end up with a [a wine configuration tool, java configuration tool]
 - you already had a firefox link in the internet menu"

Since when would any Linux user do this if native versions of the same apps are already available? Wouldn't it be easier to just install Windows?

"Now ask this theoretical user the following questions:
  - which java configuration tools configures which java and affects which browsers?"
  - what is the difference between the two firefoxes?
  - why does a .wmv correctly open in applications -> tools -> Wine File Browser?
  - why does the same .wmv not correctly open when you open it from your home-folder?
  - if you go to applications -> system -> software uninstaller .. which of the two firefoxes do you uninstall?
  - if you go to applications -> add/remove .. which of the two firefoxes do you uninstall?"

If a user chooses to complicate their life by installing redundant applications then whose problem is that?

"But please don't come with techincal reasons, analogies with java or how wine is just a document-viewer."

These are prefect examples of how menu items alone do not dictate a user's pattern of usage with an application. You keep trying to box them into specific categories but it's not possible.

"You also don't have to educate me about the technical details. I am quite aware of why it is, like it is. (I work as linux system administrator, and install ubuntu on about 30+ different workplaces of about 5 different clients of mine, not counting the servers)."

Your technical background is irrelevant. Your argument needs to stand on it's own merits. I don't care if you are the Pope.

My user's aren't going to care if the menu items are combined in a Wine sub-menu or not. They proven to not be that stupid. Some better desktop integration is desirable and we've come up with a few here. Probably need to submit a few more bug/feature requests and try to get the MOTU and Wine teams to implement them.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

"You keep posting irrelevant comparisons to scenarios ..."

A comparison to a scenario? What would such a thing be anyway?

".. which almost never occur in practice. "

Well, a google image search returns about 82,000 hits.
It was very common practise just a year ago, when the flash player for linux was still incompatible with version 7.
It was the suggested solution in both the Ubuntu Forums, Wiki as well as the Ubuntu Guide.
Guess my definition of "never occurs in practise" is different..

"The following is a perfect example:"

Well, this example was a REAL-LIFE example. Not some theoretical thingie.
If you run Firefox on wine, you can run Windows Media Player-plugin (together with Java and the most recent flash-player).

Some sites, such as my local country's public broadcasting system works quirky or not at all with totem-plugin or mplayer-plugin. So there is a real use-case for dutch people to actually install firefox on wine + windows-media-player to play those files.

Guess, you are very familiar with all 2 million Ubuntu users and their practises.
Never occured to you that it maybe your small world isn't a good sample to base your generalisations on?

"Wouldn't it be easier to just install Windows?"

This goes nice with your own previous "why don't you create your own distro" response.

And for records: installing windows is definately not easier, nor cheaper.

"If a user chooses to complicate their life by installing redundant applications then whose problem is that?"

There is nothing redunant about that situation. Unless you suggest that the user un-installs the native firefox, and use the windows one for all sites that do not require windows-media-player as well?

"These are prefect examples of how menu items alone do not dictate a user's pattern of usage with an application. You keep trying to box them into specific categories but it's not possible."

I'lll try to reponse, but i'm not exactly sure what hell you are saying here.
But even if only a couple of users will run into these problems, it doesn't make the problems any less valid.

"Your technical background is irrelevant. Your argument needs to stand on it's own merits. I don't care if you are the Pope."

The reason, after all these comments, i felt obliged to point this out, was that instead of responding to my arguments, you tried to educate me in the most simple stuff possible. About where the desktop-files are located, why windows programs end up in the wine menu, etc. It was just plain offensive assuming I was _that_ ignorant.
I couldn't think of a more polite way to point that out.

Interesting choice of you to take this as the possibility to get more offensive towards me.

"My user's aren't going to care if the menu items are combined in a Wine sub-menu or not. They proven to not be that stupid. "

Well, mine are going to care.
And users are never stupid.

I can walk with my hands tied behind my back. Doesn't make it a good idea, now does it?

[Scott Ritchie (scottritchie)]

I completely redid the desktop entries for the Gutsy Wine package. Now we have just 4: winecfg, uninstaller, and browse ~/.wine/drive_c in the Wine directory, as well as notepad in Programs->Accessories.

Notepad isn't really there to be run, more as a hint about where Windows programs will be placed. We may want to replace it with Wine's built in wordpad as well, as that may have some actual use. Additionally, browsing the Wine C:\ Drive should probably be under places rather than in the Wine folder, but I couldn't figure out how to add a Places entry in time.

[jhansonxi (jhansonxi)]

I don't have a problem with the change but I will still need to add regedit for my users. I haven't tried the new package on Gnome yet, just with XFCE and KDE. I like the new icons.

KDE:
The icons are not displaying. I changed the desktop files to point to the full svg file name but it didn't correct the problem.
KDE already includes a Wine configuration app in System Settings > Advanced > Windows Applications that is equivalent to winecfg if not superior.
The menu entries for a Windows app I installed were correctly merged into the Wine submenu.

XFCE:
Icons displayed correctly.
Notepad is in a separate submenu "Other" instead of in the Wine submenu. A Windows app I installed also ended up there.

Obviously this is not going to solve Ralf's complaint about the duplication of menu entries for Firefox, java, etc. if both native and Windows versions are installed.

It's possible to hide entries using Gnome's menu editor but the KDE and XFCE editors can only delete them. Earlier, I encountered problems with Gnome's editor in that manipulating the Wine submenu would cause it's name to change to something else (I can't remember) but installing another Windows app would cause Wine to fix it. I haven't had time to isolate the problem further and report a bug.

[Scott Ritchie (scottritchie)]

Can KDE even display .SVG files as icons, or does it require .png?

[jhansonxi (jhansonxi)]

I don't use it much so I don't know. There are very few svg files in pixmaps however. I did find this patch so it should be supported:
http://lists.kde.org/?l=kde-core-devel&m=101387014116280&w=2

Maybe a bug?

[Loye Young (loyeyoung)]

On Friday, October 12, 2007 6:13:14 pm Scott Ritchie wrote:
> Can KDE even display .SVG files as icons, or does it require .png?

yes

[Loye Young (loyeyoung)]

On Friday, October 12, 2007 6:13:14 pm Scott Ritchie wrote:
> Can KDE even display .SVG files as icons, or does it require .png?

yes, it can show both.

[jhansonxi (jhansonxi)]

The wine.desktop file doesn't indicate an icon. The effect is that the icon is missing in the Nautilus "Open with Other Application" list.