Description of problem: Currently, the cascading Gnome menus are managed by redhat-menus. This menu is composed of categories' submenu which contain Gnome's applications as well as KDE 's applications. I propose to have the possibility (by a package ? a command ?) to sort the KDE software in a KDE's submenu, as it's impossibly to review the gnome-menu-extended (https://bugzilla.redhat.com/show_bug.cgi?id=426026).
triaging as RFE
The GNOME SlackBuild project has a solution for this. First, they patch the applications.menu file of gnome-menus (the upstream equivalent of the applications.menu file of redhat-menus) to exclude all KDE (and XFce) applications from GNOME's Applications menu. Thus you do need to patch each KDE *.desktop file you want to exclude by adding an OnlyShowIn=KDE field to it. Second, the patch also adds hooks to applications.menu for optionally installed merge files that add KDE (and XFce) submenus to GNOME's Applications menu. http://dev.gnomeslackbuild.org/repositories/changes/gsb-source/trunk/src/desktop/gnome-menus/patches/gnome-menus-2.20.3-submenus.patchhttp://dev.gnomeslackbuild.org/repositories/changes/gsb-source/trunk/src/desktop/gnome-menus/patches/gnome-menus-2.20.3-submenus.patch The two optional packages, gnome-menus-kde and gnome-menus-xfce to add KDE and XFce submenus to GNOME's Applications menu are available here: Binaries: http://slackware.rol.ru/gsb/gsb/gsb-current/packages/desktop/ ftp://ftp.slackware.pl/pub/gnomeslackbuild/gsb/gsb-current/packages/desktop/ SVN: http://dev.gnomeslackbuild.org/repositories/browse/gsb-source/trunk/src/desktop/gnome-menus-kde http://dev.gnomeslackbuild.org/repositories/browse/gsb-source/trunk/src/desktop/gnome-menus-xfce
(In reply to comment #2) > Thus you do need to... Oops, this should be "Thus you do _not_ need to..."
And again, here is the link to the patch: http://dev.gnomeslackbuild.org/repositories/browse/gsb-source/trunk/src/desktop/gnome-menus/patches
I'm not sure I agree with this approach wrt menus. Imo, apps are apps, and should be shown in (*all*) desktop menus, regardless of which toolkit they're written for/in. That's how I feel atm anyway, I'd like to keep watch here and see where this goes.
Rex> I agree also with your point of view, but actually the fact that KDE packages are monoliths is the problem. With a submenu, I resolve the KDE's software pollution (when we want install KBabel, we install also 6 other applications). Furthermore, with a separation b/w Gnome and KDE, I know when I will run the kdelibs which are weighty. But it's truth that I don't know if it's possible to have an apps menus in one part and a desktop menu in the other, and isn't in my intention to force on type of menu.
Those interested in this should probably just finish the review in bug 426026
I agree. I'm going to close this so it goes off my radar. If someone has patches or some such to make redhat-menus interoperate better in different configurations without modifying the default configuration then please file a new report.