menubar/utils.lua: Can't override system desktop files with NoDisplay=true

[doronbehar]

Output of awesome --version:

awesome v4.2 (Human after all)
 • Compiled against Lua 5.3.5 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

How to reproduce the issue:

Based on https://wiki.archlinux.org/index.php/Desktop_entries#Hide_desktop_entries:

1. Copy a desktop file from /usr/share/applications/ (firefox.desktop for example) to ~/.local/share/applications.
2. Add NoDisplay=true under [Desktop Entry] to your copy of the desktop file in ~/.local/share/applications.
3. Run update-desktop-database ~/.local/share/applications in order to update the desktop entries of the system along with the user installed ones.
4. Restart Awesome.

Actual result:

The firefox program is still visible when running menubar.show().

Expected result:

The firefox program is not visible when running menubar.show().

My suspicion:

I've read the source code of the menubar module and I think the problem is that although the NoDisplay entry is read and checked against "true", perhaps it is still being merged with the system's original desktop entry which doesn't have NoDisplay=true in it's [Desktop Entry].

[psychon]

This might be a duplicate of #1816 (since the instructions start with "Copy"; I have not actually checked if we handle NoDisplay correctly).

[doronbehar]

It seems that you do:

awesome/lib/menubar/utils.lua

Lines 346 to 349 in 6617d78

	-- Don't show program if NoDisplay attribute is true
	if program.NoDisplay then
	program.show = false
	else

But as I said, I think that in case NoDisplay does appear there we need to check whether we are reading a desktop file from the user's ~/.local/share/applications and if so, remove the corresponding desktop file representation in the table generated somewhere around here:

awesome/lib/menubar/menu_gen.lua

Line 80 in 68e4dd4

function menu_gen.generate(callback)

As far as I see, fixing this will require many changes to the structure of these functions but it is certainly possible.

[psychon]

Okay, since you agree: Closing as a duplicate of #1816

[psychon]

Oh and to make things possibly clearer:

You write:

perhaps it is still being merged with the system's original desktop entry which doesn't have NoDisplay=true in it's [Desktop Entry].

Nope. The problem is that each .desktop file is handled independently. Thus, if neither one had NoDisplay=true, than you would get the entry twice.

Actually, fixing #1816 should not be that hard, I would expect. We would just need to generate the desktop file IDs and track them, so that if the same ID appears again later, the later one can be ignored....

[doronbehar]

Agree. We need to consider the location of the desktop files and if a desktop id appears twice, we need to use the one that is used in ~/.local/share/applications or /usr/local/share/applications and only then /usr/share/applications, in other words the order is important.