Learn what Felgo offers to help your business succeed. Start your free evaluation today! Felgo for Your Business

Building Qt Virtual Keyboard

Overview

This document describes how to build the Qt Virtual Keyboard plugin.

The project is split into the following subprojects:

examples/virtualkeyboard/basic/basic.pro Qt Virtual Keyboard Demo application
src/virtualkeyboard/virtualkeyboard.pro Qt Virtual Keyboard plugin
src/virtualkeyboard/styles/styles.pro Qt Virtual Keyboard Style plugin that enables style decorations for the keyboard
src/virtualkeyboard/3rdparty/hunspell/hunspell.pro A project file for compiling the Hunspell library.

Note: This project is used if the Hunspell library is built from sources rather than depending on the system library. The project will be activated when the source code is extracted to this directory.

src/virtualkeyboard/3rdparty/lipi-toolkit/lipi-toolkit.pro A project file for compiling the lipi-toolkit library.
src/virtualkeyboard/3rdparty/openwnn/openwnn.pro A project file for compiling the OpenWNN library.
src/virtualkeyboard/3rdparty/pinyin/pinyin.pro A project file for compiling the PinyinIME library.
src/virtualkeyboard/3rdparty/t9write/t9write.pro A project file for including T9 Write dictionaries as resources.
src/virtualkeyboard/3rdparty/tcime/tcime.pro A project file for compiling the TCIME library.

The input methods are implemented either in C++ or QML. Qt Virtual Keyboard provides implementations of PlainInputMethod, MultitapInputMethod and HunspellInputMethod. The MultitapInputMethod is implemented in QML while the others are implemented in C++.

Build Instructions

The Qt Virtual Keyboard can be built for Linux Desktop/X11, Windows Desktop or Boot2Qt targets. The target is automatically detected by QMAKE and requires no special configuration parameters.

Qt Creator is the preferred build environment for Qt Virtual Keyboard as you can then leverage the shadow build functionality and rapidly switch between build targets.

Configuration Options

The table below contains the top-level options for configuring the virtual keyboard features.

CONFIG Description Remarks
lang-<code> Enables the specified language The specified language can be activated using lang-<code> option, which has the format "language[_country]", where:
  • language is a lowercase, two-letter, ISO 639 language code
  • country is an uppercase, two-letter, ISO 3166 country code

This option can be used to define the language support as required. The virtual keyboard can support one or more languages at a time.

For example, CONFIG+=lang-fi_FI activates the Finnish language.

The virtual keyboard automatically includes all languages if no other languages are specified.

lang-all Enables all the languages Enables all the languages supported by the virtual keyboard. This flag is essentially an alias for CONFIG+="lang-ar_AR lang-da_DK ..."

This option is enabled by default. To build only a specific language, use the lang-<code> option above.

handwriting Enables handwriting input This flag enables handwriting input using the first engine available at build time in the following order: t9write, lipi-toolkit. To enable handwriting input using a specific engine, use the feature-specific configuration instead. For example, CONFIG+=lipi-toolkit.
arrow-key-navigation Enables arrow key navigation for the keyboard Allows controlling the keyboard using the arrow and return keys.

Advanced Configuration Options

The table below shows the advanced configuration options that will be applied automatically when activating a certain top-level feature. The options can also be used for enabling or disabling a specific feature.

In most cases, these options are not needed, but there are also cases where their use is justified. For example, the Traditional Chinese language (CONFIG=lang-zh_TW) will include both Zhuyin and Cangjie input methods by default. This behavior can be changed by adding the preferred input method to the configuration, e.g., CONFIG+="lang-zh_TW zhuyin".

Advanced CONFIG Top-level CONFIG Description Remarks
disable-desktop n/a Disables Desktop integration By default, the desktop integration is enabled when the target environment is X11 or Windows desktop. With this option, the desktop integration can be disabled.

Note: For embedded integration, where the InputPanel is instantitated by the application, there is no need to use this option explicitly. The virtual keyboard will not create the desktop input panel if the application creates InputPanel before the focus is set to an input field.

disable-layouts n/a Disables built-in layouts By default, the virtual keyboard plugin contains the English keyboard layout. By specifiying the disable-layouts configuration flag, the built-in layout(s) are excluded from the virtual keyboard plugin.

Note: In this scenario, the QT_VIRTUALKEYBOARD_LAYOUT_PATH environment variable should be set to the file system directory containing the custom keyboard layouts before running the application.

disable-xcb n/a Disables X11 integration

Note: Deprecated since 1.3. Use disable-desktop instead.

disable-hunspell n/a Disables Hunspell integration Hunspell integration is enabled if the Hunspell library is available on the system, or if it is built using the local project file. Integration can be disabled using this option.
static Enables static builds of the virtual keyboard This option enables static builds.
retro-style n/a Enables Retro style Changes the default keyboard style to the Retro style. Both styles are still included in the package, but this option allows you to change the built-in default style.
pinyin lang-zh_CN Enables the Pinyin input method for Simplified Chinese. This option activates the Pinyin input method for the Simplified Chinese language.

As this option activates a particular language, the lang-all option will not be enabled if this option is specified. To build all languages, use CONFIG+=lang-all.

tcime lang-zh_TW Enables the both Cangjie and Zhuyin input methods for Traditional Chinese. This option activates the both Cangjie and Zhuyin input methods for the Traditional Chinese language.

As this option activates a particular language, the lang-all option will not be enabled if this option is specified. To build all languages, use CONFIG+=lang-all.

cangjie lang-zh_TW Enables the Cangjie input method for Traditional Chinese. This option activates the Cangjie input method for the Traditional Chinese language.

As this option activates a particular language, the lang-all option will not be enabled if this option is specified. To build all languages, use CONFIG+=lang-all.

zhuyin lang-zh_TW Enables the Zhuyin input method for Traditional Chinese. This option activates the Zhuyin input method for the Traditional Chinese language.

As this option activates a particular language, the lang-all option will not be enabled if this option is specified. To build all languages, use CONFIG+=lang-all.

hangul lang-ko_KR Enables the Hangul input method for Korean. This option activates the Hangul input method for the Korean language.

As this option activates a particular language, the lang-all option will not be enabled if this option is specified. To build all languages, use CONFIG+=lang-all.

openwnn lang-ja_JP Enables the OpenWnn input method for Japanese. This option activates the OpenWnn input method for the Japanese language.

As this option activates a particular language, the lang-all option will not be enabled if this option is specified. To build all languages, use CONFIG+=lang-all.

lipi-toolkit handwriting Enables the handwriting input method using Lipi Toolkit. Handwriting recognition is based on the open source Lipi Toolkit.
t9write handwriting Enables the handwriting input method using T9 Write. Handwriting recognition is based on the commercial T9 Write product from Nuance Communications.

Building Documentation

make docs Generates documentation

Hunspell Integration

By default, HunspellInputMethod will not be available unless the Hunspell library and development headers are found. For Linux/X11 targets, the Hunspell library can be provided by installing the libhunspell-dev package. Alternatively, the Hunspell sources can be extracted into the src/virtualkeyboard/3rdparty/hunspell directory. If Hunspell sources are used, then the dictionary files must also be copied into the src/virtualkeyboard/3rdparty/hunspell/data directory. Furthermore, if Hunspell sources are used, hunspell.pro will be used for all targets.

An example of how the directory structure should look after copying in the Hunspell sources and dictionary files is listed below:

3rdparty
└── hunspell
    ├── data
    │   ├── en_GB.aff
    │   └── en_GB.dic
    ├── hunspell.pro
    └── src
        └── hunspell
            ├── affentry.cxx
            ├── affentry.hxx
            (etc.)

T9 Write Integration

T9 Write integration supports the T9 Write Alphabetic and T9 Write CJK engines. Both engines are integrated via T9WriteInputMethod. The input method can be initialized with either of the engines at runtime. The engine selection happens automatically based on input locale and input mode from the keyboard.

T9 Write Compatibility

Qt Virtual Keyboard is compatible with T9 Write v7.5.0 onward.

The latest tested version is v7.8.1.

T9 Write Build Preparations

The contents of the SDK must be either manually copied to the directory structure described below, or by using the unpack.py script found in the t9write directory.

To unpack the SDK using the script:

$ cd src/virtualkeyboard/3rdparty/t9write/
$ python unpack.py T9Write_Alpha_v7-8-0_SDK.zip .
3rdparty
└── t9write
    ├─── api
    │   ├─── decuma*.h
    │   ├─── t9write*.h
    │   └─── xxt9w*.h
    ├─── data
    │   ├─── arabic
    │   │   └─── *.bin [T9 Write Arabic]
    │   ├─── hebrew
    │   │   └─── *.bin [T9 Write Hebrew]
    │   ├─── *.bin [T9 Write Alphabetic]
    │   ├─── *.hdb
    │   ├─── *.phd
    │   └─── *.ldb [T9 Write v7.5]
    └─── lib
        ├─── arm
        │   ├─── shared
        │   │   ├─── alphabetic
        │   │   │   └─── *.so
        │   │   └─── cjk
        │   │       └─── *.so
        │   └─── static
        │       ├─── alphabetic
        │       │   └─── *.a / *.o
        │       └─── cjk
        │           └─── *.a / *.o
        ├─── linux-x86
        │   ├─── shared
        │   │   ├─── alphabetic
        │   │   │   └─── *.so
        │   │   └─── cjk
        │   │       └─── *.so
        │   └─── static
        │       ├─── alphabetic
        │       │   └─── *.a / *.o
        │       └─── cjk
        │           └─── *.a / *.o
        └─── win32
            ├─── shared
            │   ├─── alphabetic
            │   │   ├─── *.dll
            │   │   └─── *.lib
            │   └─── cjk
            │       ├─── *.dll
            │       └─── *.lib
            └─── static
                ├─── alphabetic
                │   └─── *.lib / *.obj
                └─── cjk
                    └─── *.lib / *.obj

Note: The above files are from the T9 Write demo SDK for Windows; the contents may vary for other platforms.

Where the contents of each directory are:

Directory Description Remarks
api This directory should contain all of the API files The API files usually located in the "api" and "public" directories of the SDK, but sometimes in the "demo" directory.

When using both Alphabetic and CJK engines at the same time, any overlapping files can be copied from either SDK.

data This directory should contain all HWR databases and optionally XT9 databases. HWR database for the T9 Write Alphabetic:
  • _databas_le.bin

HWR database for the T9 Write CJK:

  • cjk_HK_std_le.hdb HongKong Chinese
  • cjk_J_std_le.hdb Japanese
  • cjk_K_mkt_le.hdb Korean
  • cjk_S_gb18030_le.hdb Simplified Chinese
  • cjk_T_std_le.hdb Traditional Chinese

Language database:

  • File extension is either .ldb or .phd
lib/<target>/<linkage>/<engine-variant> Directory structure holding supported target builds. These directories should hold the desired target libraries. If both shared and static libraries are found, shared libraries are preferred.

For example, to enable a static win32 build, copy t9write_alphabetic_rel.obj to lib/win32/static/alphabetic directory.

Finally, the SDK is included in the build by adding CONFIG+=t9write to the qmake command line.

Static builds

The virtual keyboard can be built and linked statically against the application. This implies that Qt is also built statically (using the -static option in the configure command line).

Static builds of the virtual keyboard are enabled by adding CONFIG+=static to the qmake command line and then rebuilding.

Some third party modules used by the virtual keyboard are always built as shared libraries. These modules are Hunspell and Lipi Toolkit.

Using the static plugin

The following section should be added to the application project file that uses the statically built virtual keyboard.

static {
    QTPLUGIN += qtvirtualkeyboardplugin
    QT += svg
}

QTPLUGIN causes qmake to pull linker dependencies for the virtual keyboard plugin. The SVG module is required as an extra dependency for Qt, since the SVG format is required by the default styles.

From here on, using a statically built virtual keyboard is no different from the normal case.

Deployment

Desktop Targets

Add a Deploy Step that executes the make install command, then deploy using the Deploy All command.

Boot2Qt Targets

The installation is done by copying the necessary files to the memory card, or by using the adb push command.

Qt_Technology_Partner_RGB_475 Qt_Service_Partner_RGB_475_padded