Repository navigation
Improve menu location for Linux installs #11
Description
Activity
Hmm - see linked issue. We do actually specify (in
menu.jsonthat the items should go in theSciencecategory, 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 isxfce-applications.menu. - Changing this line to say
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.
- in my desktop environment (XFCE) there is no MergeFile
I'm also asking over at conda/menuinst#339 (comment) ....
OK, here is what I've now tried:
Details
- making
Categoriesa single string"Science"instead of an array["Science"] - adding semicolon to
"Science"per https://github.com/conda/menuinst/blob/5c377464c11a9659c88d1490b581dbdaa747e67d/menuinst/data/menuinst-1-0-2.schema.json#L162 - changing
menu_nameto "Science" or "Science;" instead of "Scientific Python (0.1.0_0)" - changing
MergeFilemanually within~/.config/menus/xfce-applications.menuto point to /etc/xdg/menus/xfce-applications.menu
Here is what works:
- each
menu_iteminmenu.jsonmust have category "Science" - the
menu_nameinmenu.jsonmust also be "Science" - The resulting menu file must be renamed to
~/.config/menus/xfce-applications.menu(to add thexfce-prefix on the basename)
The resulting contents of
~/.config/menus/xfce-applications.menuare:<!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
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:- making
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.menuandxfce-applications.menucreated 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.
- I now see both
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:<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;
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:- MENUNAME="Scientific Python", each
menu_itemgets Category="Scientific Python"; result is a new top-level menu folder called "Scientific Python" with (only) our icons in it - MENUNAME="whatever", each
menu_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.
- MENUNAME="Scientific Python", each
When building the overall installer executable:
~/.local/share/desktop-directories/SANITIZEDMENUNAME.directoryis untouched~/.local/share/applications/*.desktopfiles are untouched~/.config/menus/xfce-applications.menuis untouched
When 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- 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 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. - 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 ofmenuinst - (maybe) report
Category=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-build
-
- (maybe) report
Category=MENUNAMEas 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) report
- (maybe) figure out how to avoid actually installing the various
.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)
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
- (maybe) figure out how to avoid actually installing the various
.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)
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
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.- (maybe) figure out how to avoid actually installing the various
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 ... ?
Reacted by Matthew Brett- (maybe) report
Category=MENUNAMEas 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.
Reacted by Matthew Brett- (maybe) report
@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. - 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 ofmenuinstPR marked as ready for review, and CLA signed - (maybe) report
Category=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.
-
I vaguely lean to branded. What do you think?
I vaguely lean to branded. What do you think?
same.
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)