Difference between revisions of "Develop an simple input method/zh-cn"

From Fcitx
Jump to navigation Jump to search
(Created page with "版本 1 的 quwei.cpp")
(Created page with "当实现 Fcitx 插件时,它应该是 [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1AddonInstance.html AddonInstance] 的子类。AddonInstance 的实例化是通过 [ht...")
Line 216: Line 216:
 
FCITX_ADDON_FACTORY(QuweiEngineFactory);</nowiki>
 
FCITX_ADDON_FACTORY(QuweiEngineFactory);</nowiki>
  
When implement a Fcitx addon, it should be a sub-class of [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1AddonInstance.html AddonInstance]. The instantiation of AddonInstance is done via a [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1AddonFactory.html AddonFactory]. [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1InputMethodEngineV2.html InputMethodEngineV2] is a sub-class of AddonInstance. This class needs to be used when implementing an input method addon.
+
当实现 Fcitx 插件时,它应该是 [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1AddonInstance.html AddonInstance] 的子类。AddonInstance 的实例化是通过 [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1AddonFactory.html AddonFactory] ​​完成的。  [https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1InputMethodEngineV2.html InputMethodEngineV2] AddonInstance 的子类。实现输入法插件时需要使用该类。
  
 
The minimum implantation of an input method engine only need to contain the implementation of the keyEvent function.
 
The minimum implantation of an input method engine only need to contain the implementation of the keyEvent function.

Revision as of 03:30, 19 April 2023

Other languages:
English • ‎中文(中国大陆)‎

这是编写 Fcitx 5 输入法的分步说明。同样的指令可以用于开发其他类型的插件,只是输入法引擎是最复杂的。

了解 Fcitx 共享库插件的文件结构

Fcitx 5 提供了一个用于添加新插件类型的可扩展框架,但共享库支持是内置的,并且是所有其他插件类型的基础。所以我们只会在本文档中介绍共享库插件。

[fcitx install prefix]
|
|- share/fcitx5
|  |
|  |- addons/[addon name].conf
|  |- inputmethod/[input method name 1].conf
|  |  ...
|  |- inputmethod/[input method name n].conf
|
|- lib/fcitx5
   |
   |- [library name].so

以上是输入法插件的文件结构。对于其他类型的插件,不需要 inputmethod/ 下的文件。[addon name].conf 的文件名很重要,将用于唯一引用此特定插件。Fcitx 也遵循 XDG 目录标准,所以 XDG_DATA_DIR/fcitx5 下的文件也会被检查。同样,inputmethod/下的配置文件的文件名也很重要,将是某个输入法的唯一名称。

[addon name].conf 示例

[Addon]
Name[ca]=Pinyin
Name[da]=Pinyin
Name[de]=Pinyin
Name[he]=פיניין:
Name[ko]=병음
Name[ru]=Пиньинь
Name[zh_CN]=拼音
Name=Pinyin
Category=InputMethod
Version=5.0.8
Library=pinyin
Type=SharedLibrary
OnDemand=True
Configurable=True

[Addon/Dependencies]
0=punctuation

[Addon/OptionalDependencies]
0=fullwidth
1=quickphrase
2=cloudpinyin
3=notifications
4=spell
5=pinyinhelper
6=chttrans
7=imeapi

[输入法名称].conf示例

[InputMethod]
Name[ca]=Pinyin
Name[da]=Pinyin
Name[de]=Pinyin
Name[he]=פיניין:
Name[ko]=병음
Name[ru]=Пиньинь
Name[zh_CN]=拼音
Name=Pinyin
Icon=fcitx-pinyin
Label=拼
LangCode=zh_CN
Addon=pinyin
Configurable=True

该文件采用类似 ini 的格式,具有某些 fcitx 特定的扩展名和规则。它还支持 XDG 桌面文件样式 i18n 进行翻译。

使用 CMake 构建系统

理论上只要能生成正确的文件,就可以自由选择要使用的构建系统。但是Fcitx 5 对 CMake 提供了大量支持,因此使用 CMake 将是构建 Fcitx 项目的最便捷方式。在本文档中,我们将仅介绍使用 CMake 作为构建系统。

快速入门:区位码

区位码 输入法是一种输入法,基本上允许您输入GB2312的数字并产生与该代码匹配的汉字。它曾经被 Fcitx 4 支持,但不再被 Fcitx 5 包含。虽然它很难使用,但它可以作为一个很好的例子来说明如何为 Fcitx 5 实现一个简单的输入法。

项目框架

因此,让我们从这个项目的框架开始。

├── CMakeLists.txt
├── LICENSES
│   └── BSD-3-Clause.txt        # License for this project
├── po                          # Optional I18n
│   ├── CMakeLists.txt
│   ├── fcitx5-quwei.pot
│   ├── LINGUAS
│   └── zh_CN.po
└── src
    ├── CMakeLists.txt
    ├── quwei-addon.conf.in.in  # Addon registration file
    ├── quwei.conf.in           # Input method registration file
    ├── quwei.cpp               # Engine implementation
    └── quwei.h                 # Engine implementation

您也许需要查看一些 CMake 教程以了解一些基本的 CMake 用法。

CMakeLists.txt 在根目录查找依赖项。

cmake_minimum_required(VERSION 3.21)
project(fcitx5-quwei)

find_package(Fcitx5Core REQUIRED)
# Setup some compiler option that is generally useful and compatible with Fcitx 5 (C++17)
include("${FCITX_INSTALL_CMAKECONFIG_DIR}/Fcitx5Utils/Fcitx5CompilerSettings.cmake")

add_subdirectory(src)

src/CMakeLists.txt 示例如下:

# Make sure it produce quwei.so instead of libquwei.so
add_library(quwei SHARED quwei.cpp)
target_link_libraries(quwei PRIVATE Fcitx5::Core)
set_target_properties(quwei PROPERTIES PREFIX "")
install(TARGETS quwei DESTINATION "${FCITX_INSTALL_LIBDIR}/fcitx5")

# Addon config file
# We need additional layer of conversion because we want PROJECT_VERSION in it.
configure_file(quwei-addon.conf.in quwei-addon.conf)
install(FILES "${CMAKE_CURRENT_BINARY_DIR}/quwei-addon.conf" RENAME quwei.conf DESTINATION "${FCITX_INSTALL_PKGDATADIR}/addon")

# Input Method registration file
install(FILES "quwei.conf" DESTINATION "${FCITX_INSTALL_PKGDATADIR}/inputmethod")

quwei.conf.in 示例:

[InputMethod]
# Translatable name of the input method
Name=Quwei
# Icon name
Icon=fcitx-quwei
# A short label that present the name of input method
Label=区
# ISO 639 language code
LangCode=zh_CN
# Match addon name
Addon=quwei
# Whether this input method support customization
# Configurable=True

此文件将作为 InputMethodEntry 对象进行加载。

quwei-addon.conf.in 示例:

[Addon]
Name=Quwei
Category=InputMethod
Version=@PROJECT_VERSION@
Library=quwei
Type=SharedLibrary
OnDemand=True
Configurable=True

[Addon/Dependencies]
0=punctuation

[Addon/OptionalDependencies]
0=fullwidth
1=quickphrase
2=chttrans


此文件将作为 AddonInfo 对象加载。

InputMethodEngine 的基本实现

您可以参考github中first commit的代码。

版本 1 的 quwei.h

/*
 * SPDX-FileCopyrightText: 2021~2021 CSSlayer <wengxt@gmail.com>
 *
 * SPDX-License-Identifier: BSD-3-Clause
 *
 */
#ifndef _FCITX5_QUWEI_QUWEI_H_
#define _FCITX5_QUWEI_QUWEI_H_

#include <fcitx/inputmethodengine.h>
#include <fcitx/addonfactory.h>

class QuweiEngine : public fcitx::InputMethodEngineV2 {
    void keyEvent(const fcitx::InputMethodEntry & entry, fcitx::KeyEvent & keyEvent) override;
};

class QuweiEngineFactory : public fcitx::AddonFactory {
    fcitx::AddonInstance * create(fcitx::AddonManager * manager) override {
        FCITX_UNUSED(manager);
        return new QuweiEngine;
    }
};

#endif // _FCITX5_QUWEI_QUWEI_H_

版本 1 的 quwei.cpp

/*
 * SPDX-FileCopyrightText: 2021~2021 CSSlayer <wengxt@gmail.com>
 *
 * SPDX-License-Identifier: BSD-3-Clause
 *
 */
#include "quwei.h"

void QuweiEngine::keyEvent(const fcitx::InputMethodEntry& entry, fcitx::KeyEvent& keyEvent)
{
    FCITX_UNUSED(entry);
    FCITX_INFO() << keyEvent.key() << " isRelease=" << keyEvent.isRelease();
}

FCITX_ADDON_FACTORY(QuweiEngineFactory);

当实现 Fcitx 插件时,它应该是 AddonInstance 的子类。AddonInstance 的实例化是通过 AddonFactory ​​完成的。 InputMethodEngineV2 是 AddonInstance 的子类。实现输入法插件时需要使用该类。

The minimum implantation of an input method engine only need to contain the implementation of the keyEvent function.

Here, we use a iostream like macro FCITX_INFO() to write every key we pressed to the log.

Assume the prefix your fcitx installation is /usr. The command to build this project would be:

mkdir -p build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug # use Debug for easy debugging with gdb
make # or ninja, depending on your system
sudo make install # or sudo ninja install

If everything works fine, the install command should print out something like:

-- Install configuration: "Debug"
-- Installing: /usr/lib/fcitx5/quwei.so
-- Installing: /usr/share/fcitx5/addon/quwei.conf
-- Installing: /usr/share/fcitx5/inputmethod/quwei.conf

Now you can restart fcitx5 with fcitx5 -rd and add Quwei to the your configuration with Configtool (Fcitx 5).

After switching to Quwei, the key press in application will make Fcitx 5 print out something like:

I2021-11-16 12:29:32.352702 quwei.cpp:12] Key(f states=0) isRelease=1
I2021-11-16 12:29:32.389935 quwei.cpp:12] Key(s states=0) isRelease=0
I2021-11-16 12:29:32.413689 quwei.cpp:12] Key(d states=0) isRelease=0
I2021-11-16 12:29:32.497661 quwei.cpp:12] Key(s states=0) isRelease=1
I2021-11-16 12:29:32.498021 quwei.cpp:12] Key(f states=0) isRelease=0
I2021-11-16 12:29:32.523816 quwei.cpp:12] Key(a states=0) isRelease=1
I2021-11-16 12:29:32.524051 quwei.cpp:12] Key(d states=0) isRelease=1
I2021-11-16 12:29:32.704919 quwei.cpp:12] Key(f states=0) isRelease=1
I2021-11-16 12:29:32.705006 quwei.cpp:12] Key(d states=0) isRelease=0
I2021-11-16 12:29:32.833024 quwei.cpp:12] Key(d states=0) isRelease=1
I2021-11-16 12:29:34.633936 quwei.cpp:12] Key(Control_L states=0) isRelease=0
I2021-11-16 12:29:35.053817 quwei.cpp:12] Key(Control+C states=4) isRelease=0
I2021-11-16 12:29:35.165617 quwei.cpp:12] Key(Control+C states=4) isRelease=1
I2021-11-16 12:29:35.348654 quwei.cpp:12] Key(Control+Control_L states=4) isRelease=1

So you know your input method engine is now working.

Implement Input Method logic

Quwei is basically typing 4 digit number of Quwei code. Quwei code can be treated as Qu code xx and Wei code yy. The mapping from Quwei to GB2312 is (0xA0 + Qu, 0xA0 + Wei). When user type 3 digits of Quwei, input method will display a candidate list of 10 possible character with given quwei prefix.

You may refer to the code at the second commit in the github.

Store the state for different input contexts

Fcitx allows different input context to held a different state. The state usually refers to the partially typed text and all other associated data structures. In Quwei case, the state is the digits that user already typed. To represent this, Fcitx provides a convenient class InputBuffer to allow engine to use this class conveniently to edit the internal state. In order to automatically construct the state when an input context getting constructed, Fcitx provides a framework called InputContextProperty. In order to use this, you first need to register a factory class to InputContextManager, via registerProperty. Each property need to have a global unique name. The name can be something human-understandable. In Quwei case, I just use "quweiState". The benefit of using a nicer name is just in case you're developing something cross addon (Another addon need to access certain internal state of this addon), you can use this common name to load it in a different addon. If you do not need access from outside, the name does not really matter.

The factory class comes with a handy C++ template, FactoryFor. This is actually an type alias to LambdaInputContextPropertyFactory. This class simply accepts a lambda function as the factory implementation. This can save you sometime from creating your own subclass of InputContextPropertyFactory.

In order to get the state object from input context, you can simply use the factory object like this:

auto *state = ic->propertyFor(&factory_);

In certain cases, it is also possible to un-register the factory and re-register it again in order to "refresh" all the internal state.

Candidate List

In Fcitx 5, a candidate list is a part of the InputPanel class, stored as shared_ptr to avoid life time issue when selecting candidate triggers the User interface update. There's different capability provided by candidate list via certain interfaces. The helper class CommonCandidateList would provide most common functionality for a candidate list. It implements BulkCandidateList interface, and that is why it is not suitable for Quwei case. Because we want to have a semi-infinite candidate list for Quwei.

In Quwei, QuweiCandidateList gonna implement a PageableCandidate interface, which allows a prev/next page button to be displayed in the input method panel.

Preedit

Preedit can refer to two different user interface element, one is the preedit embedded within the application, usually referred as "client preedit" in Fcitx. Another one is displayed with in the input method panel window. Usually, input method engine would only use one of them because there is only 1 form of preedit that need to be displayed. Whether the input context supports it or not can be checked via the capabilityFlags property.

Also there's something you may want to consider when using client preedit. Due to the different implementation in toolkit, toolkit may choose to commit the client preedit right away when application loses focus. For certain input methods, it might be designed to work in a way that typing does not need extra confirmation, for example, the word completion mode in keyboard engine. In such case, even though the preedit is used, user would expect the text it to be committed even if it is still in a preedit mode. In that sense, the preedit text should be exact same of the text that will be committed after confirmation.

In some version of iOS, its Pinyin input method using its client preedit in a way that may causes confusion: user types "nihao", and client preedit is displayed as segmented pinyin "ni hao". When text box loses focus, "ni hao" (extra space) would be committed into the application, and such outcome would never happen in regular usage of Pinyin.

Another thing to consider is where to put the cursor. While it might be natural to display the cursor at the its actual place within preedit, the input panel window will also be displayed at the client preedit cursor position. That means along with user regular typing, when cursor moves, the candidate window would also moves. In some cases, this is not desirable because it causes candidate window to be moved frequently when user types. An alternative way to handle this is to set the client cursor always to be 0. If you need to support display the position of actual cursor, you may use highlight style instead. For example, when you have "ABCD" in preedit and the cursor is between B and C. You may set client cursor to 0, and make "AB" displayed with highlight style to indicate the position of cursor.

Key event handling

The most common use case is to call filterAndAccept() for all the key event that you intends to handle. Also, for most input method, key release is not relevant and should be pass-through to application. To make input method engine to work with any user input, be sure to consider all the possible key event that may be typed by user. For example, a common error is forgetting to block certain irrelevant key in composing mode and leaking the key into the application. Also, be careful for key event with modifier, you may want to pass through such key to make application specific hotkey still accessible even when user is composing.

Also, a key event has 3 different form of the Key objects. Normally a input method engine may only want to consider only the key() property. origKey() and rawKey() properties are less used. Key property is in a normalized form of key event. That removes "Shift" modifier for certain cases, which makes it easier to handle by the input method engine. For example, upper case A produced by Shift+A and Capslocked A will be the same after normalization. You may refer to the implementation to learn about how this normalization works.

Reuse features from other addons

You may refer to the code at the third commit in the github.

Fcitx provides a mechanism to invoking functions from other addons without having the need of directly linking to them. And also some easy to use CMake macro to look up the addon dependencies.

find_package(Fcitx5Module REQUIRED COMPONENTS Punctuation QuickPhrase)

We add the find_package line above to look up dependencies for Punctuation and QuickPhrase module.

If you want to implement such a module, you can use the following CMake macro

fcitx5_export_module(QuickPhrase TARGET quickphrase BUILD_INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}" HEADERS quickphrase_public.h INSTALL)

And it will automatically generate the required CMake config for your addon.

When using other addons in the code, there is a handy macro FCITX_ADDON_DEPENDENCY_LOADER that will handle the addon loading at the runtime. When it is called for the first time, the dependent addon will be loaded automatically. Here we defines four different dependency in the code:

    FCITX_ADDON_DEPENDENCY_LOADER(quickphrase, instance_->addonManager());
    FCITX_ADDON_DEPENDENCY_LOADER(punctuation, instance_->addonManager());

private:
    FCITX_ADDON_DEPENDENCY_LOADER(chttrans, instance_->addonManager());
    FCITX_ADDON_DEPENDENCY_LOADER(fullwidth, instance_->addonManager());

The first parameter should be same as the addon name, second parameter is the expression to get the AddonManager object.

This mechanism make it easy to reuse the functionality implemented by other addons and shared the code. For example, classicui queries the X11/wayland connection from xcb addon and wayland addon.

Configuration

While Quwei does not really need this feature, since it is a really common use case so it will be covered in this section. The addon has a few different interface relevant to configuration, such as getConfig, setConfig, getConfigForInputMethod, setConfigForInputMethod, reloadConfig. The getter function would need to return a Configuration object, while setConfig accepts a RawConfig object. reloadConfig will be called to reload the configuration from disk, you may want to call reloadConfig() in the constructor of the addon too.

If Configurable field is set to True in the addon registration file, such method would be called to retrieve the information and Configtool would generate UI for it.

FCITX_CONFIGURATION(
    ClipboardConfig, KeyListOption triggerKey{this,
                                              "TriggerKey",
                                              _("Trigger Key"),
                                              {Key("Control+semicolon")},
                                              KeyListConstrain()};
    KeyListOption pastePrimaryKey{
        this, "PastePrimaryKey", _("Paste Primary"), {}, KeyListConstrain()};
    Option<int, IntConstrain> numOfEntries{this, "Number of entries",
                                           _("Number of entries"), 5,
                                           IntConstrain(3, 30)};);

Usually, you will define a sub class of Configuration with the FCITX_CONFIGURATION macro. First argument is the name of the class, and then you just simply add Option as member. Following is a common implemenation of setConfig/getConfig/reloadConfig.


    static constexpr char configFile[] = "conf/clipboard.conf";
    void reloadConfig() override { readAsIni(config_, configFile); }

    const Configuration *getConfig() const override { return &config_; }
    void setConfig(const RawConfig &config) override {
        config_.load(config, true);
        safeSaveAsIni(config_, configFile);
    }

readAsIni and safeSaveAsIni are helper functions to read/save Configuration object from/to the Fcitx ini-format. The file is saved under $XDG_CONFIG_HOME.