While the S60 port was going on, it became clear to us that there was something that Qt needed: A proper API for dealing with input panels (also called virtual keyboards). For the S60 platform the motivation was obvious, since most touch phones use some sort of on-screen keyboard. But we also wanted to make the API in such a way that it could be used by developers on other platforms, which is useful for kiosks or desktop machines with touch screens.
The API itself is an extension to the QInputContext class, which already deals with input methods, and is actually really simple: Two new events that tell you when to open the panel and when to close it, RequestSoftwareInputPanel and CloseSoftwareInputPanel. All Qt's input widgets support these events and will send them when appropriate. As for how to deliver events from the panel to the widget? Well, that's already there in the form of QInputMethodEvents.
What the input panel developer then needs to do is to make a class which subclasses QInputContext, and in the filterEvent() function you look for the events which tell you show or hide your input widget. If you want to have extra control over what type of input can be used (so the input panel can show only numbers, for example), check out the new inputMethodHints property of QWidget. This property is fully editable in Qt Designer, and some widgets already use it automatically, such as QSpinBox which sets it to numbers only.
Check out the example in Git under examples/tools/inputpanel! It's also documented at http://doc.trolltech.com/4.6-snapshot/tools-inputpanel.html.
Commenting for this post has ended.
Would this work cross-application, i.e. desktop wide? Ideally, I would like to write something like the Windows Tablet Editition input panel, similar to CellWriter, but using pure Qt, and have it work with Qt apps, as well as legacy applications.
I have not checked all the input method stuff that Qt offers, but I might when above is possible :)
Thanks for all your work, Qt is truly the only toolkit out there that makes sense!
Well, not the API itself, I'm afraid. But if you keep the input panel as a separate application, you can definitely use the above API and events to trigger activation of the input panel and communicate that to the other process using IPC. This would be the QInputContext's task, in that case. Legacy applications wouldn't have the API in them, so you'll need a different solution there.
When sending events from the input panel back to the receiving app, you're best off with sending the platform's native events. It would be cool if we had an API to do that in Qt, but noone has picked up the task yet. :-)
Could it be used for desktops like the following: http://www.qt-apps.org/cont...
My plan is to use this within a desktop application on an All-in-one touchscreen pc too.
Here the correct URL (one 8 is missing in the previous URL): http://www.qt-apps.org/cont...
That believe that should work, yes!
And you wouldn't need those "open/hide" buttons anymore, since the widgets will ask for a keyboard themselves.
This will be very useful for us, since we develop POS solutions. The frontend at the moment uses OpenMotif, but we plan to switch that to Qt eventually. Will you be providing widgets for the input as well, a generic keyboard and a generic number input field only?
We have no current plans to support a generic keyboard. This is because there is no clear consensus for how this should look and behave on desktop platforms. Everybody would probably have a different opinion on how it should look. That doesn't mean we aren't open to ideas though. :-)
On Symbian you will get the standard platform keyboard.