Repository navigation
Improve menu location for Linux installs #11
Description
menu icons install into the "Other" folder. There are I think built-in categories for "science" and "Development", either of these would be better.
Originally posted by @drammock in #3 (review)
Activity
matthew-brett commentedon Jun 3, 2025
Hmm - see linked issue. We do actually specify (in
menu.jsonthat the items should go in theSciencecategory, but when I look at the output.with output:
Is that what you get? Shouldn't it be:
... <Include> <Category>Science</Category> </Include> ...instead?
What about the MNE Python installer - same?
drammock commentedon Jun 3, 2025
Just tested MNE installer --- same result (items end up in "Other"). Some notes:
/etc/xdg/menus/applications.menu; the filename isxfce-applications.menu.Scienceinstead ofScientific Python (#PKG_VERSION#)changes~/.config/menus/applications.menuaccordingly, but doesn't change the result at all (menu items are still in "Other", not in "Science")Will attempt more debugging tomorrow morning.
matthew-brett commentedon Jun 3, 2025
I'm also asking over at conda/menuinst#339 (comment) ....
drammock commentedon Jun 4, 2025
OK, here is what I've now tried:
Details
Categoriesa single string"Science"instead of an array["Science"]"Science"per https://github.com/conda/menuinst/blob/5c377464c11a9659c88d1490b581dbdaa747e67d/menuinst/data/menuinst-1-0-2.schema.json#L162menu_nameto "Science" or "Science;" instead of "Scientific Python (0.1.0_0)"MergeFilemanually within~/.config/menus/xfce-applications.menuto point to /etc/xdg/menus/xfce-applications.menuHere is what works:
menu_iteminmenu.jsonmust have category "Science"menu_nameinmenu.jsonmust also be "Science"~/.config/menus/xfce-applications.menu(to add thexfce-prefix on the basename)The resulting contents of
~/.config/menus/xfce-applications.menuare:renaming the
MergeFiledoes not appear to be necessary.I think this means that we "just" need to update
conda/menuinstto make use of the$XDG_MENU_PREFIXenv variable, probably here:https://github.com/conda/menuinst/blob/5c377464c11a9659c88d1490b581dbdaa747e67d/menuinst/platforms/linux.py#L47-L49
drammock commentedon Jun 4, 2025
I'm getting sensible behavior now with conda/menuinst#340 and #16, but I'm still ending up with a couple head-scratchers:
applications.menuandxfce-applications.menucreated during build/install, about 3 minutes apart$HOME/.local/share/applications/during build already; they really shouldn't go there until install.drammock commentedon Jun 5, 2025
OK, more progress. If we assume that
menu.jsonspecifies"menu_name": "MENUNAME"and eachmenu_itemspecifies"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 fieldname=MENUNAMEin it.desktopfiles in~/.local/share/applications/will be calledSANITIZEDMENUNAME_SANITIZEDITEMNAME.desktopand each will have an entryCategories=CAT. The paths inExecandIconwill 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 correctMergeFile(/etc/xdg/menus/xfce-applications.menu). It will include this:NOTE that the Category name that is included is the same as the name of the menu itself;
menuinstapparently does not scrutinize theCategoriesentries for each menu item when setting the<Category>field in the.directoryfile. So there are I think two possible routes to follow:menu_itemgets Category="Scientific Python"; result is a new top-level menu folder called "Scientific Python" with (only) our icons in itmenu_itemgets 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 ofwhatever.directorywill have no effect, as no desktop items will have Category=whatever.When building the overall installer executable:
~/.local/share/desktop-directories/SANITIZEDMENUNAME.directoryis untouched~/.local/share/applications/*.desktopfiles are untouched~/.config/menus/xfce-applications.menuis untouchedWhen running the
.shinstaller script:~/.local/share/desktop-directories/SANITIZEDMENUNAME.directoryis overwritten but unchanged~/.local/share/applications/*.desktopfiles are overwritten (and now have the correct paths inExecandIcon)~/.config/menus/xfce-applications.menuis untouched~/.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 theMergeFileit is otherwise identical to the file with the correctXDG_MENU_PREFIX. This "wrong" file seems to do neither harm nor good (deleting it has no effect).Next steps
make a PR intoI think (?) this won't be necessary; what will be necessary is pinning the version ofconstructorto do similar things tomenuinstw/r/t usingXDG_MENU_PREFIX. Otherwise, users (who just run the installer, not build the menu package) will still see our icons in theOthercategory.menuinstthat gets used when invokingconstructorto build the executables.menuinst main(until they make a release); or update our makefile/env to use my fork+branch ofmenuinstCategory=MENUNAMEas 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 variousthis is a bug in.desktop,.directory, and.menufiles when simply building the menu installer package (because, at that point, they aren't functional because the paths in the.desktopfiles are all placeholders)conda-buildmatthew-brett commentedon Jun 6, 2025
That seems like a very good idea - if only to clarify our understanding in writing the issue.
matthew-brett commentedon Jun 6, 2025
Is this a bug in
menuinst? That too would be good issue to raise - what do you think?drammock commentedon Jun 6, 2025
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
menuinstfunctions/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.matthew-brett commentedon Jun 6, 2025
Yes, maybe see if upstream are OK to help guide you to a shared understanding ... ?
drammock commentedon Jun 6, 2025
conda/menuinst#342conda/conda-build#5736
drammock commentedon Jun 6, 2025
conda/menuinst#343
drammock commentedon Jun 12, 2025
@matthew-brett I'm copying below the "Next Steps" from above; I think the one actionable thing at the moment is "decide if we want a branded folder, or just put our icons in
Sciencecategory". Do you have an opinion on that?make a PR intoI think (?) this won't be necessary; what will be necessary is pinning the version ofconstructorto do similar things tomenuinstw/r/t usingXDG_MENU_PREFIX. Otherwise, users (who just run the installer, not build the menu package) will still see our icons in theOthercategory.menuinstthat gets used when invokingconstructorto build the executables.menuinst main(until they make a release); or update our makefile/env to use my fork+branch ofmenuinstPR marked as ready for review, and CLA signedCategory=MENUNAMEas a bug (or at least, make a feature request to add a top-level "Category" field to the schema). Reported; awaiting response(maybe) figure out how to avoid actually installing the variousthis is a bug in.desktop,.directory, and.menufiles when simply building the menu installer package (because, at that point, they aren't functional because the paths in the.desktopfiles are all placeholders)conda-buildand won't affect end users, so not a blocker.matthew-brett commentedon Jun 12, 2025
I vaguely lean to branded. What do you think?
drammock commentedon Jun 12, 2025
same.