Version: 0.7 (kde 3.4.1) (using KDE KDE 3.4.1) Installed from: Debian testing/unstable Packages OS: Linux This bug needs a new severity rating as it doesn't cause crashes but renders the desktop virtually unusable. Here's the problem: 1) Older KMenuEdit merely made menu items invisible when they were 'deleted' 2) Items could be restored by making them visible again 3) Current KMenuEdit permanently forgets the items, without any warning or undo ability. Not like menus are important or anything... that's why we have xterm. 4) Even "rm -rf ~/.{kde,local,kderc}", running all the tools to build/update the menu, copying the contents of these folders from another home, etc. etc. etc. cannot get back the menus, however one can become intimately acquainted with the first-run wizard in the trying. 5) "rm -rf /home/user" does work, oddly, but is hardly elegant. I'd like to have KMenuEdit's old (safe) behaviour back, or possibly have it display 2 menus, each in their own pane: the "default" which cannot be edited, and the "user" which can have items deleted, renamed, inserted, and hopefully dragged and dropped from "default". Failing that, an item under the "File" menu: "Revert to default".
> 1) Older KMenuEdit merely made menu items invisible when they were 'deleted' > 2) Items could be restored by making them visible again > 3) Current KMenuEdit permanently forgets the items, without any warning or undo ability. > Not like menus are important or anything... that's why we have xterm. Not to mention that KMenuEdit is messing up ~/.config/menus/applications-kmenuedit.menu (that's where the menu is stored) after time, even when just moving some entries forth and back. It is _not nice_ how every action is adding a few lines to the file and there is no way to clean it up except by editing the file manually. I even had my KMenu hiding some entries that should have been there (and were in the file), and I believe this was because of the ever-increasing complexity of the applications-kmenuedit.menu. Really, I think there should only be one <Deleted> tag for one entry.
Vote for that -- pretty much behaviour like in toolbar editors, you can delete the item, but it is not deletion per se, but removal from the toolbar set.
The 'Restore to System Menu' command helps a bit by reverting _all_ user changes. But a real Undo framework would be nice to have.
*** Bug 136860 has been marked as a duplicate of this bug. ***
As well as accessing 'deleted' system-defined folders, it should be possible to access user application entries (.desktop files) that are not in any menu instead of having to delete them. I don't believe that they should be deleted from .local/share/applications by removing them from the menu, but perhaps the 'New Item' process could be decoupled from adding them to menus so that removing them from menus does not create the expectation that they be deleted. See 136860 for background.