CentOS - Aug 2016 - Custom desktop menu entries: weird behavior with menu categories

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
-- 
Microlinux - Solutions informatiques durables
7, place de l'?glise - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : info at microlinux.fr
T?l. : 04 66 63 10 32

Le 14/08/2016 ? 11:33, Nicolas Kovacs a ?crit :
> 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.
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

-- 
Microlinux - Solutions informatiques durables
7, place de l'?glise - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : info at microlinux.fr
T?l. : 04 66 63 10 32

On 08/14/2016 10:13 AM, Nicolas Kovacs wrote:
> Le 14/08/2016 ? 11:33, Nicolas Kovacs a ?crit :
>> 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.
> 
> 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/580c0560105a0f018b62a7e0bdf42eca9b9032f1/SPECS!gnome-shell.spec

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20160815/a1661ae9/attachment-0001.sig>

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)

-- 
Jonathan Billings <billings at negate.org>