Properly handle OnlyShowIn and NotShowIn.

[DidierSpaier]

OnlyShowIn and NotShowIn relate to a "real" desktop, not a window manager.

For instance if the DE is LXDE and OnlyShowIn=LXDE; the desktop entry
should be included it the menu, even if a WM like FVWM is used.

[gapan]

I'm not sure about this. If you're using a DE, shouldn't you be also using that DE's menu system?

[DidierSpaier]

Le 31/03/2017 à 10:04, George Vlahavas a écrit :

I'm not sure about this. If you're using a DE, shouldn't you be also using that DE's menu system?

I prefer to provide two menus. In case of LXDE: 1) the menu included in lxpanel (bottom left in one of the attached pic) 2) a root menu, displayed with a click in an empty part of the screen. It is displayed in the other pic (fvwm menu adapted for LXDE) But available entries in both application menus should be the same, i.e. in this example, the .desktops with OnlyShowIn=LXDE; should be displayed in both application menus

[DidierSpaier]

I forgot that I couldn't upload the pics here. See them there:
http://slint.fr/testing/LXDE_with_FVWM1.png
http://slint.fr/testing/LXDE_with_FVWM2.png

[gapan]

Revisiting this, I'm still not sure about it.

What if you are currently inside a DE, but want to create a menu for a WM, that you will use when you exit the DE? This way, it will include all menu entries that were specific to the DE. It makes the output dependent on the currently running environment and I'm not comfortable with that.

[DidierSpaier]

You wrote:
"What if you are currently inside a DE, but want to create a menu for a WM, that you will use when you exit the DE?"
But why would I do that? In Slint at least, all menus are refreshed when starting the DE, whatever it be.

In case of OnlyShowIn most excluded entries wouldn't work or stand if included in the other DE anyway, as they are mostly settings specific to a given DE. So, why include in a menu entries that the user will think are "broken"?

As an example I attach the output of" grep -r OnlyShowIn|sort" typed from /usr/share/applications in a Slint system.

OnlyShowIn.txt

PS the KDE entries you see in the list are because I don't want to start akonadi & such in other DEs than KDE itself, thus exclude all PIM appas outside from KDE.

[gapan]

But why would I do that?

I don't know about you, but I do it all the time!

In case of OnlyShowIn most excluded entries wouldn't work or stand if included in the other DE anyway, as they are mostly settings specific to a given DE. So, why include in a menu entries that the user will think are "broken"?

That's exactly my point! If, for example, I am in MATE and want to create a menu for JWM, I don't want OnlyShowIn=MATE entries in my menu.

Also, if I'm in MATE and want to create a menu for JWM, I would definitely want entries with NotShowIn=MATE included.

[DidierSpaier]

Well, I appears I had forgotten the specific context in which I emitted this pull request and failed to read again the proposed patch before providing my recent answers, my bad.

Actually the issue I initially mentioned only occurs if following conditions are met:

1. XDG_CURRENT_DESKTOP is set to one of the desktops mentioned in an OnlyShowIn or NotShowIn conditions of a .desktop file
2. The DE allows to set as desktop menu (raised with a right or left click in on the desktop) the menu associated with the window manager .

Practically in Slint these conditions are met for LXDE only. In this case, without applying the patch I miss in the menu provided by xdgmenumaker all entries with "OnlyShowIn=LXDE":
libfm-pref-apps.desktop:OnlyShowIn=LXDE;
lxappearance.desktop:OnlyShowIn=LXDE;
lxrandr.desktop:OnlyShowIn=LXDE;
lxsession-default-apps.desktop:OnlyShowIn=LXDE;
lxsession-edit.desktop:OnlyShowIn=LXDE;
lxtask.desktop:OnlyShowIn=LXDE;
and this regardless of the window manager used. Among those shipped in Slint and built with xdgmenumaker this can be blackbox, fluxbox, fbwm (the default), twm or windowmaker.

Granted these missing entries are not the end of the world as the can be accessed from the panel's menu anyway, so this pull request is not so important after all. I just wanted in this post to clarify a bit its rationale.