Version: (using Devel)
Installed from: Compiled sources
When assigning a shortcut like "Ctrl+Alt+Shift+2", it is displayed as "Ctrl+Alt+@".
In the KDE3 these shortcuts were displayed in the same way... and worked fine.
Here (in KDE 4.2 Beta2) they do not work.
I'm using KUbuntu 8.10 Interpid with KDE 4.2 beta2 on it installed from packages as described here http://www.kubuntu.org/news/kde-4.2-beta-2.
On your keyboard layout, SHIFT+2 = @ so if you use the keyboard shortcut with "SHIFT", this is correct:
it is mathematical:
if SHIFT+2 = @ then CTRL+ALT+SHIFT+2 = CTRL+ALT+@
Moreover even this type of keyboard association works fine on current trunk (r905373).
(In reply to comment #1)
> On your keyboard layout, SHIFT+2 = @ so if you use the keyboard shortcut with
> "SHIFT", this is correct:
> it is mathematical:
> if SHIFT+2 = @ then CTRL+ALT+SHIFT+2 = CTRL+ALT+@
My bugreport is not about the way the shortcuts is displayed, but about the fact that they DO NOT WORK for me.
For example, when I set shortcut like Ctrl+Alt+Shift+3 to run firefox, and press it -- the firefox doesn't start. Although, when I set another kind of shortcut (e.g. to Ctrl+Alt+3 [no shift], or to Ctrl+Alt+Shift+T [no number]), and press it -- firefox starts fine.
This happens in KDE 4.2 beta2.
However, if this bug is already fixed in trunk, then it certainly must be closed.
> Moreover even this type of keyboard association works fine on current trunk
I've checked shortcuts on programs, not the global shortcuts. Thanks to have added the example for starting a program so I've tried the global shortcuts to.
The issue is valid for global shortcuts.
I've changed the summary.
Same here with svn r912548, global shortcuts (and also the ones in "input action")
don't work with shift and "non-letter" keys: numbers,~,<,>,?,..
The problem originates from the fact that kde listens to global shortcuts. We then have to transform that x11 keycode to something qt compatible. Qt doesn't export methods to do that naturally.
It seems the code has some shortcomings :-(
*** Bug 179562 has been marked as a duplicate of this bug. ***
*** Bug 180449 has been marked as a duplicate of this bug. ***
To Michael Jansen:
You marked Bug 179562 and Bug 180449 as duplicates fo this one. However, Shift+Numbers (this report) "don't work" only for global shortcuts, while Shift+Tab (that reports) "doesn't work" both for global shortcuts and in applications. Maybe the title of this report should be changed to mention that some shortcuts don't work in applications too?
*** Bug 183340 has been marked as a duplicate of this bug. ***
*** Bug 184067 has been marked as a duplicate of this bug. ***
Alt+Printscreen hotkey also can't be assigned -- Bug 184070. Shouldn't I mark that report as duplicate?
I removed my config folder (.kde4) to get a new profile, and I don't get this anymore. I can correctly assign ctrl+shift+tab, ctrl+alt+shift+left/right/up/down, etc.
Using Qt 4.5.2 and KDE 4.3.1
Confirmed Nicolas' observation - seems to have been fixed.
Using KDE 4.3.1 with Qt4.5.2(-r2) on Gentoo.
Don't see it here with KDE 4.3.1 and Qt 4.5.2 in Fedora either.
That's good. Thanks for the positive feedbacks !!! :-)
No, it still doesn't works.
KDE 4.3.2, Qt 4.5.2, KUbuntu Karmic.
1. Log off, rename KDE settings (i.e. ~/.kde*), log on back.
2. Right click the start menu button, choose "Menu Editor". Set the Ctrl+Alt+Shift+1 shortcut (displayed as Ctrl+Alt+!) to Konqueror (or any other app, it doesn't matter). Also set Ctrl+Alt+4 shortcut (displayed as is) to Arora (just to have some ethalon). Save it and close.
3. Press Ctrl+Alt+4 -- it works (Arora starts). Press Ctrl+Alt+Shift+1 -- NOTHING HAPPENS (as in KDE 4.2).
(In reply to comment #17)
> Simple test:
> 1. Log off, rename KDE settings (i.e. ~/.kde*), log on back.
> 2. Right click the start menu button, choose "Menu Editor". Set the
> Ctrl+Alt+Shift+1 shortcut (displayed as Ctrl+Alt+!) to Konqueror (or any other
> app, it doesn't matter). Also set Ctrl+Alt+4 shortcut (displayed as is) to
> Arora (just to have some ethalon). Save it and close.
> 3. Press Ctrl+Alt+4 -- it works (Arora starts). Press Ctrl+Alt+Shift+1 --
> NOTHING HAPPENS (as in KDE 4.2).
I cannot logout for the moment and test a new profile. But with the running one, you are right: Ctrl+Alt+Shift+Something does not work for launching, but Ctrl+Alt+Something does work. It's weird though that I can set Ctrl+Shift+Tab for going one tab on the left, but can't assign Ctrl+Alt+Shift+1...
IIRC the problem was always with keys that produce different characters with and without shift like numbers, <, >, ', ;... I think that letters, arrow keys and such used to work, though I can't test it right now...
Confirmed on KDE 4.5.0: CTRL+ALT+SHIFT+1 doesn't work.
*** Bug 194147 has been marked as a duplicate of this bug. ***
Confirmed on KDE 4.4.4. Meta+Shift+= is converted to Meta++ and pressing the key combination does nothing.
*** Bug 213100 has been marked as a duplicate of this bug. ***
Git commit 568cb9268a3f940564d155526cb81cec4327cbf6 by Simon Persson.
Committed on 29/06/2011 at 04:56.
Pushed by persson into branch 'master'.
Fix global shortcuts that include symbols produced with shift key
KKeySequenceWidget (used to enter shortcuts) removes shift from the
recorded shortcut if the symbol produced from that key is different
when shift is used. kglobalaccel needs to include shift in the grab in
order to be triggered on this class of shortcuts, and then in the
keypress event handler it also needs to strip the shift again before
checking which shortcut was just triggered.
M +23 -3 kglobalaccel/kglobalaccel_x11.cpp
*** Bug 285305 has been marked as a duplicate of this bug. ***
It still doesn't work in KDE 4.7.2 release 5.
I tried to assign Alt+Shift+1 and Alt+Shift+2 as switch to different keyboard layouts through the Hotkeys Configuration Module, but it's always displayed as Alt+! and Alt+@, and the system doesn't react to the shortcut at all (nothing happens when I press the combination).
Exporting the scheme, editing the file manually and importing again finally made the system react, although there it's not logical either because I had to write Alt+Shift+! and Alt+Shift+@ instead of numbers.
*** Bug 289964 has been marked as a duplicate of this bug. ***
Meta+( and Meta+) still don't work in KDE 4.8.1 on Arch Linux,
whereas META+!, META+", META+§, ... META+/ do. These shorcuts have the form Meta+Shift+[Number].
I intended to use these with KWin for moving Windows to other Desktops.
I a similar issue. Alt+Shift was being intercepted (default f18 install with existing user). See here: http://forums.pcbsd.org/archive/index.php/t-12754.html
The ability to tell what a given shortcut/key combination is assigned to would be a useful feature.
There is a workaround for the issue mentioned by the previous poster:
System Settings > Hardware > Input Devices > Advanced > Key(s) to change layout
Uncheck combinations involving Alt-Shift
Add any Alt-Shift-* shortcuts desired and Apply.
In Input Devices, reselect the desired key combinations and Apply.
After this, everything seems to work as it should (both layout switching and the other shortcuts)
this works with plasma-framework 5.28.0 for me. Since this is a very old bug, I suggest closing it, if nobody has any objections.
Matthias Heinz, in KDE 5.18 it still doesn't.
What shortcut did you try in 5.28.
Did you assign it through systemsettings?
(In reply to Sasha Unspecified from comment #32)
> Matthias Heinz, in KDE 5.18 it still doesn't.
> What shortcut did you try in 5.28.
yes, I assigend it through the systemsettings. Please check the version of your KDE framework (it's called plasma-framework in Debian and recently got updated to 5.28.0 there).
What exactly shortcut did you assign in 5.28?
(As I've said, my is 5.18, so I can't test 5.28 yet.)
I tried with "Ctrl+Alt+Shift+1" and "Ctrl+Alt+Shift+2" for switchting desktops and it worked. Also I use Meta+Tab and Meta+Shift+Tab for switchting through my desktops. In earlier versions the "Shift" got always ignored, now it is interpreted and the shortcuts work as expected.
You will have to wait for KDE framework 5.28 then.
OK, thank you.
I just wanted to ensure that you really tried the thing (for example, not Ctrl+Shift+Letter, not a local shortcut).
OK, then it really should be closed.