Bug 350095

Summary:	Ctrl-commands do not work at all
Product:	[Applications] krita	Reporter:	alindebe <irishmangoes>
Component:	General	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	halla, portnov
Priority:	NOR
Version:	2.9.4
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description alindebe 2015-07-10 15:07:09 UTC

I first installed Krita on Fedora 19. The first couple times I used it, ctrl-commands (ctrl-x, ctrl-z, etc) worked as expected.

I then upgraded to F21 and F22 simultaneously, because Krita 2.9 is not available below F22, and upgraded from I believe 2.8 to 2.9.

Now, my ctrl-commands do not work. Pressing the ctrl-key on its own brings up the color selector tool, which works just fine, but pressing any other key after that while holding down the ctrl-key just returns it to the tool I had been using.

I have tested it both with and without my tablet plugged in, since it first appeared when I was using the tablet. Neither makes a difference.

Edit -> Undo (or redo, cut, copy, paste, etc) still works, so it's not impossible to work around it.. but using menu tools for everything is a frustrating workaround.

Reproducible: Always

Steps to Reproduce:
1. Press ctrl-z (or ctrl-x, c, v, shift-y, etc)

Actual Results:  
Tool returns to what I had been using (paintbrush, selection tool, whatever) and works as if I'm not holding any keys.

Expected Results:  
Action is undone (or cut, copied, pasted, redone, whatever the ctrl-command should be).

Note that my version of Krita right now is 2.9.5, not 2.9.4, but that option did not appear in the list.

Not sure if it matters but I am also using Gnome, and not KDE.

Comment 1 alindebe 2015-07-10 15:09:33 UTC

When I say simultaneous installation, I mean sequential. And when I say tablet, I mean an Intuos5 drawing tablet (and not a tablet computer or anything else).

Comment 2 Ilya V. Portnov 2015-07-10 15:17:56 UTC

This seems to be duplicate of https://bugs.kde.org/show_bug.cgi?id=320423.

Comment 3 alindebe 2015-07-10 15:22:09 UTC

Yup, it appears this is indeed related to that. I have an Arabic layout as my default, and even when English is the active layout it still has a problem.

Changing the order in my keyboard settings so that English is on top (and thus default) fixed the issue.

I'm not sure I want to mark this as Resolved since putting a latin-alphabet keyboard as default is a workaround, not a fix, but maybe it should be reassigned to a different component?

Comment 4 alindebe 2015-07-10 18:58:33 UTC

Sorry to keep adding comments, but there's a little bit more to the story: Simultaneous with the ctrl-command problems, my drawing tablet had stopped responding to pressure input (so all pen strokes were 100% pressure, as if I were just clicking a mouse).

I had assumed it was a small hitch related to upgrading (something something drivers something), but as soon as I fixed the ctrl-commands it turned out to be fixed as well. I have no idea why the two issues would be related in the underlying code, but it seems like they are. Pressure sensitivity is ignored when a non-latin keyboard layout is the default.

Comment 5 Halla Rempt 2015-07-11 07:45:04 UTC

Hi,

I'm sorry, but this isn't a bug in Krita; it's a bug in the underlying Qt library: https://bugreports.qt.io/browse/QTBUG-32908

Comment 6 Halla Rempt 2015-07-11 07:47:28 UTC

See also https://bugs.kde.org/show_bug.cgi?id=320423

Comment 7 alindebe 2015-07-11 16:49:18 UTC

Yeah, that's why I said it should probably be reassigned to a different component. It's not resolved, though - it's still a bug.

Comment 8 Halla Rempt 2015-08-12 13:24:17 UTC


*** This bug has been marked as a duplicate of bug 320423 ***