Since an upgrade, my keyboard shortcuts doesn't work anymore. When I hit Meta+m to type my mail with the command 'xvkbd -text 'foo@bar'", the 'xvkbd' command never send the inputs characters as expected. Instead, I have a bug that switch me to another plasma activity and pop me some random applications (kde 4.14.2, plasma 4.11.11, mint). If I test this behaviour (same settings) on a daily plasma 5 released live-cd, and if I try the keyboard shortcuts in a 'konsole' terminal, the shell try to complete (like tab pressed) some network devices : http://pix.toile-libre.org/upload/original/1435658627.png I repeat, this was working as a charm before (don't know when exactly) Reproducible: Always Steps to Reproduce: 1. create a new 'custom shortcut', 'Global shortcut, 'via command/URL' 2. install 'xvkbd' and add the command "xvkbd -text 'foo@bar'" in the newly created entry 3. choose meta+m combo Actual Results: random results Expected Results: foo@bar (as if we typed right from the keyboard)
Created attachment 93432 [details] image
The switching of activities is broken too, likely by this bug. This is tested under Kubuntu Vidid with Plasma 5.3.2. Steps to Reproduct: 1. create a new activity (have at least two) 2. hit meta+tab to switch to the next activity Actual Results: Nothing happens Expected Results: Changing of the activity.
Migrated to archlinux x86_64 and plasma 5, by example meta + m as simple command URL with the command zenity --info --text 'ok' doesn't work at all (zenity works as well if the command is launched in a pseudo terminal) plasmashell 5.4.0 No errors in ~/.xsession-errors
Meta+A (latin 9 keyboard) pop up the activities window. (it's supposed to be Meta+Q) Setting a new shortcut with meta+A don't override this. tested on archlinux / plasma 5 with a new fresh user
An interesting test is that if you uninstall khotkeys and relogin, meta+a still pop up activities window
Same problem here. Meta+Q doesn't work, Meta+S (stop activity) doesn't work Plasma 5.4.1 KDE Frameworks 5.14.0
(In reply to gilles Quenot from comment #4) > Meta+A (latin 9 keyboard) pop up the activities window. (it's supposed to be > Meta+Q) > > Setting a new shortcut with meta+A don't override this. This sounds as if you've a non-qwerty keyboard (likely azerty? ;-) Try pkill kglobalaccel5; sleep 1; kglobalaccel5 & do shortcuts work as expected afterwards?
Yes, I have an azerty keyboard accordingly to the latin 9 keymap as stated earlier. If I hit meta+a, I get 'éà&(&à&é' (instead of 20151013 with the command 'xvkbd -xsendevent -text "$(date '+%Y%m%d')"') in the konsole5 pseudo-terminal before or after your commands. Same thing with kwrite 15.8.1. But if I run keyboard shortcuts in firefox 41.0.1 (GTK), all keyboards shortcuts with meta+* works !
But that's about how the client is handling the xsendevent input from xvkbd. So the shortcut by itself is working (it triggers the correct event, just Qt5 handles the synthetic keyboard input different from Qt4 and or gtk+)? Your original bug description sounded different, though.
Changed title. Is it OK ?
I meant the first post*, but the "problem" is that this is a bug or incompatibility between xvkbd and Qt5 - neither khotkeys nor kglobalaccel is a problem here (the shortcut is triggered by kglobalaccel and and khotkeys executes the proper command - just the command does not what it's expected to do, depending on the client it's applied to) Did you try whether this is related to the pressed meta modifier (ie. does it happen with a shortcut that does not require to press the meta key or when calling xvkbd delayed sleep 5; xvkbd -xsendevent -text "$(date '+%Y%m%d')" * notably this: "Instead, I have a bug that switch me to another plasma activity and pop me some random applications" sounded as if the shortcut wasn't triggered at all but something else was done.
Given bug #353781 it seems Qt5 ignores at least the xkey.state flag of sent events, so the bug is in Qt5 for pretty much sure.
This has been brought to the Qt mailing list before: http://lists.qt-project.org/pipermail/interest/2014-June/012718.html *** This bug has been marked as a duplicate of bug 353781 ***