Hi,
For my client's desktops, I'm usually customizing the various Linux desktops I'm installing. I'm using custom icon themes (Elementary), custom system fonts (Droid Sans), and one of the things I also customize are desktop menu entries.
Here's an example of what I do on a Slackware+Xfce-based desktop, so you get the idea. Once all applications are installed, I run the cleanmenu.sh script:
http://www.microlinux.fr/microlinux/desktop-14.2-64bit/tools/
As you can see, this script replaces the various *.desktop files in /usr/share/applications and similar places with my own custom *.desktop files:
http://www.microlinux.fr/microlinux/desktop-14.2-64bit/tools/desktop/
This solution has worked very well over the years. There are a few reasons I'm doing this. Most of my users come from a Windows-centric world, so it's better for them if the menu sports something like "Office>Presentation Software" instead of "LibreOffice Impress". Another reason is visual consistency. BTW, the "Elementary Xfce" icon theme is great not only for Xfce, but also for other desktops, and it fits great in corporate environments needing something sober and not too distracting. Last but not least, some menu entries are better organized in different categories. IMHO, the screenshot utility should default to "Graphics" and not to "Utility", and Brasero should be in "Utilities" and not in "Multimedia".
Curiously enough, some menu entries stubbornly refuse to have their category redefined.
1. When I edit gnome-terminal.desktop and define "Categories=System;", it won't appear in "Outils systèmes" as expected but remains in "Utilitaires".
2. I have a category "Divers" (something like "Misc") with a single desktop entry for Printer Configuration. Now when I edit system-config-printer.desktop and define something like "Categories=System;", the "Divers" category remains there and the menu entry won't budge.
Most of the menu entries can be redefined OK, and they appear in the new category. Why a handful of desktop entries would not work remains a mystery. This looks damn well like a bug, although I wouldn't even know how to call it.
Any ideas?
Cheers from the sunny South of France,
Niki
Le 14/08/2016 à 11:33, Nicolas Kovacs a écrit :
- When I edit gnome-terminal.desktop and define "Categories=System;",
it won't appear in "Outils systèmes" as expected but remains in "Utilitaires".
- I have a category "Divers" (something like "Misc") with a single
desktop entry for Printer Configuration. Now when I edit system-config-printer.desktop and define something like "Categories=System;", the "Divers" category remains there and the menu entry won't budge.
Most of the menu entries can be redefined OK, and they appear in the new category. Why a handful of desktop entries would not work remains a mystery. This looks damn well like a bug, although I wouldn't even know how to call it.
After some more experimenting, I found the culprit. It looks like the structure of the classic Applications menu is not only defined by the individual *.desktop files in /usr/share/applications, but also in a weird /etc/xdg/menus/gnome-applications.menu file which contains a bunch of redundancies. Not exactly KISS principle.
So it looks like in order to customize my menus, I have to edit individual *.desktop files in /usr/share/applications as well as the XML-style entries in /etc/xdg/menus/gnome-applications.menu.
I bluntly admit I don't get the logic behind this sort of thing.
Cheers,
Niki
On 08/14/2016 10:13 AM, Nicolas Kovacs wrote:
Le 14/08/2016 à 11:33, Nicolas Kovacs a écrit :
- When I edit gnome-terminal.desktop and define "Categories=System;",
it won't appear in "Outils systèmes" as expected but remains in "Utilitaires".
- I have a category "Divers" (something like "Misc") with a single
desktop entry for Printer Configuration. Now when I edit system-config-printer.desktop and define something like "Categories=System;", the "Divers" category remains there and the menu entry won't budge.
Most of the menu entries can be redefined OK, and they appear in the new category. Why a handful of desktop entries would not work remains a mystery. This looks damn well like a bug, although I wouldn't even know how to call it.
After some more experimenting, I found the culprit. It looks like the structure of the classic Applications menu is not only defined by the individual *.desktop files in /usr/share/applications, but also in a weird /etc/xdg/menus/gnome-applications.menu file which contains a bunch of redundancies. Not exactly KISS principle.
So it looks like in order to customize my menus, I have to edit individual *.desktop files in /usr/share/applications as well as the XML-style entries in /etc/xdg/menus/gnome-applications.menu.
I bluntly admit I don't get the logic behind this sort of thing.
I can't comment on the logic .. I build these, I don't write them :D
But, one thing to check is the spec file for the package that provides the .desktop file to ensure it is configured as noreplace. If it is not, you need to back up your custom files as they will replaced with an upgrade.
You can find the actual package with :
rpm -q --whatprovides </full/path/to/actual/file>
once you know the rpm, you can find the Source RPM (SRPM) used to build it like this:
rpm -qi <rpm_name>
once you know the Source RPM name, you can find the spec file here:
https://git.centos.org/summary/rpms!kernel
(substitute the SRPM name for kernel)
Then click on the 'c7' branch link, and on the next screen, click the 'tree' link.
That should take you to a screen with SPECS/ and SOURCES/ .. click SPECS/ and then the file name of the spec file. That will open up the actual spec file used to build the RPM that contains the desktop file.
For example, there are several .desktop files defineed in the gnome-shell SRPM, and they would be replaced:
https://git.centos.org/blob/rpms!gnome-shell/580c0560105a0f018b62a7e0bdf42ec...
That is, they are not set to config(noreplace).
The best thing to do is to keep a copy of all of your modified .desktop files somewhere else and you can copy them back in if necessary after an update.
Thanks, Johnny Hughes
On 2016-08-15, Johnny Hughes johnny@centos.org wrote:
[...]
The best thing to do is to keep a copy of all of your modified .desktop files somewhere else and you can copy them back in if necessary after an update.
Thanks, Johnny Hughes
The OP could place the modified .desktop files in /usr/local/share/applications. The environment variable XDG_DATA_DIRS will determine precedence.
Le 15/08/2016 à 17:57, Johnny Hughes a écrit :
But, one thing to check is the spec file for the package that provides the .desktop file to ensure it is configured as noreplace. If it is not, you need to back up your custom files as they will replaced with an upgrade.
I know that. The simple solution here is to run a script that replaces all vanilla desktop files by custom ones, then run it after each upgrade. I've been doing for that for years, it works perfectly.
Cheers,
Niki
On Sun, Aug 14, 2016 at 05:13:43PM +0200, Nicolas Kovacs wrote:
After some more experimenting, I found the culprit. It looks like the structure of the classic Applications menu is not only defined by the individual *.desktop files in /usr/share/applications, but also in a weird /etc/xdg/menus/gnome-applications.menu file which contains a bunch of redundancies. Not exactly KISS principle.
So it looks like in order to customize my menus, I have to edit individual *.desktop files in /usr/share/applications as well as the XML-style entries in /etc/xdg/menus/gnome-applications.menu.
I bluntly admit I don't get the logic behind this sort of thing.
If you want to define new menu categories, put a file ending with .menu in /etc/xdg/menus/applications-merged/. It should be read in by any of the default .menu files that call DefaultMergeDirs. I'm pretty sure this will only let you define new menus, and not override existing ones. But it sounds to me like you're editing a lot of files that will most likely be replaced next time you get an update to the gnome-menus package.
I define extra menu entries and then define XDG_DATA_DIR to a network volume to provide menu entries for our 3rd-party licensed software.
Just be aware that if you point XDG_DATA_DIR to a directory that is exists but you aren't permitted to read will cause Gnome 3 to crash in CentOS7. (I've already filed a bug)
-
Johnny Hughes -
Jonathan Billings -
Liam O'Toole -
Nicolas Kovacs