kde4使用scim-bridge

使用scim-bridge实现kde4环境下中文输入的功能，是早就有人提到的中文输入解决办法

在kde4 for FreeBSD环境下，因为scim-bridge移植进ports比较晚，所以直到今天才开始测试scim-bridge

在ports里，scim-bridge分成了两个port，一个是 textproc/scim-bridge-qt4，用于建立客户端库，另外一个是 textproc/scim-bridge，提供一种代理机制，访问scim的功能。可以说这是一个暂时的权益之计，scim的子项目skim移植到kde4是早晚的事情，但就目前，这似乎是一种通用的办法，至于ibus，虽说很多人都不吝啬言辞的盛赞，但在FreeBSD环境下，还是要等待，至于ibus会好到哪儿，用时再说了。看相关资料，似乎是xim的设计者弥补不足而设计的新协议。

编译安装scim-bridge-qt4，scim-bridge没费多大的心神，只需要scim的运行依赖比skim需要安装kdelibs3要节省空间不少，但在开始使用这个bridge时，遇到的问题让我啼笑皆非。

按照kde on freebsd邮件列表给支的招发，因为我采用kdm启动桌面环境，所以修改了下~/.xprofile文件

加入了下面一行：

export QT_IM_MODULE=scim-bridge

注销登录后，熟悉的scim托盘图标出现，而且一出就是俩。。。：－（

ctrl-space 之后，能唤出scim的工具条，基本功能实现，ps -xc | grep scim 查看了下，看不出什么问题，只好乱点右键在这两个托盘图标上，一个中文一个英文，好在右键菜单都提供退出功能。

再次注销登录，不曾遇到的怪现象出现了，英文界面图标依然出现，而中文那个却消失了，用户目录下也出现了core文件。很脆弱。

琢磨了好一阵子，才知道scim-bridge在系统退出时，不删除建立的socket（代理的特色？），在 ／tmp目录下，google 了一下相关网页，同患难者甚众，看来是设计上的权宜之计，虽说不痛不痒，但总不是那么完美。说到“完美”，无论是windows还是类unix，都是越来越差劲了。

scim-bridge，可用，但要手工作点儿粗活，需要rm下/tmp目录下的scim*，不过有点儿可乐的是，删除socket的时，scim倒是能感知到，能重新启动scim-bridge，这种半自动化着实让我惊讶，更加让我感到有点儿欣慰的是，自动生成一个托盘图标，着实顺眼不少。对scim-bridge的印象也大有改观。想想也是，对于bridge还能要求怎样，kde4更新不停的轮番轰炸，让人怎么能安下心来开发平台相关软件呢！

kde on freebsd上有位仁兄给出一个妙招，大意是把/tmp挂载到临时文件系统，估计也就是内存盘，能免去手工删文件的劳作，但两个托盘图标，依旧需要指指点点才能去掉，而我不过是多道手续，也罢，就不过多折腾改观了，但一个结论是有了，目前scim-bridge是无法集成进桌面版，期待软件作者的更新和移植，最好是我所喜欢的那个skim能出kde4版。

虽说scim-bridge有些暇呲，但难掩玉的光华，本篇博文的中文输入使用的就是scim-bridge，它对konq的支持不错，值得一赞！

xorg高占用率及其他

xorg 7.4的cpu高占用率

近两日运行kde4.2发现，只要桌面有动作，哪怕是晃动鼠标，都会使X的cpu占用率突升到60%以上，这应该是升级到xorg 7.4所遇到的最头疼的问题，目前很难定位具体是什么原因造成的，google上所说的中文字体处理因素经过测试是没有影响的，现在只能锁定在xorg 7.4在一些新特性的验证上，其中一个值得深究的细节是，单纯运行Xorg自带的twm，窗口边缘存在“更新不及时”的情况，即窗口边框存在破损，这在xorg 7.3中是不存在的。

期待 xorg 的ports 能尽快解决这个问题！

Hal ck 和 pk

因为想要policykit-kde发挥功能，这两天看了ck,pk,hal一些相关的资料，邮件列表也逛了一大圈，发觉邮件列表真是个不错的东西，信息量很大，能吸收到很多的东西，其中很多前瞻性的讨论让我对开源和自由软件文化有了更进一步的了解。要想融入其中，邮件列表应该是必须要培养的一个习惯。

关于ck和pk，我所没有想到的是，在功能的划分上，有那么多的“恩恩怨怨”，这其中一个很重要冲突在于有些资料中所提到的“unix文化特质”——模块功能的独立性，也就是说，作为unix工具链的一个模块，着重功能实现和改进就好，而不要去考虑融入更多的附加功能。在这一点上，hal和ck的功能有所重复，而这也是“恩恩怨怨”中最大的冲突点，ck该不该提供hal已经提供的功能。

kcm_module

算是对桌面发行版的一个考量，也是源于对kde 4.2中“系统设置”这个容器管理方式的喜欢，我从kde 4 的源代码中简单理出了kcm_module程序的框架，用于今后桌面发行版功能的进一步定制。

在桌面发行版上，最近一直摇摆于这样的一种矛盾中，即做基于FreeBSD和kde的桌面，还是做FreeBSD的kde桌面，差别在于“基于”这两个字。“基于”类似与一般意义上的“发行版”，即在FreeBSD和kde的基础上做集成和进一步开发，pcbsd是一个例子，目前这个桌面发行版把更多的精力放在pbi软件包机制和界面的换肤，这样的发行版和基于gnu linux的桌面发行版本质是相同的，利用内核加工具链以及桌面环境构建的框架，发展“独特风格”的应用系统，这类系统的优点在于区分于同质性桌面发行版，更着眼与市场。但从开源软件文化的角度来说，我个人还是有些抵触的，而且也是一种考虑，同质性的东西会存在更多的竞争，而竞争的结果又不简单的取决于技术。

我个人更倾向于上面所述矛盾的后者，即保持FreeBSD和kde完整性的桌面系统，所有的定制和再开发保持在FreeBSD和kde所构建的框架。目前所能想到的策略是

1、保持FreeBSD的ports and pkgs机制。

2、界面定制更多的使用kcm_module模块。

3、livecd + install 的安装机制。

Kdevelop4 and Kdevplatform

Kdevelop4 是kdevelop正在开发的KDE4桌面环境集成开发环境，目前还是处于β版,关注这个软件很大程度上源于对KDE3桌面环境组件中kdevelop 3.x的好印象，它的KDE4版当然是值得期待的，而且有可能成为kde4桌面环境的主流开发工具。

昨晚使用kdesdk4的ports作为模板，简单修改弄了个测试kdevelop的ports，并且根据依赖关系也弄了kdevplatform的ports，这一点上，和kdevelop 3.x 一个源代码包有些不同，kdevplatform提供了kdevelop很多的后台支持。

利用生成的ports测试devplatform相当顺利，除了kde4基本系统构建环境所需的组件和程序外，几乎不需要其他的依赖，编译安装顺利完成。kdevelop也没遇到特别的软件包依赖问题，这得益与kde4所使用的cmake构建环境，免去了autotools以及相关大量工具链的依赖。但在编译kdevelop过程中，在编译到98%时，系统提示 “apps-temples目录下文件不知如何处理而退出”，查看相关代码，知道是最近添加的“应用程序模板”，估计是为应用程序向导而准备的，所以在CMakeLIST.txt文件中注释掉相关行后编译安装，顺利完成。

试用的时候，给我带来的惊喜不小，kdevelop的主要功能完成度已经很高了，尤其是开发辅助相关的界面和操作，详细看截图：

发件人 Running kde 4 for FreeBSD

稍感不足之处是“项目向导”功能还没有完全实现，我想这有待 app-temple 的进一步完善！