skim (scim-panel-kde) 0.9.0 发布

fundawang

最初由 liuspider 发表
你说的是 支持 qt immodule 吧

这个工作我会做的，但是你有一点概念混淆了：skim 就像是 scim 这个命令一样，只不过 skim 启动一个基于 KDE 的GUI 而不是像后者那样启动一个 gtk2 的。 而这个 qt-immodule 支持，是为 scim-lib 写的，也就是说它和 scim-lib 中已经有的 gtk-immodule 支持是并列的，只不过现在看来，这个 qt-immodule 会作为 skim 的一部分来发表

从长远看，scim-lib 中将只包含核心部分：依赖于 gtk2 的部分将会被分离出来（如 gtk-immodule, scim-panel-gtk, gconf config module etc.)，分离出来的将作为一个单独的包来发布（比如叫 sgim 或者 gscim )

（最后这段是一点个人看法，还没有和 james 好好讨论个这个问题）

我是有点混淆。

因为 scim 的 spec 本身就要求 gtk2，但实际上前端是应该分离出来的。可是这样可能造成一个情况，scim的require没法写，单独安装的scim-lib是没法用的，因为没有前端。

建议 scim 系列  2.0 的时候重新考虑体系架构，把界面和对界面库的输入模块接口算作一层，语言智能算法算作一层，输入方法算作一层。几层之间由scim-lib来调度。

liuspider

＞因为 scim 的 spec 本身就要求 gtk2，但实际上前端是应该分离出来的。可是这样可能造成一个情况，scim的require没法写，单独安装的scim-lib是没法用的，因为没有前端。

其实看看 xine，他就是这种情况： 首先需要 安装 xine-lib ，但是光有这个是没法用的，因为没有前端，因此你必须装 xine-ui 或者其他的前端（有很多基于KDE的，但是一时想不起名字）

所以我认为分离出去应该是完全可行的

james_su

我目前还没有考虑把 gtk2 的部分分离出去。因为 scim-lib 本身需要一个 GUI 部分的參考实现，如果分离出去，使用起来会比较困难。当然 gconf config 是可以分离出去的。

最初由 liuspider 发表
你说的是 支持 qt immodule 吧

这个工作我会做的，但是你有一点概念混淆了：skim 就像是 scim 这个命令一样，只不过 skim 启动一个基于 KDE 的GUI 而不是像后者那样启动一个 gtk2 的。 而这个 qt-immodule 支持，是为 scim-lib 写的，也就是说它和 scim-lib 中已经有的 gtk-immodule 支持是并列的，只不过现在看来，这个 qt-immodule 会作为 skim 的一部分来发表

从长远看，scim-lib 中将只包含核心部分：依赖于 gtk2 的部分将会被分离出来（如 gtk-immodule, scim-panel-gtk, gconf config module etc.)，分离出来的将作为一个单独的包来发布（比如叫 sgim 或者 gscim )

（最后这段是一点个人看法，还没有和 james 好好讨论个这个问题）

fundawang

分离出去是必要的，也是可行的，但这个工作不应该是现在做。

我本来的想法是这样的，scim可以有不同依赖的前端，比如依赖Qt的、依赖gtk的，甚至只依赖X或Xorg的。如果用户只安装了KDE桌面环境，那么你就没有必要让人家只为了一个输入法就再装gtk。如果用户只用WM系列的桌面环境，那么就应该自动启用依赖X的前端。

liuspider

这样的话，我觉得可以加入一个比如字符界面的GUI实现（个人觉得比如基于 ncurse 等）：最简单的结构，实现最基本的功能

而且有很多人是完全没有 gtk/gnome 的，所以我觉得分离出所有 gtk 相关的东东，是个未来可以考虑的方向... （正如　xine 使用的模式）

james_su

最初由 liuspider 发表
这样的话，我觉得可以加入一个比如字符界面的GUI实现（个人觉得比如基于 ncurse 等）：最简单的结构，实现最基本的功能

而且有很多人是完全没有 gtk/gnome 的，所以我觉得分离出所有 gtk 相关的东东，是个未来可以考虑的方向... （正如　xine 使用的模式）

因为如果要分离的话，x11 FrontEnd 也需要分离出来，使得 SCIM 本身不依赖于任何图形环境。但这样会加大使用难度，和维护难度，而且我也没有想过该如何分离。

为了取悦大多数普通用户，我已经把 scim 0.99.0 的大部分模块都合并进一个二进制包中了。而在最早的时候，scim 的二进制包的确是完全分开的，但遭到广大用户的诟病。

liuspider

最初由 james_su 发表
因为如果要分离的话，x11 FrontEnd 也需要分离出来，使得 SCIM 本身不依赖于任何图形环境。但这样会加大使用难度，和维护难度，而且我也没有想过该如何分离。

我觉得当　ＸＩＭ　变的不那么重要的时候（比如　qt-immodule 合并入Qt 后），就可以考虑分离出这个　x11 FrontEnd 。但是那之前，我觉得可以考虑将依赖　gtk 的部分先行分离出去。

最初由 james_su 发表
为了取悦大多数普通用户，我已经把 scim 0.99.0 的大部分模块都合并进一个二进制包中了。而在最早的时候，scim 的二进制包的确是完全分开的，但遭到广大用户的诟病。

是的，我也看得出来。但是分离出来　gtk 包的话（暂且叫 gscim 吧），剩下的 scim-lib 部分的二进制包可以作为一个来发布的，而 gscim 也是作为一个完整的来发布，包括 scim-panel-gtk, gconf confg module 等

个人看法 ;)

james_su

最初由 liuspider 发表
我觉得当　ＸＩＭ　变的不那么重要的时候（比如　qt-immodule 合并入Qt 后），就可以考虑分离出这个　x11 FrontEnd 。但是那之前，我觉得可以考虑将依赖　gtk 的部分先行分离出去。


是的，我也看得出来。但是分离出来　gtk 包的话（暂且叫 gscim 吧），剩下的 scim-lib 部分的二进制包可以作为一个来发布的，而 gscim 也是作为一个完整的来发布，包括 scim-panel-gtk, gconf confg module 等

个人看法 ;)

主要是用户会抱怨，为什么我装了 scim rpm 包，但用不了 scim？

所以 SCIM 主包至少包含基本可以使用的组件。如果有一个完善的基于 X 的 panel 可以用的话，则可以考虑把 gtk panel 独立出来。

另外一个问题就是 scim-setup。如果能够实现一个基于 xml 的通用配置界面语言（类似于 kconfig），使其不依赖于图形库，就好了。

还有，我考虑把 qt immodule 集成到 scim-lib 主包里面，这样使用起来会更方便一些，维护也会比较方便。不知你意思如何？

liuspider

最初由 james_su 发表
另外一个问题就是 scim-setup。如果能够实现一个基于 xml 的通用配置界面语言（类似于 kconfig），使其不依赖于图形库，就好了。

呵呵，据我所知，kconfig XT framework 的一个核心思想是使书写配置界面变的简单。如果你的意思是一个通用的 这种 framework 的话，我觉得不是不可行，但是实现上比较复杂，而且关键是有一些复杂的东西是不能纳入到这种 framework 中的，比如 IMEngine 的配置界面。

最初由 james_su 发表
还有，我考虑把 qt immodule 集成到 scim-lib 主包里面，这样使用起来会更方便一些，维护也会比较方便。不知你意思如何？

我倒没什么反对意见，不过，我觉得，这样的话就把 scim-lib 搞得有点混乱了：同时依赖 gtk 和 qt ，尽管这都是可以选择的 ;)

下一步我想就去实现这个 qt-immodule 了，skim 暂时只作 bug fix

james_su

我考虑的就是一个可以把 IMEngine 配置界面也包括进来的 XML 架构。如果这个实现了话，IMEngine 只要提供一个 xml 文件，scim-setup 就可以显式该模块的配置页了。

当然这个实现起来是比较复杂。目前只是一个设想而已。

另外，我试了一下 skim，总体运行良好，不过有一些小的问题：
1、候选词表中词与词之间没有空格，看着费劲；
2、工具条上文字按钮右边都多一块空白，不知道能不能清除掉；
3、候选词表中焦点词汇的?色不是很显眼，尤其是在碰到用户自造词的时候。

最初由 liuspider 发表
呵呵，据我所知，kconfig XT framework 的一个核心思想是使书写配置界面变的简单。如果你的意思是一个通用的 这种 framework 的话，我觉得不是不可行，但是实现上比较复杂，而且关键是有一些复杂的东西是不能纳入到这种 framework 中的，比如 IMEngine 的配置界面。


我倒没什么反对意见，不过，我觉得，这样的话就把 scim-lib 搞得有点混乱了：同时依赖 gtk 和 qt ，尽管这都是可以选择的 ;)

下一步我想就去实现这个 qt-immodule 了，skim 暂时只作 bug fix