183458 2009-02-06 17:38:57 +0000 Numpad (keypad) keys not mapped correctly when setting Global Shortcuts 2017-08-15 14:17:18 +0000 1 1 10 Unmaintained kdelibs shortcuts 4.5 Ubuntu Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=357133 NOR normal --- 1 pfdevmuller faure alphabravo andresbajotierra AndyKluger archsubuser arkangath atorgovitsky bjoernp72 bugs.kde.pistos bugs.kde chris cmellwig cndedicated dag desintegr doc.evans duncan.clough+kde edoubrayrie elvanor faure fred.mitchell g111 h.klene ironfroggy jarno.malmari joachim.jacob joshuafcole kde kde kdebugs kdelibs-bugs-null kishore96 l22087 lookanio luislezcair m.hatifnatt mac madumlao Marcin.Kasperski marens mhoppstaedter milan milovan.krivokapic mkbosmans mowalle.dev mynameislich navid.zamani pan.shizhu phopedush revealed rhansen scitechpol simonandric5 stefan.loewen thomas.luebking thorsten.mueller.de tobias.bora v.ortex vet.roland watho woegjiub yellowhat46 yogeshm.007 yyyy12 https://commits.kde.org/kglobalaccel/2c20ddff034e4958bf0536ca91ae9e444955305d 868 oldest_to_newest 712798 0 pfdevmuller 2009-02-06 17:38:57 +0000 Version: (using KDE 4.2.0) OS: Linux Installed from: Ubuntu Packages When setting global shortcut keys, numpad keys seem to be mapped the same as their regular counterparts (eg. +, -). Pre KDE 4.2, numpad keys were mapped as "KP_add" or whatever the key might have been. This is no longer the case, and causes problems. Specifically, I can't get Amarok 2.0.1 to recognise the numpad + and - (combined with windowskey) as global shortcuts for volume control. I've tried setting them via Amarok, and via systemsettings, neither works. Please let me know if you need any more info. 754361 1 sergio.pe.facebook+kde 2009-05-08 23:53:37 +0000 I have the same problem :S ArchLinux, KDE 4.2.2 from KDEmod 765982 2 steinwender 2009-05-28 01:30:29 +0000 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 783922 3 mac 2009-06-29 17:23:49 +0000 *** This bug has been confirmed by popular vote. *** 783942 4 mac 2009-06-29 18:14:25 +0000 Same problem here, KDE 4.2.2 from Debian testing. 848572 5 andresbajotierra 2009-10-22 01:17:48 +0000 *** Bug 166098 has been marked as a duplicate of this bug. *** 848574 6 andresbajotierra 2009-10-22 01:17:56 +0000 *** Bug 208026 has been marked as a duplicate of this bug. *** 854160 7 andresbajotierra 2009-11-01 23:18:49 +0000 *** Bug 212386 has been marked as a duplicate of this bug. *** 854632 8 chris 2009-11-02 21:49:22 +0000 Same problem here on Ubuntu 9.10 (Karmic) with stock KDE 4.3.2. 855436 9 bugs.kde 2009-11-04 04:43:49 +0000 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. 910959 10 elvanor 2010-02-03 21:44:48 +0000 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...) 927849 11 sergio.pe.facebook+kde 2010-03-03 19:40:35 +0000 The bug persits on KDE 4.4.1 927891 12 chris 2010-03-03 20:48:36 +0000 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. 941859 13 ewoerner 2010-03-29 04:41:42 +0000 *** Bug 190694 has been marked as a duplicate of this bug. *** 946664 14 pan.shizhu 2010-04-08 05:00:43 +0000 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. 948805 15 kde 2010-04-12 19:17:36 +0000 The bug persits on KDE 4.4.2 Archlinux, KDE 4.4.2 from extra 949227 16 kde 2010-04-13 20:46:33 +0000 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. 1008430 17 bugs.kde 2010-08-23 16:03:33 +0000 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. 1061112 18 ashl1future 2010-12-18 15:14:28 +0000 In Git version with KDE 4.5.4 Amarok is able to change volume by win + (+/-). But not in the numpad keys. 1075448 19 myriam 2011-01-19 10:57:18 +0000 *** Bug 254536 has been marked as a duplicate of this bug. *** 1075450 20 myriam 2011-01-19 10:57:50 +0000 *** Bug 195445 has been marked as a duplicate of this bug. *** 1081721 21 chris 2011-01-31 14:07:51 +0000 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. 1229982 22 bjoernp72 2012-02-23 23:25:00 +0000 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. 1243630 23 woegjiub 2012-04-07 01:55:54 +0000 Still not working, under KDE 4.8.x This is rather distressing. 1248425 24 duncan.clough+kde 2012-04-22 10:39:48 +0000 This bug is still present in kubuntu 12.04... 1253056 25 joshuafcole 2012-05-08 03:56:25 +0000 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). 1266438 26 lookanio 2012-06-17 15:11:31 +0000 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. 1278433 27 tobias.bora 2012-07-23 22:09:03 +0000 I confirm this very annoying bug (Kubuntu 12.04). I hope you'll be able to solve it soon. Thanks. 1282270 28 faure 2012-08-06 14:41:52 +0000 Michael -- I presume this is a bug in kkeyserver_x11, not in Qt itself? There's some XK_KP_* stiff in that code, though. 1285358 29 martin 2012-08-16 13:17:28 +0000 *** Bug 178542 has been marked as a duplicate of this bug. *** 1289592 30 l22087 2012-08-21 09:57:23 +0000 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. 1291401 31 faure 2012-08-24 16:44:46 +0000 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... 1291420 32 73443 faure 2012-08-24 17:47:16 +0000 Created attachment 73443 Patch for kde-runtime/kglobalaccel 1291423 33 73444 faure 2012-08-24 17:49:57 +0000 Created attachment 73444 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. 1291431 34 navid.zamani 2012-08-24 18:09:51 +0000 (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. ;) 1291448 35 faure 2012-08-24 18:49:30 +0000 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). 1291454 36 ashl1future 2012-08-24 19:06:25 +0000 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. 1291457 37 navid.zamani 2012-08-24 19:15:03 +0000 (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. :) 1294399 38 milovan.krivokapic 2012-09-05 08:53:40 +0000 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! :) 1294402 39 navid.zamani 2012-09-05 09:36:32 +0000 (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. 1294673 40 faure 2012-09-06 13:26:10 +0000 4.9 is a stable release, not a beta for 5.0. 1294675 41 navid.zamani 2012-09-06 13:38:58 +0000 (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. 1296538 42 milovan.krivokapic 2012-09-12 08:55:50 +0000 (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. 1296618 43 navid.zamani 2012-09-12 11:24:22 +0000 (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. 1297940 44 milovan.krivokapic 2012-09-17 11:14:04 +0000 All ok, no worries. :) 1313067 45 milovan.krivokapic 2012-11-06 15:11:05 +0000 (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. 1315933 46 tobias.bora 2012-11-15 21:41:13 +0000 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. 1321666 47 mynameislich 2012-12-06 17:46:37 +0000 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. 1321675 48 navid.zamani 2012-12-06 18:54:03 +0000 (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. 1373946 49 milan 2013-06-04 22:59:09 +0000 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! 1373947 50 milan 2013-06-04 23:02:30 +0000 Forgot to add: "qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut 'Window Maximize'" Control + Alt + KP_8 1374603 51 tobias.bora 2013-06-06 19:15:25 +0000 @ 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 ! 1374607 52 milan 2013-06-06 19:23:27 +0000 @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 1426393 53 phopedush 2014-01-23 00:02:31 +0000 Coming up on this bug's 5-year anniversary! Woo! 1428832 54 joachim.jacob 2014-02-05 10:07:58 +0000 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. 1428904 55 bugs.kde.pistos 2014-02-05 16:39:39 +0000 @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? 1429876 56 joachim.jacob 2014-02-10 10:59:13 +0000 (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! :-) 1429929 57 tobias.bora 2014-02-10 16:24:07 +0000 @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. 1432172 58 v.ortex 2014-02-23 16:14:21 +0000 This ist extremely annoying, since I use the Numpad excessively. Five years for such a critical bug are unbelievable. PLEASE fix it. 1434291 59 mhoppstaedter 2014-03-07 13:11:23 +0000 I also think that there should be a solution for this bug after such a long time. Please fix this. Thank you. 1434304 60 navid.zamani 2014-03-07 14:01:11 +0000 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. 1435882 61 cfeck 2014-03-16 11:18:43 +0000 > 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. 1508192 62 yellowhat46 2015-03-30 20:39:24 +0000 Any news about this bug in plasma 5? I am on arch linux with KDE 5.8.0 and I have this bug. Thanks 1513191 63 thorsten.mueller.de 2015-04-24 13:00:54 +0000 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? 1514117 64 luislezcair 2015-04-27 18:26:44 +0000 I think this bug is the same as https://bugs.kde.org/show_bug.cgi?id=346806 1537319 65 scitechpol 2015-08-16 23:33:45 +0000 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. 1570017 66 AndyKluger 2016-01-16 15:37:52 +0000 Is kdelibs still the correct product for this bug, or should it be re-associated with a different one, such as plasma-frameworks? 1593528 67 revealed 2016-05-10 10:49:59 +0000 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. 1659207 68 madumlao 2017-02-06 22:47:53 +0000 Happy 8 years :) 1659229 69 bugs.kde.pistos 2017-02-07 03:22:18 +0000 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! 1659242 70 navid.zamani 2017-02-07 06:13:05 +0000 🎼 Happy crumble dayy … KDEE … 🎼 You are wayy … too buggy for mee … 🎼 Gone to Enlightenment … cause of youu … 🎼 Happy Enlightenment … ’s buggy too. :( 1659255 71 Marcin.Kasperski 2017-02-07 07:38:58 +0000 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… 1659292 72 navid.zamani 2017-02-07 08:26:25 +0000 (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. ;) 1671241 73 archsubuser 2017-04-13 12:13:28 +0000 > 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++ 1677084 74 fred.mitchell 2017-05-19 18:43:08 +0000 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. 1677101 75 madumlao 2017-05-19 22:57:32 +0000 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! 1677102 76 navid.zamani 2017-05-20 00:54:41 +0000 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? 1677876 77 scitechpol 2017-05-26 15:36:11 +0000 (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. 1678426 78 jarno.malmari 2017-05-30 10:24:12 +0000 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") )) 1682585 79 faure 2017-06-15 08:05:13 +0000 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. 1682706 80 navid.zamani 2017-06-15 23:12:22 +0000 (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. 1682741 81 faure 2017-06-16 07:30:09 +0000 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 1682745 82 faure 2017-06-16 07:38:41 +0000 "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 1682831 83 navid.zamani 2017-06-16 15:23:56 +0000 (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> 1683237 84 faure 2017-06-18 21:08:36 +0000 *** Bug 357133 has been marked as a duplicate of this bug. *** 1694019 85 faure 2017-08-11 06:26:28 +0000 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 1694744 86 faure 2017-08-15 14:17:18 +0000 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 73443 2012-08-24 17:47:16 +0000 2012-08-24 17:47:16 +0000 Patch for kde-runtime/kglobalaccel kglobalaccel_keypad.diff text/plain 7217 faure ZGlmZiAtLWdpdCBhL2tnbG9iYWxhY2NlbC9rZ2xvYmFsYWNjZWxfeDExLmNwcCBiL2tnbG9iYWxh Y2NlbC9rZ2xvYmFsYWNjZWxfeDExLmNwcAppbmRleCBkYmUxZjMyLi5hMzYxY2E0IDEwMDY0NAot LS0gYS9rZ2xvYmFsYWNjZWwva2dsb2JhbGFjY2VsX3gxMS5jcHAKKysrIGIva2dsb2JhbGFjY2Vs L2tnbG9iYWxhY2NlbF94MTEuY3BwCkBAIC04Niw3NCArODYsOTUgQEAgYm9vbCBLR2xvYmFsQWNj ZWxJbXBsOjpncmFiS2V5KCBpbnQga2V5UXQsIGJvb2wgZ3JhYiApCiAJCXJldHVybiBmYWxzZTsK IAl9CiAKLQlpbnQga2V5Q29kZVg7Ci0JdWludCBrZXlNb2RYOworCS8vIFJlc29sdmUgdGhlIFgg c3ltYm9sCiAJdWludCBrZXlTeW1YOworCWlmKCAhS0tleVNlcnZlcjo6a2V5UXRUb1N5bVgoa2V5 UXQsIChpbnQgKikma2V5U3ltWCkgKSB7CisJCWtEZWJ1ZygpIDw8ICJrZXlRdCAoMHgiIDw8IGhl eCA8PCBrZXlRdCA8PCAiKSBmYWlsZWQgdG8gcmVzb2x2ZSB0byB4MTEga2V5Y29kZSI7CisJCXJl dHVybiBmYWxzZTsKKwl9CiAKLQkvLyBSZXNvbHZlIHRoZSBtb2RpZmllcgotCWlmKCAhS0tleVNl cnZlcjo6a2V5UXRUb01vZFgoa2V5UXQsICZrZXlNb2RYKSApIHsKLQkJa0RlYnVnKCkgPDwgImtl eVF0ICgweCIgPDwgaGV4IDw8IGtleVF0IDw8ICIpIGZhaWxlZCB0byByZXNvbHZlIHRvIHgxMSBt b2RpZmllciI7CisJLy8gU3BlY2lhbCBjYXNlOiBRdCBrZXlzIHRoYXQgY2FuIG1hcCB0byBtdWx0 aXBsZSBwaHlzaWNhbCBrZXlzLgorCS8vIEV4YW1wbGU6IFF0OjpLZXlfMCBjYW4gYmUgMHgzMCBv ciBYUF8wLgorCWNvbnN0IGludCBzeW1RdCA9IGtleVF0ICYgflF0OjpLZXlib2FyZE1vZGlmaWVy TWFzazsKKwlpZiAoc3ltUXQgPj0gUXQ6OktleV8wICYmIHN5bVF0IDw9IFF0OjpLZXlfOSkgeyAv LyBUT0RPIHdoYXQgYWJvdXQgWEtfS1BfQWRkIGV0Yy4/CisJCWNvbnN0IHVpbnQgYWx0ZXJuYXRl S2V5U3ltWCA9IHN5bVF0IC0gUXQ6OktleV8wICsgWEtfS1BfMDsKKwkJKHZvaWQpZ3JhYlhLZXlT eW0oYWx0ZXJuYXRlS2V5U3ltWCwga2V5UXQsIGdyYWIpOworCX0KKworCXJldHVybiBncmFiWEtl eVN5bShrZXlTeW1YLCBrZXlRdCwgZ3JhYik7Cit9CisKK2Jvb2wgS0dsb2JhbEFjY2VsSW1wbDo6 Z3JhYlhLZXlTeW0odWludCBrZXlTeW1YLCBpbnQga2V5UXQsIGJvb2wgZ3JhYikKK3sKKwljb25z dCBpbnQga2V5Q29kZVggPSBYS2V5c3ltVG9LZXljb2RlKCBRWDExSW5mbzo6ZGlzcGxheSgpLCBr ZXlTeW1YICk7CisJa0RlYnVnKCkgPDwgaGV4IDw8IGtleVN5bVggPDwga2V5UXQgPDwgIi0+IGtl eUNvZGVYPSIgPDwga2V5Q29kZVg7CisJaWYoICFrZXlDb2RlWCApIHsKKwkJa0RlYnVnKCkubm9z cGFjZSgpIDw8ICJrZXlRdCAoMHgiIDw8IGhleCA8PCBrZXlRdCA8PCAiKSB3YXMgcmVzb2x2ZWQg dG8geDExIGtleWNvZGUgMCI7CiAJCXJldHVybiBmYWxzZTsKIAl9CiAKLQkvLyBSZXNvbHZlIHRo ZSBYIHN5bWJvbAotCWlmKCAhS0tleVNlcnZlcjo6a2V5UXRUb1N5bVgoa2V5UXQsIChpbnQgKikm a2V5U3ltWCkgKSB7Ci0JCWtEZWJ1ZygpIDw8ICJrZXlRdCAoMHgiIDw8IGhleCA8PCBrZXlRdCA8 PCAiKSBmYWlsZWQgdG8gcmVzb2x2ZSB0byB4MTEga2V5Y29kZSI7CisJLy8gUmVzb2x2ZSB0aGUg bW9kaWZpZXIKKwl1aW50IGtleU1vZFg7CisJaWYoICFLS2V5U2VydmVyOjprZXlRdFRvTW9kWChr ZXlRdCwgJmtleU1vZFgpICkgeworCQlrRGVidWcoKSA8PCAia2V5UXQgKDB4IiA8PCBoZXggPDwg a2V5UXQgPDwgIikgZmFpbGVkIHRvIHJlc29sdmUgdG8geDExIG1vZGlmaWVyIjsKIAkJcmV0dXJu IGZhbHNlOwogCX0KIAotCWtleUNvZGVYID0gWEtleXN5bVRvS2V5Y29kZSggUVgxMUluZm86OmRp c3BsYXkoKSwga2V5U3ltWCApOworCVFMaXN0PHVpbnQ+IG1vZHNUb0dyYWI7CisJbW9kc1RvR3Jh YiA8PCBrZXlNb2RYOwogCiAJLy8gQ2hlY2sgaWYgc2hpZnQgbmVlZHMgdG8gYmUgYWRkZWQgdG8g dGhlIGdyYWIgc2luY2UgS0tleVNlcXVlbmNlV2lkZ2V0CiAJLy8gY2FuIHJlbW92ZSBzaGlmdCBm b3Igc29tZSBrZXlzLiAoYWxsIHRoZSAlJiogYW5kIHN1Y2gpCisJLy8gSW4gdGhhdCBjYXNlLCBn cmFiIGJvdGggd2l0aCBhbmQgd2l0aG91dCBzaGlmdC4gV2UgY2FuJ3Qga25vdyB3aGljaAorCS8v IG9uZSBpcyBjb3JyZWN0LCBiZWNhdXNlIGZvciB0aGUgY2FzZSBvZiB0aGUgbnVtZXJpYyBrZXlw YWQsIHRoZXknbGwKKwkvLyBiZSBzd2FwcGVkIGF0IGFueSBwb2ludCBpbiB0aW1lIHdoZW4gdGhl IHVzZXIgZW5hYmxlcyBOdW1Mb2NrLi4uCiAJaWYoICEoa2V5UXQgJiBRdDo6U0hJRlQpICYmCi0J ICAgICFLS2V5U2VydmVyOjppc1NoaWZ0QXNNb2RpZmllckFsbG93ZWQoIGtleVF0ICkgJiYKLQkg ICAga2V5U3ltWCAhPSBYS2V5Y29kZVRvS2V5c3ltKCBRWDExSW5mbzo6ZGlzcGxheSgpLCBrZXlD b2RlWCwgMCApICYmCi0JICAgIGtleVN5bVggPT0gWEtleWNvZGVUb0tleXN5bSggUVgxMUluZm86 OmRpc3BsYXkoKSwga2V5Q29kZVgsIDEgKSApCisJCSFLS2V5U2VydmVyOjppc1NoaWZ0QXNNb2Rp ZmllckFsbG93ZWQoIGtleVF0ICkgJiYKKwkJa2V5U3ltWCAhPSBYS2V5Y29kZVRvS2V5c3ltKCBR WDExSW5mbzo6ZGlzcGxheSgpLCBrZXlDb2RlWCwgMCApICYmCisJCWtleVN5bVggPT0gWEtleWNv ZGVUb0tleXN5bSggUVgxMUluZm86OmRpc3BsYXkoKSwga2V5Q29kZVgsIDEgKSApCiAJewogCQlr RGVidWcoKSA8PCAiYWRkaW5nIHNoaWZ0IHRvIHRoZSBncmFiIjsKLQkJa2V5TW9kWCB8PSBLS2V5 U2VydmVyOjptb2RYU2hpZnQoKTsKKwkJbW9kc1RvR3JhYiA8PCAoa2V5TW9kWCB8IEtLZXlTZXJ2 ZXI6Om1vZFhTaGlmdCgpKTsKIAl9CiAKLQlrZXlNb2RYICY9IGdfa2V5TW9kTWFza1hBY2NlbDsg Ly8gR2V0IHJpZCBvZiBhbnkgbm9uLXJlbGV2YW50IGJpdHMgaW4gbW9kCisJYm9vbCBmYWlsZWQg PSBmYWxzZTsKIAotCWlmKCAha2V5Q29kZVggKSB7Ci0JCWtEZWJ1ZygpIDw8ICJrZXlRdCAoMHgi IDw8IGhleCA8PCBrZXlRdCA8PCAiKSB3YXMgcmVzb2x2ZWQgdG8geDExIGtleWNvZGUgMCI7Ci0J CXJldHVybiBmYWxzZTsKLQl9CisJUV9GT1JFQUNIKHVpbnQga2V5TW9kWCwgbW9kc1RvR3JhYikg ewogCi0JS1hFcnJvckhhbmRsZXIgaGFuZGxlciggWEdyYWJFcnJvckhhbmRsZXIgKTsKKwkJa2V5 TW9kWCAmPSBnX2tleU1vZE1hc2tYQWNjZWw7IC8vIEdldCByaWQgb2YgYW55IG5vbi1yZWxldmFu dCBiaXRzIGluIG1vZAogCi0JLy8gV2UnbGwgaGF2ZSB0byBncmFiIDgga2V5IG1vZGlmaWVyIGNv bWJpbmF0aW9ucyBpbiBvcmRlciB0byBjb3ZlciBhbGwKLQkvLyAgY29tYmluYXRpb25zIG9mIENh cHNMb2NrLCBOdW1Mb2NrLCBTY3JvbGxMb2NrLgotCS8vIERvZXMgYW55b25lIHdpdGggbW9yZSBY LXNhdnZ5IGtub3cgaG93IHRvIHNldCBhIG1hc2sgb24gUVgxMUluZm86OmFwcFJvb3RXaW5kb3cg c28gdGhhdAotCS8vICB0aGUgaXJyZWxldmFudCBiaXRzIGFyZSBhbHdheXMgaWdub3JlZCBhbmQg d2UgY2FuIGp1c3QgbWFrZSBvbmUgWEdyYWJLZXkKLQkvLyAgY2FsbCBwZXIgYWNjZWxlcmF0b3I/ IC0tIGVsbGlzCisJCUtYRXJyb3JIYW5kbGVyIGhhbmRsZXIoIFhHcmFiRXJyb3JIYW5kbGVyICk7 CisKKwkJLy8gV2UnbGwgaGF2ZSB0byBncmFiIDgga2V5IG1vZGlmaWVyIGNvbWJpbmF0aW9ucyBp biBvcmRlciB0byBjb3ZlciBhbGwKKwkJLy8JY29tYmluYXRpb25zIG9mIENhcHNMb2NrLCBOdW1M b2NrLCBTY3JvbGxMb2NrLgorCQkvLyBEb2VzIGFueW9uZSB3aXRoIG1vcmUgWC1zYXZ2eSBrbm93 IGhvdyB0byBzZXQgYSBtYXNrIG9uIFFYMTFJbmZvOjphcHBSb290V2luZG93IHNvIHRoYXQKKwkJ Ly8JdGhlIGlycmVsZXZhbnQgYml0cyBhcmUgYWx3YXlzIGlnbm9yZWQgYW5kIHdlIGNhbiBqdXN0 IG1ha2Ugb25lIFhHcmFiS2V5CisJCS8vCWNhbGwgcGVyIGFjY2VsZXJhdG9yPyAtLSBlbGxpcwog I2lmbmRlZiBOREVCVUcKLQlRU3RyaW5nIHNEZWJ1ZyA9IFFTdHJpbmcoIlx0Y29kZTogMHglMSBz dGF0ZTogMHglMiB8ICIpLmFyZyhrZXlDb2RlWCwwLDE2KS5hcmcoa2V5TW9kWCwwLDE2KTsKKwkJ UVN0cmluZyBzRGVidWcgPSBRU3RyaW5nKCJcdGNvZGU6IDB4JTEgc3RhdGU6IDB4JTIgfCAiKS5h cmcoa2V5Q29kZVgsMCwxNikuYXJnKGtleU1vZFgsMCwxNik7CiAjZW5kaWYKLQl1aW50IGtleU1v ZE1hc2tYID0gfmdfa2V5TW9kTWFza1hPbk9yT2ZmOwotCWZvciggdWludCBpcnJlbGV2YW50Qml0 c01hc2sgPSAwOyBpcnJlbGV2YW50Qml0c01hc2sgPD0gMHhmZjsgaXJyZWxldmFudEJpdHNNYXNr KysgKSB7Ci0JCWlmKCAoaXJyZWxldmFudEJpdHNNYXNrICYga2V5TW9kTWFza1gpID09IDAgKSB7 CisJCXVpbnQga2V5TW9kTWFza1ggPSB+Z19rZXlNb2RNYXNrWE9uT3JPZmY7CisJCWZvciggdWlu dCBpcnJlbGV2YW50Qml0c01hc2sgPSAwOyBpcnJlbGV2YW50Qml0c01hc2sgPD0gMHhmZjsgaXJy ZWxldmFudEJpdHNNYXNrKysgKSB7CisJCQlpZiggKGlycmVsZXZhbnRCaXRzTWFzayAmIGtleU1v ZE1hc2tYKSA9PSAwICkgewogI2lmbmRlZiBOREVCVUcKLQkJCXNEZWJ1ZyArPSBRU3RyaW5nKCIw eCUzLCAiKS5hcmcoaXJyZWxldmFudEJpdHNNYXNrLCAwLCAxNik7CisJCQkJc0RlYnVnICs9IFFT dHJpbmcoIjB4JTMsICIpLmFyZyhpcnJlbGV2YW50Qml0c01hc2ssIDAsIDE2KTsKICNlbmRpZgot CQkJaWYoIGdyYWIgKQotCQkJCVhHcmFiS2V5KCBRWDExSW5mbzo6ZGlzcGxheSgpLCBrZXlDb2Rl WCwga2V5TW9kWCB8IGlycmVsZXZhbnRCaXRzTWFzaywKLQkJCQkJUVgxMUluZm86OmFwcFJvb3RX aW5kb3coKSwgVHJ1ZSwgR3JhYk1vZGVBc3luYywgR3JhYk1vZGVTeW5jICk7Ci0JCQllbHNlCi0J CQkJWFVuZ3JhYktleSggUVgxMUluZm86OmRpc3BsYXkoKSwga2V5Q29kZVgsIGtleU1vZFggfCBp cnJlbGV2YW50Qml0c01hc2ssIFFYMTFJbmZvOjphcHBSb290V2luZG93KCkgKTsKKwkJCQlpZigg Z3JhYiApCisJCQkJCVhHcmFiS2V5KCBRWDExSW5mbzo6ZGlzcGxheSgpLCBrZXlDb2RlWCwga2V5 TW9kWCB8IGlycmVsZXZhbnRCaXRzTWFzaywKKwkJCQkJCQkgIFFYMTFJbmZvOjphcHBSb290V2lu ZG93KCksIFRydWUsIEdyYWJNb2RlQXN5bmMsIEdyYWJNb2RlU3luYyApOworCQkJCWVsc2UKKwkJ CQkJWFVuZ3JhYktleSggUVgxMUluZm86OmRpc3BsYXkoKSwga2V5Q29kZVgsIGtleU1vZFggfCBp cnJlbGV2YW50Qml0c01hc2ssIFFYMTFJbmZvOjphcHBSb290V2luZG93KCkgKTsKKwkJCX0KIAkJ fQotCX0KIAotCWJvb2wgZmFpbGVkID0gZmFsc2U7Ci0JaWYoIGdyYWIgKSB7Ci0JCWZhaWxlZCA9 IGhhbmRsZXIuZXJyb3IoIHRydWUgKTsgLy8gc3luYyBub3cKLQkJaWYoIGZhaWxlZCApIHsKLQkJ CWtEZWJ1ZygpIDw8ICJncmFiIGZhaWxlZCFcbiI7Ci0JCQlmb3IoIHVpbnQgbSA9IDA7IG0gPD0g MHhmZjsgbSsrICkgewotCQkJCWlmKCggbSAmIGtleU1vZE1hc2tYICkgPT0gMCApCi0JCQkJCVhV bmdyYWJLZXkoIFFYMTFJbmZvOjpkaXNwbGF5KCksIGtleUNvZGVYLCBrZXlNb2RYIHwgbSwgUVgx MUluZm86OmFwcFJvb3RXaW5kb3coKSApOworCQlpZiggZ3JhYiApIHsKKwkJCWZhaWxlZCA9IGhh bmRsZXIuZXJyb3IoIHRydWUgKTsgLy8gc3luYyBub3cKKwkJCWlmKCBmYWlsZWQgKSB7CisJCQkJ a0RlYnVnKCkgPDwgImdyYWIgZmFpbGVkIVxuIjsKKwkJCQlmb3IoIHVpbnQgbSA9IDA7IG0gPD0g MHhmZjsgbSsrICkgeworCQkJCQlpZigoIG0gJiBrZXlNb2RNYXNrWCApID09IDAgKQorCQkJCQkJ WFVuZ3JhYktleSggUVgxMUluZm86OmRpc3BsYXkoKSwga2V5Q29kZVgsIGtleU1vZFggfCBtLCBR WDExSW5mbzo6YXBwUm9vdFdpbmRvdygpICk7CisJCQkJfQogCQkJfQogCQl9CiAJfQpAQCAtMjQ4 LDYgKzI2OSw4IEBAIGJvb2wgS0dsb2JhbEFjY2VsSW1wbDo6eDExS2V5UHJlc3MoIGNvbnN0IFhF dmVudCAqcEV2ZW50ICkKIAlLS2V5U2VydmVyOjpzeW1YVG9LZXlRdChrZXlTeW1YLCAma2V5Q29k ZVF0KTsKIAlLS2V5U2VydmVyOjptb2RYVG9RdChrZXlNb2RYLCAma2V5TW9kUXQpOwogCisJa0Rl YnVnKCkgPDwgaGV4IDw8ICJrZXlTeW1YPSIgPDwga2V5U3ltWCA8PCAia2V5TW9kWD0iIDw8IGtl eU1vZFggPDwgIiAtPiBrZXlDb2RlUXQ9IiA8PCBrZXlDb2RlUXQgPDwgImtleU1vZFF0PSIgPDwg a2V5TW9kUXQ7CisKIAlpZigga2V5TW9kUXQgJiBRdDo6U0hJRlQgJiYgIUtLZXlTZXJ2ZXI6Omlz U2hpZnRBc01vZGlmaWVyQWxsb3dlZCgga2V5Q29kZVF0ICkgKSB7CiAJCWtEZWJ1ZygpIDw8ICJy ZW1vdmluZyBzaGlmdCBtb2RpZmllciI7CiAJCWtleU1vZFF0ICY9IH5RdDo6U0hJRlQ7CmRpZmYg LS1naXQgYS9rZ2xvYmFsYWNjZWwva2dsb2JhbGFjY2VsX3gxMS5oIGIva2dsb2JhbGFjY2VsL2tn bG9iYWxhY2NlbF94MTEuaAppbmRleCBmMmUyNzE3Li5lM2Q5MGM4IDEwMDY0NAotLS0gYS9rZ2xv YmFsYWNjZWwva2dsb2JhbGFjY2VsX3gxMS5oCisrKyBiL2tnbG9iYWxhY2NlbC9rZ2xvYmFsYWNj ZWxfeDExLmgKQEAgLTUwLDExICs1MCwxMyBAQCBwdWJsaWM6CiAJICogXHJldHVybiB0cnVlIGlm IHN1Y2Nlc3NmdWwsIG90aGVyd2lzZSBmYWxzZS4KIAkgKi8KIAlib29sIGdyYWJLZXkoaW50IGtl eSwgYm9vbCBncmFiKTsKLQkKKwogCS8vLyBFbmFibGUvZGlzYWJsZSBhbGwgc2hvcnRjdXRzLiBU aGVyZSB3aWxsIG5vdCBiZSBhbnkgZ3JhYmJlZCBzaG9ydGN1dHMgYXQgdGhpcyBwb2ludC4KIAl2 b2lkIHNldEVuYWJsZWQoYm9vbCk7CiAKIHByaXZhdGU6CisJYm9vbCBncmFiWEtleVN5bSh1aW50 IGtleVN5bVgsIGludCBrZXlRdCwgYm9vbCBncmFiKTsKKwogCS8qKgogCSAqIEZpbHRlcnMgWDEx IGV2ZW50cyBldiBmb3Iga2V5IGJpbmRpbmdzIGluIHRoZSBhY2NlbGVyYXRvciBkaWN0aW9uYXJ5 LgogCSAqIElmIGEgbWF0Y2ggaXMgZm91bmQgdGhlIGFjdGl2YXRlZCBhY3RpdmF0ZWQgaXMgZW1p dHRlZCBhbmQgdGhlIGZ1bmN0aW9uCkBAIC02NSw3ICs2Nyw3IEBAIHByaXZhdGU6CiAJdmlydHVh bCBib29sIHgxMUV2ZW50KCBYRXZlbnQqICk7CiAJdm9pZCB4MTFNYXBwaW5nTm90aWZ5KCk7CiAJ Ym9vbCB4MTFLZXlQcmVzcyggY29uc3QgWEV2ZW50ICpwRXZlbnQgKTsKLQkKKwogICAgIEdsb2Jh bFNob3J0Y3V0c1JlZ2lzdHJ5ICptX293bmVyOwogfTsKIAo= 73444 2012-08-24 17:49:57 +0000 2012-08-24 17:49:57 +0000 Patch for kdelibs/kdeui/util kdelibs_keypad.diff text/plain 876 faure ZGlmZiAtLWdpdCBhL2tkZXVpL3V0aWwva2tleXNlcnZlcl94MTEuY3BwIGIva2RldWkvdXRpbC9r a2V5c2VydmVyX3gxMS5jcHAKaW5kZXggNWE3ZDZkOC4uMDQ4OTU0MCAxMDA2NDQKLS0tIGEva2Rl dWkvdXRpbC9ra2V5c2VydmVyX3gxMS5jcHAKKysrIGIva2RldWkvdXRpbC9ra2V5c2VydmVyX3gx MS5jcHAKQEAgLTczNCwxMSArNzM0LDE4IEBAIGJvb2wgc3ltWFRvS2V5UXQoIHVpbnQga2V5U3lt LCBpbnQqIGtleVF0ICkKICAgICAgICAgZWxzZQogICAgICAgICAgICAgKmtleVF0ID0ga2V5U3lt OwogICAgIH0KLQotICAgIGVsc2UgaWYoIGtleVN5bSA8IDB4MzAwMCApCisgICAgZWxzZSBpZigg a2V5U3ltIDwgMHgzMDAwICkgewogICAgICAgICAqa2V5UXQgPSBrZXlTeW07CisgICAgfQorICAg IGVsc2UgaWYgKGtleVN5bSA+PSBYS19LUF9TcGFjZSAmJiBrZXlTeW0gPD0gWEtfS1BfOSkgewor ICAgICAgICBrRGVidWcoKSA8PCAibnVtZXJpYyBrZXlwYWQhIjsKKyAgICAgICAgaWYgKGtleVN5 bSA+PSBYS19LUF8wKSB7CisgICAgICAgICAgICAvLyBudW1lcmljIGtleXBhZCBrZXlzCisgICAg ICAgICAgICAqa2V5UXQgPSBRdDo6S2V5XzAgKyAoKGludClrZXlTeW0gLSBYS19LUF8wKTsKKyAg ICAgICAgfQorICAgIH0KIAotICAgIGVsc2UgeworICAgIGlmICgqa2V5UXQgPT0gUXQ6OktleV91 bmtub3duKSB7CiAgICAgICAgIGZvciggdWludCBpID0gMDsgaSA8IHNpemVvZihnX3JnUXRUb1N5 bVgpL3NpemVvZihUcmFuc0tleSk7IGkrKyApCiAgICAgICAgICAgICBpZiggZ19yZ1F0VG9TeW1Y W2ldLmtleVN5bVggPT0ga2V5U3ltICkgewogICAgICAgICAgICAgICAgICprZXlRdCA9IGdfcmdR dFRvU3ltWFtpXS5rZXlTeW1RdDsK