Bug 183458

I have the same problem :S

ArchLinux, KDE 4.2.2 from KDEmod

Same problem here (Kubuntu KDE 4.2.2 and 4.2.3).

Setting the global shortcut: Pressing left Win and any plus (alphanumeric or numpad) produces Meta++ in dialog.
BUT: Only left Win and alphanumeric plus work.
Pressing left Win and numpad plus -> nothing happens.

Setting different keyboard layouts doesn't help (tried en and de).
All (or most) keys from numpad are broken (at least 0-9, +, -, /, *).

kglobalshortcutsrc:
decreaseVolume=Meta+-,Meta+-,Decrease Volume
increaseVolume=Meta++,Meta++,Increase Volume

*** This bug has been confirmed by popular vote. ***

Same problem here, KDE 4.2.2 from Debian testing.

*** Bug 166098 has been marked as a duplicate of this bug. ***

*** Bug 208026 has been marked as a duplicate of this bug. ***

*** Bug 212386 has been marked as a duplicate of this bug. ***

Same problem here on Ubuntu 9.10 (Karmic) with stock KDE 4.3.2.

Gentoo, KDE 4.3.1.  Previously (in 3.5), I mapped my numpad keys to be global shortcuts for switching to desktops.  I can no longer do this in 4.3.

Could this bug severity be boosted? It appears still not fixed in 4.4 although it actually affects a lots of apps (Amarok for instance...)

The bug persits on KDE 4.4.1

I think this is probably caused by a change in Qt4's handling of input (vs. Qt3).  I think this should be demonstrable in a simple (non-KDE specific) way.  I'll see if I can come up with a way to clearly show a difference, and therefore the unwanted behavior.  This bug is making me crazy.

*** Bug 190694 has been marked as a duplicate of this bug. ***

I confirm this bug in my way: cannot set hotkeys in keypad AT ALL.

procedure:

1. set numlock off.
2. use system settings to set any shortcut to Ctrl+Alt+Keypad_PgUp
3. press Ctrl+Alt+Keypad_PgUp and found that the shortcut not activated at all.
4. press Ctrl+Alt+PgUp works, but this is not I want.

The bug persits on KDE 4.4.2

Archlinux, KDE 4.4.2 from extra

As I can see Qt has an KeypadModifier like the MetaModifier or ShifModifier.
I think khotkeys doesn't handle that modifier information and doesn't safe it into the khotkeysrc. Because of this, the non keypad version of the short cut works instate of the expected one.

I found a workaround.

Using xev and xmodmap, I changed the numpad keys to different keysyms.  For example, my ~/.Xmodmap file now has this in it:

keycode 87 = XF86Launch1
keycode 88 = XF86Launch2
keycode 89 = XF86Launch3
keycode 83 = XF86Launch4
keycode 84 = XF86Launch5
keycode 85 = XF86Launch6
keycode 79 = XF86Launch7
keycode 80 = XF86Launch8
keycode 81 = XF86Launch9
keycode 90 = XF86LaunchA
keycode 91 = XF86LaunchB

Then (after running `xmodmap ~/.Xmodmap`), KDE's Keyboard Shortcuts configuration can detect and map the numpad keys, thinking they are something else (in this case, Launch keys instead of KP_1, KP_2, etc.).  So, I'm, in effect, tricking KDE, but I get the desired result, which is the ability to map my numpad to whatever I want.

Hope this helps some folks.

In Git version with KDE 4.5.4 Amarok is able to change volume by win + (+/-). But not in the numpad keys.

*** Bug 254536 has been marked as a duplicate of this bug. ***

*** Bug 195445 has been marked as a duplicate of this bug. ***

KDE 4.5.5/Ubuntu 10.10 still maps the wrong keys when you use the numpad.  

Wow, we are coming up on a YEAR.  Oh well, back to Trinity for the time being.

Happy third anniversary!

KDE 4.8.0 in Sabayon 8 ... still there. 

In shortcut-settings, KP_LEFT  maps to Left-Arrow. When set, KP_LEFT ist not recognized as LEFT, so the input machinery makes a difference, it may be just that dialogue in system-settings that doesn't. It should work same as xev does.

This is annoying.

Still not working, under KDE 4.8.x

This is rather distressing.

This bug is still present in kubuntu 12.04...

Concur, this is a critical bug for me, since that's 16 keys I used frequently for directional shortcuts that are inoperable without hacking around it via xmodmap (breaking compatibility with everything else).

KDE 4.8.4 and state of this bugs hasn't changed :-( Tiling (kwin) is really useless without this bug beeing fixed :-(  
Guys, I hope you will cope with this soon.

I confirm this very annoying bug (Kubuntu 12.04).

I hope you'll be able to solve it soon.

Thanks.

Michael -- I presume this is a bug in kkeyserver_x11, not in Qt itself?
There's some XK_KP_* stiff in that code, though.

*** Bug 178542 has been marked as a duplicate of this bug. ***

Ohh. Disapointing to see how long this has been around. This is my second day running KDE after converting from gnome. Hope it's fixed soon.

The numeric keys can't be differenciated from the standard digits, because Qt (qkeymapper_x11.cpp) assigns XK_KP_0 to Qt::Key_0, so we lose the distinction with the other '0' key. And the global shortcut is stored as a string (e.g. Ctrl+0), no distinction there either. After all the main point of the numeric keypad is to work like the real keys (even though X provides different keycodes for them, at the "physical" level).

OK, well, I suppose you guys would be happy if it at least worked, even if not differenciated. Right?

But there the problem is our code, like keyQtToSymX(), which assumes a given Qt key is mapped to a single X key (keysym).
symQt=48 -> keySym=48, so kglobalaccel doesn't listen for keysym 0xffb0, KP_0.
KGlobalAccelImpl::grabKey() only grabs keysym 48, the standard '0' key. OK so possibly a hack in kde-runtime/kglobalaccel/kglobalaccel_x11.cpp can help...

Created attachment 73443 [details]
Patch for kde-runtime/kglobalaccel

Created attachment 73444 [details]
Patch for kdelibs/kdeui/util

These two patches make the numeric digits (0 to 9) work.

It seems there's a little bit more work needed for the other keys (Add, Subtract etc.) in kglobalaccel, we need to find out the "alternate keysym" for the Qt keys '+', '-' etc.

To be finished when I'm back to the office, i.e. in 10 days or so.

Meanwhile, please, if you're hit by this bug, please try these patches. I am not 100% confident that I didn't break something for other keys than the one I tested... given that the patches ended up being a lot more intrusive than I was initially hoping.

(In reply to comment #31)
> The numeric keys can't be differenciated from the standard digits, because
> Qt (qkeymapper_x11.cpp) assigns XK_KP_0 to Qt::Key_0, so we lose the
> distinction with the other '0' key. And the global shortcut is stored as a
> string (e.g. Ctrl+0), no distinction there either. After all the main point
> of the numeric keypad is to work like the real keys (even though X provides
> different keycodes for them, at the "physical" level).

And another example of why dumbing-down things is bad. Simplifying is only good, if it doesn’t cost power. Otherwise you lose efficiency. Like here. :/

Very unfortunate…

> OK, well, I suppose you guys would be happy if it at least worked, even if
> not differenciated. Right?

Yes. Thanks a lot for the effort, man! :)

> But there the problem is our code, like keyQtToSymX(), which assumes a given
> Qt key is mapped to a single X key (keysym).

Why would it do that? That limitations has no use, yet takes away a lot of freedom. :(
Can we just get rid of the assumption for good?

I feel like it’s easier for us end-users, and application developers, to just switch to over to another toolkit. ;)

Actually, I'm wrong about Qt, it sets "Qt::KeypadModifier" when seeing a numeric keypad key, so it does offer some distinction. We just need to handle this in KDE's code, if we want to differenciate it from the standard keys.
I suppose this is wanted?

When someone sets a shortcut for "CTRL +", do they assume both "+" keys will work? I suppose so, because we don't have a different string representation anyway (CTRL KPAdd?). Hmm, Qt doesn't actually handle this in the conversion to/from string, AFAICS.

Anyway, keyQtToSymX() is our own code, we could make it return a list -- or like I did, handle the case of multiple keys externally. No need to switch to another toolkit, we can either make it work as is (with the keys not being differenciated, like my patch does), or improve Qt itself if necessary (e.g. for differenciation also in the string representation).

My opinion in CTRL+'+'. If I use it I will want to handle both '+' - alphanumeric and in numpad. But the problem in this only case is the alpha-key has '=' as primary representation. So ctrl+'+' in text may produce ctrl+'=' if we are talking about symbols not keycodes of buttons.
Improve Qt to differentiate string representation is good idea. Modify function by adding argument determined the differentiation.

(In reply to comment #35)
> I suppose this is wanted?
I suppose yes. From a usability/user standpoint, we see different keys on our keyboards, so we should be able to do different things with them. :)
(Especially, since advanced keyboard layouts don’t see the numpad as just a clone of the normal keys anyway. Let alone advanced *keyboards* posing as normal ones.)

> When someone sets a shortcut for "CTRL +", do they assume both "+" keys will work?
That question should never come up. The thing that stores the shortcuts should have all the same fields as the Qt key event, no? Including KeypadModifier, all other modifiers, locks, modes, and whatever there is. (I’d just store the key event directly in there, also directly compare the objects later [except for time stamps etc. of course]), and save the work. Dunno if that makes sense in Qt though… ;)

As for displaying things… Hmm… if keyQtToSymX() would eat the same stuff (like, the whole key events, or at least all the fields, including KeypadModifier), it could output the correct X keysym all the time, no? Resulting in 100% transparency, and the correct key(sym) displayed in the UI.

> No need to switch to another toolkit,
I was just frustrated. In light of Qt::KeypadModifier, I’m a bit more relaxed again. :)

P.S.: I always offer free beers to every open-source developer who did software I use and happens to be in Cologne. (Since I don’t have any money, but like to say thanks anyway. :)

This is still an issue in KDE 4.9. This bug is stretching from 4.2 to 4.9, I think it is time to be squashed! :)

(In reply to comment #38)
> This bug is stretching from 4.2 to 4.9, …

It’s by far not the only one.
But please wait for the release (5.0). No point in attacking unfinished early beta versions that are not meant to be used by the general public.

4.9 is a stable release, not a beta for 5.0.

(In reply to comment #40)
> 4.9 is a stable release, not a beta for 5.0.

Sorry, there seems to be a misunderstanding. 4.x is the beta branch for 5.0.

(In reply to comment #39)
> (In reply to comment #38)
> > This bug is stretching from 4.2 to 4.9, …
> 
> It’s by far not the only one.
> But please wait for the release (5.0). No point in attacking unfinished
> early beta versions that are not meant to be used by the general public.

4.9 is a stable version of KDE. I have no idea how you came up with beta argument at all. Also afaik there is no KDE 5 but its planned to be KDE 4.10 which still has no relation with what I wrote.

I am aware there are other bugs also stretching through multiple KDE versions, and I didn't attack anyone. Perhaps you should reread my previous comment and think again.

(In reply to comment #42)
> 4.9 is a stable version of KDE. I have no idea how you came up with beta
> argument at all. Also afaik there is no KDE 5 but its planned to be KDE 4.10
> which still has no relation with what I wrote.

I’m sorry. I inferred that KDE 4.x must be a developer line, like the odd versions of Gnome and Linux back in the times. (Where e.g. 2.3 and 2.5 were for development and 2.4 and 2.6 were for normal users.) I thought it was the same for KDE 4.x, because of its general buggyness and because of what other people wrote. It was sort of a natural conclusion that just was obvious to me, so I didn’t question it.

Thanks for the hint. I must have looked like an idiot to you guys. ;)
But hey, the thing really is quite buggy or even feels unfinished in so many places where it just shouldn’t for a stable release version. But you’re right. I should not complain, since it’s free, and should instead support you guys more, so that you have the time and resources.

> and I didn't attack anyone.
Sorry, I didn’t mean to say that like that. Everything’s good. :)

Anyway… This was really off-topic for this bug. Sorry everyone.

All ok, no worries. :)

(In reply to comment #33)
> Created attachment 73444 [details]
> Patch for kdelibs/kdeui/util
> 
> These two patches make the numeric digits (0 to 9) work.
> 
> It seems there's a little bit more work needed for the other keys (Add,
> Subtract etc.) in kglobalaccel, we need to find out the "alternate keysym"
> for the Qt keys '+', '-' etc.
> 
> To be finished when I'm back to the office, i.e. in 10 days or so.
> 
> Meanwhile, please, if you're hit by this bug, please try these patches. I am
> not 100% confident that I didn't break something for other keys than the one
> I tested... given that the patches ended up being a lot more intrusive than
> I was initially hoping.

Can we get a mini guide how to apply this patch? I d really like to give it a try.

Hello !

I agree with Milovan, a mini guide would be quite helpful. Is is always available on kubuntu 12.10 ?

Do you have some news about the integration of this patche in the next kubuntu release ? When is it going to be add in the official KDE version ?

Thanks.

This is one legendary bug.  It is going to be 4 years old soon. Yet it's also the kind of thing you notice on day one. It just shows no one at KDE really uses their keyboard. It's actually a deal breaker and I keep going back and forth between KDE and GNOME JUST because of this. So many guides talk about how to work around this bug, instead of just fixing it. I can't care about fancy features if I can't even quick tile my windows properly (and using something other than the keypad risks interfering with emacs).

I hope this stupid bug gets fixed. Or I might have to waste my time looking at the source code instead. I don't have enough votes to give to this bug.

(In reply to comment #47)
I can tell you one thing: It will be fixed in a heartbeat, if xkb is dead.
Apparently it’s a horrible mess and so nobody wants to touch in even with a pitchfork, even after 4 years. I can relate to that.

I hope that xkb goes away. Maybe the kernel gets reworked so X doesn’t have to use its own implementation… or maybe Wayland does it differently…

I for one, consider the concept of a “desktop environment” to be a wrong concept we should never have started, and the “tablet” one to be a step in an even worse direction. Hence I detached myself and am making my own graphical shell for humans with fully working brains that actually want to create something with their computers.

Hi all,

After trying for some time I found a workaround. This works better than mapping the keys to XF86Launch using xmodmap like Pistos proposed. I tried it that way but I also use the numpad a lot for calculations etc so it was a no-go for me.

I found the following workaround using xbindkeys. First you need to install xbindkeys. Then you can map any key combination to a qbus kwin shortcut. You can get a list of all available shortcut names using the following command in the terminal:

qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.shortcutNames

and all window commands by:

qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.shortcutNames | grep Window

You can then use the shortcut name you want and bind the keys to it by modifing ~/.xbindkeysrc

I've added the following to my .xbindkeysrc file:

## begin .xbindkeys

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Bottom Left'"
Control + Alt + KP_1

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Bottom Right'"
Control + Alt + KP_3

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Top Left'"
Control + Alt + KP_7

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Top Right'"
Control + Alt + KP_9

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Left'"
Control + Alt + KP_4

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Quick Tile Right'"
Control + Alt + KP_6

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Minimize'"
Control + Alt + KP_2

## end .xbindkeys

Now my numpad keys in combination with Control+Alt are used for tiling and maximizing windows.

Hope this helps someone!

Forgot to add:

"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Maximize'"
Control + Alt + KP_8

@ Milan : Great !!! It works perfeclty, it is really simple to install, modify, configure, test... As long as it's not officially supported, this solution will be mine !

Thanks !

@Tobias : No problemo :-) If you can't find a specific key or if some combinations don't work you can also use the following command:

xbindkeys -k

This way you can find the keycode, for example c:86 is numpad +

Then just add Control+Alt+c:86 to .xbindkeysrc
I found that sometimes KP_Substract for example won't work, but if I use the keycode instead it does.

Milan

Coming up on this bug's 5-year anniversary! Woo!

Can still confirm the bug. I am in a testing phase, considering switching to KDE. But this is a major bug for me. It does not deserve status 'normal' in terms of usability. KDE's focus seems to be the mouse indeed.

@Joachim: The workaround I mentioned above has been serving me perfectly.  As such, this is a non issue for me.  Someone else also posted an alternative workaround.  Have you tried either of these?

(In reply to comment #55)
> @Joachim: The workaround I mentioned above has been serving me perfectly. 
> As such, this is a non issue for me.  Someone else also posted an
> alternative workaround.  Have you tried either of these?

To show my willingness to help, I have implemented the qbus workaround of Milan. 

Note:
1. definitely use 'xbindkeys -k' to determine the keyboard shortcuts
2. the behaviour of this method seems to be 'switching': pressing numpad 9 again and again switches between previous position and top right tiling. This is not what I intended for.
3. there is no 'quick tile to top' and 'quick tile to bottom' (which I use the most actually).

So yes, thanks for asking, but unfortunately, after 30 minutes of work, it is still an issue for me. Don't ignore it please! :-)

@Joachim Jacob : It is an other problem. The current behaviour is that if the window is already tiled, it comes back to it's previous position (that's not completely absurd...). I think you'd like that when you press it several times it is more or less near from the screen border ? I don't know if it's possible for the moment (maybe a tiling scripts exists, I saw this one but I'm not sure it's what you want http://kde-look.org/content/show.php/Tiling?content=161151), but you can ask it if someone is interested in making this kind of feature.

About the "quick tile to top/bottom" I was surprised to when I saw it wasn't present, maybe you could do a feature request, I don't think it's really hard to implement.

This ist extremely annoying, since I use the Numpad excessively. Five years for such a critical bug are unbelievable. PLEASE fix it.

I also think that there should be a solution for this bug after such a long time. 
Please fix this. Thank you.

Actually, it got worse. Now certain keyboard shortcuts do not work anymore at all in some layouts. It’s the same basic bug.

I think KDE needs a complete rewrite of its input system. From scratch. Including the underlying X layer’s part. It’s simply FUBAR.

Maybe as a Google Summer Of Code project?

Otherwise KDE 4 will never come out of beta.

> Maybe as a Google Summer Of Code project?

If you find a programmer who understands keyboard internals of X11/xkbd, Qt4/xlib, Qt5 /xcb, and kdelibs/khotkeys/kglobalaccel, then please direct him here.

Any news about this bug in plasma 5?
I am on arch linux with KDE 5.8.0 and I have this bug.

Thanks

Bug still exists in Plasma5 with KDE 5.9.0

Could we at least have it to respond to the numpad? If I set something to Ctrl+1 and during setting it accepts and recognizes this combination why can't it do this later when I use it?

I think this bug is the same as https://bugs.kde.org/show_bug.cgi?id=346806

Year 2015. The bug persists.

The shortcuts recorder saves the combination "Control + Alt + KP_6" as "Control + Alt + 6". So you need to use the second shortcut, not the first.

Is kdelibs still the correct product for this bug, or should it be re-associated with a different one, such as plasma-frameworks?

Hello.

I'm facing the very same issue with openSUSE Tumbleweed 20160505. Plasma 5.6.3 ;

My keyboard is of a Logitech MK700 / MK710 pack. Mouse/keyboard combo.

In Plasma i use the model "Logitech / Generic" different models did not change the behaviour.

I wanted to use meta and Numeric Plus Minus for the screenmagnifier. Workaround for me is to enable xbindkeys to autostart as sugguested in comment #49. My $HOME/.xbindkeysrc:
# begin .xbindkeys
"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'view_zoom_out'"
Mod2+Mod4 + Super_L + KP_Subtract
"qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'view_zoom_in'"
Mod2+Mod4 + Super_L + KP_Add
## end .xbindkeys

Mod2+ is "Num" (Probably unneccesary).

I was allowed to compare the output of:
xbindkeys -k where the same buttons are working with my machine. The silly is. They produce the very same output. But the one works, and the other not.

Many Thanks.

Happy 8 years :)

Happy birthday to you,
Happy birthday to you,
Happy birthday dear
KDE-numpad-bug-that-has-not-been-fixed-in-nearly-a-decaaaaaaade....
... happy birthday to you!

🎼 Happy crumble dayy … KDEE …
🎼 You are wayy … too buggy for mee …
🎼 Gone to Enlightenment … cause of youu …
🎼 Happy Enlightenment … ’s buggy too. :(

Happy xbindkeys.
Works whatever is desk.

PS What about dropping current keybinding module altogether and just using xbindkeys instead as KDE key-shortcut app (and porting setup module to generating it's config)? I am serious…

(In reply to Marcin Kasperski from comment #71)

My guess is, that  KDE plans on just moving to Wayland, and dropping X in its entirety. Apparently it was never fun to work with, and isn’t worth it anymore.
So this bug will never be fixed. Ever.

Don’t expect the new stuff to be any less buggy though. It wouldn’t be KDE, if anything would ever leave the early alpha quality level. As always, there will be a lot of settings, but you’re a weirdo if you actually use them and notice that everything breaks, as “everything works fine and is very stable” for the developers, who apparently never use any of them themselves. ;)
(I should create a “Advanced Control Panel” for Gnome 3, with a bazillion settings to play with, that all just cause Gnome 3 to crash. And then I should make big advertisement everywhere about how Gnome 3 is way more configurable than KDE. If KDE then disagrees because they don’t work, I’d tell them “and neither do yours”. … But I won’t … because it would mean learning *gag* Gnome 3. ;)

> set quick tile shortcuts to meta+alt+[numkey]
> google for quick tile shortcut bugs for like an hour
> remember to try checking bug tracker
> immediately find this bug report
> be excited that at least quick tiling itself works, and it's actually a problem with numpad input, so I have that going for me, which is nice
> see that bug was reported in 2009
> question hatred for GNOME
> remap quick tile shortcuts to p[]l;',./ like I'm on a stupid %*^#ing netbook
> add to list of reasons to learn C++

This is a long-standing bug. I'm affected by it too. It is also embarrassing. I know workarounds have been posted over what is nearly a decade...!!!!

My keyboards all have the numeric pad that never sees much use because of this bug. I have 9 virtual desktops, and would only been massively cool if I could simply use this keypad to call them up.

Please, please, PLEASE fix this bug already. I'd do it myself but I have so many projects in the fire right now I don't have the time.

I have a morbid fascination with watching this bug remain unfixed. There should be Linux user group parties all over the world for the 10 year anniversary. Mark it in your korganizers folks: 2019-02-06, the 10-year kde numpad bug party. Heck invite your GNOME friends along!

Since this bug has turned into a bulletin board by now…

Frankly, there is no viable desktop environment for Linux nowadays.
• KDE hasn’t left “early beta” quality since 4.0, as this bug shows. Try anything out of the ordinary in the settings, and it will either be broken or not exist anymore. (Kate is still my favorite though.)
• Gnome took it to its logical conclusion, and just removed all the features right away anyway. Including themability. (Qalculate still can’t be beaten though.)
• Ditto for Cinnamon/Mate, which are of better quality, but still crippled by minimalism.
• XFCE et al are even more minimal, so even less viable for non-consumers.
• Enlightenment is currently in a large transition, and also only works if you don’t try anything too much out of the ordinary, if at all.

I think it is time for something new. Something clean and elegant, yet uncompromisingly powerful. A true Linux PC graphical shell. Not a “desktop environment”. Not a command line / search. Yet with all the advantages of both.

Where is it though?

(In reply to Navid Zamani from comment #76)
> Since this bug has turned into a bulletin board by now…
> 
> Frankly, there is no viable desktop environment for Linux nowadays.
> • KDE hasn’t left “early beta” quality since 4.0, as this bug shows. Try
> anything out of the ordinary in the settings, and it will either be broken
> or not exist anymore. (Kate is still my favorite though.)
> • Gnome took it to its logical conclusion, and just removed all the features
> right away anyway. Including themability. (Qalculate still can’t be beaten
> though.)
> • Ditto for Cinnamon/Mate, which are of better quality, but still crippled
> by minimalism.
> • XFCE et al are even more minimal, so even less viable for non-consumers.
> • Enlightenment is currently in a large transition, and also only works if
> you don’t try anything too much out of the ordinary, if at all.
> 
> I think it is time for something new. Something clean and elegant, yet
> uncompromisingly powerful. A true Linux PC graphical shell. Not a “desktop
> environment”. Not a command line / search. Yet with all the advantages of
> both.
> 
> Where is it though?

Hi, Navid. I loved KDE 4 and I used this temporary solution by binding some shortcuts using xbindkeys. Check my dotfiles: https://github.com/gerardbm/dotfiles/blob/master/.xbindkeysrc

However, KDE 5 (Plasma) is more buggy, so I switched to i3-gaps and I recommend a 'tiling windows manager' more than 'desktop environments'. It's a subjective opinion, of course. 

Windows managers are clean, elegant and they can be configured through dotfiles, so you can save them in a github repository and clone to any machine to use  the same configuration. 

There are some interesting WMs: dwm (configured in C, so you need to compile it every time), awesome (configured in Lua and more extensible), xmonad (configured in haskell), etc. Take a look at Unixporn on Reddit.

Thanks for the workaround @Milan! Giving two cents back, here's a Scheme version (.xbindkeysrc.scm):

(map (lambda (binding)
       (xbindkey-function
        (car binding)
        (lambda ()
          (run-command (string-append
                        "qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut '"
                        (cadr binding)
                        "'")))))
     '(((Mod4 KP_Up)    "Window Maximize")
       ((Mod4 KP_Down)  "Window Minimize")
       ((Mod4 KP_Left)  "Window Quick Tile Left")
       ((Mod4 KP_Right) "Window Quick Tile Right")
       ))

My new laptop has a numeric keypad, so I was actually able to come back to debugging this.

Qt5 supports "Ctrl+Num+1" since Qt 5.1 (which is something that some of you people could have found out, rather than just ranting), we just need to record it that way, and grab that.

See https://phabricator.kde.org/D6226 for a start.
I also have worked on kwindowsystem and kglobalaccel for global accel support, it works, but Ctrl+& doesn't work (implicit shift), I need to find out if it was broken by my changes and how to fix it.

(In reply to David Faure from comment #79)

Thanks for looking into this.
You must understand,that after 8 years, we simply have given up, and also don’t consider it to be our job. We’ve long switched to something more sensible, and at least I consider KDE dead now. So it’d be a waste of time. (Ranting still feels good though. :P)

Also, I have a layout with three different kinds of shift keys, where this bug disables way more than just certain numpad combinations.

Git commit 033ad8c63a728904d464a3566ccd71f69ad946ad by David Faure.
Committed on 16/06/2017 at 07:29.
Pushed by dfaure into branch 'master'.

KKeySequenceWidget: make it possible to record Ctrl+Num+1 as a shortcut.

Summary:
Qt supports this string representation for Qt::KeypadModifier since 5.1
but this code didn't support that modifier.

This is the easy part of the fix for the 8-years-old bug, and it makes
it possible to use the numeric keypad for application shortcuts.

The bigger issue is handling of keypad modifiers in global shortcuts
(patches to come for kwindowsystem and kglobalaccel).

Test Plan: Set shortcut Ctrl+Num+1 for "decrement number by 1" action in kate, works.

Reviewers: aacid

Reviewed By: aacid

Subscribers: apol, #frameworks

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D6226

M  +17   -14   src/kkeysequencewidget.cpp

https://commits.kde.org/kxmlgui/033ad8c63a728904d464a3566ccd71f69ad946ad

"job" ? Nobody's getting paid here. You, me, everyone else, we're all working *together* on free software. Fixing it is everybody's and nobody's *job*. If you stopped caring about KDE, that's fine, you can unsubscribe from this report. I'm fixing this for the other people who voted for this bug - and who knows, maybe I'll need such a shortcut myself one day.

The fixes are up for review now.
https://phabricator.kde.org/D6233
https://phabricator.kde.org/D6234

(In reply to David Faure from comment #82)
> "job" ?

You know exactly how I meant it, yet your reaction is so … KDEy…
Not my job does not imply your job. Nor does any of it imply employment or being paid. English “job” is broader than Denglish “Job”.

>  You, me, everyone else, we're all working *together* on free software.

Nope. We’re not in KDE together. My work resources go towards ending the concepts  “Desktop” (and not in favor of mobile OSes either), “Application”, “Button”, etc, forever, in favor of a OS for *computer users* (as opposed to app[lication] users).

</thread>

*** Bug 357133 has been marked as a duplicate of this bug. ***

Git commit 32526718eae99ccb594360627586eebdf793372b by David Faure.
Committed on 11/08/2017 at 06:26.
Pushed by dfaure into branch 'master'.

KKeyServer: fix handling of KeypadModifier.

Summary:
This required adding a new method symXModXToKeyQt since
symXToKeyQt (without modifier as input) has no way to find out
whether to use XK_KP_1 or XK_1. For this reason symXToKeyQt is now
deprecated.

Includes a unittest for keyQtToSymX, keyQtToModX and symXModXToKeyQt.

Test Plan:
After porting kglobalaccel to KKeyServer::xcbKeyPressEventToQt,
the following global shortcuts were successfully tested:
Ctrl+1, Ctrl+Num+1, Ctrl+Num+/, Ctrl+F1, Ctrl+& (implicit shift)

Reviewers: graesslin

Subscribers: graesslin, #frameworks

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D6233

M  +1    -0    autotests/CMakeLists.txt
A  +79   -0    autotests/kkeyserver_x11_unittest.cpp     [License: LGPL (v2/3+eV)]
M  +96   -52   src/platforms/xcb/kkeyserver.cpp
M  +13   -1    src/platforms/xcb/kkeyserver_x11.h

https://commits.kde.org/kwindowsystem/32526718eae99ccb594360627586eebdf793372b

Git commit 2c20ddff034e4958bf0536ca91ae9e444955305d by David Faure.
Committed on 06/08/2017 at 21:38.
Pushed by dfaure into branch 'master'.

KGlobalAccel: port to KKeyServer's new method symXModXToKeyQt, to fix numpad keys

Test Plan:
the following global shortcuts were successfully tested:
Ctrl+1, Ctrl+Num+1, Ctrl+Num+/, Ctrl+F1, Ctrl+& (implicit shift)

Differential Revision: https://phabricator.kde.org/D6234

M  +7    -45   src/runtime/plugins/xcb/kglobalaccel_x11.cpp

https://commits.kde.org/kglobalaccel/2c20ddff034e4958bf0536ca91ae9e444955305d