Category Archives: fcitx development
Get event order right (Try 2!)
TL;DR: this is not considered as a user facing change. In a previous post, we discussed the issue between the input method event order and the blocking dbus call. To put it simple, input method may generate multiple different outcomes … Continue reading
libime 原理介绍（二）
之前第一篇主要介绍了关于 beam search 和输入切分相关的内容，以及提供的一些基础数据结构。接下来主要着重补全介绍上次没有提及的 UserLanguageModel 和 HistoryBigram 的实现细节。 声明，本文需要的很多前置知识都可以在大学本科的自然语言处理类课程找到，关键词「统计语言模型」，「N-gram」。概括的说，N-gram模型是对现实语言的不精确概括，它不关心语法，只关心词与词之间出现的频率，尽管不精确，但对于输入法，机器翻译，语音识别等等领域都有不错的效果。 首先上一篇当中提到了我们的输入法的算法核心是 N-gram 和 beam search。一般对采用这种算法的输入法来说，N会取 3 或者 2。可以取得效果和内存占用的平衡。这里姑且来说我们也继承了一部分 Sunpinyin 的精神，因为最初最初的数据就是采用 Sunpinyin 使用的 Open-Gram。当然这里顺便一提，在最新的版本我们重新用全新的数据训练了语言模型。但依然采用了和 Sunpinyin 一样的 Trigram。 HistoryBigram，顾名思义，是一个存储用户输入的 Bigram。它干的事情其实非常之简单，就是把用户的输入的句子根据词一条一条的储存起来。而在内存中，它被存储在 DATrie 中。你也许想问一个问题，就是 DATrie 抽象起来看，可以被看作一个字符串到 4 byte 数据的映射，那么它究竟是怎么存储 Bigarm 这样有两个级别的 Key 的映射表呢？ 答案其实很简单，就是你把 Key … Continue reading
Fcitx 5 Plasma Theme support
Kimpanel is a plasma applet that uses plasma and dbus to display the input method popup window. In X11, people who want to have native plasma theme based input method window may use it to provide a nice integration with … Continue reading
libime 原理介绍（一）
2022/06/29：感谢一些朋友的指正，更新了关于 rime 的一点信息。 写在开头的话：许多年前，在我才刚刚开始用 linux 的时候，刚好赶上了 Sunpinyin 的诞生。那个时候 Yong Sun 写了 Sunpinyin 代码导读。尽管那个时候因为知识的储备不够丰富，基本上没有能够理解文章的内容，但是现在回过头来的话，终于在 2017 年的时候，自己从头写了一个类似算法的输入法引擎，来代替早已过时的 Fcitx 4 中的默认拼音和码表。 虽然也许有人会有疑问，为什么要从头写这样一个输入法引擎，难道 Sunpinyin 不够好吗？我很久之前的一篇博客其实具体做出了一些功能上的解释。这里我们再重新从代码角度来解释一下 libime 的来龙去脉。 libime 目前的库分为 4 个部分，其中粤拼单独在一个Git 代码仓库里，粤拼大部分的代码是和拼音类似的。之后也不会特别介绍粤拼的部分。 另外一些原因是，其中很多核心的代码对我自己来说也已经不很熟悉了，也是趁此机会记录一下翻新一下自己的记忆。另外我相信这些经历的部分，对于了解 Linux 输入法和 Fcitx 的发展过程的也是很有趣的，当成一个故事来看大概也不错？ 核心部分（Core） 在解说 Core 之前，就要说到为什么要写 libime 这件事。而这就不得不说说之前的几个前辈们，有些我只有大致的了解，所以可能有错误。首先是 fcitx4 … Continue reading
Chrome/Chromium 今日 Wayland 输入法支持现状
似乎有不少人总是有疑问，Chrome的Wayland输入法支持到底是什么情况，能不能输入，支不支持，那么就姑且来总结一番。本文仅代表写作时的状态，不代表后续的情况。（以下用 Chrome 指代 Chrome/Chromium）。 首先简单介绍一下 Chrome 对 Wayland 支持的情况。对于 Chrome 这种跨平台的项目来说，肯定有自己的抽象层，从而能够高效地利用对应平台的 GPU，图形栈。现阶段来说，这一层抽象的项目的名称是 Ozone，更多详细的介绍可以参考 https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/ozone_overview.md。这里的描述是这样的：Ozone 是在使用了底层输入和图形的 Aura 窗口系统下的平台抽象层。一旦完成，这个抽象将支持各种系统，包括嵌入式 SoC，或者新的 Linux X11 替代：Wayland/Mir 来启动 Aura。 现在如果要在 Wayland 上用原生 Wayland 而不是 XWayland 来显示，那么将要使用 Ozone 作为它的图形栈。那么 Ozone 有什么样的输入法支持呢？在很长的一段时间内，它的输入法支持只有 text_input_v1，并且需要使用 –enable-wayland-ime 来启用。对于不了解 Wayland 输入法架构的人来说，这里对 Wayland … Continue reading
