Alacarte menu changes do not change applications menu item.

Bug #148565 reported by William F Pearson
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Wine
Confirmed
Undecided
Unassigned
alacarte (Ubuntu)
Confirmed
Low
Unassigned
gnome-menus (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Binary package hint: alacarte

This bug affects both Feisty and Gutsy and is reproducible.

When editing a application launcher that was incorrectly added during a Wine installation alacarte didn't edit both file affected.

This file was correctly changed with alacarte.
.local/share/applications/wine-Programs-MEDITECH-Workstation\ 3.desktop

This file was NOT changed with alacarte.
.local/share/applications/wine/Programs/MEDITECH/Workstation 3.desktop

The second file is the one that appears in "main menu > Applications > Wine > Programs > MEDITECH"

Alacarte should update the new path when the application launcher is edited.

Reproduction.
Install application "wine setup.exe"
Click on menu "Application > Wine > Programs > MEDITECH > Workstation 3"
Error "Path not found"
Open alacarte and correct the the application path.
Click on menu "Application > Wine > Programs > MEDITECH > Workstation 3"
Error "Path not found"
To correct the error, edit the following file with a text editor
.local/share/applications/wine/Programs/MEDITECH/Workstation 3.desktop

Just a note: I believe the application path was incorrectly generated in the first place because it's a legacy 16 bit proprietary telnet client. This app is poorly hacked on Windows. It's not surprising to find problems with it in Ubuntu.

Please advise me if I need to file additional bugs with the wine or gnome teams. I filed this bug because the editing process is handled by alacarte. If I can be of further assistance let me know.

Revision history for this message
Carl-Erik Kopseng (kopseng) wrote : Confirmation. Hugely irritating and confusing

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*

Revision history for this message
Jon Poole (cistech01) wrote :

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.

Revision history for this message
Carl-Erik Kopseng (kopseng) wrote : General bug for the Wine part of the menu

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

Revision history for this message
Carl-Erik Kopseng (kopseng) wrote : This is taking some time...

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

Daniel T Chen (crimsun)
Changed in alacarte:
status: New → Confirmed
Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote :

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.

Changed in alacarte:
status: Confirmed → Incomplete
Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote :

 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!

Changed in alacarte:
status: Incomplete → Invalid
Changed in wine:
status: New → Invalid
Revision history for this message
Abelardo Jara-Berrocal (abelardojarab-gmail) wrote :

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.

Changed in wine:
status: Invalid → Confirmed
Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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.

Changed in alacarte (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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.

Revision history for this message
Julian Andres Klode (juliank) wrote :

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?

Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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'

affects: gnome-main-menu (Ubuntu) → gnome-panel (Ubuntu)
affects: gnome-panel (Ubuntu) → gnome-menus (Ubuntu)
Changed in gnome-menus (Ubuntu):
importance: Undecided → Low
Changed in alacarte (Ubuntu):
importance: Undecided → Low
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for reporting this issue.

Does this occur in newest WINE?

Changed in wine:
status: Confirmed → Incomplete
Changed in alacarte (Ubuntu):
status: Confirmed → Incomplete
Changed in gnome-menus (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in alacarte (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-menus (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

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

Changed in gnome-menus (Ubuntu):
status: Expired → Confirmed
Changed in alacarte (Ubuntu):
status: Expired → Confirmed
Changed in wine:
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.