Bug 273243

Summary: Changes made to Wine menu entries are saved to new .desktop files which don't override the originals, so changes never apply
Product: [Applications] kmenuedit Reporter: JR <zorael>
Component: generalAssignee: Unassigned bugs mailing-list <unassigned-bugs>
Status: CONFIRMED ---    
Severity: normal    
Priority: NOR    
Version: 0.8   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description JR 2011-05-14 03:44:37 UTC
Version:           unspecified (using Devel) 
OS:                Linux

Kubuntu 11.04 running KDE 4.6.3 from Kubuntu ppas. kmenuedit reports version 0.8.

(Please reassign bug if it is more related to the kickoff plasmoid than to kmenuedit.)

Wine program menu entries are defined in .desktop files in ~/.local/share/applications/wine/* subdirectories that mirror the menu hierarchy, which mirrors the Windows behavior.

When altering such menu entries via kmenuedit, the changes are saved into new .desktop files directly in ~/.local/share/applications/, with the originals' subdirectory paths "translated" and incorporated into the new files' filenames. The originals are never touched. For example, changes made to .local/share/applications/wine/Programs/Spotify.desktop become a new file named .local/share/applications/wine-Programs-Spotify.desktop.

The bug is that the new file with its updated/altered contents is not considered (by kickoff) as overriding the old one, so effectively the changes never apply.

Reproducible: Always

Steps to Reproduce:
1. Install Wine
2. Install a Windows program via Wine, such as Spotify
3. Open up kmenuedit and make changes to its menu entry, such as adding a comment (Spotify's entry is placed at Wine > Programs > Spotify by default)
4. Save
5. Open up the applications menu and observe the entry

Actual Results:  
6. Your changes are silently ignored. They were changed to a different .desktop file than the original, and the original's contents take precedence

Expected Results:  
6. The changes should have taken effect and the menu entry should be as you set it up to be

This may be either due to how  kmenuedit deals with subdirectory .desktop files, or how it deals with hierarchy definitions in ~/.config/menus/applications-kmenuedit.menu.