| dfaure | |
| ngraham |
| Frameworks | |
| VDG |
Drag-and-drop of toolbar actions is a nice feature that currently is
basically hidden to end users. The only way to enable it is to open the
"Configure Toolbars" dialog (!). Some applications (e.g. Kate) open the
dialog as modal, so there is no way at all to use this feature in such
apps.
This patch implements a global 'edit mode' (that can be enabled via
context menu) in which the user can move the whole toolbar or drag the
actions within the toolbar.
| No Linters Available |
| No Unit Test Coverage |
Won't un/locking already change the fact that they can be dragged? Or what is it going to become draggable?
| src/ktoolbar.cpp | ||
|---|---|---|
| 410 ↗ | (On Diff #22216) | Isn't it better to set a parent like for the other ona than use the QScopedPointer? |
No, "unlocking" means you can drag the whole toolbar, e.g. from the top to the bottom of the window. This is for dragging actions within the toolbar instead.
I like the idea.
I'm just not sure about the exact wording of the action, but I'll let the VDG decide on that.
| src/ktoolbar.cpp | ||
|---|---|---|
| 410 ↗ | (On Diff #22216) | I'm also surprised by the inconsistency, and I bet future readers will be too. As to whether it should all be ported to QScopedPointer, I'm not convinced. Technically, I would bet that deletion by the parent is faster than deleting each children individually with e.g. QScopedPointer (because that will have to remove from the list of children in the parent, so it means N linear searches). |
| 412 ↗ | (On Diff #22216) | Is this a case where &KToolBar::setToolBarsEditable would work, without the need for a lambda? |
My perspective here is that instead of using an actual checkbox to enable the dragging, I would create visual handles instead. Maybe something like this:
Why?
Because checkboxes generally don't enable element manipulation actions
Users prefer "stupid simple" than reading
An icon or visual representation requires less thinking (I agree that my mockup is horrible)
However,
I agree that this could be better executed since probably most users don't know that they can detach toolbar actions and work with them like a sidebar or toolbar
Why don't we do this the way Firefox does it: Have a menu entry that puts the whole UI in config mode.
That works far better then trying to make each individual config feature discoverable.
What I would like to see is that when you open the "Edit Toolbar" dialog that you then can drag around tool bar buttons and drag them from and to the dialog, like Firefox does it and how @colomar suggested. Given you can already re-arrange toolbar buttons whilst said dialog is open, what needs to be added is the ability to drag those from and to the dialog.
Yes, exactly. The closer to Firefox' "Customize" UX, the better. No more separate dialogs, just one mode where you configure your UI.
Yeah. macOS also does something similar, showing a sheet of items that can be dragged-and-dropped to and from the toolbar:
I think we should do something like that here. It would be a huge usability improvement.
That is excellent! But in the implementation, mind the "multiple kxmlgui-clients" use case, like konqueror or kdevelop (or kate I guess). It can make things tricky...
(you drop between two clients, how do you know which one should memorize the action into its kxmlgui file?)
That is excellent!
That was from my very first PlanetKDE blog post back in 2009 :D
And from what I recall, I hit that exact issue you're describing and gave up.
Haha yes almost exactly like that! Maybe today I'd use a sheet instead of a separate dialog window. But I have great faith that the 2019 David is able to conquer the challenges of 2009. :)
