| dhaumann | |
| cullmann |
| KTextEditor | |
| Kate |
Fixes Kate/KWrite's menu-bearing toolbar buttons so that they all show their drop-down menus immediately when clicked, instead of requiring a click-and-hold (which is the normal Qt behavior for toolbar buttons with menus).
Note: due to a Breeze design choice, this patch has the effect of removing the downward-pointing arrow that lets you know that the toolbar button will open a menu. There's an open patch that changes that, though: D13064
BUG: 353747
FIXED-IN: 5.47
Added Schema, Mode, Intentation, Bookmarks, Highlighting and Scripts buttons to Kate's toolbar and clicked them. They all showed their drop-down menus immediately.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Hello,
I would appreciate that you rephrase the description for this patch (and others where the same comment appear): the dissapearing arrow with breeze is not a *bug* in breeze, but a (conscious) design choice, that is discussed in D13064 and in the bug attached. D13064 is not fixing that bug, it is a proposal to revert that design choice.
The same holds true for other actions such as: Tools > Highlighting, Mode, Indentation, Script.
Question here is: Is this delayed thing needed for building the contents on-the-fly (look at the aboutToShow() functions)?
I don't think being delayed was a deliberate choice; it's simply the default interaction method for toolbuttons that open menus in Qt (for some odd reason). Every menu toolbutton throughout KDE software that shows its menu instantly does setDelayed(false);, and I've never seen the menu have to visually build itself while open.
Let me handle those other cases with this patch, too.