Bug 350095 - Ctrl-commands do not work at all
Summary: Ctrl-commands do not work at all
Status: RESOLVED DUPLICATE of bug 320423
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 2.9.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-10 15:07 UTC by alindebe
Modified: 2015-08-12 13:24 UTC (History)
2 users (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 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 ***