FEATURE: 404942
FIXED-IN: 5.16.0
Details
Diff Detail
- Repository
- R31 Breeze
- Branch
- scrollable-humongous-menus (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 9034 Build 9052: arc lint + arc unit
Please not. I use wide menus extensively, e.g. for bookmarks, and are not keen to wait eons to find an item because of the slow scrolling.
This issue has an origin from : https://github.com/psifidotos/applet-window-appmenu/issues/45
menus dont respect the available screen size
FWIW, there is a way to do it on a per-menu basis using a combination of
QWidget::setStyle and QProxyStyle
Not sure that would really help in this specific case since the bug reporter wants his bookmarks menu to be scrollable rather than expanding, while @cfeck wants the same menu to be expanding rather than scrollable!
I suppose (sigh) I could make it configurable...
The problem is that adding this property limits to a single column. It should show all columns, and additionally allow the user to scroll. For a menu that only has a few more items than fit in a column this is acceptable, but for the menu in the referenced ticket it is not.
Yeah, that's the point. :)
Well the person who filed that ticket clearly didn't find the expandable menu acceptable, or else they wouldn't have filed it! :)
Horizontal menus are fast, but unusable or hard to read if they get too large. Scrollable menus with the arrows that you hover over are annoyingly slow if you don't use a scroll wheel to scroll, but don't block the entire screen if you have a large number of items. In both cases, the best solution from the user's end is to make more folders so that the list doesn't overflow.
What he complains about is that items are unreachable. Yes, it should scroll. Either horizontally or vertically. A scrollbar would be perfect so you see how much you don't see. In addition to multiple columns, if there are 1½ or more.
Maybe making it configurable would make most users happy :)
Another unexpected behavior in this issue is that if you are using the Global Menu widget, the emerging menu (that supposedly doesn't fit the screen) shouldn't cover the panel that has the Global Menu widget.
kstyle/breezestyle.cpp | ||
---|---|---|
678 | if (cond) { return true; } else { return false; } ⇒ return cond ? true : false; ⇒ return cond; |
FWIW, there is a way to do it on a per-menu basis using a combination of
QProxyStyle is super heavy as it creates an entire new instance of BreezeStyle. My approach would have been to bodge KStyle to read menu->property("_kde_scroll_menu").toBool() and than use that in the rare instance where we want scrolling (e.g. global menu)