Bug 53476

Summary: Changes made with kmenuedit produce indeterminate results
Product: [Applications] kmenuedit Reporter: Peter <peter>
Component: generalAssignee: Unassigned bugs mailing-list <unassigned-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: bwkemps
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Peter 2003-01-27 11:52:38 UTC
Version:            (using KDE KDE 3.0.99)
Installed from:    Debian stable Packages
OS:          Linux

It's a key featue of usability to give users the ability to customize the main menu, and it's great to see KDE is putting devoting code to this. 

The user interface in kmenuedit is extremely well done, with several very elegant features, such as the ability to move an item below rather than into a folder by giving it a little nudge to the left. The shortcut (keybindings) feature is elegant, although I would have preferred to have this located (also) under the icon itself. However, the current version (0.4) unfortunately produces results that are so erratic as to be close to unusable in practice.

1. Editing changes can be made and apparently be accepted, but next time you open the menu they are gone in part or in whole in a manner that seems random to the user:
 	* Folders that were renamed appear under their old name
 	* Folders that were moved appear in their old position
	* Folders that were deleted appear undeleted
	* Applications that were moved reappear under their old folders
	* Applications that were deleted reappear undeleted

I emphasize that this does not happen with a reliable consistency; sometimes changes are kept.

2. Making many menu choices can keep KDE from loading. 

On one occasion I made a large number of changes with kmenuedit and the program stopped responding. After going to init 1, KDE failed to restart. I discovered ~/.kde/share/thumbnails had several hundred temporary files; after deleting them, KDE loaded.

2. The menu choice "Show hidden items" is counterintuitive and produces erratic results. Items that were requested to be deleted appear as hidden, and renamed items appear under their old name as hidden. After exiting from a "show hidden items" session, numerous errors were introduced:
	* Renamed folders disappeared
	* Moved applications vanished

I hope these problems will be taken seriously and looked into carefully before 3.1 is finally released. kmenuedit is potentially a killer app that will help bring KDE into the league of WinXP and OSX, but it needs to produce the results it promises to give the user!

I very much appreciate the work you guys are doing on this.

Cheers,
Peter
Comment 1 Koen Vossen 2003-05-12 20:19:50 UTC
I'm running Debian Unstable (KDE 3.1.1). 
I have experienced the same bugs in KMenuEdit and fully confirm the issues mentioned in the 
previous post. 
 
 
Comment 2 Shane Richards 2003-07-09 07:18:46 UTC
Running Mandrake 9.x, KDE from CVS since 3.1.1  
I have also experienced these problems (from CVS builds), recently did a clean reinstall frm 
CVS-20030628 and found the following: 
 
'Graphics' and 'Multimedia'  sections did not initially appear in the menu, to be honest, I'm not 
sure exactly what I did or did not do to fix this, as some times menu changes may not appear 
for minutes at a time. Note this was a totally fresh build/install. 
 
Using kmenuedit leaves some strange directories/files: 
  
after creating a new subsection: 
~/.local/share/desktop-directories/foo.desktop  (whereas my prefix =  '~/.kde') 
 
after creating an app link: 
~/.kde/applnk/usr/share/applnk/<section name>/<app name.desktop>  
 
There seems to be no reliable way of determining the outcome, however. Sometimes files will 
be saved, sometimes not. Reediting a destop entry (even in konqueror using 'properties') does 
not always save the changes. 
 
The 2 reliable methods of creating changes are:  
 
1. create your foo.desktop file in <prefix>/apps/kappfinder/apps and run kappfinder. 
 
2. create foo.desktop, edit in kvim, save in the 'applnk' tree.  
For folders, have to create folder in 'applnk' tree, and manually create a corresponding entry in 
'desktop-directories' folder. 
 
Possibly related: when editng file associations, duplicate entries show up in the 'applications' 
folder every time you add a program to the list. ie: select textfile,edit file type,add new editor. 
Now write,kedit,kate,kvim etc. will all have two entries in the right-click menu. 
Comment 3 Tim Hartung 2003-07-13 19:24:30 UTC
> ...will all have two entries in the right-click menu. 

And next time you log in, the new entries are gone completely!

(Running Mandrake 9.1, KDE 3.1.0 from Distribution)
Comment 4 Brian Rectanus 2003-07-20 08:31:08 UTC
Confirmed for Debian (testing and unstable) for CVS version.  See also bug 54919
which deals with menu items being out of order (alpha sorted, but not until a
restart).
Comment 5 Unknown 2003-10-01 13:09:00 UTC
I concur using CVS HEAD.  Also as a suggestion, it would be nice to have an APPLY 
and RESET button to undo changes that may have been made for an item so that a 
single change can be undone without losing the rest. 
 
I have found that the problem changes came from non-KDE apps added, such as 
evolution or gaim that are located in non-standard places.  I have also found that 
icons inserted from non-standard locations also do not stick with regularity. 
 
Best wishes 
Comment 6 Antonis Zafiropoulos 2003-11-17 16:58:20 UTC
Same as above applies to distribution SUSE 9, running KDE 3.1.4
Comment 7 Shane Richards 2003-11-20 15:59:31 UTC
I have to say that as of recent CVS builds (last month or so), the problems I reported in comment #2 seem to have been resolved. And the last CVS upgrade for me, my menu was even preserved.

Thankyou.
Comment 8 Robert Cole 2004-01-08 05:47:26 UTC
I'm having the exact same sort of problems. For example with Gimp the icon isn't there for the app. I use kmenuedit to add the gimp icon and it doesn't take.

Gentoo 1.4 KDE 3.2.0 beta 2
Comment 9 Kurt Merhoff 2004-01-30 19:30:26 UTC
In attempting to edit my K menu with kmenuedit I got unpredictable and quite awful results. I wanted to create a 'Favorites' submenue and copy frequently used applications and other submenues into it. I was able to create the 'Favorites' submenu but when attempting to copy other K menu submenus into it they would sometimes move rather than copy and when trying to copy or move them back they would disappear completely.

I have not been able to find suitable documentation on how the KDE menu system works to be able to fix this problem manually. Until this is fixed please post an easy to find howto for repairing and/or manually setting K menu selections.

(I'm running a Debian unstable w/ KDE 3.1.4)
Comment 10 Gerhard Heeke 2004-02-26 15:46:50 UTC
Same here with KDE 3.2 and Debian stable. KMenuedit produces unpredictable results. Sometimes menuitems just vanish.
Comment 11 meldroc 2004-02-27 07:48:52 UTC
I'm getting similar problems, using KDE 3.2.0.  Most of the time when I use kmenuedit to create new entries, or change things like icons in entries, when I save, close, and check in the K menu, the changes aren't there.  Kmenuedit is almost useless with this problem.

I'm guessing this has something to do with the files in .config and .local

As far as I'm concerned, just doing the changes by making .desktop files in .kde/share/applnk is preferred, on account of it actually works.
Comment 12 kdozer 2004-03-20 06:47:16 UTC
I also see this problem in KDE 3.2.0 

(debian stable packages from http://download.kde.org)

No changes made using kmenuedit are saved to $KDEHOME. 
Comment 13 kdozer 2004-03-24 03:44:10 UTC
I just noticed, the problem occurs when I try to change a menu entry coming from

$KDEHOME/share/applnk/SubMenu/appname.desktop

The changes are saved in 

$XDGDATA-APPS/kde-appname.desktop
(where XDGDATA-APPS==$HOME/.local/applications)

however, no change is made to 

$XDGCONF-MENU/applications-kmenuedit.menu
(where XDGCONF-MENU==$HOME/.config/menus)

so the menu entry still points to the unchanged
$KDEHOME/share/applnk/SubMenu/appname.desktop

and the change is ignored, both in kmenuedit and when I click on the menu entry.

Suggested fix:

When a change is made to a menuentry in $KDEHOME/share/applnk, either

1. Update that desktop file directly (old behaviour, pre-XDG), 

or

2. Mark that entry as hidden, save changes to $XDGDATA-APPS and add an entry to $XDGCONF-MENU/applications-kmenuedit.menu.

Note: the reason I have files in $KDEHOME/share/applnk, despite having a clean $KDEHOME for KDE 3.2 is due to kappfinder storing desktop files in the historic location (see Bug #78348)

thanks!

John.
Comment 14 Waldo Bastian 2004-05-04 16:02:40 UTC
#13 is fixed in KDE 3.2.2

I'm closing this bugreport. If you encounter specific problems with kmenuedit in KDE 3.2.2 or CVS HEAD, please file a new bugreport.

Comment 15 Waldo Bastian 2004-05-04 17:24:44 UTC
*** Bug has been marked as fixed ***.
Comment 16 Bart W. Kemps 2004-07-12 01:01:48 UTC
I encountered the same problem on KDE 3.2.2-6 Red Hat (Fedora Core 2).

* Items don't move from one menu to another
* Items cannot be deleted
* Copied items appear in their original menu, instead of the place they are copied to
* The copied items also cannot be deleted

(When I manually delete the .desktop-items from ~/.local/share/applications they DO dissapear. I haven't figured out yet how to manually edit the KDE-menus.)
Comment 17 Marcus Uddenhed 2005-08-05 14:51:42 UTC
I have somewhat problems editing menus if i do 1 changes from default
layout it move every menu that resides under KDE Program up to the same level
as KDE Programs folder in menu and when i start to move back the menus to where
they suppose to be it either moves it as it should or creates new menus with
same name as old with a prefix of a number added without moving the menu.

This is my system below:

KDE Version  0.7 (KDE 3.4.1, compiled sources)
Application  KDE Menu Editor
Operating System  PC-BSD 0.7.8 built upon FreeBSD (i386) release 5.4-RELEASE
Compiler  gcc version 3.4.2 [FreeBSD] 20040728

Would preciate every help i can get.

Regards

Marcus
Comment 18 jerome 2005-08-11 00:58:50 UTC
I have this problem with a persistent "Spreadsheets (KOffice Spreadsheet Component)", on a fresh upgrade to KDE 3.4.2 for Fedora Core 3. It's aproblem leftover from 3.4.1. KMenuEdit accepts the request to delete, but never saves the change. Deleting the associated .desktop file deletes the item from the menu, though I haven't rebooted yet to test whether this sticks.