Summary: | Changes made with kmenuedit produce indeterminate results | ||
---|---|---|---|
Product: | [Applications] kmenuedit | Reporter: | Peter <peter> |
Component: | general | Assignee: | 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
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. 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. > ...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)
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). 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 Same as above applies to distribution SUSE 9, running KDE 3.1.4 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. 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 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) Same here with KDE 3.2 and Debian stable. KMenuedit produces unpredictable results. Sometimes menuitems just vanish. 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. 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. 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. #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. *** Bug has been marked as fixed ***. 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.) 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 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. |