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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
