Alacarte menu changes do not change applications menu item.

I can confirm this bug. Actually, I did not know this was what was happening until I read this bug report and checked those paths.

It is very confusing to change a menu entry, then trying it, nothing happens, then using the menu edito again, copying the string to be executed, running it in a terminal, and it works! "Ehhh. What?"

This should be updated soon - has been a bug for *ages*

Yeah... I am new to Linux but not the computer world. However this is pretty annoying as I have been trying to figure it out on my own and finally resorted to looking for the answer on how to do it just to find out that ITS A BUG... Damn. Oh well. How long do we think this will take to fix. I suppose this doubles as a confirmation as well.

I have seen that this bug goes for all the changed menu entries I have. I though it might be general (affecting *all* parts of the "Programs" menu, including Gnome apps), but after checking, it seems as if it just affects the Wine part of it. Changing any program in the Gnome part will bring up an error dialog when trying to execute.

To replicate this bug, just download any Win32 app, install it, make sure it runs from the menu.
Now use the menu editor and change the entry to execute whatever you want (like "yada yada"). Try it. It will still function.

As mentioned above, each CHANGED menu entry in the Wine part of the menu has two files associated with it in the ~/.local/share/applications/wine/ directory.
Unchanged entries just have one, which makes me believe the fix might be as simple as substituting "-" for "/" in a regexp somewhere.

The other reason can be that file with "-" is meant to be a form of override (for instance to be used when the menus are "global"), but alacarte doesn't take that into account when executing. Just speculations on the logic, of course.

Here's the output of find. The "Check for New Update" entry is the only one that has changes, as you can see.

.local/share/applications/wine
.local/share/applications/wine/Programmer
.local/share/applications/wine/Programmer/FairUse Wizard 2
.local/share/applications/wine/Programmer/FairUse Wizard 2/Check for New Update.desktop
.local/share/applications/wine/Programmer/FairUse Wizard 2/FAQ.desktop
.local/share/applications/wine/Programmer/FairUse Wizard 2/License.desktop
.local/share/applications/wine/Programmer/FairUse Wizard 2/FairUse Wizard 2.desktop
.local/share/applications/wine/Programmer/FairUse Wizard 2/Uninstall FairUse Wizard 2.desktop

.local/share/applications/wine-Programmer-FairUse Wizard 2-Check for New Update.desktop

This bug has been reported 9 months ago, and the bug itself has been around much longer. Why isn't this fixed?

As a problem scenario, I might have installed Xara Xpress 4 through the default wine configuration (~/.wine), and then decided to move this directory afterwards (because I want to keep the installs clean and separate). I place all my different wine installs into /local/apps, i.e. /local/apps/Photoshop, /local/apps/Cæsar3, etc.

The only change I really need to do to make it work, is to update the launcher in the Gnome menu, but as we all know, this does not work! Only one of the two files gets updated, as seen below:

(All files relative to ~/.local/share/applications/)

wine-Programmer-Xara-Xara\ Xtreme\ Pro\ 4\ Trial-Xara\ Xtreme\ Pro\ 4\ Trial.desktop
------------------------------------------------------------
[Desktop Entry]
Name=Xara Xtreme Pro 4 Trial
Exec=env WINEPREFIX="/local/apps/XaraXpress/" wine "C:\\Programfiler\\Xara\\Xara Xtreme Pro 4\\Xtreme.exe"
Type=Application
StartupWMClass=Wine
Path=/local/data/carl-erik/.wine/dosdevices/c:/Programfiler/Xara/Xara Xtreme Pro 4
Icon=29ab_xtreme.0
Name[nb_NO]=Xara Xtreme Pro 4 Trial
Icon[nb_NO]=29ab_xtreme.0
Terminal=false

wine/Programmer/Xara/Xara\ Xtreme\ Pro\ 4\ Trial/Xara\ Xtreme\ Pro\ 4\ Trial.desktop
---------------------------------------------------------------
[Desktop Entry]
Name=Xara Xtreme Pro 4 Trial
Exec=env WINEPREFIX="/local/data/carl-erik/.wine" wine "C:\\Programfiler\\Xara\\Xara Xtreme Pro 4\\Xtreme.exe"
Type=Application
StartupWMClass=Wine
Path=/local/data/carl-erik/.wine/dosdevices/c:/Programfiler/Xara/Xara Xtreme Pro 4
Icon=29ab_xtreme.0

As you can see, only the first file gets the WINEPREFIX changed to /local/apps/XaraXtreme

You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

I have the same situation, if I run wine on command line and install something, it does not reflect on Wine menu on Gnome (Alacarte) so sincerely this is a valid bug.

This bug affects ALL applications installed through wine (ie by running a setup.exe)

Wine creates desktop files like this:

~/.local/share/applications/wine/Programs/Spotify.desktop

These show up in the gnome menu, but if you try to edit them using the menu editor, it resaves them as:

~/.local/share/applications/wine-Programs-Spotify.desktop

But the gnome menu still gives priority to the original file, thus the changes do not actually affect the menu.

Whether this is a bug in the menu editor or wine is debatable. It all depends on whether subdirectories of the applications directory are supports or not.

Reopening on alacarte and adding gnome-main-menu. Regardless of whether wine is at fault for making the desktop files wrong in the first place, the actual issue of not being able to edit shortcuts is caused by inconsistency between these two programs. gnome-main-menu prefers to show the .desktops from the subdirectory, but alacarte only save edits to the flat versions. One of these behaiviours has to be wrong.

Do you really mean gnome-main-menu (the one from Novell with the application browser); or do you mean the standard GNOME menu with Applications,Places,System in gnome-panel?

Oops, I really mean standard one, sorry.

Anyway, here is a one-liner that will fix your gnome menu so you can edit those wine (and possibly other) broken .desktop files. It collapses all the sub-directories, renaming them with the same flat scheme alacarte would use and removing the originals.

find ~/.local/share/applications/ -mindepth 2 -iname '*.desktop' -type f | rename 'my($c) = 0; s{(/)}{ ++$c >= 7 ? "-" : $1 }ige'

Thank you for reporting this issue.

Does this occur in newest WINE?

[Expired for alacarte (Ubuntu) because there has been no activity for 60 days.]

[Expired for gnome-menus (Ubuntu) because there has been no activity for 60 days.]

This bug still affects all the listed programs:

- Wine still creates shortcuts under a folder heirarchy
- Alacarte still copies them to the flat filenames upon editing
- Gnome-menu still gives priority to the original files, not the edited version