Description of problem: I know it's my fault. I have noticed that when wine.menu file I wrapped up is used, wine submenu is displayed not only in main applications menu, but in administration and server settings ones as well. I have found a (probably) dirty way of fixing this problem. The thing is: does somebody know a better way?
Created attachment 144344 [details] Fixed wine.menu file
Will look into it ... Thanks for reporting.
*** Bug 231701 has been marked as a duplicate of this bug. ***
My bug is a duplicate? But this bug is about the Wine submenu also appearing under other non-Application menus (I don't have that problem). Oh well.
It at least (to my opinion) has the same cause thats why I marked it as a duplicate. I will try to figure out the 'right' way to fix this till next wine release.
Would you please _not_ set priority flags for bugs that are already assigned and acked by the respective owner. Thanks. Here is a little status upgrade on the road to .35: I looked into the issue a bit and the more I look at it this is not a wine bug. Wine uses ~/.wine/drive_c as root for the installed apps. This means everything that is installed and done for wine is user specific which is good. This leads to some problems. Say a user installs a software which creates/adds icons to the start menu. Wine then uses ~/.local/share/ to store these desktop entries (as they are per user). The wine submenu created by the fedora package however is a system directory. I tried with gnome here and gnome at least does not merge stuff from system and .local folders if they have the same name but instead displays two folders, one with the desktop stuff from the package and one from the installed applications. The question is now how to 'fix' this. Actually what is done by at least gnome is somewhat right. If a menu folder exists in both ~/.local and in the system directory and you want to make sure specific entries that exist in both folders don't get overwritten or renamed you have to display both. Here are some ideas on how to solve this: 1) Stick the wine folder from the fedora package back at applications where it came from. Problem with this is that people have to look for the wine tools there. 2) Rename the wine tools folder to 'wine-tools' This way there is no duplicate entry but this imho bloats the main menu for people having wine installed. 3) Do not ship special desktop stuff with the package for the system folder and instead add the wine tools desktop entries on creation of ~/.wine This options would solve the issues with two folders in the main menu and some other thing but usually people do not run wineprefixcreate often and before they do they won't have access to the wine tools from the menu. I personally think what would be best is to kick the wine tools from the main menu and leave them where they came from (1) and also patch wineprefixcreate to add them to the stuff in ~/.local (3). If nobody objects I will prepare a patch and push .35 tomorrow...
After not being happy with these solutions I took the time to read the desktop menu specification. They have a whole section about merging menues. I already played around a bit with it today and I hope that I will be able to fix this issue in a nice way so I will hold of .35 till tomorrow. If somebody with experience wants to help me just let me know...
This list should offer help http://lists.freedesktop.org/archives/xdg/ It would be best to fix this in the nice way (merged), even if it takes longer
Should be fixed in the next release (Please check wine-0_9_38-2_fc7 and wine-0_9_38-2_fc8). To fix problems for your current menu run /usr/bin/wineshelllink-fedora. Subsequent additions from wine should then automatically be right.
wine-0.9.38-2.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
Looking great now, thanks Andreas!