Bug 408443 - Input field on sliders don't lose focus when clicking outside of the input field
Summary: Input field on sliders don't lose focus when clicking outside of the input field
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: Usability (other bugs)
Version First Reported In: 5.2.6
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-08 01:58 UTC by jimbo
Modified: 2024-11-15 15:00 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 jimbo 2019-06-08 01:58:45 UTC
SUMMARY
Input field on sliders don't lose focus when clicking outside of the input field

STEPS TO REPRODUCE
1. Select the Magic Wand Tool and Right Click any slider to enter it's input field
2. Left Click within the Tool Options panel

OBSERVED RESULT
The input field still has focus after clicking away

EXPECTED RESULT
The input field loses focus

SOFTWARE/OS VERSIONS
Windows: Windows 7 Professional 64 bit
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
This behaviour can confuse new users as the caret is tiny (and it can be covered by the slider fill if the number is large enough) so when they try to left click the slider again it no longer moves (because they are in the input field). This breaks what the user expects the slider to do [and has caught me out a few times when I first started learning Krita].

So, should you even allow the user to use left click to change the caret position while on the slider? We only use it for numbers, which don't really require that level of editing and when it interferes with the action of the sliders it should be considered for removal.

P.S. Just noticed the panel, toolbar and brush settings now have consistent Right Click behaviours. Thanks for fixing that!
Comment 1 wolthera 2019-09-21 15:47:27 UTC
Not sure what we can do about this.
Comment 2 Vitamorus 2024-11-15 15:00:24 UTC
Re-confirmed for 5.2.6.

Based solely on Wolthera's comment it might be a limitation with Qt (resolved in Qt 6?). Reimplementing some mouse event possible/sensible?