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

From Qt Wiki
Jump to: navigation, search
 
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