Bugzilla – Bug 340343
Sabayon: Unable to save SLAB\Main Menu and Application browser settings
Last modified: 2011-04-04 03:15:04 UTC
Sabayon seems to not have any control over what can or cannot be presented on the main menu or the application browser.
Some possibly relevant gconf keys are under /desktop/gnome/applications/main-menu. Those should work, but they're probably not as discoverable as they would be if they were in the GUI. It would probably help to make it explicitly clear what exactly you want to be able to do, especially if the lockdown features already in gconf aren't sufficient.
I am unable to save any changes to the "SLAB" or Application browser. When I run a sabayon session and > run more applications>Utilities>main menu. I can edit the "main menu" and "more applications" content and when I view these changes by re-opening the more applications screen again the changes are there. If I change the contents of the "favorites" on the SLAB and reopen the SLAB these changes are there. When I save this view and then logout out of the sabayon session and reopen the session the changes are all gone.
Changing to component GNOME. Sorry for the spam.
This is currently not working in SLED 10 SP2, either. Sabayon is not tracking any changes made to the slab so even if you try to customize it by adding/removing items from the gnome slab, sabayon never notices (and the changes are never saved as a result).
How do we provide desktop configuration in this manner then?
It looks like the slab is populated by entries in ~/.local/share/gnome-main-menu/applications.xbel instead of gconf entries. I'm not sure when this changed but gconf seems like a much more suitable backend for storing gnome configuration information.
can this be fixed soon? it is a goal of the education project to predefine several desktops for certain age groups so that only appropriate software is available.
Hmmm, the profile zipfiles should have an entry for ~/.local/share/gnome-main-meu/applications.xbel. Could you please check if this is the case? We definitely don't ignore the .local hierarchy, so I wonder what's wrong there.
In SLED 10 SP2, if I open up a terminal and manually cp /path/to/good/applications.xbel ~/.local/share/gnome-main-meu/applications.xbel (after doing an su to root for permissions reasons), sabayon will track it and add it to the profile. If I just modify the slab entries like I normally would (drag and drop launchers onto it, right-click in the application browser, etc...) it never gets tracked. I'll try to do some testing in OpenSUSE 11 to see if the behavior is the same.
Will there be any resolution to this soon? It would be extremely nice to market openSUSE as having "parental" controls.
The version with which you had the bug is now obsolete. I'll close this as NORESPONSE. If you can still reproduce it in current 11.4, please reopen the bug and move it to the appropriate version. Thanks!