ikde.org 始动!

地址:ikde.org

我和心之所在兄一时激动就搭了这么个站,还是跑在我的VPS上,话说回来原来有两个IP,这次倒是利用上了另外一个。似乎对于我这可怜的VPS没有造成太大负担,目前。
名字话说当初想了不少,比如wowkde什么的,不过心之兄说太高调……(其实他本来也说ikde很高调哎)
这个名字最初是心之兄想的,后来我觉得和以前看的I,robot很像,所以也同意这个名字。
至于主题当然是KDE没话说,我打算最初的计划就是介绍一些KDE里面通常不被了解的一些好玩的东西,至于之后再说的。
我的第一篇已经写完了,那些KDE中的技术(一)Nepomuk。下一个计划当然就是同样备受争议的Akonadi 🙂
Posted in 日志 | 5 Comments

还是很菜的。

API和ABI。
比如c语言的struct,如果struct的大小或者属性的顺序变了,那么以前编译过的程序和共享库之间是不兼容的。

struct s {
    int a;
    int b;
};

如果修改之后:

struct s {
    int a;
    int c;
    int b;
};

那么如果你按照之前的头文件编译

struct s o;

o.b和现在的o.b的地址是不一样的,之间差了s中的c这个长度。那么执行的时候就会得到错误的结果,需要靠重新编译解决。

为什么get和set是有必要的?

get和set可以将原有的属性之间ABI的不兼容变化成API。get和set的函数是和包含在共享库当中的,这个函数一定会和共享库一起编译。这样ABI之间的不兼容就被API化解了。

要么保持数据结构不变,要么就不要将它暴露给别人。

Posted in Linux | 6 Comments

追漫笔记-3

这次都不是热血漫……
1、黄昏少女X记忆丧失
怪谈系,让人想起被斩了的《诡辩学派四谷前辈的怪谈》,其实这个调调不错的。更新挺慢,女主是黑长直,似乎和最近很多形象类似啊(食灵-黄泉,化物语-战场原)。更新太慢有点记不得剧情了……汗。这个是凑数用吗……
2、只有神知道的世界
嗯,神大人是魔法师们的楷模啊,老实说很有意思的切入点,给人的感受主线还是神大人从攻略之神变成人的过程。女主“们”其实画的还都蛮萌的。实际上人还是不可能脱离社会而活着的,就算是宅也要宅得有自己的气势啊!神大人的例子虽然过于理想化,但实际上最后还是要变回人的吧。
3、直率
啊啊……这部比较变态重口味。(好吧一般向里面)总之认识能力不足的女主和M的男主的故事。有空时看看,挺有意思的。大概分类还是,搞笑漫,吧?

似乎有点偷工减料啊……啊,毕竟只有2比较推荐。再来一个吧。

4、进击的巨人
十分给力,不过连载速度是两周一次?目前的量还不够过瘾。
人类的命运随时感觉要被终结,就是在这种绝望当中平凡的斗争,才显得更加有力。其实有预言帝说其实这是个实验室(喂,大剑吗……),人类其实是被豢养在这片土地上,当然这能够解释清楚很多事情。不过具体如何发展还是拭目以待吧。似乎是作者的第一部连载作品?加油啊!

Posted in 日志 | Tagged , , , , | 1 Comment

对blog做了一些小调整

主要是调整颜色增加可读性。
以及reply的时候改为两层,对同一话题的reply请reply楼顶即可。
另外我终于把supercache成功开启了…当然对已经有cookie的读者是感觉不到啦。

另外默认被回复的评论是会发送email的。

Posted in 日志 | Comments Off on 对blog做了一些小调整

Long road to fcitx 4.1

好吧,离4.0发布虽然还没多久,来考虑一些新问题。

最重要的就是承诺过的fcitx的gtk im module,以及更多的rework。

众所周知,fcitx有这样那样的问题,gtk水土不服啦,只能单实例运行啦,输入效果差啦等等。

我以前说过,我主要的精力还是放在整体的framework上,而不会花太多精力在输入法本身上。所以这次的工作主要就是解决和其他程序的兼容性问题和代码的重构。

fcitx的issue列表不能说很短了,扫过去的话,其实很多都是和gtk im module相关的。

为什么不是xim,我个人认为有两个很简单的原因,其一当然是现实所迫,那么多的程序没有gtk im module就不能正常工作,不幸这个只能从fcitx做起。另外一点,就是xim离开x还能运行吗?因此gtk im module当然有它存在的意义。

另外一方面就是把fcitx完全的拆散,everything work seperately,everything works well,现在关于这方面的点子在我脑子中一个接一个的冒出来,我都有些心潮澎湃了……

比如软键盘真的应该集成到fcitx内部吗?似乎没有必要。quickphrase也是。如果剔除之后他们能不能和原来的功能一起工作?如何一起工作?都是一些有意思的问题。fcitx的core最后应该剩下什么?坚持不依赖ui toolkit的fcitx是不是应该提供一些简单的ui toolkit机制让其他功能也可以开发自己的ui?

希望4.1出现的时候(按照我的速度以及精力……汗,这点还是异常值得吐槽的)能够对于fcitx的本身带来一些革命性的变化。

虽然不知道最后说点什么好,结语是,希望有一天fcitx能够走到所有平台上,就这样吧。

P.S.

由于时间原因,我个人是不倾向于定时间表的,啊,虽然我很乐意干这件事情,但是还是有很多其他有意思/意义事情想做,被自己的兴趣赶着屁股走不是啥好事,反而会失掉热情。

那么还是只列一个计划表吧,按照这个计划表慢慢往下走。

1、将所有ui部分抽象,实现一些event driven的接口。

2、将和其他程序交互的部分抽象(xim,immodule),初步计划用socket重写这部分。话说最近阅读的一个代码也给了我启发,虽然仅仅用telnet做协议,但是很简单,而且工作的很好。

3、把内置的两个输入法(拼音,码表)也提取出来,作为模块。

4、增加其他milestone上的new feature

5、test again and again

6、4.1就到此吧 🙂

Posted in fcitx development | 16 Comments