Bug 404131 - Don't give focus to the brush search box unless explicitly clicked on by the user or via shortcut key?
Summary: Don't give focus to the brush search box unless explicitly clicked on by the ...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: Usability (show other bugs)
Version: 4.1.7
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-09 10:10 UTC by ꜱᴩʀɪᴛᴇ➀
Modified: 2019-04-16 09:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ꜱᴩʀɪᴛᴇ➀ 2019-02-09 10:10:16 UTC
SUMMARY
I always get caught up when using Krita in hurried manner because for one reason or another, the brush search box keeps getting the focus and I would keep hitting the shortcut key repeatedly thinking it's not working only to look at the search box and see I've basically been typing on it the whole time.

For my use case, I have Krita open on another workspace and the browser or whatever reference on the other. So I switch between workspaces frequently. When I switch back to Krita's workspace, the search box gets focused on. At least ,this is the behavior it shows on elementary OS 5.0.

STEPS TO REPRODUCE
1. Open Krita on a separate workspace.
2. Switch to a different workspace.
3. Switch back to Krita's workspace.

OBSERVED RESULT
Search box often takes over focus rendering shortcut keybinds unusable. It is hard to pinpoint what gets it focused other than the example I provided above but that's just one of the many instances where it takes focus without me wanting it to.

EXPECTED RESULT
It shouldn't take over focus unless I specifically click on it or activate it with a keybind.

SOFTWARE/OS VERSIONS
Linux: elementary OS 5.0

ADDITIONAL INFORMATION
I initially thought I could live with it but the more I use Krita, the more it's really getting in my way. Like I suggested above, having it be disabled by default and only activate when clicked by the user could be one way to avoid such problem from occurring.
Comment 1 Halla Rempt 2019-02-09 10:20:01 UTC
What window manager does elementary use? I've never seen that distribution myself, so I haven't got any idea, but this doesn't happen when using kwin and KDE plasma.
Comment 2 ꜱᴩʀɪᴛᴇ➀ 2019-02-09 10:32:55 UTC
Neofetch says it's using Mutter (Gala) as window manager
Comment 3 Halla Rempt 2019-04-16 09:40:51 UTC
I've actually managed to reproduce this now with Plasma. I'm still not sure whether this is something we're doing in Krita's code, though...
Comment 4 Halla Rempt 2019-04-16 09:45:39 UTC
Git commit 233cf084f664d9cb8d6a5ec7d2ecbc282f091f2d by Boudewijn Rempt.
Committed on 16/04/2019 at 09:44.
Pushed by rempt into branch 'master'.

Do not focus the tag search line edit in the show event

This is a bad idea, since that will take focus away from the canvas
every time the krita window is shown anew.

M  +0    -7    libs/widgets/KoResourceItemChooser.cpp
M  +0    -5    libs/widgets/KoResourceTaggingManager.cpp
M  +1    -2    libs/widgets/KoResourceTaggingManager.h
M  +0    -5    libs/widgets/KoTagFilterWidget.cpp
M  +0    -1    libs/widgets/KoTagFilterWidget.h

https://commits.kde.org/krita/233cf084f664d9cb8d6a5ec7d2ecbc282f091f2d