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

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

In D21622#475230, @ngraham wrote:

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

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

+1, pressing and holding feels unnecessarily slow.

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 👏 👏 👏

In D21622#475508, @aacid wrote:

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).

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

Ok.

In D21622#475197, @ngraham wrote:

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.

In D21622#475905, @davidhurka wrote:

In D21622#475197, @ngraham wrote:

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! :)