使用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的支持不错，值得一赞！
2009年2月26日星期四
2009年2月25日星期三
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 的安装机制。
近两日运行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 的安装机制。
2009年2月2日星期一
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的主要功能完成度已经很高了，尤其是开发辅助相关的界面和操作，详细看截图：
稍感不足之处是“项目向导”功能还没有完全实现，我想这有待 app-temple 的进一步完善！
2009年1月31日星期六
简单理解kde4的语义学桌面搜索
简单理解kde4的语义学桌面搜索
杜比环绕声
语义学桌面搜索是kde4桌面环境所提供的新搜索技术，它依据的是知识库的语义学研究成果。我一直很好奇这个技术，得益于kde 4.1 rc1的使用，说说我对这个技术的理解。
目前所能理解的搜索，大都是利用文件名、扩展名以及一些文件属性等关键字进行搜索，较早的实现是以文件名为关键字，采取目录树遍历的方法，诸如kde3的kfind程序，目前的实现大都基于事先建立的关键字索引数据库，来加快搜索速度，例如freebsd提供的locale程序。但这些搜索技术都是基于文件属性的，搜索的结果定位在文件位置上。
在桌面环境下更高的搜索需求是存在的，例如特定的内容在哪些文件中出现过，搜索特定大小的图片文件，搜索特定长度的音频文件等等，这些搜索都要深入到文件内部，而这种搜索实现可以从网络引擎获得的直接经验，但具体依据什么样的关键字，搜索范围能扩大到什么程度，目前还不得而知。
语义学搜索，是目前的一项研究，从目前kde4的实现上看，它是基于文件属性以及文件内容搜索的。 这种搜索基于文件内容和属性的描述语言——RDF，简单的说是一种类似xml语言，可以对多种属性进行定义和描述的框架。在这个框架上，可以根据不同类型的文件，建立不同的属性，然后对它进行描述，每个属性都是对外的一个接口，从搜索上看，就是提供多头的关键字。利用这些关键字，可以和计算机内的其他文件建立“蜘蛛网”般的各种联系。这种网是基于文件内部属性的，这个网可以简单的称之为“语义网”。
实现这个“语义网”需要大致需要三个条件
1、文件内容属性的分析
2、加快搜索的属性索引数据库
3、组建“语义网”
对应于kde4的语义学桌面搜索实现，分别是 soprano,strigi和nepomukserver
strigi是一个基于clucene的后台搜索服务，它可以动态跟踪文件，利用clucene建立和维护索引数据库，soprano提供不同文件类型的基于rdf描述的分析和存储方式。
nepomukserver提供了一个框架，对不同类型文件的rdf进行定义，比较直观的操作是它可以通过dolphin对文件添加“个人评分”“个性标记”以及“个性备注”,它也可以通过一些图片查看、制作软件添加个性标记，可以通过音乐播放软件添加附加的标记，这些都会被定义为rdf的描述。并最终利用strigi建立索引。当然这个索引数据库会很大，在kde4贡献者博客上，我看到了一位用了1个半小时的时间为30G的磁盘文件建立了200M的索引数据库。
有了这些技术上的支持，桌面搜索范围得到了明显的增强。
利用kde4的nepomuk框架，目前我可以查看那些文件里面出现了“FreeBSD”这个字，我也可以快速的汇总我所标记的文件。可以预想，随着neomuk-kde框架的进一步成熟，支持的程序越来越多，除了文件管理更方便之外，还可以通过rdf描述的属性关键字，把个人计算机中的文件组成一个小型“google网络”。
杜比环绕声
语义学桌面搜索是kde4桌面环境所提供的新搜索技术，它依据的是知识库的语义学研究成果。我一直很好奇这个技术，得益于kde 4.1 rc1的使用，说说我对这个技术的理解。
目前所能理解的搜索，大都是利用文件名、扩展名以及一些文件属性等关键字进行搜索，较早的实现是以文件名为关键字，采取目录树遍历的方法，诸如kde3的kfind程序，目前的实现大都基于事先建立的关键字索引数据库，来加快搜索速度，例如freebsd提供的locale程序。但这些搜索技术都是基于文件属性的，搜索的结果定位在文件位置上。
在桌面环境下更高的搜索需求是存在的，例如特定的内容在哪些文件中出现过，搜索特定大小的图片文件，搜索特定长度的音频文件等等，这些搜索都要深入到文件内部，而这种搜索实现可以从网络引擎获得的直接经验，但具体依据什么样的关键字，搜索范围能扩大到什么程度，目前还不得而知。
语义学搜索，是目前的一项研究，从目前kde4的实现上看，它是基于文件属性以及文件内容搜索的。 这种搜索基于文件内容和属性的描述语言——RDF，简单的说是一种类似xml语言，可以对多种属性进行定义和描述的框架。在这个框架上，可以根据不同类型的文件，建立不同的属性，然后对它进行描述，每个属性都是对外的一个接口，从搜索上看，就是提供多头的关键字。利用这些关键字，可以和计算机内的其他文件建立“蜘蛛网”般的各种联系。这种网是基于文件内部属性的，这个网可以简单的称之为“语义网”。
实现这个“语义网”需要大致需要三个条件
1、文件内容属性的分析
2、加快搜索的属性索引数据库
3、组建“语义网”
对应于kde4的语义学桌面搜索实现，分别是 soprano,strigi和nepomukserver
strigi是一个基于clucene的后台搜索服务，它可以动态跟踪文件，利用clucene建立和维护索引数据库，soprano提供不同文件类型的基于rdf描述的分析和存储方式。
nepomukserver提供了一个框架，对不同类型文件的rdf进行定义，比较直观的操作是它可以通过dolphin对文件添加“个人评分”“个性标记”以及“个性备注”,它也可以通过一些图片查看、制作软件添加个性标记，可以通过音乐播放软件添加附加的标记，这些都会被定义为rdf的描述。并最终利用strigi建立索引。当然这个索引数据库会很大，在kde4贡献者博客上，我看到了一位用了1个半小时的时间为30G的磁盘文件建立了200M的索引数据库。
有了这些技术上的支持，桌面搜索范围得到了明显的增强。
利用kde4的nepomuk框架，目前我可以查看那些文件里面出现了“FreeBSD”这个字，我也可以快速的汇总我所标记的文件。可以预想，随着neomuk-kde框架的进一步成熟，支持的程序越来越多，除了文件管理更方便之外，还可以通过rdf描述的属性关键字，把个人计算机中的文件组成一个小型“google网络”。
让kde 4.2的Nepomuk正常工作
Nepomuk的启动流程
首先系统配置为Nepomuk 启动，然后启动 Nepomuk ontology loader，因为这个服务依赖 nepomukstorage，所以先启动 nepomukstorage
之后启动 nepomukqueryservice，nepomukstrigiservice,nepomukfilewatch,，装载 Soprano 的所有插件，搜索/usr/local/share/soprano/plugins目录下的插件，先搜索.desktop文件，然后根据desktop文件内容加载对应的库（nquadparser.desktop、nquadserializer.desktop、raptorparser.desktop、raptorserializer.desktop、redlandbackend.desktop），搜索了两遍，确定插件加载。
加载 libsoprano_redlandbackend.so 这个后端库，激活这个后端，并发现以下错误：could not find backend "sesame2" . Falling back to default.
建立搜索数据库：repository ' "main" ' at ' "/root/.kde4/share/apps/nepomuk/repository/main/"，这里面包含数据库的路径。
creating model of type "hashes" with options
"hash-type='bdb',contexts='yes',dir='/root/.kde4/share/apps/nepomuk/repository/main/data/redland'"
Nepomuk::Repository::open: Successfully created new model for repository "main" 成功建立数据库，bdb格式的
CLuceneIndex::open in thread 701501696
CLuceneIndex::close in thread 701501696
CLuceneIndex::close done in thread 701501696
CLuceneIndex::open done in thread 701501696
这应该是一个测试，测试是否可以建立index
Successfully created new index for repository "main"
Successfully initialized nepomuk core
成功初始化nepomuk核心，成功初始化nepomukstorage，接下来按照下面的顺序初始化
Nepomukstrigi、 nepomukfilewatch、 nepomukqueryservice、 nepomukqueryservice、 nepomukontologyloader
建立nepomuk服务器链接，加载Soprano后端，启动strigi服务，提示失败原因是：低优先级别调度，当使用redland soprano后端时不能启动，，启动nepomukontologyloader 进程，监护 /root/.kde4/share/apps/nepomuk/ontologies目录，发现日期修改。
启动nepomukfilewatch进程，启动nepomukqueryservice进程，完成nepomuk相关服务的加载！
原来sesame2的编译需要java环境，在soprano的ports中若没有java环境，就不编译sesame2的后端组件。
FreeBSD环境下配置Nepomuk
从上面的分析可知，Nepomuk的文件检索功能需要soprano的sesame后端的支持才行，所以正常运行Nepomuk需要安装好sesame2，经过一些测试，主要的步骤如下：
从soprano的ports的测试可知，soprano是内含sesame后端代码的，但在编译时，需要检测JNI，为了满足这个条件，需要安装JAVA SDK环境
安装javavmwrapper-2.3.2 ports
下载安装 diablo-jdk-freebsd7.i386.1.6.0.07.02.tbz，可从FreeBSD基金会网站下载，也可自行编译。
安装完成后设置 JAVA_HOME=/usr/local/Diablo-jdk1.6.0
然后重新安装soprano软件，查看 /usr/local/lib/soprano/目录下，已经有sesame后端了！
重新启动kde，Nepomuk已经可以正常启动，系统启动即建立指定目录的索引！
首先系统配置为Nepomuk 启动，然后启动 Nepomuk ontology loader，因为这个服务依赖 nepomukstorage，所以先启动 nepomukstorage
之后启动 nepomukqueryservice，nepomukstrigiservice,nepomukfilewatch,，装载 Soprano 的所有插件，搜索/usr/local/share/soprano/plugins目录下的插件，先搜索.desktop文件，然后根据desktop文件内容加载对应的库（nquadparser.desktop、nquadserializer.desktop、raptorparser.desktop、raptorserializer.desktop、redlandbackend.desktop），搜索了两遍，确定插件加载。
加载 libsoprano_redlandbackend.so 这个后端库，激活这个后端，并发现以下错误：could not find backend "sesame2" . Falling back to default.
建立搜索数据库：repository ' "main" ' at ' "/root/.kde4/share/apps/nepomuk/repository/main/"，这里面包含数据库的路径。
creating model of type "hashes" with options
"hash-type='bdb',contexts='yes',dir='/root/.kde4/share/apps/nepomuk/repository/main/data/redland'"
Nepomuk::Repository::open: Successfully created new model for repository "main" 成功建立数据库，bdb格式的
CLuceneIndex::open in thread 701501696
CLuceneIndex::close in thread 701501696
CLuceneIndex::close done in thread 701501696
CLuceneIndex::open done in thread 701501696
这应该是一个测试，测试是否可以建立index
Successfully created new index for repository "main"
Successfully initialized nepomuk core
成功初始化nepomuk核心，成功初始化nepomukstorage，接下来按照下面的顺序初始化
Nepomukstrigi、 nepomukfilewatch、 nepomukqueryservice、 nepomukqueryservice、 nepomukontologyloader
建立nepomuk服务器链接，加载Soprano后端，启动strigi服务，提示失败原因是：低优先级别调度，当使用redland soprano后端时不能启动，，启动nepomukontologyloader 进程，监护 /root/.kde4/share/apps/nepomuk/ontologies目录，发现日期修改。
启动nepomukfilewatch进程，启动nepomukqueryservice进程，完成nepomuk相关服务的加载！
原来sesame2的编译需要java环境，在soprano的ports中若没有java环境，就不编译sesame2的后端组件。
FreeBSD环境下配置Nepomuk
从上面的分析可知，Nepomuk的文件检索功能需要soprano的sesame后端的支持才行，所以正常运行Nepomuk需要安装好sesame2，经过一些测试，主要的步骤如下：
从soprano的ports的测试可知，soprano是内含sesame后端代码的，但在编译时，需要检测JNI，为了满足这个条件，需要安装JAVA SDK环境
安装javavmwrapper-2.3.2 ports
下载安装 diablo-jdk-freebsd7.i386.1.6.0.07.02.tbz，可从FreeBSD基金会网站下载，也可自行编译。
安装完成后设置 JAVA_HOME=/usr/local/Diablo-jdk1.6.0
然后重新安装soprano软件，查看 /usr/local/lib/soprano/目录下，已经有sesame后端了！
重新启动kde，Nepomuk已经可以正常启动，系统启动即建立指定目录的索引！
订阅：
博文 (Atom)
博文
