Hi,
I have noticed that when wine creates a menu item (that for example, on Ubuntu gets put in the Applications > Wine > Programs menu), the command that gets written uses 'wine' as the program to run. This means that you need to have Wine in your PATH and cannot use more than one version of Wine. For example, if I wanted to use /opt/wine-1.0, /opt/crossover and /opt/wine for different applications I cannot access these correctly from the menu items created. Additionally, the user experience (yes, I have been watching Owen's Google talk :)) is that the application does not start (especially if the only version of Wine is not on the PATH).
The solution to this is to add the full path to wine, e.g. '/opt/wine-1.0/bin/wine' when generating the menus. Are there any objections to this?
Along similar lines, building on what Owen said in the talk that if all goes well Jane user will not notice that she is using Wine to run her Windows software: why is there an entry in the Applications section that says 'Wine' (and why does it have the folder icon and not the Wine icon)! It would be better if this said something like "Program Files", replacing Wine > Programs -- this removes a level of indirection and gives the user something that they are familiar with and is more discoverable than 'Wine'.
Thoughts?
- Reece
On Sun, Jan 25, 2009 at 3:32 PM, Reece Dunn msclrhd@googlemail.com wrote:
Hi,
I have noticed that when wine creates a menu item (that for example, on Ubuntu gets put in the Applications > Wine > Programs menu), the command that gets written uses 'wine' as the program to run. This means that you need to have Wine in your PATH and cannot use more than one version of Wine. For example, if I wanted to use /opt/wine-1.0, /opt/crossover and /opt/wine for different applications I cannot access these correctly from the menu items created. Additionally, the user experience (yes, I have been watching Owen's Google talk :)) is that the application does not start (especially if the only version of Wine is not on the PATH).
The solution to this is to add the full path to wine, e.g. '/opt/wine-1.0/bin/wine' when generating the menus. Are there any objections to this?
Along similar lines, building on what Owen said in the talk that if all goes well Jane user will not notice that she is using Wine to run her Windows software: why is there an entry in the Applications section that says 'Wine' (and why does it have the folder icon and not the Wine icon)! It would be better if this said something like "Program Files", replacing Wine > Programs -- this removes a level of indirection and gives the user something that they are familiar with and is more discoverable than 'Wine'.
Thoughts?
- Reece
There's actually a bug on this: http://bugs.winehq.org/show_bug.cgi?id=17055
but didn't generate much discussion.
Personally, I like it. -- -Austin
I have noticed that when wine creates a menu item (that for example, on Ubuntu gets put in the Applications > Wine > Programs menu), the command that gets written uses 'wine' as the program to run. This means that you need to have Wine in your PATH and cannot use more than one version of Wine. For example, if I wanted to use /opt/wine-1.0, /opt/crossover and /opt/wine for different applications I cannot access these correctly from the menu items created. Additionally, the user experience (yes, I have been watching Owen's Google talk :)) is that the application does not start (especially if the only version of Wine is not on the PATH).
The solution to this is to add the full path to wine, e.g. '/opt/wine-1.0/bin/wine' when generating the menus. Are there any objections to this?
This would probably seem sensible. It may cause some confusion for users if they do intentionally have multiple versions installed (knowing which items point to which version, etc), but unless one were to come up with some kind of "version switching" app that lets the user choose which version to run with, it would seem like it's the kind of thing we shouldn't be too bothered with.
Along similar lines, building on what Owen said in the talk that if all goes well Jane user will not notice that she is using Wine to run her Windows software: why is there an entry in the Applications section that says 'Wine' (and why does it have the folder icon and not the Wine icon)! It would be better if this said something like "Program Files", replacing Wine > Programs -- this removes a level of indirection and gives the user something that they are familiar with and is more discoverable than 'Wine'.
"Windows software" may be a better term than "Wine". "Program Files" wouldn't really make sense, since all the items in the Applications menu are meant to be program files. On the issue of whether we should keep the "Programs" subfolder, I guess you could transparently redirect things that try to create items there, and it would probably not cause too many problems. The current system though doesn't seem too bad.
On 25.01.2009 22:58, Owen Rudge wrote:
"Windows software" may be a better term than "Wine". "Program Files" wouldn't really make sense, since all the items in the Applications menu are meant to be program files. On the issue of whether we should keep the "Programs" subfolder, I guess you could transparently redirect things that try to create items there, and it would probably not cause too many problems. The current system though doesn't seem too bad.
Also, Windows and Linux desktops have a bit of different "views" on what the "desktop menu" should contain: most of the time, the Windows start menu contains one folder per application, with that folder containing not only the application but also a link to the README or web page, uninstaller etc. In contrast, Linux desktop first sort the items per category (eg Education, Development) and there is one icon per application (no READMEs etc). Now, if the Windows start menu would simply be merged with the desktop menu at the top level, you'd suddenly throw (potentially a lot) application/vendor "categories" into it - arguably with a messy result. Ideally, Windows applications would just show up in the according desktop menu categories - but of course, since this information isn't provided by Windows in any way* you would have to have a database of application-to-category mappings**. So realistically, while not the nicest solution, there probably has to be some "Wine applications" or "Windows applications" (or, if you want to do without Win* entirely, "Other applications" or so).
* - Vista added the Game Explorer, so games could be identified and added to the Games category. ** - This actually sounds like something the "3rd party Wine users" (eg Crossover, Bordeaux, Wine Doors) could implement.
-f.r.
Frank Richter wrote:
Also, Windows and Linux desktops have a bit of different "views" on what the "desktop menu" should contain: most of the time, the Windows start menu contains one folder per application, with that folder containing not only the application but also a link to the README or web page, uninstaller etc. In contrast, Linux desktop first sort the items per category (eg Education, Development) and there is one icon per application (no READMEs etc).
Sure.
At the moment these are located in the "Applications > Wine > Programs
My Game > Game" which is too long. I was just suggesting cutting out
the "Programs" level, so the link would be "Applications > Wine > My Game > Game", reducing the menu by one level. While this still means that Windows applications will put their shortcuts in a sub-folder, it reduces the amount of nested menus involved (especially if there is just going to be a single menu option from Applications > Wine).
- Reece
Reece Dunn msclrhd@googlemail.com writes:
I have noticed that when wine creates a menu item (that for example, on Ubuntu gets put in the Applications > Wine > Programs menu), the command that gets written uses 'wine' as the program to run. This means that you need to have Wine in your PATH and cannot use more than one version of Wine. For example, if I wanted to use /opt/wine-1.0, /opt/crossover and /opt/wine for different applications I cannot access these correctly from the menu items created. Additionally, the user experience (yes, I have been watching Owen's Google talk :)) is that the application does not start (especially if the only version of Wine is not on the PATH).
The solution to this is to add the full path to wine, e.g. '/opt/wine-1.0/bin/wine' when generating the menus. Are there any objections to this?
It seems to me you are just trading one problem for another, now it will break if the wine binary is moved even if it's still in the PATH.
I think this should be handled by the desktop environment; if the app specified in the menu isn't found it should offer a list of alternatives or something along those lines. This is not specific to Wine.
Reece Dunn wrote:
Along similar lines, building on what Owen said in the talk that if all goes well Jane user will not notice that she is using Wine to run her Windows software: why is there an entry in the Applications section that says 'Wine' (and why does it have the folder icon and not the Wine icon)! It would be better if this said something like "Program Files", replacing Wine > Programs -- this removes a level of indirection and gives the user something that they are familiar with and is more discoverable than 'Wine'.
It has the Wine icon on Ubuntu. Currently, it houses the Programs submenu and 3 other menu items (Uninstall Wine Software, Configure Wine, and Browse C:\ Drive). Ideally, we'd get rid of all 3 of these: Uninstall would be integrated into Add/Remove Programs, Configure Wine would be done through system->preferences and by right click->properties on applications, and Browse C:\ Drive would be in the Places menu. Once those are gone, then we can move things "up" one step - instead of Applications->Wine->Programs, we'd just have Applications->Wine Programs.
One open question: what to do with Windows apps that don't put themselves in Program Files, but rather put themselves at the top of the start menu?
Thanks, Scott Ritchie
On 27.01.2009 05:00, Scott Ritchie wrote:
One open question: what to do with Windows apps that don't put themselves in Program Files, but rather put themselves at the top of the start menu?
Desktop menu building could put both 'Program Files' and 'real top-level' entries under the same "Wine Programs" menu.
-f.r.
-
Alexandre Julliard -
Austin English -
Frank Richter -
Owen Rudge -
Reece Dunn -
Scott Ritchie