Hmm - see linked issue. We do actually specify (in menu.json that the items should go in the Science category, but when I look at the output.

$ cat .config/menus/applications.menu

with output:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
 "http://standards.freedesktop.org/menu-spec/menu-1.0.dtd">
<Menu>
    <Name>Applications</Name>
    <MergeFile type="parent">/etc/xdg/menus/applications.menu</MergeFile>
    <Menu>
        <Name>Scientific Python (0.1.0)</Name>
        <Directory>scientific-python-010.directory</Directory>
        <Include>
            <Category>Scientific Python (0.1.0)</Category>
        </Include>
    </Menu>
</Menu>

Is that what you get? Shouldn't it be:

        ...
        <Include>
            <Category>Science</Category>
        </Include>
        ...

instead?

What about the MNE Python installer - same?

Just tested MNE installer --- same result (items end up in "Other"). Some notes:

• in my desktop environment (XFCE) there is no MergeFile /etc/xdg/menus/applications.menu; the filename is xfce-applications.menu.
• Changing this line to say Science instead of Scientific Python (#PKG_VERSION#) changes ~/.config/menus/applications.menu accordingly, but doesn't change the result at all (menu items are still in "Other", not in "Science")

Will attempt more debugging tomorrow morning.

I'm also asking over at conda/menuinst#339 (comment) ....

OK, here is what I've now tried:

Here is what works:

• each menu_item in menu.json must have category "Science"
• the menu_name in menu.json must also be "Science"
• The resulting menu file must be renamed to ~/.config/menus/xfce-applications.menu (to add the xfce- prefix on the basename)

The resulting contents of ~/.config/menus/xfce-applications.menu are:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
 "http://standards.freedesktop.org/menu-spec/menu-1.0.dtd">
<Menu>
    <Name>Applications</Name>
    <MergeFile type="parent">/etc/xdg/menus/applications.menu</MergeFile>
    <Menu>
        <Name>Science</Name>
        <Directory>science.directory</Directory>
        <Include>
            <Category>Science</Category>
        </Include>
    </Menu>
</Menu>

renaming the MergeFile does not appear to be necessary.

I think this means that we "just" need to update conda/menuinst to make use of the $XDG_MENU_PREFIX env variable, probably here:

https://github.com/conda/menuinst/blob/5c377464c11a9659c88d1490b581dbdaa747e67d/menuinst/platforms/linux.py#L47-L49

I'm getting sensible behavior now with conda/menuinst#340 and #16, but I'm still ending up with a couple head-scratchers:

• I now see both applications.menu and xfce-applications.menu created during build/install, about 3 minutes apart
• the desktop icons are being put into $HOME/.local/share/applications/ during build already; they really shouldn't go there until install.

OK, more progress. If we assume that menu.json specifies "menu_name": "MENUNAME" and each menu_item specifies "name": "ITEMNAME" and "Categories": ["CAT"], what I've now learned is:

When building the menu installer package:

• there will be a new file ~/.local/share/desktop-directories/SANITIZEDMENUNAME.directory (MENUNAME converted to lowercase and spaces as dashes) with a field name=MENUNAME in it

• .desktop files in ~/.local/share/applications/ will be called SANITIZEDMENUNAME_SANITIZEDITEMNAME.desktop and each will have an entry Categories=CAT. The paths in Exec and Icon will be incorrect (placeholderplaceholder, etc)

• using use XDG_MENU_PREFIX where appropriate conda/menuinst#340, there will be a new file ~/.config/menus/xfce-applications.menu (under XFCE) that identifies the correct MergeFile (/etc/xdg/menus/xfce-applications.menu). It will include this:

  <Menu>
      <Name>MENUNAME</Name>
      <Directory>SANITIZEDMENUNAME.directory</Directory>
      <Include>
          <Category>MENUNAME</Category>
      </Include>
  </Menu>

  NOTE that the Category name that is included is the same as the name of the menu itself; menuinst apparently does not scrutinize the Categories entries for each menu item when setting the <Category> field in the .directory file. So there are I think two possible routes to follow:

  1. MENUNAME="Scientific Python", each menu_item gets Category="Scientific Python"; result is a new top-level menu folder called "Scientific Python" with (only) our icons in it
  2. MENUNAME="whatever", each menu_item gets Category="Science"; result is that our icons go into the default "Science" category (alongside any other installed programs that also have Category=Science). The creation of whatever.directory will have no effect, as no desktop items will have Category=whatever.

When building the overall installer executable:

• ~/.local/share/desktop-directories/SANITIZEDMENUNAME.directory is untouched
• ~/.local/share/applications/*.desktop files are untouched
• ~/.config/menus/xfce-applications.menu is untouched

When running the .sh installer script:

• ~/.local/share/desktop-directories/SANITIZEDMENUNAME.directory is overwritten but unchanged
• ~/.local/share/applications/*.desktop files are overwritten (and now have the correct paths in Exec and Icon)
• ~/.config/menus/xfce-applications.menu is untouched
• There will be a new file ~/.config/menus/applications.menu (as before conda/menuinst#340) that identifies the wrong mergefile (/etc/xdg/menus/applications.menu, as before conda/menuinst#340). Aside from the MergeFile it is otherwise identical to the file with the correct XDG_MENU_PREFIX. This "wrong" file seems to do neither harm nor good (deleting it has no effect).

Next steps

• make a PR into constructor to do similar things to menuinst w/r/t using XDG_MENU_PREFIX. Otherwise, users (who just run the installer, not build the menu package) will still see our icons in the Other category.
• decide if we want our own branded folder, or just put our icons in "Science"
  • if we want our own folder, we should probably use a variable to set both menu name and category, to ensure that all menu items end up in the right category
• get conda/menuinst#340 merged & pin our env to menuinst main (until they make a release); or update our makefile/env to use my fork+branch of menuinst
• (maybe) report Category=MENUNAME as a bug (or at least, make a feature request to add a top-level "Category" field to the schema)
• (maybe) figure out how to avoid actually installing the various .desktop, .directory, and .menu files when simply building the menu installer package (because, at that point, they aren't functional because the paths in the .desktop files are all placeholders)

• (maybe) report Category=MENUNAME as a bug (or at least, make a feature request to add a top-level "Category" field to the schema)

That seems like a very good idea - if only to clarify our understanding in writing the issue.

• (maybe) figure out how to avoid actually installing the various .desktop, .directory, and .menu files when simply building the menu installer package (because, at that point, they aren't functional because the paths in the .desktop files are all placeholders)

Is this a bug in menuinst? That too would be good issue to raise - what do you think?

• (maybe) figure out how to avoid actually installing the various .desktop, .directory, and .menu files when simply building the menu installer package (because, at that point, they aren't functional because the paths in the .desktop files are all placeholders)

Is this a bug in menuinst? That too would be good issue to raise - what do you think?

I can't tell if this is a bug or intended behavior. It doesn't make sense to me as intended behavior, but none of the menuinst functions/classes have docstrings, and the public docs site doesn't have a detailed API reference, so I'd have to really dig into the codebase to investigate. Better to ask upstream first I think.

Yes, maybe see if upstream are OK to help guide you to a shared understanding ... ?

Yes, maybe see if upstream are OK to help guide you to a shared understanding ... ?

conda/menuinst#342
conda/conda-build#5736

• (maybe) report Category=MENUNAME as a bug (or at least, make a feature request to add a top-level "Category" field to the schema)

That seems like a very good idea - if only to clarify our understanding in writing the issue.

conda/menuinst#343