Bug 277134

Summary:	Shortcut grabbing doesn't work correctly when «Make Caps Lock an additional Ctrl» and «Meta on Left Ctrl» is set
Product:	[Unmaintained] kdelibs	Reporter:	Tore Anderson <tore>
Component:	shortcuts	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	fpesari
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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