Hm... I'm wondering about the discoverability of this feature, even with tooltips. Tooltips are tricky for stylus users. And I am not sure whether there's any other application that makes use of a button like this. Wouldn't it be better to have a longpress that pops up a menu, an overlay with buttons?

I tested this out and I don't know if it is really that big of a workflow improvement. A zoom that might be more helpful would be one that works like the animation docker. If you open up the timeline docker and look on the left side of it there is an icon that looks like a left/right arrow. If you press and hold, you can drag left and right to change the zoom level. Something like that might be more helpful. Right now with the zoom slider on the popup palette, it is limited to 10% - 200% which has a limited use.

A lot of the functionality recently added is to help tablet users, so using modifiers would not be accessible for them (like people with a Surface pro that only have touch and their stylus).

There is a task in phabricator with all of the things people are requesting from the popup palette... https://phabricator.kde.org/T8548

A better approach might be to take all the feedback from that ticket and come up with an improved design for the popup palette. That way we can try to give it more flexibility that people seem to be wanting.

Hm... I'm wondering about the discoverability of this feature, even with tooltips.

Hey Boud. That's a fair point, and one that I don't really have a good answer to... Users aren't accustomed to right-clicking buttons, and most people probably don't read tooltips at all. I guess the best argument here is that small features designed in this way don't necessarily hurt the workflow of users who aren't aware of them, but they benefit those who do know.

Tooltips are tricky for stylus users.

That may be, at least in the traditional way that Krita currently handles them. But then that may raise a different issue about tablet control.

I do know of some very successful tablet-oriented software that displays tooltips when users Ctrl+cursor over a GUI element. Something to consider at some point maybe.

And I am not sure whether there's any other application that makes use of a button like this.

I know of some other applications that use modifier-clicks on interface buttons for slightly modified behavior, but not right clicks.

Having said that, most desktop applications aren't made with drawing tablets in mind. I have no clue really, but i'd guess that most Krita users use a (budget) drawing tablet as their primary input device and as tablets and 2-in-1 laptops become increasingly common tablet control is likely to become even more significant. So we're talking about input devices with usually something like 4 buttons on the pen and something like another 4-10 buttons on the tablet. On top of that, users may have a keyboard handy, but in a growing number of situations they may not.

So my question is how does the tradition of GUI design square with present and future of hardware design? I certainly wouldn't want to confuse or alienate traditional desktop users who want traditional desktop user interfaces. Having said that, the pop-up palette isn't really designed in light of that tradition, right? I guess my logic here is that if the pop-up palette was designed primarily for tablet users, then all of GUI elements within it should be designed in a similar light - which is something that I think we can already see in things like the rotation wheel/donut. Stepping outside of tradition in light of the input hardware, making full use of what few buttons and sensors that are available.

At any rate, I hope to continue to contribute to Krita as much as possible and I'm sure that as we get to know each other you'll find that I'm not one to be too bound by traditions. =]

Wouldn't it be better to have a longpress that pops up a menu, an overlay with buttons?

Possibly. Although it could be argued that a longpress is just as hidden from users as a right-click.

I considered a variation on that, too - a right-click or longpress would open a little menu with different zoom levels, while a left-click would instantly bring you to whichever zoom level you selected last (or 100% by default). I could be wrong here, but I felt that the most useful zoom levels to jump to were things like fit to page (so artists can see their entire work) and 100% (so they can see it at the proper pixel size). That's why I opted to test this out instead, because it seemed quicker and less cumbersome than navigating a menu just to pick out ~1/3 commonly-used zoom levels.

A zoom that might be more helpful would be one that works like the animation docker. If you open up the timeline docker and look on the left side of it there is an icon that looks like a left/right arrow. If you press and hold, you can drag left and right to change the zoom level. Something like that might be more helpful. Right now with the zoom slider on the popup palette, it is limited to 10% - 200% which has a limited use.

Hey Scott. I agree with this completely and I actually had a similar thought. I do think that a zoom "handle" (not sure what else to call it) similar to the one on the animation docker would be a great fit for the pop-up palette and a significant improvement to the current slider, which in my opinion doesn't feel that great with a tablet and, like you said, imposes a pretty arbitrary restriction on zooming. I'm with you on that one, all the way.

However, that actually doesn't solve the issue that the current "100% Zoom" button, or my Quick Zoom button, tries to solve. Even if the user can zoom freely with a handle, it's still pretty useful to be able to jump to both 100% (pixel accurate) and Fit Page (the equivalent to stepping back from your canvas to see the bigger picture) zoom levels on demand. As such, this means that the 100% button would likely have to stay, even if the zoom slider was replaced with a handle. That's how I see it, at least.

A lot of the functionality recently added is to help tablet users, so using modifiers would not be accessible for them (like people with a Surface pro that only have touch and their stylus).

Fair point. Although, most other graphics tablets do have a handful of mappable buttons, people who use things like the surface don't. If anything, in my opinion that just really highlights how important it is to make effective use of things like the right-click button which almost all tablet pens do have, including the surface.

There is a task in phabricator with all of the things people are requesting from the popup palette... https://phabricator.kde.org/T8548 A better approach might be to take all the feedback from that ticket and come up with an improved design for the popup palette. That way we can try to give it more flexibility that people seem to be wanting.

I had no idea! Sorry again if this wasn't the right place for an "exploratory patch" like this, I'm still very new to phabricator and I get lost here pretty easily! It was kind of a toss-up between posting it here or as an attachment to the mailing list and this seemed like a better place.

Hi, @emmetoneill!

I've just tried to use this patch without detailed reading the manual and I should say that the feature in its current state is absolutely impossible to discover :)

There are two conceptual problems:

1. Right-click and Shift + Left-click are not expected in this place. And why Middle-click is not used? :)
2. There is no feedback on what the button does. It is obvious it switches zoom, but it is quite hard to say to what zoom it changes it. The original button had at least a caption telling it is going to zoom to 100% :)

Possible solutions:

1. The first problem could be solved by switching to a QToolButton with attached menu, like our "New Layer" button.
2. Write somewhere, which zoom mode we are now in :)

PS:
Just to be clear, the proposed solutions are just ideas. I don't insist on them. There might be better approaches to fix the problems.