Qt-contributors-summit-2011-Input methods and Wayland in Qt 5: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
==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)
* <span class="caps">BUT</span>: 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 <span class="caps">API</span> 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 <span class="caps">QML</span> (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 <span class="caps">API</span>:
* 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 <span class="caps">XKB</span>)
* 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 <span class="caps">QML</span>, 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.

Revision as of 13:53, 24 February 2015