Search Results for: why fcitx

Re-ask: Why Fcitx?

I wrote some post about “Why Fcitx” before, while I was little bit worried about fcitx’s future. But for now, I already have some idea for this question. There is already several input method framework on Linux world, why Fcitx … Continue reading

Posted in fcitx development | Tagged | 11 Comments

Why Fcitx?

(伪调查用意……) 这是一个我难以回答的问题,我无法向别人很好的回答这个问题。 在我看来,缺少一个feature或者多一个feature无法成为这个问题永恒的答案。(当然这可能是你们的答案 🙂 ) 每个有兴趣选择开发Fcitx的人(虽然也没几个)在最开始的时候,都无一例外的被我问了这个问题。为什么选择Fcitx而不是其他的输入法? 这个问题的答案也许没有理由,但对我来说也是一个值得思考的问题。 我也想从其他人那里知道答案。 因为对于我来说最终的答案可能只是我对它投入了精力而已。剩下的都只是附属产物。

Posted in fcitx development | Tagged | 24 Comments

Why fcitx need refactor?

首先诸君没必要给Fcitx加上各种定义,定义是人定的。最重要的就是开发者定的。然后不幸,现在这个人是我。 轻量?简洁?快速?这大概是多数人对于fcitx的看法。 我心中的理想的fcitx是什么样的? 可用性(Usability),原生(Native),KISS。 第一条,在这方面做的努力可能注意不到,在3.6时代困扰不少人的方块字问题,后来通过Fontconfig和Pango(如果禁用Pango就是Fontconfig找字体了)得到了相对比较好的解决。 第二条,这单纯是个人喜好,似乎也是很多linux用户的喜好。界面要原生。Fcitx的界面原生吗?没有使用GTK/Qt,谈不上原生,但是这个皮肤引擎给了Fcitx原生的能力,比如我就曾经写过一个小程序,使用KDE的Plasma主题生成Fcitx的皮肤。 即使对于GNOME来说,我其实也没有必要去写什么利用GNOME-Shell做的界面,不过他那个bug如果不给我解决掉(不是那个xim的,是关于界面显示的,其实是影响所有程序的一个bug),那还是只能悲剧。 第三条,Fcitx的架构其实一直非常简单,一直也没有引入什么更多的外部依赖(除非有必要),现在Fcitx需要发展的话,其实将不得不使用更多依赖,不过不用担心,这些不仅可以在编译时确定,同时也可以在安装时,运行时确定。 为什么我一直执着于不引入高级库的抽象?除了为了满足一些人的洁癖之外,更重要的原因就是保持简单。对于内部的事件处理,虽然当然也可以用比如libevent,或者gio,或者别的什么,但是它相对也不会带来什么用户可见的好处。(最影响Fcitx速度的部分是输入法引擎,用sysprof测定过),增加我的各种学习成本…… 另外也就是留下各种余地,如果有一天Fcitx要做更大的跨平台动作,那些某个平台上没有的库希望也不会成为阻碍。 $ ldd /usr/bin/fcitx linux-vdso.so.1 =>  (0x00007fff4e5ff000) libfcitx-core.so.0.1 => /usr/lib/libfcitx-core.so.0.1 (0x00007f8677546000) libfcitx-config.so.4.1 => /usr/lib/libfcitx-config.so.4.1 (0x00007f867733b000) libfcitx-utils.so.0.1 => /usr/lib/libfcitx-utils.so.0.1 (0x00007f86770fa000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8676edd000) libc.so.6 => /lib/libc.so.6 (0x00007f8676b7c000) libdl.so.2 => /lib/libdl.so.2 (0x00007f8676978000) … Continue reading

Posted in fcitx development | 3 Comments

我和 Fcitx 的 14 年

人的一生能有多少个 14 年? 开端(2009) 这可能是一切的开始。其实最早给 Fcitx 的贡献,就是 3.6.3rc 之后给 Fcitx 增加 Kimpanel 的支持。2008 年 KDE 4 刚刚发布,之后因为一些偶然的契机,发现有人为了 KDE 界面的集成,为 KDE 和 Fcitx(也包括scim 和 ibus)增加了一个基于 DBus 的面板协议。当时 Fcitx 的相关的代码因为 Fcitx 并没有一个插件架构,因此是保存在其中的一个分支当中的。 当年的这个时刻我竟然也写了博客记录,当我找到它的时候,它夹在两篇略羞耻恋爱感想的中间…… 当我发现记录一切缘起这篇博客是在 102 页的时候我也是吃惊不小的。 Fcitx-dbus-svn ON AURPosted on October 25, … Continue reading

Posted in 日志 | Tagged , | 11 Comments

对“fcitx5 依赖 boost 和 KDE, 探讨继续使用 fcitx4 的可行性“的回应

原贴:https://forum.suse.org.cn/t/topic/15817/7 首先,要对其中的几个所谓的错误说法进行驳斥。 1、Fcitx 5 依赖 KDE 和 Boost? 这是错误的,作为高度模块化的项目,核心库和服务器,输入法引擎,配置界面都是分离的代码库。 核心部分,反而比以前要精简得多,因为 gtk 和 qt im module 都变成了独立的项目,事实上,如果你乐意,可以编译出一个和图形库无关的 fcitx,这也是 fcitx5 能被移植到 android 上的基础。 输入法引擎部分,现在新的拼音引擎使用了极少的一部分 boost,大部分都是 header only 的,只有几个少量和 io 相关的库需要 boost 的共享库。如果你的发行版拆包精细,将只是引入约 500k 左右的依赖。 而配置界面的部分,则可能是有疑问的了,事实上它本身是在同一个代码库内分解成了两个实现,一个是只依赖于 Qt 和少量 KF5 的库,另一个则是和 KDE 系统设置集成的,也就是和 fcitx4 … Continue reading

Posted in fcitx development | Tagged , , | 4 Comments