[kde-linux] Desktop switching when Virtualbox is full screen

Tue Jun 9 18:16:49 UTC 2015

On Mon, Jun 8, 2015 at 8:47 AM, Duncan <1i5t5.duncan at cox.net> wrote:
> Mark Knecht posted on Mon, 08 Jun 2015 06:31:33 -0700 as excerpted:
>
>>    Is there a way for KDE to _always_ grab specific keyboard shortcuts?
>>
>>    My KDE-4 setup runs 3 monitors set horizontally with 6 desktops. I
>> scroll between monitors and can switch between desktops using
>> Ctrl-F1..F6. Currently I'm needing to use a number of Windows dual
>> monitor VMs running full screen. Unfortunately when Windows is full
>> screen in the VM monitors #1 & #2 are completely taken up and the
>> desktop switching shortcut doesn't work. I have to scroll my mouse to
>> monitor 3 which is still KDE to use it, or momentarily take the VMs out
>> of full screen and position my mouse over desktop area.
>>
>>    I understand that generically the shortcut is likely being passed
>> Windows and dumped as it probably has no defined function in the
>> programs I'm running there but I'm wondering if there's a way for KDE to
>> always take specific shortcuts and not pass them down to running inside
>> of KDE?
>
> From what I know and have observed, xorg's global keyboard handling, as
> you suggest, consists of a list of running apps that have told xorg they
> want subscribed to that list.  The problem is that each app in that list,
> after seeing the key itself, can either pass it on to the others, or
> "swallow" it, so it doesn't get seen by any others on the list, or by
> whatever active application the keys get sent to after they've dropped
> thru the list.
>
> So what you need to do is control the order of the apps on that list.
> I'm not /sure/ of this, but based on what I've observed at least, the
> order is based on when the app was started.  Apps get placed on the top
> of the list when they request to be added to it, pushing others down, so
> the last app started gets first dibs on keys.
>
> If that is indeed correct, then what you will need to do is either start
> the VMs earlier in the X startup process so they get on the list first
> and pushed down when kde's listeners get there, which I think is going to
> be a bit difficult to do and may have other consequences, OR restart the
> kde listeners AFTER the VMs in question, so kde's listeners are at the
> top of the stack and get first dibs on the keys.  That might actually be
> possible.
>
> The other alternative would be to work around the problem using a third-
> party hotkey app like sxhkd (simple X hotkey daemon), which I happen to
> run here in ordered to listen for and trigger actions based on touchpad
> gestures.  The way that works is that the touchpad driver translates
> those gestures into high-number (8-20, IIRC) "mouse button" push events.
> sxhkd then listens for those high-number mouse button events, and
> triggers other actions based on the event, what app is active, etc.  This
> works well because sxhkd is started with kde, but later than kde's own
> stuff, so it's top of the notification stack and gets first dibs on keys,
> including mouse buttons.  One nice thing about sxhkd is that it can be
> configured per-event to either swallow that event, or pass it on to
> others further down the stack and ultimately to the active window.
>
> You could configure sxhkd (or alternative app, xbindkeys is another
> powerful alternative in the category) in one of two ways.  You could
> either have it respond to the key directly, or more likely given what
> you've described, have it listen for one key, and emit a different one --
> perhaps one of the many available "extra inet and media keyboard keys",
> choosing one that your keyboard doesn't actually emit on its own, and
> then configure kde's hotkeys to respond to that "fake" key, emitted by
> sxhkd in response to the real event that triggered it.
>
> The idea would be to find an available "fake" key that you're not using,
> that the VM doesn't swallow, so that you could effectively bypass the VM
> layer, by having sxhkd trap the real trigger and emit the fake one, which
> the kde listener is actually configured to respond to in place of the
> real one.
>
> As I said, I do something rather similar here, with the touchpad driver
> programmed to emit high-number mousebutton "clicks", which sxhkd then
> intercepts and acts accordingly based on the "mouse button" aka touchpad
> gesture I did and various things like active and running windows,
> depending on how it is programmed for that specific "mouse button".  Many
> times, I actually have it simply emit other keys using another app,
> xdotool.
>
> For instance, the touchpad pinch gesture is set to trigger kde/kwin's
> zoom feature by emitting the keys I have kwin zoom configured to use,
> regardless of what's active, while what the rotate gesture does depends
> on the active window -- if it's gwenview, it emits the keystrokes that
> are configured in gwenview to rotate the displayed image, if it's some
> other graphics app, it might issue other keys to get the same effect,
> while if it's a non-graphics app, it might issue other keys that do
> something specific in that app.  Meanwhile, as I have things configured,
> two-finger swipes are reserved for scrolling (both vertical and
> horizontal are setup, that's pretty much default for two-finger swipes),
> three-finger swipes for app-specific stuff like the back (3-finger-swipe-
> left) and forward (right) and zoom-page (up/down) functions in firefox,
> and four-finger-swipes for global functions, 4-finger-swipe-left
> activates kwin's close-window function on the active window, for
> instance, just as if I'd hit the X in the titlebar, while 4-finger-swipe-
> down will either drag-lock or repeat whatever "mouse button" I trigger
> next, and 4-finger-swipe-up cancels the repeat.  That lets me trigger
> pinch-to-zoom either once (just pinch in or out), or repeatedly for
> continual zooming (4-finger-swipe down, pinch, 4-finger-swipe-up when I
> want to stop).
>
> And... I just realized I actually have 4-finger-swipe-right set to
> trigger a desktop switch, almost exactly as I described for you, sxhkd
> catches the "mouse button" and fakes the hotkey I have kde configured to
> use for desktop switch.  Now I can desktop-switch without having a bare
> desktop to scroll over, faking the win-Fx key I have setup to do the same
> thing, if I'm using the mouse and not the keyboard at that moment. =:^)
>
> You'd set it up exactly the same way, except using a keyboard shortcut
> instead of the touchpad/mouse-button event I use, with sxhkd listening
> for one shortcut that the VMs swallow, and faking another one that they
> don't. =:^)
>
> The problem then is down to simply installing sxhkd and xdotool, setting
> up sxhkd to listen for the hotkey you want to use and to run after the VMs
> that are causing the problem, and finding a key that the VMs don't
> swallow to fake, that you can setup in kde to do the actual switch, and
> in sxhkd to be faked using xdotool when you hit the real hotkey.
>
> As for finding such unused keys to fake, check /usr/share/X11/xkb/
> keycodes/evdev for a list.  Try KEY_PROG1, for instance, which you'll set
> sxhkd to emit with a call to xdotool key XF86Prog1, or similar.
>
> --
> Duncan - List replies preferred.   No HTML msgs.

Thanks Duncan. I'm going to try this path and see how it works out.

Cheers,
Mark