RFC: On-screen- / virtual-keyboard

* RFC: On-screen- / virtual-keyboard
@ 2011-12-01 10:47 Samuel Stirtzel
  2011-12-01 10:49 ` Koen Kooi
  2011-12-01 10:55 ` Richard Purdie
  0 siblings, 2 replies; 7+ messages in thread
From: Samuel Stirtzel @ 2011-12-01 10:47 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

Hi,
some devices like the Nokia N900 or the OpenPandora provide a hardware
keyboard,
other devices need USB keyboards to operate, but how could a user
input text into a touchscreen-only device?

#1. The situation

Portable devices with a touchscreen usually provide virtual keyboards,
looking around in OE-dev and OE-Core,
there is illume-keyboard but i doubt it can be used with XFCE that easily.

To tell the user that he has to buy a (small) hardware keyboard to use
a touchscreen device isn't an "appropriate" solution,
if you know what I mean ;)

#2. What was already discovered

There are plenty of virtual keyboards out there, for example:
-gok (gnome on-screen keyboard) [1]
-kvkbd (kde virtual keyboard) [2]
-illume-keyboard (e17 enlightenment on-screen-keyboard add-on) [3]
-onboard (generic on-screen keyboard) [4]
-(Qt) Colibri (in application virtual keyboard) [5]
-(Qt/Gtk2/Gtk3) Maliit (in application virtual keyboard) [6]

But they all have some limitations:
Either they only work with one window manager, or they don't have
support for different keyboard layouts.
In application keyboards have major drawbacks too, the user can't
enter text into other applications (eg. terminals).

The onboard virtual keyboard needs GObject-Introspection which is
somehow cumbersome to build (or did someone succeed to build it?).

#3. What is needed

Most likely suitable would be a virtual keyboard that can be used
across distributions (or at least within OE-Core),
and it should work independent from the window manager.

Using a virtual keyboard (library / plug-in) that is bound to the code
of the applications would also be possible, but it is very limiting.

Of course the keyboard needs some functionality, like switching the
keyboard layout to the preferred localization, resizing properly, it
should look "nice".
The best would be, if the keyboard features usability enhancements,
something like: The user can see the button that he pressed hovering
above his finger or the like (just these "iWhatever" features).

If the user needs to use a pen for the keyboard, that would be no problem.
But if the user has to re-type every second letter because of an
unusable layout, then I would prefer to ship speech recognition
software :)
(on a mobile phone I could just do that, but on "industrial" devices
it would not be accepted that easily).

#4. Working towards the solution

Porting onboard could work out well, but GObject-Introspection is not
that trivial.

If you have any other idea, or know about any software that would be
interesting, it would help much.
There is no problem if the software is incomplete / currently in
active development, or in a beta stage.
(As long as it is already usable).

#5. Appendix

[1] gok: http://www.gok.ca/
[2] kvkbd: http://kde-apps.org/content/show.php?content=94374
[3] illume: http://wiki.openmoko.org/wiki/Illume
[4] onboard: https://launchpad.net/onboard
[5] colibri: https://projects.developer.nokia.com/colibri (note: site
currently in maintenance)
[6] maliit: https://wiki.maliit.org/Main_Page

-- 
Regards
Samuel

^ permalink raw reply	[flat|nested] 7+ messages in thread