Between Linux and Anime

Or to most anything else really. So this is what I hope will become the first of a series of blogs documenting my adventures getting a regular KDE Plasma (desktop) installation to tango with an x86 touch device – common nowadays in the form of Windows 8 tablets.

On my Machine and OS:
My specific machine is a Lenovo Yoga 11s (Haswell version), so not fully a tablet, but convertible into one by flexing the lower half all the way to the back. I had initially attempted with fair success to set up a Plasma Active-based system (by using experimental OpenSUSE Plasma Active packages), and with the right amount of tinkering that actually worked very well. However I eventually bumped into a few insurmountable hurdles: for example, the inability to set up Chinese and Japanese input since Maliit (the virtual keyboard) was an input method and, to the best of my knowledge, not dynamically switchable with a foreign language input method like ibus. So when inevitable circumstance eventually forced me to set up everything from scratch again, I decided this time to start with a regular KDE Plasma Desktop (on top of OpenSUSE 13.1), and see if I can harness the inherent malleability of Plasma and of Linux itself to achieve an acceptably touch-friendly setup.

Anyway on to the topic at hand. One of the distinguishing features of most x86 tablet computers today is that they, being originally sold as windows machines, sport a physical “windows button” near the screen:

This button on Linux would be bound to “super”, which on most DEs makes it basically useless since “super” by itself doesn’t usually do anything. On the other hand, touch screens on Linux generally simply behave like mice do, where taps are clicks and swipes are click-drags. The right click context menu is invaluable when using a traditional Linux desktop without a keyboard, and yet there is no direct way to right click with a touch screen. So a very useful customization I was able to put on my system is to bind the useless “windows button” to right-click.

This is less trivial than it might initially appear. A major pitfall is that while “super” on Linux by itself generally doesn’t do anything, it is heavily used as a modifier key for many keyboard shortcuts in most setups. So we need to bind “super” to a custom trigger, while at the same time preserving its use as a modifier key so that we don’t affect the keyboard shortcuts. Fortunately, someone has already worked this out for us. KSuperKey was originally written to allow KDE Plasma users to open the Kickoff menu (or the KDE Desktop’s “start menu”) by hitting just the super key a’la windows, but the program is also powerful enough that it could be used to bind the super key to any key combination – while preserving its status as a modifier key.

So as a first step, grab and install KSuperKey, then use it to bind super to a currently unused key-combination. For example, to bind super to Alt + F10, run the following:

ksuperkey -e 'Super_L=Alt_L|F10'

You can add this to a script in ~/.kde4/Autostart/ so that it is run automatically on session startup. Now hitting the windows button should be the same as hitting Alt + F10, so the next step is to map Alt + F10 to right click. But how do we emulate right click in the first place? Turns out it isn’t half hard. Just install xdotool, and create a script called fake-right-click (or anything you want) with the following contents:

xdotool click 3

Give it execute permissions and run it and you should immediately see the right click context menu open next to your mouse pointer! So now all we need to do is bind Alt + F10 to our new script.

You may think this easily achievable using the built in KDE custom shortcuts control module, and indeed this was what I tried first, but it turned out that for some reason or another this wasn’t reliable, and hitting the windows button would sometimes bring up the context menu and sometimes not. A more reliable means by experiment is to use xbindkeys. Using it for our purposes is quite easy: get it installed, then create the file ~/.xbindkeysrc with the following content:

"/path/to/fake-right-click"
alt + F10

Then simply run xbindkeys. (Again, you can add xbindkeys to a script in ~/.kde4/Autostart/ to have it run on session startup). That’s the last step! Hitting the windows button now should behave exactly like right click, letting you do all kinds of things previously not possible without a keyboard and mouse:

If you use Konsole or Yakuake with transparency you might have noticed that Kwin’s blur effect, that has been around for awhile and that blurs the background of various transparent elements in the UI (eg panels and plasma popups), does not apply to transparent Konsole or Yakuake windows. This has always irked me a tiny bit, but when I discovered that you can blur transparent terminal windows on OSX, that got me itchy enough to do the token research.

The story is a familiar one: it’s not too hard just to GET WORKING, and patches to do it exist, however getting it to work in a sensible way is non-trivial, and so the patches are rejected and the feature itself is pending future structural changes. Basically, it’s not going to happen on it’s own anytime soon.

Fortunately, there are ways to get it working on your own – and they do not involve applying custom patches and rebuilding anything. Turns out there is a terminal command one can run to immediately apply blur on, for example, current active Konsole windows:

xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0 -id `qdbus org.kde.konsole /konsole/MainWindow_1 winId`

And for a currently active Yakuake:

xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0 -name Yakuake

Now to do this automatically so that your yakuake and konsole windows are ALWAYS blurred, you can simply add the following lines to your ~/.bashrc:

Edit: commenters have posted improved versions of the code, thanks commenters! See improved version below:

Edit2: KF5 Konsole and Yakuake 3 onwards requires updated code, as well as xdotool to be installed so we can fetch yakuake’s win id:

konsolex=$(qdbus | grep konsole | cut -f 2 -d\ )
if [ -n "$konsolex" ]; then
for konsole in `xdotool search --class konsole`; do
xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0 -id $konsole;
done
fi
if [ `qdbus | grep yakuake` ]; then
xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0 -id `xdotool search --class yakuake`;
fi


Of course, this often results in the command being run redundantly, but that doesn’t appear to bring any tangible ill-effects. It all works well enough for a quick hackaround. And the results are delicious indeed.

I’ve had more frustration than I’m comfortable admitting to trying to get this to work – I actually gave up and compiled kvkbd at one point. Now that I have it down though it all looks infuriatingly obvious in hindsight. Anyway..

The problem: if you have the official Plasma Active 3 image installed and running on some device, and at some point or another installed/ran a gtk app on your system, you’ll quickly realize that the Maliit-based virtual keyboard does not trigger in your gtk app. That’s contrary to what was promised from the Maliit move! And in fact Maliit predates Plasma Active and should have perfect gtk support, so what gives? It turns out that Plasma Active only includes the Maliit input context plugin for Qt and not for gtk, and that’s basically the problem. (Presumably they decided to save it since the image does not include anything gtk)

The solution: You basically need to install that gtk input context plugin. What I did was I took the package from the recommended repos for openSUSE linked from the Maliit website (specifically this repo). The commands to run (as root!) are:

# zypper ar http://download.opensuse.org/repositories/M17N:/Maliit/openSUSE_Factory/ maliitosfact
# zypper refresh
# zypper in maliit-inputcontext-gtk2


And then update the gtk immodules before rebooting:

# gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules

Note: Zypper will complain about different maliit versions and prompt you to fix by pulling and replacing packages from the openSUSE repo – DON’T DO IT! Just tell it to break maliit-inputcontext-gtk2 by ignoring some dependencies so you install only one package!

You might also want to disable the openSUSE maliit repo after you’re done so you don’t inadvertently pull stuff from it in future:

zypper mr -d maliitosfact

I’m not 100% sure pulling and replacing those packages will actually cause bad things to happen, but I’ve learnt by being bitten – painfully – multiple times not to risk these things if at all possible :) Anyway, the plugin in fact does work perfectly with the Maliit stuff from Plasma Active despite the zypper warnings:

Plasma Active Maliit Keyboard working on an old Fennec build

Of course, this all only works assuming you’re on an i586/x86 device. It’ll probably be harder to find binary packages for the input plugin on arm for example, but this should hopefully at least point you in the right direction. Perhaps you could just build it from source or something.

I know it’s probably already near the end of PA3’s lifecycle now, but hopefully this will still help some frustrated soul out :)