Bug 509033 - The new floating Selection Action Bar cannot be moved by a stylus and its current design is causing usability issues
Summary: The new floating Selection Action Bar cannot be moved by a stylus and its cur...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Selection (other bugs)
Version First Reported In: nightly build (please specify the git hash!)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-02 15:09 UTC by Tyson Tan
Modified: 2025-10-02 05:16 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2025-09-02 15:09:54 UTC
SUMMARY
Since August 27, 2025, Krita Next now has floating Selection Action Bar whenever there is an active selection. I can use a mouse to drag the Action Bar around using its right handle, but I can't drag it with my stylus.

Tested with krita-5.3.0-prealpha-57121616e6-x86_64.AppImage (2025-09-02)

I would like to express my concerns about the usability issues this new feature may pose for artists. While the Action Bar can be beneficial on an Android Pad, where context menus and keyboard shortcuts are limited, it significantly hinders my workflow on a desktop.

The bar obstructs the canvas content when it appears. When I create a selection that needs moving or transforming, I require an unobstructed view of everything around it to ensure I'm making the right decision. The constant need to move the Action Bar out of the way is frustrating and disrupts productivity.

It seems clear that this bar should either stick to a corner of the canvas or remain within the Tool Options panel. Additionally, not everyone will easily notice that they can drag the right handle; while I have experience in UI/UX design, many users might struggle with this and become frustrated by their inability to reposition the bar.

If we are to keep this UX design as is, I recommend adding an option to disable it—preferably directly on the Action Bar or within the Tool Options panel.
Comment 1 Ming Chuan 2025-09-04 05:23:54 UTC
There is an option to disable it under Configure Krita -> General -> Tools

It's probably debatable that whether it should be enabled by default, on android and desktop
Comment 2 Tyson Tan 2025-09-05 01:08:08 UTC
(In reply to Ming Chuan from comment #1)
> There is an option to disable it under Configure Krita -> General -> Tools

That's exactly why I made my point in Comment 1 -- This option is hiding so deep and the wording so vague that not many people can find it. We should have an option to turn it off in the front face of the canvas UI, because it's a major showstopper for those don't like it.

For the Option, I suggest we change the wording.

Selection Actions Bar -> Selection Actions Floating Bar/Panel
Because without "floating", people are likely to associate this with the Toolbar area.

Enable Selection Actions Bar
Add tooltip when hovering: Display a floating toolbar with related actions whenever a Selection is created.

Function wise, I think we should add 2 actions to make it actually useful:
1) Add to Selection
2) Subtract from Selection

These are essential to create a clean selection, and should be placed next to Deselect All. I can't recall once I didn't use them when doing selection stuff. The current Tool Options panel approach is using a state switch for them, which is not intuitive or nimble enough for actual use case.
Comment 3 Tyson Tan 2025-09-05 01:18:13 UTC
I would also like to remind everyone that on this webpage: https://krita.org/en/features/ Krita advertises itself to have "An intuitive user interface that stays out of your way." However, this bar does the opposite. It obstructs the canvas and makes the UX unnecessarily janky. I do believe it can be useful, but it should stay out of the way and stick to a corner of the canvas.
Comment 4 Ming Chuan 2025-09-05 04:40:14 UTC
Thanks for sharing your insights! I agree with you, though I’m just a user (who also don't need the bar) passing by. I noticed a link to the community discussion from the merge request: [Selection Action Bar - Develop / Feature Requests - Krita Artists](https://krita-artists.org/t/selection-action-bar/48767), posting there might help increase visibility these insights
Comment 5 Emmet O'Neill 2025-10-02 03:31:32 UTC
Hi Tyson, thank you for the bug report and your feedback.

For the bug report part, I believe that tablet/stylus interactions with this panel have been fixed as of git commit b87a27297dad0b337d3eb0a7dec951ad11eb2b2b "SelectionActionsPanel: Fixed tablet input". 

Testing with my Huion hs610 tablet on Linux has shown no additional issues with moving the panel, using the various action buttons, drawing, making new selection, etc. With that, I'll be marking this bug as "FIXED", but please feel free to reopen if I've something still isn't working correctly and I'll do my best to fix it as soon as possible. :)

Just for context, this feature was added as a part of this year's Google Summer of Code program, so it had a slightly different design and implementation process than a typical Krita feature. 

With that said, we obviously want it to be a net positive for artist workflows in general, so I'll make sure to pass that on to the team. Priority #1 is making things better, not worse. Ming Chuan already mentioned that it can currently be disabled in the `Configure Krita -> General -> Tools` submenu, but ideally we can iterate on the design to the point where it will be less out of the way. (If not, then we can discuss disabling it by default or going back to the drawing board entirely with the idea.)

Even though the GSoC 2025 period is now over and this feature was merged, nothing is final and we will keep iterating on this until we get it right, and so your feedback (as well as yours Ming Chuan!) is greatly appreciated.

-- Marking as fixed, please reopen if this issue still persists! --
Comment 6 Tyson Tan 2025-10-02 05:16:02 UTC
Thanks Emmet, I can confirm that the stylus dragging action is fixed.


# Dragging outside of the right handle clicks the buttons

In recent iterations, I appreciate being able to drag anywhere on the Action Bar to move it. However, dragging outside of the right handle still triggers button clicks, which may not be ideal. Should I open a new bug report for this issue?


# The Action Bar is useful

I'm aware of the GSoC story from my posts on Krita-Artists.org and by translating Krita Monthly Update - Edition 30 on krita.org.

Despite my criticism, I appreciate the general concept of this Action Bar. Recently, while waiting for hours in a hospital, I used Krita with a Wacom One 12 Pen Display in vertical orientation and an 8bitDo Micro Gamepad for shortcuts. By pressing Tab to hide all UI elements, I maximized the canvas area. The Action Bar enabled me to perform more selection tasks without constantly unhiding the UI. This is beneficial for our Android users and others with similar setups.

Therefore, I believe we should not disable this function by default. It is essential to Krita's future UI/UX design but requires some UX adjustments to improve its usability before releasing it to our general users.


# Using Text-based menu instead of Icon-based bar

Relying solely on icons is not effective. I often struggle to understand their functions without hovering over them for tooltips, which disrupts my confidence in clicking. In my experience, 3 icons are memorable, while 5 become overwhelming. If a feature requires thought before use, I'm less likely to engage with it.

Instead, we can implement a text-based menu:

[ Select | Edit | # ]

[ Select ]
  - Select All
  - Invert Selection
  - Deselect
  - "Back" Icon

[ Edit ]
  - Move
  - Transform
----------
  - Fill
  - Clear
----------
  - Crop to Selection
  - Copy to New Layer
----------
  - "Back" Icon

features a "Gear" icon to open a configuration dialogue for adjusting settings (adding/removing actions). The entire bar is draggable, eliminating the need for a dedicated drag handle.

The "Back" icon in each sub-menu allows users to close the menu without fearing of clicking on the canvas.

This design minimizes the need to interpret icons and enables us to add more functions to the sub-menu without significantly obstructing the canvas.


# Positioning

Almost all my issues with the Action Bar stem from its positioning, which obstructs the canvas. While centering it under a selection helps users understand context, placing it in a corner would be less intrusive, though connections between the selection and the bar might go unnoticed.

It really is a trade-off.