Virtual Keyboard for Plasma desktop/screen locker

[raffarti]

Hello everyone,

this is about design and development of a virtual keyboard for plasma.
TOPICS:
  1)End-user features.
  2)Technical issues and solutions.
  
NOTE: this is not a statement of purpose, this is a request for help, you're 
invited to discuss every pixel of it.

INTRO:
As tablet pc owner, I can say that what plasma really needs is a keyboard for 
the screen locker, everything else (even login with kdm) can be done using any 
existing virtual keyboard (like onboard).
Also sddm needs it.
Currently I'm using a QML keyboard with a C++ plugin based on XTest (didn't 
tried to put it on the screen locker yet, though). It works great to me, but 
it's a rough implementation so I'm planning to rework it.
It would be great if it could be adopted for plasma (or compatible, at least), 
so I'd like to collect as many advices and minds as possible.

Basic Idea:
I'd like the keyboard to be able to works in as many contexts as possible 
(stand-alone or qt integrated), that is how I'd like it:
  -A QML wrapper.
  -A C++ plugin for QML.
  -One or more QML Models (one for each layout or layout type?).
  -A set of implementations for the QML Model (most likely one KDE and one 
plain QML).
  -A Set of C++ dynamic plugins, one for each implementation.
  -One keymap for IM, one for full physical keyboard emulation.

1)END-USER Features:
What I'd like to do is a virtual keyboard capable of switching between an 
Input Method mode (text based) and a physical emulation mode (Key event 
based).
An Input Method approach should be more reliable and easy to implement on a 
client application, supporting only text input, it should have a compact 
layout and allow extra features as spell checking/prediction/correction.
A physical emulation keyboard is useful for legacy environments, not designed 
for mobile, which makes large use of keyboard shortcuts.

My question is, which one means more to KDE? A text input only (IM) strategy 
could cover everything essential, has a typical compact layout optimal for 
small screens, but KDE is actually a desktop environment and a physical 
emulation would be useful for seasoned KDE user especially on devices such as 
2-in-1 and convertible tablets.
Which of those two ways has to be implemented first?

Desirable features:
-Seamless IM/emulation switching
-Editable keymaps
-Extra fancy plugins (probably integrated by QML directly)(e.g. virtual 
touchpad, applications integration, windows management,...)
-...?


2)TECHNICAL issues and solutions:

Warning: I'm not much experienced on those matters so anything follows could 
be inaccurate or wrong.

IM (text based) solution:
  -one key mapping per language.
  -key mapping based on UTF8 for printable characters + Qt::Key (or other 
enum/string/whatever) for action buttons (enter, backspace,...)
  -QInputMethod for Qt
  -XIM for X (or so I guess, just googled it yesterday)
  -Wayland supports IM AFAIK
  
Key emulation solution:
  -one key mapping per platform or one per language if based on Qt::Key (note 
that using native keycodes you should have immediate support for all native 
supported languages)
  -Qt doesn't provides any conversion form Qt::Key to UTF8, thus both Qt and 
X11 implementations will use XKB for keysym to utf8 translation
  -Moreover, both Qt and X11 implementations will require KKeyServer if key 
mapping uses Qt::Key
  -X11 implementation can be done using XTest library or using XSendEvent 
directly (caveat) or xcb equivalents. (please don't forget to discuss that 
point)
  -QCoreApplication::processEvent(...) or QCoreApplication::sendEvent(...)
  -Wayland I have no idea, but my guess is something similar to X exists.
  
For both a set of symbols or icons is needed to display non-printable keys.


Each part of this project should be modular and re-usable by similar projects, 
their interface should be as generic as possible.

Anyone willing to join the development is welcome (especially true for QML 
parts).

  Raffaele Pertile
  
P.S.
Is Maliit still dead?
---
raffarti