This is a request for others to please test and tell if you can reproduce this problem.
I have mapped “alt + left button” to “Sample Foreground Color from Merged Image” under canvas input settings > Alternate invocations.
If I switch layers and immediately try to pick a colour off the canvas, the color sampler does not get triggered, and I can no longer pan, zoom etc. the canvas, either, until I interact with some docker or alt-tab out of Krita.
I’m running on Linux Mint Cinnamon . This might be a Linux thing, since “alt” is typically mapped to move windows on the OS side, but as far as I know I have removed all such mappings.
If you can, please test the following, whatever OS you’re on:
- 1: Map the color sampler shortcut like I have:
- 2: create a document with two layers.
- 3: in the layers docker, click to switch to another layer and immediately try to sample a colour off the canvas by moving the cursor over the canvas and pressing alt. This needs to be done in less than a second, by my estimation.
Does the color sampler appear? Can you still pan the canvas with middle mouse button?
On Debian 10 (MATE) I don’t seem to have any problem with Alt+left button assigned as you say. It works fine and so does middle mouse panning.
Some time ago, I also tried to stop the Alt key from moving the window and had no luck with the obvious ‘Look and Feel’ types of system level menus.
Eventually I found a forum that gave a solution to the problem but I can’t remember where. (I keep telling myself that I should make notes but I never do.)
This link may be of use or may set you on a useful path to somewhere:
ubuntu-mate No luck disabling option-alt LEFT RIGHT mouse clicks - Ask Ubuntu
Thanks for testing! I have remapped that to Super already, and Alt doesn’t move any windows.
I also get this sometimes when alt-tabbing out of Krita - I think I just figured out how that happens - maybe you could try this too:
- With Krita active, switch focus to some other program by alt-tabbing.( You need to have two displays, or have both Krita and another program visible on the same display)
- bring your cursor over to the Krita window and press Alt without switching focus to the Krita window in any way first.
For me the same issue occurs. If I switch focus to another program by clicking on its window with a mouse, this works fine, it’s only with alt-tabbing that I get problems.
I’ve turned off all system level things that involve the Alt key so Alt-tabbing doesn’t work for me anyway. (Alt as a modifier is used on many graphics applications.)
I’ve always preferred to select by direct clicking and have difficulty remembering keyboard shortcuts anyway.
If I have one application running on the left monitor and krita running on the right monitor, with the left monitor application having focus, then pressing Alt when the cursor is over the krita window has no effect, I have to mouse click on it to make it have focus.
Pressing Alt+left mouse has no effect until the second time I do that, the first time having brought focus to the krita window.
I have not been able to reproduce it with Krita 5.0.6 on Windows 10 and in SUSE Tumbleweed (in a VM). It worked without any problems/as expected.
A week ago I also meet the issue on my OpenSUSE Leap 15.4 (KDE), so I remap color sampler to (default) ctrl.
System modifier has been set to super, so it should no conflict in theory.
- Map color sampler to Alt+Left bottom.
- Open any WIP project, (don’t remember have any canvas input between), click inside Layer Docker, then press Alt for color sampler, it will have like 50% chance to fail.
- After Alt failed to input, other canvas input shortcut will also fail.
- Minimize and restore Krita window will fix that input fail.
Thanks! So at least it happens with different desktop environments on Linux, if not maybe all…
I suspect you’d find that if you waited a little bit between switching layers and sampling colours, it would work 100% of the time. There seems to be an interval where this happens that’s just long enough to happen often, but not every time one tries to pick colours.
And this looks like the bug report here (sort of)
A little different form the report of my case is, pressing Super+D to show desktop and press again to switch back will have the same unresponsiveness.
This made me curious. And so I decided to test it not only four times in a row, like the first run, but over a longer Period, and after a minute of constant forth and back it stuck on my SUSE Tumbleweed too.