I like this idea :). It gives feedback for all values of parameters, without any clicks.

I have some idea to improve it: 1 image = 1000 words. IMHO near brush presets name (in this example 'Ink G Pen 10') should be icon (thumbnail) of current brush preset. This would gives better understanding, some kind of self explanatory.

We have a hot-key (type:press&hold) for fast calling a menu with list of custom options. Control with gestures: up-down — select a field, left-right — change & apply value. With invisible cursor.

Practically it's like this:
Press&hold a hot-key, move a 'cursor' up or down (it's scrolling a list with unlimited length; good for loop), move a 'cursor' left or right (change & apply value)... [repeat for all required options]... release a hot-key.

Fast, usable, modern.

P.S. Customizing may be with right click for any option field in GUI and select option 'Send to custom menu' (inside menu just press a button 'Delete' or 'X' and field is gone). Good if it available and for switches too, like a 'false-true' field for it, and all same principles.

Or may be, we have a long list with fixed options and we can switches it in menu (see top image) for fast access in custom menu. But...

@alexeyost: but nonexistent in Krita. In itself, it's not a bad idea per se, but in the context of a complex program like Krita, it's not a great idea to add a new, local UX. This only makes the program harder to learn.
I don't even think this would be faster to edit sliders using gestures than clicking on the sliders. As this menu is right on the canvas, where you paint, you have little mouse travel to tweak parameters, and you're working with the exact same sliders you have everywhere in Krita.

@eliotj: And having an icon on top of the brush's name... this would look good I think, but why not remove the name altogether? After all, this widget will only affect the currently selected brush preset. It's just like opacity, flow, and size sliders on the toolbar: you know that they only affect your current brush, without the name or any reminder of the selected preset.

@gdquest
Yes, it is exact same sliders and switchers what we have everywhere in Krita. But in one simple menu (fly-on-the-canvas) for fast access. And this table stored inside a brush preset.
}

And it should be possible to customized it by painter. Adding, deleting, sorting.

Simplest way for adding, if we may send everything in brush settings inside this menu just clicking on option and select 'Send to custom menu'. Options table by default — https://phabricator.kde.org/T1749#21686 — if we create a new preset for specific brush engine.

Simplest way for deleting, if we may delete current field just by pressing 'delete' button.

Simplest way for sorting, if we may move a option field right inside a custom menu. Not in another UI inside...inside...inside Krita — it's bad way!
}

Only one key used for calling this menu (like Shift+LMB), only one short vertical stylus move to select a field and one horizontal stylus move to change a value (switchers too). It's new way for very old program, but fresh way on 21st century. ;)
}

And this menu should to keep last field position in focus for next calling (default is Brush Size).
}

In use:

PressKey(Call menu) -> move stylus 'ГLГL' (we select and adjusted 4 options in 3 second) -> ReleaseKey(Close Menu). Is it hard to learn?! You are joking, aren't you? :)
}

P.S. And it all not 'a new, local UX'. It's compilation of UX in one complex for Krita. Example, more then 10000000 of people use a 'Snapseed' (it has similar control) and it's only one example. Try it.

Another post — https://phabricator.kde.org/T1749#33619

@alexeyost : You're talking about adding a looping list of parameters (new type of UI element) and to control menu elements with gestures (currently only used for the brush size, directly on the canvas). Yes, this is new UX.

Now, even if it is intuitive to you, you shouldn't assume that adding a new way of controlling a menu on top of an already complex program will come at no cost for every other user. I've done enough UI design for games to know how little it takes to tip people off. I learned to start with the simplest option and to iterate on it, based on the users' input (players in my case).

That's why I prefer Scott's initial proposal. Simple, does the job, consistent with existing UX in Krita, and shouldn't take too long to implement for Dmitry.

@gdquest : Yes, this is a little new UX in Krita currently. But not new UX globally, I mean. And yes, potentially it should replace a Shift+LMB staying a rapid. And if there is a choice between a pie or list, list is more usefull for Krita (in all my experience). And list is easier and clearer to configure.

And yes, Scott's initial proposal is more traditional for Krita and it's good. But for it we have one more buttons on path to change options (bit more slow access, bit more irritations for people), and more difficult control for tablet on long lists. For mouse it's not a problem, because mouse has a scroll wheel, but for stylus no way for it in Krita (for example Blender has it) and we should pickup a scrollbar, it's outdated.

Nevertheless, primarily I propose separate this menu from the popup palette (with its own hot-key. also it can be parallel) and add unlimited customizing for it. And only secondary about cool modern control with gestures and looping list of parameters... It's so bad that we can't use A/B testing for it and other in Krita. :\

P.S. Well, maybe I'm not making myself very clear... That's because English is not my first language.

@alexyost. You have an interesting propsal. The main concern I have about your solution is that you cannot use hot key shortcuts on a tablet. You only have the UI on the screen and side button on the stylus. The settings must be on one of those, or it can't be accessed. There might not be a keyboard

@scottpetrovic
I know some people who have a simple tablet and stylus no works with side buttons. What will we do with it? :)

And all professional digital painters (all whom I know) do works like 'one hand on tablet and second hand on keyboard' (or duplicate a some keyboard keys on tablet keys for tablets with many keys... like a Shift, Alt and Ctrl key).

But ok, why in Dmitry's proposal no problems with hot-key like Shift+gesture? (And many gestures, not only two for all!)
— https://phabricator.kde.org/T1749

I'm just trying to understand this limitation for keyboard. (And let's not forget about parallel call)

Yes, stylus that have no way to right-click will be left behind. All of the biggest tablet's that work with Krita have a side button, so this is not an issue. Things like IPad's do not work with Krita, so this product isn't considered.

You are correct that existing desktop applications design their UI around the requirement of a keyboard. I do not think we should design around the past, but the future.

Programs like Photoshop do not work very well on a tablet. It was designed at a time when a keyboard was a requirement and tablets did not exist. The UI is very rigid in these programs and they are not flexible to accommodate tablet screens. They also seem to ignore that a person's arm is in the way of a UI and obstruct much of the screen.

Dmitry is an amazing programmer, but he is not a UI designer. He created this task originally to share what features he had in mind in the form of a mockup. He is not saying what the final UI will look like.

I remind. It's the proposal to replace the current method of changing only one brush parameters — the brush size with "Shift + Drag LMB" — with the expansion of amount the available parameters. And only one additional gesture (vertical) for it.

More options on "Shift + Drag LMB"

P.S. Why is it still necessary? 'Popup' become too monstrous and have slow workflow currently...