Qt-contributors-summit-2011-Input methods and Wayland in Qt 5

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Wayland and input methods

• Try out-of-process approach (that is, application does not load virtual keyboard itself, but let Wayland compositor do it). Provides certain flexibility, reduces start up time, too.
• Wayland should have an interface for input method windows
  • Need to be transient to application window,
  • Need to forward input events correctly
  • Need to allow outbound communication between input method and application (too many input method related details otherwise in Wayland, reduces flexibility, too)
• Wayland ask for the input method texture and does the compositing with application texture
  • Good: Wayland knows exactly which texture is the input method texture, can do the mapping without races.
• Want to keep input methods pluggable (that's the whole idea of QInputContext after all)
• BUT: Need to figure out which input method parts are better served by Lighthouse.
  • Q: Should QInputContext move into Lighthouse?
  • A: Nope, just remove QWidget dependency and move into QtCore

Better support for input methods in standard Qt.

My background (Michael Hasselmann): Working on Maliit, the input methods for MeeGo (maliit.org). In MeeGo Touch, many hacks were needed to use QInputContext for QGraphicsView and QDeclarativeView. An extension API for QInputContext allows application developers to control certain aspects of the virtual keyboard. Some of that should probably go upstream.

Rough overview of some issues we faced:

• Suport for input widget relocation (see http://wiki.meego.com/images/Technical-overview-widget-reloc.pdf)
• Getting preedit to be considered as text content when appropriate (not composed languages),
• Rich text (currently, all based on plain text – cannot even transmit smileys easily),
• Getting things committed when text widget is reset, maybe enhance the updating mechanism,
• Better view to widget than qwidget interface, needs to be done anyway if QWidget is phased out (well, moved into add-on),
• Ability to make input method extensions with QML (maybe),
• Mouse event handling might have some adjustment, how can user start to select on top of preedit etc.,
• Word activation (turn a string into a preedit).
• Send commands to application: Copy, paste, … (we did that in MeeGo Touch through a specific input method toolbar that docks on top of the virtual keyboard)

Extension ideas for Qt's input context API:

• report input method area to application
• dynamic key overrides: customize keys on a virtual keyboard, from application side
• input method toolbar support? needed for terminal applications at least (tab, ctrl, esc – makes no sense to have in default keyboard layouts, but can also be useful for rich text editing or messaging UI)
• orientation support
• key event emulation (already needed for browser plugins, say, games in Flash, but useful if we want to replace XKB)
• preedit injection (a preedit is a word/character that is "composed", and a preedit injection inserts a word/character into the current preedit)

Session outcome

• Come up with a QFocusable interface, used by QML, QWidgets, other custom stuff.
• How to sync rotation between app and virtual keyboard? Only smoothly possible with in-process virtual keyboard?
• Input method areas property on input context
• Auxillary keyboard support, announced as texture by application
• Direct input mode hint for raw key event processing.