Bug 91176 - assigning "<" as accelerator doesn't work
Summary: assigning "<" as accelerator doesn't work
Status: RESOLVED WORKSFORME
Alias: None
Product: kcontrol
Classification: Miscellaneous
Component: kcmkeys (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Ellis Whitehead
URL:
Keywords:
: 103341 113286 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-10-12 13:31 UTC by Melchior Franz
Modified: 2009-05-15 10:07 UTC (History)
4 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 Melchior Franz 2004-10-12 13:31:29 UTC
Version:           cvs/head as of 2004/10/11 (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc (GCC) 3.3.1 (SuSE Linux) 
OS:                Linux

Since a few weeks I observe this disturbing behavior:


Accels with Win keys
--------------------------------------------------
applications don't react on accelerator keys containting the "Win" key any more. All my accelerators using Win key combinations are non-functional. Logging 125 I see that the Win key is recognized, yet the accelerator isn't triggered:

kdecore (KAccel): KAccelPrivate::eventFilter( AccelOverride ): this = 0x8243388, key = Super_R
kdecore (KAccel): KAccelPrivate::eventFilter( AccelOverride ): this = 0x8224b48, key = Super_R
kdecore (KAccel): KAccelPrivate::eventFilter( AccelOverride ): this = 0x8243388, key = Right
kdecore (KAccel): KAccelPrivate::eventFilter( AccelOverride ): this = 0x8224b48, key = Right




Assigning <
--------------------------------------------------
it's impossible to assign the "<" key as an accelerator. Instead of reporting it as "Shift <" it's always seen as "Shift >" in all applications' "Configure Shortcuts ..." dialog. The ">" works as expected.
Comment 1 Lubos Lunak 2004-10-12 17:11:37 UTC
Please provide your 'xmodmap' output.
Comment 2 Lubos Lunak 2004-10-12 17:48:16 UTC
I can confirm the < vs > case, it's some black magic in KKey::simplify() (the Shift+Equal->Shift+Plus case) and KKeyServer::Sym::getModsRequired(), but after trying now I really don't feel like fixing that :(.
Comment 3 Waldo Bastian 2004-10-12 18:01:36 UTC
I was looking at KKey::simplify() as well already. I have a french keyboard and the '1' sits above the '&', so 'Shift+&' gives '1', but KShortcutDialog reports that as 'Shift+1'.

In KShortcutDialog::keyPressed, KKey::simplify() correctly converts 'Shift+1' to '1' but then it hits:
        if( m_bQtShortcut ) {
                key = key.keyCodeQt();
which effectively reverts the effect of KKey::simplify().

Having the following debug code:

void KShortcutDialog::keyPressed( KKey key )
{
        kdDebug(125) << "keyPressed: " << key.toString() << endl;
        key.simplify();
        kdDebug(125) << "keyPressed simple: " << key.toString() << endl;
        if( m_bQtShortcut )
                key = key.keyCodeQt();
        kdDebug(125) << "keyPressed simple #2: " << key.toString() << endl;

I get:
kdecore (KAccel): keyPressed: Shift+1
kdecore (KAccel): keyPressed simple: 1
kdecore (KAccel): keyPressed simple #2: Shift+1
Comment 4 Melchior Franz 2004-10-13 10:49:07 UTC
Reverting as follows fixes the ignored Win key bug (X11R6.8.1):

  /kapplication.cpp/1.682/Tue Oct 12 13:38:59 2004//T1.682
  /kaccel.cpp/1.147/Tue Oct 12 13:39:56 2004//T1.147


... and here's my xmodmap output:

  xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

  shift       Shift_L (0x32),  Shift_R (0x3e)
  lock        Caps_Lock (0x42)
  control     Control_L (0x25),  Control_R (0x6d)
  mod1        Alt_L (0x40),  Alt_L (0x7d)
  mod2
  mod3
  mod4
  mod5        Super_L (0x83),  Super_R (0x81)
Comment 5 Waldo Bastian 2004-10-13 13:20:29 UTC
I have reverted the changes to kaccel.cpp/kapplication.cpp, we need the code
that was there for the handling of the Win key, since Qt doesn't know about
that key. This also fixes the keyboard repeat problem (that was a feature actually).

That leaves the "<" problem.
Comment 6 Lubos Lunak 2005-04-06 13:50:19 UTC
*** Bug 103341 has been marked as a duplicate of this bug. ***
Comment 7 Thiago Macieira 2005-09-25 18:12:44 UTC
*** Bug 113286 has been marked as a duplicate of this bug. ***