-
Notifications
You must be signed in to change notification settings - Fork 48
Description
Checklist
- I added a descriptive title
- I searched open requests and couldn't find a duplicate
What is the idea?
The menu.json schema should include a top-level key for Category, and the builder should look at the categories specified by the individual menu items when determining whether to create files associated with the new menu folder.
Currently the schema only specifies a Categories key under each entry in menu_items > platforms > linux. There is no way to control the new menu folder's category independently from its name. In other words, currently the builder creates ~/.config/menus/applications.menu with the following (partial) content:
<Menu>
<Name>MENUNAME</Name>
<Directory>SANITIZEDMENUNAME.directory</Directory>
<Include>
<Category>MENUNAME</Category>
</Include>
</Menu>Notice how MENUNAME gets used both as the name and the include category. This means if you want your new menu item(s) to appear in your new menu, you MUST specify in menu.json something like:
{
"$schema": "...",
"$id": "...",
"menu_name": "MY MENU NAME",
"menu_items": [{
"name": "Specific shortcut name",
"description": "...",
"command": ["..."],
"platforms": {
"linux": {
"Categories": "MY MENU NAME" <----- CURRENTLY NECESSARY, BUT UNEXPECTED/CONFUSING
}
}
}]
}Why is this needed?
Because the user needs to enter "Categories" manually, they'll probably look at the XDG spec, see that it's possible to use builtin categories or make custom categories, and follow the advice to call theirs X-My-Custom-Category, e.g. https://wiki.xfce.org/howto/customize-menu which says:
It is recommended to make up a custom category starting with “X-”, which is the prefix of non-standard categories by convention.
But this won't work (unless they name their menu folder "X-My-Custom-Category", which nobody would think to do).
What should happen?
- a new optional top-level "Category" key (ignored on Win/macOS I guess?) to define the Include Category of the new menu folder. If
null, fall back tomenu_name. - internal logic to examine the values in each
menu_items > platforms > linux > Categoriesentry to see if the menu folder's category is even being used by any of the menu items. If not, don't bother creating the associated.directoryfile, and don't create/modifyapplications.menueither.
Additional Context
Consider also a converse case, where one wants the menu items to go into one or more of Linux's default categories (Science, Development, Internet, Office, whatever) and doesn't want to create a new menu folder at all. In that case, each menu item can independently define which category or categories it should appear under, but a new menu folder will still get created even if none of the menu items will show up inside it. Luckily it's not as bad as it might be, because menu folders with zero included items are automatically suppressed by the desktop environment... but it still feels a bit "crufty" to be generating a ~/.local/share/desktop-directories/SANITIZEDMENUNAME.directory that is not needed/used, and modifying ~/.config/menus/applications.menu in ways that have no affect on the user. This case is what motivates point (2) in the "what should happen" section, above.