I’m a KDE fan, but I installed GNOME 3 to give it a test drive. I like some aspects, but I don’t care for all the clutter in the menu, in the form of KDE apps that duplicate the functions of native GNOME apps. So I just opened alacarte and un-checked all those KDE apps. Simple, cleaned up the menu beautifully. Then I booted into my main environment, right-clicked on my launcher to open its editor and delete the GNOME apps. All of my KDE apps were gone!
Deleting GNOME apps from KDE works fine: They stay gone in KDE but they’re still present in GNOME. The reverse is not true. Is there a better way than what I tried? Besides installing a GNOME distro in a vbox; I tried that and found it too sluggish. I could also replicate a menu structure on a dock (Cairo), but I thought I’d check with the experts first in case there’s a less clunky approach.
You can look for the generated .desktop files after using ‘alacarte’ or similar tools (I’m not familiar which these apps and just assuming that they would create .desktop files).
or you can explicitely set a different $XDG_DATA_HOME for Kde and Gnome, so that they will look for .desktop files in a different location. Notice that Gnome3 ignores submenus by default: Traditional menu broken in 11.4. There are other tricks (maybe even simpler ones that I don’t know), but generally speaking, some knowledge about freedesktop is required before you can do what you want with menus under KDE, Gnome and others. You can read the details in the freedesktop specs: freedesktop.org - Specifications.
Hi again please-try-again, thanks for the links. I see that the solution here is in theory the same as for my question about autostarting apps, edit a *.desktop file to say “OnlyShowIn=xxx”. However, in this case it didn’t work. I found those *.desktop files in usr/share/applications (and nowhere else), with all the kde4 apps convieniently in their own subdirectory. Since I’m the only user of this laptop I can afford to modify the sole copy (and anyway I lack the programming skills to create script with a graphical interface to select menu items to filter on a per-user, per-environment basis). But even when so modified, eith OnlyShowIn=KDE or NotShowIn=GNOME, they still show up in GNOME, so I’m trying to understand the other files involved to see GNOME is ignoring these instructions. Any chance this is because GNOME 3 is in many ways a new OS?
I’ll keep you posted how it goes; I may have more questions but I hope I can make them better and more specific. As always I appreciate the help that newbies and dabblers receive from this forum.
You shouldn’t modify the files in /usr/share/applications - they’ll get overwritten. You should rather copy all the .desktop files in /usr/local/share/applications, edit these files, modify the categories, create new once, set the environment variable XDG_DATA_DIRS to point to the new location, copy the *.menu files in /etc/xdg/menus to another location and set the variable XDG_CONFIG_DIRS to point to this location. If you compare the files /etc/xdg/applications.menu and /etc/xdg/gnome-applications.menu and read (or re-read) this thread Traditional menu broken in 11.4 - Page 2, you’ll understand why Gnome3 doesn’t display submenus, although if you modify XDG_MENU_PREFIX, you can get back the traditional menus in gnome fall-back mode. The good news is that once you understand how freedesktop is organized, you’ll be able to customize the menus on all Linux and Unix (and start your own distro at some point) - in fact. my menus have nothing in common with the (IMO) useless defaults. The bad news is that it’s a lot of work, learning and scripting (if you want to make your life easier) and you should know if it’s worth it. Gnome3 doesn’t really use menus anyway - except in fallback-mode. Menus entries in the .desktop files will only show up if they belong to a category defined in the used .menu file. If a .desktop file includes more than one category, it will appear more than once in different submenus. Once you’ve learned how to deal with menus, you’ll probably find out that using the CLI would have been faster. lol!
Sounds like it. My goal here is not to someday release a distro, but just to get a feel for GNOME Shell, as a user. I appreciate the help, but what you’ve really helped me understand is that I can live with it the way it is. -GEF
Having decided to leave well enough alone, I’ve got broken menus in KDE. Some things are missing, and some have dupes. When I use kmenuedit and remove the dupes, the save doesn’t take. I swaer I didn’t touch the *.menu files. The *.desktop files I tested with OnlyShowIn=KDE, I put back like I found 'em, and in any case the entries to which they correspond are not the ones with the dupes!
I figure something is corrupt; is there a way to get a clean slate in the menu system shy of re-installing the whole OS? If I delete the relevant directories, will they regenerate?
On 09/06/2011 07:16 AM, gfagan wrote:
>
> Update: I logged into KDE as root, and the menu for that account is
> normal. -GEF
you should never log into KDE/Gnome/XFCE or any other *nix-like system’s
graphical user interface desktop environment as root…
doing so 1) opens you up to several different security problems if you
(for example) browse the net, 2) too many too easy ways to damage your
system no matter how careful your actions (for example: well documented
cases of unintended change of ownership of ~/.ICEauthority and
~/.Xauthority from user to root sometimes occurs), 3) anyway logging
into KDE/etc as root is never required to do any and all
administrative duties, 4) and, not even logging in as root just to see
if it works as root is useful, because the “yes” or “no” learned is
almost always totally useless in finding the problem giving the
symptoms. however, logging in as root to learn the yes/no could the
cause of the next adverse symptom encountered.
so, always log in as yourself, and “become root” by using a root powered
application (like YaST, File Manager Superuser Mode) or using “su -”,
sudo, kdesu, or gnomesu in a terminal to launch whatever tool is needed
(like Kwrite to edit a config file)…read more on all that here:
additionally: after logging into KDE/Gnome/etc as root, if you
experience problems (for example, with uncommanded file ownership and
permissions changes) and if you can provide us with details of what you
were doing while you were logged in as root, that would help us identify
if there’s a bug that needs to be fixed…thanks for your help…
–
DD Caveat
openSUSE®, the “German Automobiles” of operating systems
On 09/06/2011 07:16 AM, gfagan wrote:
>
> Update: I logged into KDE as root, and the menu for that account is
> normal
root’s menus still works only because you have not corrupted them…
and, if you were to use YaST > Security & Users > User and Group
Management to add a new Test user, and then log out as yourself and log
in as that new test user [instead of as root–which you should never do]
then you would have learned that the Test user’s account also had a
fully functional and non-corrupted set of menus…and, you would have
learned the same information (the system is ok, it is some of the
configs in your /home which are toast)…
read my other note about logging into KDE as root: and realize that
another reason to never log in to KDE as root is so you do not corrupt
root’s stuff
–
DD Caveat
openSUSE®, the “German Automobiles” of operating systems
There are 2 levels of menus - as for most things - a system level and a user level. Things you modify at system level - such as the menus in /usr/share/applications or /usr/local/share/applications - affect all users. You did most likely screw up you user’s menus by playing with tools like kmenuedit and alacarte. BTW I’m not sure alacarte is appropriate for Gnome3. Gnome3 itself has lost the concept of menus - except in gnome-fallback mode where traditional menus can be restored with some tricks. Menus you create/modify as user with kmenuedit are copied from the system path (/usr/share/applications) to the user path defined in XDG_DATA_HOME or if it’s not set to the user’s ~/local/share/applications directory. This is the directory you need to remove to get rid of the menus you ceated/modified and NOT the ~/.kde4 folder (it won’t help). Creating another user can help understanding and solving problem. Logging on as root is just insane.
lenwolf>perhaps you should just rename your hidden kde4 folder…let kde recreate it.
Thanks, that’s what I needed to know, that KDE would recreate it. I renamed /home/myusername/.config/menus to oldmenus and almost everything worked, except wine. Then I copied the applications-merged subdirectory from oldmenus to the new menus directory and got my wine programs folder back.
please_try_again>Creating another user can help understanding and solving problem. Logging on as root is just insane.
And DD echoed those sentiments. Point taken. I rarely log on as root, did so this time only to check if menu problem was global or user level, will in future create a test user instead. (FYI, alacarte has no replacement in GNOME 3, and while G3 ignores its structure, it still shows only those apps which are checked on in alacarte. By default, startup manager is not checked.)