Is is possible to re-create the system menu back to it's initial post-install state?

OS is Slackware

Thanks

PS the reason I ask is that the entire "Graphics" section has disappeared for some reason.

see "kbuildsycoca4 --help", run (likely) "kbuildsycoca4 --noincremental"
But a disappearing group usually just means that you uninstalled all applications out of that group.

thanks for the reply. I definitely haven't uninstalled everything from that selection, I still have GIMP installed, and I only noticed that it had disappeared when I compiled and installed digikam.

"kbuildsycoca4 --noincremental" spits out loads of stuff - much of which looks like errors of some sort:

(sample)

Code: Select all

kbuildsycoca4(2794) KConfigGroup::readXdgListEntry: List entry Keywords in "k3bsetup.desktop" is not compliant with XDG standard (missing trailing semicolon).
kbuildsycoca4(2794) VFolderMenu::mergeFile: VFolderMenu::mergeFile: "/home/tappy/.config/menus/applications-kmenuedit.menu"
kbuildsycoca4(2794) foldNode: "Move" and "Education/Graphics" requires combining!
<snip>
kbuildsycoca4(2794) VFolderMenu::processMenu: Menu "Tools" does not specify a directory file.
kbuildsycoca4(2794) VFolderMenu::processMenu: Menu "Graphics" does not specify a directory file.
kbuildsycoca4(2794) VFolderMenu::processMenu: Menu "More" does not specify a directory file.
kbuildsycoca4(2794) VFolderMenu::processMenu: Menu "Terminal" does not specify a directory file.
kbuildsycoca4(2794) VFolderMenu::processMenu: Menu ".hidden" does not specify a directory file.
<snip>
kbuildsycoca4(2794) VFolderMenu::processMenu: Moving "Applications/Graphics" to "Education/Graphics"                                                           
kbuildsycoca4(2794) VFolderMenu::processMenu: Moving "Graphics-2" to "Education/Graphics"                                                                     
kbuildsycoca4(2794) VFolderMenu::processMenu: Moving "Education/Graphics" to "Development/Graphics"                                                           
kbuildsycoca4(2794) VFolderMenu::processMenu: Moving "Development/Graphics" to "Graphics-2"
<snip>
kbuildsycoca4(2794) KBuildServiceFactory::populateServiceTypes: "/home/tappy/.local/share/applications/gimp.desktop" specifies undefined mimetype/servicetype "image/x-gimp-gih"
kbuildsycoca4(2794) KBuildServiceFactory::populateServiceTypes: "/home/tappy/.local/share/applications/gimp.desktop" specifies undefined mimetype/servicetype "image/x-psp"


kbuildsycoca4(2794) VFolderMenu::mergeFile: VFolderMenu::mergeFile: "/home/tappy/.config/menus/applications-kmenuedit.menu"

This seems to cause some errors - it's the edited config through kmenuedit.
Move the file out of the way

Code: Select all

mv "/home/tappy/.config/menus/applications-kmenuedit.menu" "/home/tappy/.config/menus_applications-kmenuedit.menu"

and run "kbuildsycoca4 --noincremental" again, see what happens.

Worked a treat. Thanks!

How would I do this on Kubuntu? I've tried running kbuildyscoca4 --noincremental (including as root) and it doesn't seem to work.

Is there any documentation on all the files that I see? I'm looking mainly in usr/share and there are literally 221 folders in that folder. That's what is so frustraing about Linux: information overload without much of a guide as to where everything is placed and why. I did find http://docs.kde.org/stable/en/kde-workspace/kmenuedit/ but it doesn't get into the backend at all.

I'd like to have the option to restore the default. In general, I always like to have a way to go back from a customization. This should probably be a button in Kmenuedit (as well as saving customizations).

UPDATE: OK, I found the hidden .config file in my home folder and deleted it, then did the noincremental build and it worked. But I really think this needs to be documented somewhere. Restoring the default is a very basic thing and it should be documented somewhere where people are likely to look.

Unfortunately the procedure for correcting problems such as this one is not always as simple as removing a single file as the problem could also lie in many other areas - and the wrong removal could remove user customisations which they would then have to do again.

Due to the large number of KDE applications and way they are configured, it is simply not feasible to document individually the various files to remove to reset various settings back to defaults.

What would be great, IMO, would be for the 'local' (i.e., user) menu config to be simply an inherited, "non-connected" copy of the system config, created at the time of the user account creation. Thereafter, all changes to that user's menus would be done to that copy only and would be unaffected by upstream changes to the system. A means of selectively reviewing and (with user approval) accepting future system changes/additions could be available for software that was installed or removed later. But it would be at the user account's discretion to inherit (or not) such changes. That way, a backup copy of the local config could be made at any time, one that could be applied later to totally undo any changes. In fact, a simple nested directory structure as used by another unnamed OS would be perfectly sufficient and easy to manage, IMO.

I just ran into a similar issue as described above. I had edited the applications menu using KMenuEdit. I later logged back in, but this time to Xfce. I opened Alacarte (and later MenuLibre) in an attempt to track down some spurious entries that were now showing up in the Xfce menu. I made no changes, but the next time I logged into KDE, my menu bore no resemblance to the way in which I had last left it. Apparently it was due to some kind of interaction between the three menu tools, two desktops and the system bridging between them, I guess. If both desktops had isolated local menus, that would not have happened. I renamed applications-kmenuedit.menu and xfce-applications.menu (both in ~/.config/menus/), logged into each desktop and simply accessed the menu. Back in KDE, I then renamed applications-kmenuedit.menu back and now KMenuEdit at least now reflects what's actually on the menu.

I think.

Which brings up the question: Is there any way to protect the account-level menu from being polluted by system-level changes? I'm guessing they come from (among other places?) the *.desktop files in /usr/share/applications and below.

Thanks.

lphilpot wrote:What would be great, IMO, would be for the 'local' (i.e., user) menu config to be simply an inherited, "non-connected" copy of the system config, created at the time of the user account creation. Thereafter, all changes to that user's menus would be done to that copy only and would be unaffected by upstream changes to the system.

And then users would complain that they just installed application xyz and it doesn't appear in the menu.
Or even worse, a program gets uninstalled but would still show up in the menu. User would complain he/she can't start program xyz anymore.

Don't forget that KDE is also used on single user desktop systems.

Changes done with kmenuedit are local to the user. They are saved in ~/.config/menus, .local/share/desktop-directories/ and ~/local/share/applications/.
That's according to freedesktop.org, btw.

Which brings up the question: Is there any way to protect the account-level menu from being polluted by system-level changes? I'm guessing they come from (among other places?) the *.desktop files in /usr/share/applications and below.

Yes, by creating a file in ~/.config/menus. You can create you own menu structure there. Applications/submenus outside of this structure are not shown, if there's no explicit Merge statement. Detailed informations can be found here: http://standards.freedesktop.org/menu-spec/latest/

wolfi323 wrote:And then users would complain that they just installed application xyz and it doesn't appear in the menu.
Or even worse, a program gets uninstalled but would still show up in the menu. User would complain he/she can't start program xyz anymore.

I understand what you're saying, but It's easy enough to clean up old shortcuts, nonetheless.

Don't forget that KDE is also used on single user desktop systems.

As it is right here.

Yes, by creating a file in ~/.config/menus. You can create you own menu structure there. Applications/submenus outside of this structure are not shown, if there's no explicit Merge statement. Detailed informations can be found here: http://standards.freedesktop.org/menu-spec/latest/

Thanks for the reference.

The sharing of the menus between Xfce and KDE is intended, per the XDG specification published on freedesktop.org
Given that both menu editors work in different ways, i'm not surprised that it did not work properly however.