Use a more conventional dropdown menu style instead of press-and-hold
ClosedPublic

Authored by ngraham on Thu, Jun 6, 2:57 PM.

Details

Summary

Currently, ToolAction menus (of which there is only one, the selection tool menu)
activate the current tool on click, and require a click-and-hold to choose a new tool.
This is a somewhat unfamiliar user interface that I myself struggled with when initially
encountering it, and I've encountered user complaints about it as well.

This patch adjusts the behavior so that clicking on the arrow on the right side of the
button will open the pop-up and allow choosing another tool, which is a more common
method of implementing the feature. The patch also adjusts the tooltop accordingly.

Test Plan

Diff Detail

Repository
R223 Okular
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
ngraham created this revision.Thu, Jun 6, 2:57 PM
Restricted Application added a project: Okular. · View Herald TranscriptThu, Jun 6, 2:57 PM
Restricted Application added a subscriber: okular-devel. · View Herald Transcript
ngraham requested review of this revision.Thu, Jun 6, 2:57 PM
filipf added a subscriber: filipf.Thu, Jun 6, 3:00 PM

I was just having issues with this when I was looking at D21621. I had completely forgotten that click and hold is how you change it.

As for this solution, I haven't tested it but the hit area is quite small isn't it?

It is, yes. If we don't like that but want to keep this dropdown menu button, the only alternative is to do button->setDelayed(false) which will make the whole button show the dropdown on click, but this will remove the ability to quickly enable the current tool and also expose us to https://bugs.kde.org/show_bug.cgi?id=344746

+1 to what? The patch's current change, or what we're still discussing? :)

abetts added a comment.Thu, Jun 6, 4:00 PM

+1 to what? The patch's current change, or what we're still discussing? :)

On visuals. I hadn't seen this patch until now. :)

ndavis added a subscriber: ndavis.Thu, Jun 6, 5:03 PM

+1, pressing and holding feels unnecessarily slow.

ndavis accepted this revision.Thu, Jun 6, 5:23 PM
This revision is now accepted and ready to land.Thu, Jun 6, 5:23 PM
This revision was automatically updated to reflect the committed changes.
aacid added a subscriber: aacid.Thu, Jun 6, 8:53 PM

I don't know why you say "it's a more common way", kmail does exactly what okular did, thus, being consistent.

Now try using this with a touch screen, how do you click on the 2x2 pixels that represent the arrow?

But hey, don't give me enough time to give feedback so progress can't be stopped 👏 👏 👏

I don't know why you say "it's a more common way", kmail does exactly what okular did, thus, being consistent.

...Consistently bad! :) KMail is wrong too, because press-and-hold to show a popup menu is just a bad UI. BTW other apps of ours like Spectacle do it this way.

Now try using this with a touch screen, how do you click on the 2x2 pixels that represent the arrow?

I don't have trouble hitting the arrow of a split button with my laptop's touchscreen. It's not the easiest thing in the world, but it's hardly impossible. However this is a real issue--for mouse users too, not just touch--so it seems like we should make the arrow part of a split button wider in Breeze. And/or we can make this menu in Okular not be hidden behind a split button at all, and always open its popup on click/touch. But I don't think it makes sense to revert this just to make things better for the very small number of touch users who actually figured out that you need to press-and-hold to open the menu (I never did until I became a KDE developer).

aacid added a comment.Thu, Jun 6, 10:32 PM

Ahhhh, yes, the everyone does it wrong except me reasoning.

Ok.

clicking on the arrow on the right side of the button will open the pop-up and allow choosing another tool, which is a more common method of implementing the feature.

How do you know how common click-and-hold is, if no one discovers it? (Play Spore :) and look how a bunch of buttons changes function when you click-and-hold it or hold Alt while clicking it or hold Tab while clicking it...)

If instant popup mode will be accepted now, I will look at completing D21195.

clicking on the arrow on the right side of the button will open the pop-up and allow choosing another tool, which is a more common method of implementing the feature.

How do you know how common click-and-hold is, if no one discovers it? (Play Spore :) and look how a bunch of buttons changes function when you click-and-hold it or hold Alt while clicking it or hold Tab while clicking it...)

Okular is a document reader, not a 11-year-old video game. People don't generalize UI conventions they learn in video games because as a rule video games have totally custom UIs that don't follow typical conventions at all.

By way of illustration for press-and-hold-to-show-a-menu being unintuitive, I literally just 5 minutes ago fixed a bug where a user couldn't figure out press-and-hold: https://bugs.kde.org/show_bug.cgi?id=408346.

Couldn’t the whole class ToolAction be replaced by KActionMenu now?

Just set the default action at startup and connect triggered(QAction*) to setDefaultAction(QAction*) and Okular::Settings.

Seen here: https://www.walletfox.com/course/customqtoolbutton.php

Sounds like a good patch opportunity! :)