GNOME Bugzilla – Bug 739480
Applications Menu Extension Ignoring Subfolders
Last modified: 2017-11-24 17:34:10 UTC
I am using Ubuntu GNOME 14.04 LTS [amd64]. I am using Alacarte 3.10.0-1ubuntu2 to edit my applications menu. When I add a subfolder to a category in the menu, it does not show in the Applications Menu. Instead, all items in the child folder appear in the parent folder.
I'm afraid not supporting subfolders is intentional[0], not only in the app picker, but as well in the application menu. [0] http://tworivers.com/blog/archives/267
*** Bug 741067 has been marked as a duplicate of this bug. ***
*** Bug 747253 has been marked as a duplicate of this bug. ***
The link seems to have changed and is now found at: http://tworivers.com/archives/267 The article argues that instead of submenus you should use headers. That is a reasonable argument. Then I argue that we should follow the suggestion of the article and separate the submenus into headers instead of submenus.
(In reply to Moo from comment #4) > Then I argue that we should follow the suggestion of the article and > separate the submenus into headers instead of submenus. Not supporting submenus is intentional, so this is likely still a WONTFIX, but fine, let's get another design opinion with that suggestion.
For what it's worth, the history on that link is not "oh, headers are a so much better way to express nested menus", but more like: me: We don't want to support nested menus, do we? designers: Nooooooooooo! me: Ok, do we have a reference on that I can cite? designers: not really, didn't google turn up anything? me: http://tworivers.com/blog/archives/267 maybe? designers: sure, whatever So I wouldn't keep my hopes up too much about submenu support (in any form) ...
I see. One of the reasons the above article argues against submenus is that they can when placed on the right side of the screen make the submenu appear to the left, which is rather strange. However, the app-menu is GNOME is *always* in the top-left corner. Hence that can never happen. Hence the argument in the article does not apply to this particular use case. Right now the app-menu has no support for subgroups whatsoever in any form (be it through headers or submenus or anything else). I would like to get the UI team to investigate this and get feedback on which design choice they favor. Maybe we could get a implementation going if we get consensus how its to be done?
(In reply to Moo from comment #7) > I would like to get the UI team to investigate this and get feedback on > which design choice they favor. The design choice they favored so far is: don't support nested menus. So before looking into *how* to best support submenus, you first need to convince the design team on the question of *whether* to support nested menus.
How is a menu with 50+ items more usable than having proper sub-menus? Would it be possible to support nested menus and have it deactivated by default? Kali Linux relies on nested menus (see picture in this article for example: https://www.kali.org/news/kali-linux-metapackages/) and we might be willing to sponsor this feature if it helps. Florian, do you think this would be a reasonable solution? The Debian menu also had this interesting concept of declaring menu entries in a relatively deep structure but collating those sub-menus together as long as you don't go over X (let's say 10) entries in the menu. So if you have 200 games installed, you get a structure like "Games > Arcade", "Games > FPS" etc but if you only have 5 games installed then you get everything below "Games". This could also make a good compromise here, don't you think so?
There's a reason we developed the shell overview as a better way to select applications. A menu with 50 items is as unusable as a deep menu hierarchy. I would say: if you want to have deep menus, write your own extension.
That's not really helpful. Here were are in a bug about apps-menu extension and there's no reason to discuss the merits of a menu vs the shell overview. Then if you have many packages installed, you have many packages installed, it's a fact and you can't change anything about it. But the apps-menu can be made smarter to better deal with those... and this is what this bug is about. I have made a concrete suggestion that avoids sub-menus when they don't bring anything and that still respect them when they are defined and when the menu would be too large. What's the drawback of my suggestion? If that enhancement can be merged in the extension, Kali is ready to fund its development. If anyone reading this wants to implement this, feel free to send a quotation to me. We can obviously fork the extension but it's not in the interest of anyone. We don't need multiple menu implementations.
Created attachment 303630 [details] [review] Show subfolders in applications menu extension I looked at this and came up with the attached patch, developed against 3.14 but tested against gnome-shell 3.14 and 3.16. The main changes are: - in _display() and _loadCategory(), we load non-toplevel categories, keeping the tree structure. sub-categories are implemented using submenus. - in _createLayout(), the scroll view is implemented in a custom PopupMenu.PopupMenuSection subclass so that the submenus work properly. - some hacks are removed, such as scrollToCatButton() or _onMotionEvent() for categories, as those were causing issues - One thing that I didn't manage to fix in a nice way is setting the categories box width to a value suitable for the sub-categories. There is a failed attempt at doing that, _menuContainerGetPreferredWidth(). I'm sure some things could be done better, e.g. having CategoryMenuItem and ParentCategoryMenuItem share some code. But I think this is a good start and works fairly well, and we can polish it if there is interest in merging this feature.
Review of attachment 303630 [details] [review]: We don't want submenus, so marking it as such to get it off the review list
I would really love to have submenus. Now the menus are all messy with unrelated entries grouped together. Having hierarchal submenus would logically group related applications into their own submenus. This would increase usability and make things easier and faster to find. On menus with many entries scrolling is currently required, this is highly undesirable.
(In reply to Moo from comment #14) > Having hierarchal submenus would logically group related applications into > their own submenus. This is debatable, considering that the grouping is generally done according to someone else's logic - or rather: many different people's logics - that may or may not match the user's expectations. Yes, stuff like games are usually pretty clear-cut, but already something as simple as a mail program can be found in "Internet" or "Office", depending on the program - and making that "Internet/Mail", "Internet/Communications" or "Office/Productivity" doesn't improve that problem. In other words: (1) Locating a particular item in a menu is easier when there are not too many items (2) Finding a particular menu is easier when there are not too many menus Categories do help with (1), but they come at the cost of (2) - as always, there's a balance to hit. You think the balance should be shifted a bit more towards (1) by adding one or two additional levels - fair enough, that's certainly a valid opinion. But that doesn't make our opinion of stressing (2) a bit more by keeping the menu hierarchy flat invalid ...
(In reply to Florian Müllner from comment #15) > This is debatable, considering... > (2) Finding a particular menu is easier when there are not too many menus Fair enough. But then i think something should be done to avoid having to scroll. The menus should have more height, to fit more entries in them, so the user can quickly see the item, without have to scroll to find what he is looking for.
As stated before: Not supporting submenus is intentional, so closing.