Bug 136860

Version:           0.7 (using KDE 3.5.5, Arch Linux)
Compiler:          Target: i686-pc-linux-gnu
OS:                Linux (i686) release 2.6.18-ARCH

The problem described here may be related to the following bug: http://bugs.kde.org/show_bug.cgi?id=107404.

If I have more than one version of a kmenu entry with the same name, then KDE's file associations dialogue doesn't behave correctly when I try to associate a file type with the most version currently shown by the file menu.

Steps to reproduce (part 1):

1. Using kmenuedit, create a KMenu entry for MPlayer using the command line 'mplayer -fs'. It will start MPlayer in full screen mode.

2. Associate MPlayer with .avi files (right-click on .avi, Properties -> Edit File Type -> Add -> Multimedia/MPlayer).

3. Delete MPlayer entry from kmenu with kmenuedit.



Expected behaviour (part 1): MPlayer is removed from kmenu is disassociated from .avi files.



Actual behaviour (part 1): MPlayer is removed from kmenu, but still associated with .avi files. The MPlayer.desktop file is not removed from ~/.local/share/applications.



The problem becomes more confusing if you try to re-add the kmenu entry for MPlayer. Because there is no way to unhide the "deleted" entry using kmenuedit, the only choice is to create a new entry for MPlayer. Since an MPlayer.desktop already exists in ~/.local/share/applications, a file called MPlayer-2.desktop will be created.



Steps to reproduce (part 2):

4. Create a new entry for MPlayer using kmenuedit (since the old entry can't be restored), but use 'mplayer' as the command line (no full screen).

5. Right-click on an .avi, Properties -> Edit File Type -> Add -> Multimedia/MPlayer. Observe that the command line shown when MPlayer is highlighted is the new command line: 'mplayer'.

6. OK out of the file associations dialogue and click on an .avi file.



Expected behaviour (part 2): MPlayer opens in a window (new 'mplayer' command line).



Actual behaviour (part 2): MPlayer opens in full screen mode (old 'mplayer -fs' command line).



The file associations dialogue is preferring the earliest version of the MPlayer entry (MPlayer.desktop) instead of the most recent version (MPlayer-2.desktop).

There is no way to permanently delete or edit the first MPlayer.desktop using kmenuedit. Any changes made with kmenuedit will only affect the most recent version of the MPlayer entry, but the file associations dialogue will only add the earliest version, rendering kmenuedit effectively useless for affecting the MPlayer command line at all.

There actually is a way to edit the earliest version of MPlayer.desktop by using the Edit button in the file associations dialogue, but that seems unnecessarily complicated and decentralised.

Wouldn't it be better for the file associations dialogue to always prefer the most recent version of a menu entry if there's more than one version of an entry with the same name? Should kmenuedit ensure that only one version exists?