Bug 306316

Summary: Wrong keyboard layout in KDE application hotkeys when changing layout by means of the taskbar
Product: [Unmaintained] plasma4 Reporter: Aurelien <aurelien.lourot>
Component: widget-taskbarAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED MOVED    
Severity: minor CC: aurelien.lourot
Priority: NOR    
Version First Reported In: 4.8.5   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Example (Part 1 of 4)
Example (Part 2 of 4)
Example (Part 3 of 4)
Example (Part 4 of 4)

Description Aurelien 2012-09-05 22:14:15 UTC 
In the taskbar, there is a button for changing the keyboard layout. It seems like it isn't taken into account for the hotkeys in KDE applications. For example, in KWrite with a french keyboard, if I press 'A', it understands 'A', but if I press CTRL+'A', it understands CTRL+'Q'. 

Reproducible: Always

Steps to Reproduce:
1. Do a fresh installation of a distribution based on KDE (e.g. Fedora 17 KDE Spin) with an US keyboard and using the US layout. 
2. In the System Settings, add the french layout. 
3. Plug a french keyboard. 
4. By means of the taskbar, change the layout to french. 
5. Open KWrite and type 'A'. 
6. Press CTRL+'A'. 
Actual Results:  
On step 5, KWrite understands 'A', which is correct. 
On step 6, KWrite understands CTRL+'Q' and asks you if you want to save your changes, instead of selecting the text you have typed...

Expected Results:  
On step 6, KWrite shall select the typed text. 

I have encountered this bug on Fedora 16 and 17, both up to date. 
The bug appears only within KDE applications (e.g. not with GEdit). 
My system runs on VirtualBox 4.1.20. 

Workaround: change the keyboard layout by means of system-config-keyboard. 

Note: this bug may be specific to Fedora and have nothing to do with KDE. In this case, sorry for the loss of time.
Comment 1 Aurelien 2012-12-27 08:40:13 UTC 
I've analysed the source code. Following happens: 
1) When I configure two keyboard layouts in the system settings (one US, one FR) and press "Apply", the daemon kded_keyboard calls XkbHelper::runConfigLayoutCommand(), which runs "setxkbmap -layout us,fr". This seems correct. It creates two Xkb "groups". 
2) When I toggle the layout by means of the plasma keyboard applet, X11Helper::setGroup() gets called, calling in turn XkbLockGroup(<display>, XkbUseCoreKbd, <new group>). This seems correct too. It toggles the Xkb group. 

Now three possibilities: 
1) either there is a bug in Xkb, 
2) or Xkb is not supposed to be used that way, 
3) or the problem comes from Qt. 

As only KDE applications (e.g. KWrite) seem to be affected but not other applications (e.g. GEdit), I'd rather follow the third lead. I'll continue my investigations in that direction and update this ticket.
Comment 2 Aurelien 2012-12-28 22:08:22 UTC 
Created attachment 76068 [details]
Example (Part 1 of 4)
Comment 3 Aurelien 2012-12-28 22:09:11 UTC 
Created attachment 76069 [details]
Example (Part 2 of 4)
Comment 4 Aurelien 2012-12-28 22:09:52 UTC 
Created attachment 76070 [details]
Example (Part 3 of 4)
Comment 5 Aurelien 2012-12-28 22:10:19 UTC 
Created attachment 76071 [details]
Example (Part 4 of 4)
Comment 6 Aurelien 2012-12-28 22:15:48 UTC 
The problem comes from QShortcut, which is used by KShortcut and KStandardShortcut. 

I have made a small example, with Qt only (without KDE), to prove that the problem doesn't come from KDE. See attachments. 

I'll create a Qt ticket, post its number here, and mark this one as resolved.
Comment 7 Aurelien 2012-12-28 22:19:04 UTC 
Seems like this ticket is related: 
https://bugs.kde.org/show_bug.cgi?id=177654