Bug 277134 - Shortcut grabbing doesn't work correctly when «Make Caps Lock an additional Ctrl» and «Meta on Left Ctrl» is set
Summary: Shortcut grabbing doesn't work correctly when «Make Caps Lock an additional C...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: shortcuts (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-05 12:42 UTC by Tore Anderson
Modified: 2024-09-14 17:07 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tore Anderson 2011-07-05 12:42:20 UTC
Version:           unspecified (using KDE 4.6.3) 
OS:                Linux

When enabling the two options (under System Settings - Keyboard - Advanced - Ctrl key position), shortcut grabbing (e.g. under System Settings - Shortcuts and Gestures) does not work properly anymore, they are learned incorrectly

Reproducible: Always

Steps to Reproduce:
Enable the two settings in question and click apply. Next try to assign the following shortcuts any random actions (physical keyboard buttons indicated):

1. Caps Lock + Space
2. Left Control + Space
3. Left Windows key + Space

(the use of Space here is arbitrary)

Actual Results:  
The shortcuts are learned as follows:

1. Meta + Ctrl + Space
2. Meta + Ctrl + Alt + Space
3. Some symbols, appearing straight after Left Windows Key is pressed, before space (I do not recognise which language they are in)

Expected Results:  
They should have been learned as follows (remapped logical keys indicated):

1. Ctrl + Space
2. Meta + Space
3. Meta + Space

My keyboard layout is Norwegian.

If I unset the «Meta on Left Ctrl» setting, the grabbing appears to work correctly (both the Caps Lock and Left Ctrl physical keys are recognised by the shortcut grabber as the Ctrl key).
Comment 1 Andriy Rysin 2011-07-10 15:54:08 UTC
This looks like a problem with shortcuts handling - keyboard layout switcher don't have to do much with it. Reassigning to kdelibs, hopefully somebody there can help.
Comment 2 Andrew Crouthamel 2018-11-06 15:17:25 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Andrew Crouthamel 2018-11-18 03:23:27 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Tore Anderson 2018-11-19 07:12:13 UTC
Yes, this is still not working correctly, but it behaves a bit different than in 2011.

With the two options enabled (which are now named «Caps Lock is also a Ctrl» and «Left Ctrl as Meta»), this is the following results when attempting to grab/learn a new shortcut:

- Physically pressing Caps Lock + Space:
--- expected result: «Ctrl+Space»
--- actual: «CapsLock, Ctrl+Space,Ctrl + ...» (the «...» indicates that it is still expecting more keypresses to complete the shortcut sequence)

- Physically pressing Left Ctrl + Space:
--- expected result: «Meta+Space»
--- actual result: «Meta+Alt+Space,Alt+ ...» (again «...» - it is still listening for more keystrokes»

Physicall pressing Left Windows + Space:
--- expected result: «Meta+Space»
--- actual result: «Meta+Space, Meta+ ..» (again «...»).

I'm using Fedora 28 (kdelibs-4.14.38-6.fc28.x86_64).

Tore
Comment 5 Fabio Pesari 2022-03-16 08:48:08 UTC
Confirmed on openSUSE Tumbleweed, Plasma version 5.24.3. I think Caps as an additional Ctrl is an important accessibility-related tweak and as such, this issue deserves attention.
Comment 6 Christoph Cullmann 2024-09-14 17:07:04 UTC
Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have resolved this bug.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann