Keyboard permanently shows labels on buttons as if I am holding shift

Thanks for the bug report. Having those labels stuck in uppercase sounds quite familiar, though having it happen right on startup seems new. In the past there were issues with counting the active shift keys going wrong. Those were supposed to be fixed, though.

Since you built from source before, would you mind building both virtkey and Onboard straight from bazaar? This will make sure we're on the same page. There are plenty new features to try out too.
Some instructions are in the original thread of question #226567, comment #5 in particular. Just ask if you need more help.

Marmuta,

looks like you got me wrong: this bug doesn't appear right on startup. At startup everything is fine. The glitch happens after a couple of minutes while using, and I can't say for sure, what actions cause it.

Ok, I will re-build again, but what do you mean by "straight from bazaar"? :) Should I clone the most recent version with

bazaar branch lp:onboard

debuild it into a deb-package and install it with dpkg?

Unfortunately, I've built my current installation without creating .deb package, but rather just with distutils. Is there a better way to remove it rather than just manual deletion of each file installed?

Ok, not on startup, that's good. It's pretty much the bug as I remember it then.

Right, branch the development versions of virtkey and Onboard from our bazaar repositories:

bzr branch lp:virtkey
cd virtkey
debuld binary
sudo dpkg -i ../*virtkey*.deb
cd ..

bzr branch lp:onboard
cd onboard
debuild binary
sudo dpkg -i ../onboard*.deb

You have to install the dependencies manually, but you did most of this before already. Check debian/control_python3.in if you need the names of all the dependencies.
"apt-get build-dep ..." won't work for installing them, since Debian doesn't know about virtkey and onboard.

Like before, you can still do "./setup.py build && sudo ./setup.py install" instead of building and installing the packages. If you can, I recommend going with packages, though.

I'm not aware of an easier way to remove the distutils installed files. If you installed to the default /usr/local, you'll have to remove all files manually. If you had changed the prefix to /usr before, you can skip this step and just let dpkg -i overwrite what was there.

Boris, there have been changes to the way Onboard is built. From now on you can skip building and installing virtkey. All you need is:

bzr branch lp:onboard
cd onboard
debuild binary
sudo dpkg -i ../onboard*.deb

or alternatively replace the last two lines with:
./setup.py build
sudo ./setup.py install

Hi, marmuta! Sorry for a longtime delay.

Yesterday I removed my distutils installation of Onboard and Virtkey at /usr/local and installed it as a .deb-package as you instructed. Since that time this bug hasn't reappeared (as well as the bug with border settings). I'm happy :)

As for your last comment, did you merge Virtkey tree (if I'm not mistaken, it contains two .c source files, producing a single .so) into the Onboard code?

Two questions on configuration I have: first, I've not found any .service file for Onboard in /usr/share/dbus-1/services or system-services. I'm curious: how do you manage to receive notifications from dconf/gconf configuration changes without dbus interface?

Second, how does one start Onboard right at the startup of gdm3? Should I put its .desktop file to /usr/share/gdm/greeter/autostart with appropriate AutostartCondition?

And one last bug-like thing: in the previous version, when I dragged Onboard with a crosshair-like button, it used to move smoothly. Now it reacts to any drag with a 0,5 second delay even on a system without any programs running. Not that it was very important, but just to inform you.

Thanks a lot!

Great, I was pretty sure I had work done on this bug. I'll close it then.

Yes, what we needed of virtkey was adapted to and merged with Onboard. Gerd Kohlberger worked on this over the last couple of days. Easier to develop/debug/install that way and it will help packaging for Debian.

gconf support was dropped with GTK-3. We're using gesetting now, though the backend will usually be dconf. Notifications are offered by gsettings/GIO. No need to touch D-Bus ourselves, we get (python) callbacks called.

Onboard itself offers a small D-Bus service (see README) too, but there is no activation (auto start), meaning no *.service file necessary.

Can't help with gdm3 unfortunately, I haven't played with it that much and only saw it using caribou as keyboard. IIRC, in gdm2 Onboard was indeed started with a desktop file in /usr/share/gdm/greeter/autostart, though. We even still honor the RUNNING_UNDER_GDM environment variable.

About the drag delay, there's a slight delay when pressing buttons to support canceling key-strokes after initiating a drag gesture on multi-touch screens. This should be closer to 0.1 seconds, though and only happens after 3 seconds of inactivity. I'm not sure where 0.5s could come from. Can you confirm, that the delay doesn't exist when using the move button a second time?

Thanks for the info, marmuta.

As for the drag delay, i'll try to explain Onboard's behavior in mor detail: To be precise, when you drag the keyboard, at first it follows your fingers, then after a ~0.1 sec. it halts and stays at one place for a variable period of time, ~0.1-0.5sec, after that it wakes up and tries to catch up with your finger. If you're constantly moving your finger atop the tablet, Onboard would leap and halt with ever-increasing duration of halt periods.

I see, that drag delay must be something different then. If the previous Onboard version behaved better, perhaps try switching preferences->Keyboard->advanced>Input event source to GTK. Typing in firefox' URL-bar will suffer, but that's the closest thing I could imagine having an influence. Else I'll sooner or later try to reproduce it on my Nexus 7 (doesn't run Ubuntu currently) .

Wow, that really worked! In the GTK events mode it really moves smooth, but input to the mozilla's addressbar lags for the first ~5 seconds of input. I wonder, what's the meaning of this option? It seems to use gdk-translated input events instead of native X ones, but at what stage? And why firefox has something to do with it? Firefox makes use of Cairo, which works right on top of X, not above gdk, right? Does it have something to do with reverse translation of events? I'm quite puzzled :)

'GTK' mode receives pointer events (motion, button press/release, etc.) from the GTK toolkit, as applications are supposed to. This is what all Onboard versions before used. Problem: key-stokes may get lost whenever an entry has a popup list, like the firefox awesome bar, see bug #905636, for example.

Hence I cooked up 'XInput' mode. It ignores GTK and directly listens for XInput events of slave devices. Typing should still be possible in situations where previous versions where unresponsive or key strokes were dropped. We have used this for quite some time now, but there may still be the occasional hick-up, as you discovered.

I'm going to try to reproduce the pauses somehow. I'd be difficult to fix remotely otherwise. Would you open a new bug for this please? Just copy your descriptions above in.

Ok, thanks, I see, it's about xinput extension events. Crested a bug report: https://bugs.launchpad.net/onboard/+bug/1210665