We have an on-screen (or, if you prefer, virtual or software) keyboard for Plasma. It can run independently of the shell by way of the plasma-keyboardcontainer application (which we use in Plasma Active) or the Keyboard Plasmoid that comes as part of the kdeplasma-addons repository.
We've been working on may improvements to both the code and the user interface in the last few months. These include improving how it works with a hardware keyboard, being able to move it around the screen on a device, better performance, features like caps- and num-lock (by double-tapping the respective buttons).
There is much more we'd like to do with it, however. If you go to Plasma Active's open tasks page you can find a number of tasks open for the keyboard. This includes things like adding arrow keys to it (these are already supported in the code, we just need to enable them, in a nice way, in the tablet layout), adding locale support so people can easily get to their ü's and ç's, providing copy and paste functionality and more.
These are all bite-sized projects and the code is easily accessible in the Plasma Addons repository under applets/plasmaboard. The stand-alone shell is in the Plasma Mobile repository in the virtualkeyboard directory.
If you're looking for an easy way to get involved with Plasma development that will help Desktop, Netbook and Active simultaneously, look no further. This is a really nice little project to get started with, and we're happy to help you get your legs in the code. :)
Subscribe to:
Post Comments (Atom)
15 comments:
Is it built on http://www.maliit.org/ ?
There is also problem with login manager since kde doesnt work with on-screen keywboards, so it is impossible to login using kdm on tablet pc
I have some idea about merge screen keyboard thing with input method support.
Obviously currently keyboard can generates key event and pass to input method, but the input method will also provides it's own input window. I hope in the future this on-screen will support some future like the keyboard on the android.
Actually KDE already have kimpanel protocol and can use it to communicate with input method. So I think this can be implement easily. (And I have a rewritten dataengine for kimpanel and hope to contribute this to KDE in future.)
@KAMiKAZOW: no; we evaluated maliit, however the keyboard plasmoid predated maliit being a valid target and even now we're not sure maliit is a long-term solution (even though many parts of it look quite good). we can always switch to it as a technology behind the keyboard later, of course, should that prove to be a valid path.
@alexxy: right now we're not developing for a username/password log-in based system. autologin is what we're assuming for the moment, and in future it wold be nice to see a KDM with a touch based log in syste, not necessarily password based, as that doesn't seem to make a whole lot of sense for these kinds of devices.
however .. all THAT said, i would still like to see KDM with virtual keyboard support. the KDM Plasma project may be able to provide just that.
the big issue right now with KDM is that the virtual keyboard container is not started when KDM is, and i have no idea how well it would actually work in practice right now (no window manager, etc). would be interesting for someone to try this out, however, and let us know!
@csslayer: yes, i'd like to see the keyboard directly handle the multibyte input method events when the keyboard is shown. no point in two systems, as you note.
that dataengine you mention sounds interesting; i hope you can post it soon for others to see and try! :)
Why are you not sure that Maliit is a long-term solution?
@KAMiKAZOW: try again, this time without accusations, and your comment will remain. i'm happy with differences in viewpoint. i will not, however, harbour a culture of nonconstructiveness here on my blog.
What are the specific points that made you not chose Maliit after evaluating it?
Looking at your priorities, it seems like a good fit:
* KWin virtual keyboard awareness
Works out-of-the box as far as I know.
* Copy/paste of text?
A toolbar can be enabled that provides copy/past buttons on the keyboard. Our experience is that ideally this interaction should be done on toolkit side though.
* Add arrow keys to the tablet layout
https://meego.gitorious.org/meegotouch/meegotouch-inputmethodkeyboard/merge_requests/431
* Characters for more locales (e.g. German, French, etc)
Some 20 good layouts for different locales are provided.
https://gitorious.org/maliit/maliit-plugins/trees/master/m-keyboard/layouts
* Gtk+ IM plugin to trigger it
Done. http://gitorious.org/meegotouch-inputmethodbridges
* Multi-byte input
Just-works. See above layouts, or some of the layouts created with MesInput.
http://www.mesinput.com/viewlayouts/layout/36027
We also have solved input of composed scripts (CJK for instance)
* Rewrite in QML
There is a QML based plugin available.
https://gitorious.org/maliit/maliit-plugins/trees/master/meego-keyboard-quick
* Ensure that line edit does not get obscured by keyboard
This should maybe have been your first priority. Maliit has toolkit integration for this in Qt Components, Meego UX components and Libmeegotouch, and the expertise to help you realize it in your toolkit. http://wiki.meego.com/images/Technical-overview-widget-reloc.pdf
A toolkit independent fallback has also been written: http://wiki.maliit.org/Ideas#Window_relocation
@Jon Nordby: kwin integration, arrow keys and locale layouts are already supported by the virtual keyboard being used currently in Plasma Active. what is needed is for them to be incorporated into the default layout that is used for the tablet and a way to switch quickly / nicely between localized layouts in the shell the keyboard appears in.
i do like how maliit has that nice swipe gesture for it, as well as the long hold for accented keys.
copy and paste support (and i agree that its best done on the toolkit end, but...), gtk+ IM plugin and multibyte input are indeed bits that maliit currently does nicer.
after reading the linked PDF on making the lineedit visible (thanks for the link :) it strikes me that this is much more about the toolkit, or in this case the QML components, than the keyboard itself. did i just understand the PDF incorrectly?
in any case: i'd be happy to see a maliit based solution that integrates nicely with Plasma Active (and, for that matter, Plasma Desktop) on our target OSes. particularly if it relieves us of development effort and gives us a high quality component.
it was a while since i last tride Maliit, so i grabbed it fresh from git to try it out on my laptop (no packages for openSUSE that i could find) and after running the demo app found that:
* it requires compositing (fine for tablet where we can require that; not so great on the desktop where many run w/out)
* the letter keys didn't actually work (enter and delete keys worked, sending the characters to the target window in the demo app just fine)
* swipe to change layouts didn't work (perhaps i didn't have something configured right there?)
* couldn't figure out how to hide the keyboard without pressing "Hide keyboard" in the demo app
and obviously (though this is a relatively minor issue, as i assume theming is easy enough) it doesn't fit the Plasma look and feel at all.
so it isn't a panacea. it has issues, but it also has benefits.
the last bit of concern is the contributions and code size. mallit is ~51kloc; the plasma keyboard is ~3.2kloc. maliit is obviously designed to be more generic and flexible and so that difference in code weight. however, it also means that if it ends up with us having to maintain that codebase in the future, for whatever reason, it's hefty.
33 people have contributed to maliit, according to git. in the framework there are 7 commits from ixonos, 76 from vincit, 314 from openisumus and 527 from nokia. 3 from intel and 13 from others. the plugins are slightly more stark:
nokia: 997
openismus: 299
vincit: 252
ixonos: 7
others: 1 (3 lines of code to do with ruby)
my concern here is that maliit is evidently a successful commercial opensource project (a positive thing) which has been apparently driven by the needs of the companies around meego (Nokia and Intel primarily it seems?) when both of those companies seem to be taking distancing steps from the platform. this makes me wonder about the future maintenance of maliit, which may be completely an unfounded concern (and please help give me a better foundation for the assessment if there is one! :)
by contrast, plasmaboard has had 16 different contributors from a variety of companies as well as the volunteer contributor community. this isn't a panacea, either, of course, but it's a 3.2kloc asset (pretty small, all told) that we understand pretty well, giving it a good maintenance story.
what i have to weigh is the future risk, current costs and current benefits of all possible paths.
if there is interest on behalf of the maliit project in coordinating with us and working on having maliit The Virtual Keyboard in Plasma Active, i'd love to have that conversation. irc, email, skype, phone, whichever :)
cheers..
No, you understood the PDF correctly. Widget relocation is mostly about the toolkit. But it requires integration with the input method framework, the information about what area the input method covers (and thus needs to be avoided) comes from the framework.
In an environment where windows can be freely moved around (not very common on mobile platforms), you'd have to incorporate something like what is shown in the second link in addition.
* it requires compositing
We had code for supporting for using shaped windows instead, but we dropped it. It could be brought back if there is a good use case for it.
* swipe to change layouts didn't work
The currently built-by-default input method plugin is the QML one, as it does not have any extra dependencies. It does not support this feature or indeed most of the nice things our other keyboard plugin does.
* couldn't figure out how to hide the keyboard without pressing "Hide keyboard" in the demo app
The input method is available when you have an input widget focused, and dismissed when you don't. The other keyboard plugin also allows you to swipe down on the keyboard to dismiss (which will result in focus out in application, maintaining the invariant). The hide button simply steals focus from the input widget.
Maliit for sure is no panacea. There are plenty of issues, especially when you take it outside the environment it was initially developed for. But that people do that is important for our project (and thus my interest here):
We are actively working to make Maliit more than just a successful commercial open source project, we want to make its life and success independent of any single party. This is non-trivial, as I'm sure you understand, but I think we can succeed.
=== More to the point:
I think the potential benefits of Maliit for KDE lies mostly in the framework. The plug-ins we provide are less important seeing as you already have plasmaboard.
The framework is what enables the Gtk+ IM support, the widget relocation for mentioned supported toolkits, support for other input method plugins (commercial or open), et.c.
Therefore what I propose that you consider is to have the plasmaboard be a Maliit input method plugin. You could even make it an optional thing. I'd argue that the risk of trying this is very low, and the cost should not be too prohibitive either.
If you're interested in this, I suggest you get in contact using one of our communication channels listed on maliit.org
We are interested!
Hey, you did not respond to my last comment about using the plasmaboard as a Maliit plugin.
Maliit is now in Mer (Middleware), and I understand that Plasma Active is also targeting it. To have a good input method story on Mer I think it would be ideal to integrate Plasma and Maliit.
You will find me in #mer and #active, or in the Maliit channels.
Aaron, it looks like Jon is still hoping for a response.
Also, is there any new status on this keyboard? And what should we call this keyboard - does it have a name?
@Murray: unfortunately i'm overly busy these days and lack the time to start a big forray into Maliit integration.
as for status on the plasma keyboard, yes, there has been a fair amount of progress since this blog posting, mostly in terms of bug fixing and performance improvements (as i covered in another recent blog)
it doesn't particularly have a name, as it isn't the sort of thing that gets a lot of discussion / attention (other than "is there a keyboard? does it work?"). "plasmaboard" is what it shows up as in the widget listings, however ..
Hello,
It would be hugely beneficial if the plasma keyboard had a word completion feature. I cannot type so I use an onsreen keyboard (archaic xvkbd) clicking one key at a time.
http://forum.kde.org/brainstorm.php?mode=idea&i=97545#anchormain
I'm not quite sure if you will see this post, but your blog post seem to alway come up as a reference in my research.
I trying to have a similar plasma active keyboard working in the desktop environment... ie, pop up when the cursor fall in an input area. It work nicely in active, but I personnaly don't like the "tablet layout"... I'm rather old school.
However, on my brand new asus eeepc t101mt, with touch screen, I really like it to be working.
Considering it is plasma environment, is it possible to bring the active keyboard to the desktop layout?
Thanks for your time.
Simon G
Post a Comment