#550 Doesn't acknowledge NotShowIn.

menu-cache (31)

I'm using mt branch of menu-cache but this bug is present in v. 3 too.

I have Icewm and Xfce here. 'Applications' directory in pcmanfm displays properly the apps according with the environment I boot into but it fails to acknowledge the NotShowIn key. So desktop files I have that have 'NotShowIn=XFCE;' still show up in the Applications directory of pcmanfm in Xfce.


  • Lonely Stranger

    Lonely Stranger - 2012-11-13

    It works for me. The issue may be that you haven't set the environment variable XDG_CURRENT_DESKTOP to some appropriate value ("XFCE" in your case) before you start pcmanfm. If you don't have it set then both ShowOnlyIn and NotShowIn values will be ignored. If you have it set to wrong value then that value will be checked in ShowOnlyIn and NotShowIn instead of what you want. Check it, please.
    Thank you very much.

  • Lonely Stranger

    Lonely Stranger - 2012-11-13
    • assigned_to: nobody --> lstranger
    • status: open --> open-works-for-me
  • Sérgio Cipolla

    Sérgio Cipolla - 2012-11-13

    $ env|grep -i desktop

    So maybe it should check DESKTOP_SESSION variable (that's the way it works here)?

  • Sérgio Cipolla

    Sérgio Cipolla - 2012-11-14

    Andriy, are you going to work on this? (asking because of the 'Works For Me' resolution)
    Here's for IceWM in Fedora:
    $ env|grep -i desktop

    So the way the desktop session is setup here is with the DESKTOP_SESSION variable.
    Just want to know because for me it looks like a menu-cache issue but if you say the bug is somewhere else then I report there.

  • Sérgio Cipolla

    Sérgio Cipolla - 2012-11-17

    The problem isn't the desktop session. menu-cache works with OnlyShowIn but fails with NotShowIn.

    OnlyShowIn=XFCE highlighted: http://ompldr.org/vZ2M3dw

    NotShowIn=XFCE failed: http://ompldr.org/vZ2M3eg

    I'm no programmer but I looked for 'ShowIn' in the menu-cache code and I saw some stuff that looks like pretty old as was only for GNOME.

  • Lonely Stranger

    Lonely Stranger - 2012-11-27

    Note that the XDG specification says that OnlyShowIn and NotShowIn should be never specified in the same file. If you have them both then NotShowIn will be ignored. Unfortunately, that's unavoidable due to specification:

    Your assumption that DESKTOP_SESSION variable should be honored by applications that use menu is wrong. That variable is user-specific and specifies which selection was made in display manager. Just read available documentation on that variable usage. To make assumption based on that is completely wrong (it may contain values 'default', 'gnome+openbox' and so on) and PITA.

    Moreover, decision what desktop environment is used, isn't in menu-cache but in application. You may open a bug for lxpanel or pcmanfm but I believe both will be rejected for reason that I explain below. Since we have LXDE standard-compliant, we use XDG specifications here. XDG standard specifies variables that are prefixed with XDG_ and the variable which defines the desktop environment is de-facto XDG_CURRENT_DESKTOP. If that variable isn't set then applications assume the desktop is unspecified. Pcmanfm ignores both OnlyShowIn and NotShowIn in that case, and lxpanel shows all items that are available either in GNOME, KDE, XFCE, or LXDE - i.e. you should add all of them into NotShowIn to remove from menu of lxpanel in such case.

    So I think you should just correctly set XDG_CURRENT_DESKTOP variable (case isn't ignored so you should have it exactly as in OnlyShowIn or NotShowIn lines, i.e. "XFCE") and you'll get your desired result.

    I hope that explanation helps.
    Thank you.

  • Lonely Stranger

    Lonely Stranger - 2012-11-27
    • status: open-works-for-me --> pending-works-for-me
  • Sérgio Cipolla

    Sérgio Cipolla - 2012-11-27
    • status: pending-works-for-me --> closed-works-for-me

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks