今天被GNOME3操暴了。

录视频骂他。

首先是gnome3的alt tab,我从firefox 切到gnome-terminal很正常,反过来就会默认高亮在gnome-terminal上,导致我按一下切不过去。怎么用都不顺手.

其次改窗口大小,即使有aero snap,有时候我也想要点别的大小的窗口,首先边框太窄,左右下角很难按到,然后是左上正常,右上不能调整。

然后是搜索程序界面,这对于geek来说怎么样也应该是个纯键盘的操作,然后我搜出来3个,横向排列。结果直接他妈必须用上下而不是左右键选择。

再其次是gnome-tweak-tool的小问题,tab不能靠拖着切换。然后随便用kwrite对比了一下。(小问题而已。)

最后就是纯傻逼的把托盘图标分成两份,和indicator不一样的是,老式图标其实可以放在上面,其实只需要一个过滤器。这直接把所有应用程序强暴了。(这个我早知道了,前面的是今天遇到的问题,我以后一定要在程序里面放彩蛋骂gnome)

今天我刚一开始用就感觉呼吸不畅胸闷,然后它就立马把我给操了。要不是我想要为可怜的fcitx+gnome3用户开发插件,我才他妈不装这破玩意呢。

Posted in Linux | Tagged , | 20 Comments

Welcome for test

$ pacman -Q fcitx-hg
fcitx-hg 600-1

Welcome for test. 我确定它一定会有bug的……我也刚刚开始日常使用而已。

另外皮肤配置有改动(抱歉抱歉……不过功能没少……),改日再写一个新的说明。

PKGBUILD:

http://www.wuala.com/csslayer/pkgbuild/

Posted in fcitx development | 16 Comments

关于代码风格和宏

这是个反思的时机。

由于现在fcitx只有我一个人修改,不需要合作的时候怎么写都无所谓。主要是让一位兄弟望而却步。

我的代码风格到底猎奇吗?

他对于libfcitx-config这个库的意见最大

fcitx的代码现在总体上受了很多其他的代码影响,比如插件的设计,灵感来源于compiz,包括配置文件的设计,比如采用独立文件描述配置文件,这样fcitx-config-gtk就可以像ccsm一样简单设计了。同时为了易于手动修改,于是采用了类ini的写法。

然后为了在代码中方便取用配置文件的值,可以将配置文件的值和一个c的struct绑定,为了方便描述这种绑定这里使用了大量的宏。

使用宏的习惯是我从Postgresql继承来的,学校的开发涉及Postgresql,里面也使用了很多宏,比如系统表的初始值,系统表的定义。

CONFIG_BINDING_BEGIN(FcitxPinyinConfig);
CONFIG_BINDING_REGISTER("Pinyin", "PinyinPriority", iPinyinPriority);
CONFIG_BINDING_REGISTER("Pinyin", "ShuangpinPriority", iShuangpinPriority);
CONFIG_BINDING_REGISTER("Pinyin", "DefaultShuangpinSchema", strDefaultSP);
CONFIG_BINDING_REGISTER("Pinyin", "UseCompletePinyin", bFullPY);
CONFIG_BINDING_REGISTER("Pinyin", "AutoCreatePhrase", bPYCreateAuto);
CONFIG_BINDING_REGISTER("Pinyin", "SaveAutoPhrase", bPYSaveAutoAsPhrase);
CONFIG_BINDING_REGISTER("Pinyin", "AddFreqWordKey", hkPYAddFreq);
CONFIG_BINDING_REGISTER("Pinyin", "DeleteFreqWordKey", hkPYDelFreq);
CONFIG_BINDING_REGISTER("Pinyin", "DeleteUserPhraseKey", hkPYDelUserPhr);
CONFIG_BINDING_REGISTER_WITH_FILTER("Pinyin", "InputWordFromPhraseKey", strPYGetWordFromPhrase, FilterGetWordFromPhrase);
CONFIG_BINDING_REGISTER("Pinyin", "BaseOrder", baseOrder);
CONFIG_BINDING_REGISTER("Pinyin", "PhraseOrder", phraseOrder);
CONFIG_BINDING_REGISTER("Pinyin", "FreqOrder", freqOrder);
CONFIG_BINDING_REGISTER_WITH_FILTER("Pinyin", "FuzzyAnAng", MHPY_C[0].bMode, FilterAnAng);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyEnEng", MHPY_C[1].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyIanIang", MHPY_C[2].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyInIng", MHPY_C[3].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyOuU", MHPY_C[4].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyUanUang", MHPY_C[5].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyCCh", MHPY_S[0].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyFH", MHPY_S[1].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyLN", MHPY_S[2].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzySSH", MHPY_S[3].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "FuzzyZZH", MHPY_S[4].bMode);
CONFIG_BINDING_REGISTER("Pinyin", "Misstype", bMisstype);
CONFIG_BINDING_END()

比如这段代码。

宏的目的是为了使得机械重复的代码变得精简已读。那么这里如何呢?我觉得除了分号的使用(最后应该统一不用分号最好……),明显把这部分变得更加易读了(个人观点)。如果宏加上合适的文档说明,应该可以明确表达出这段代码的含义。

再谈到关于模块之间的互相调用。这部分的思想同样来源于Postgresql。以及之前看到的关于ABI的文章。

每个模块有自己的名称(固定不变),每个模块注册对应的函数,每个函数有自己的ID(固定不变),每个函数有固定的参数。真实参数通过这个固定参数的一个结构体传递,全部传递指针。

#define FCITX_X11_NAME "fcitx-x11"
#define FCITX_X11_GETDISPLAY 0
#define FCITX_X11_GETDISPLAY_RETURNTYPE Display*
#define FCITX_X11_ADDXEVENTHANDLER 1
#define FCITX_X11_ADDXEVENTHANDLER_RETURNTYPE void
#define FCITX_X11_REMOVEXEVENTHANDLER 2
#define FCITX_X11_REMOVEXEVENTHANDLER_RETURNTYPE void
#define FCITX_X11_FINDARGBVISUAL 3
#define FCITX_X11_FINDARGBVISUAL_RETURNTYPE Visual*
#define FCITX_X11_INITWINDOWATTR 4
#define FCITX_X11_INITWINDOWATTR_RETURNTYPE void
#define FCITX_X11_SETWINDOWPROP 5
#define FCITX_X11_SETWINDOWPROP_RETURNTYPE void
#define FCITX_X11_GETSCREENSIZE 6
#define FCITX_X11_GETSCREENSIZE_RETURNTYPE void
#define FCITX_X11_MOUSECLICK 7
#define FCITX_X11_MOUSECLICK_RETURNTYPE void

// 实际函数示例
static void* X11GetDisplay(void* x11priv, FcitxModuleFunctionArg arg);

这里注册的是X11的模块名称以及相关函数。宏名称的定义的格式是约定好的。

typedef struct FcitxModuleFunctionArg
{
    void* args[10];
} FcitxModuleFunctionArg;

void* InvokeModuleFunctionWithName(struct FcitxInstance* instance, const char* name, int functionId, FcitxModuleFunctionArg args);

#define InvokeFunction(INST, MODULE, FUNC, ARG)  \
    ((MODULE##_##FUNC##_RETURNTYPE) InvokeModuleFunctionWithName(INST, MODULE##_NAME, MODULE##_##FUNC, ARG))


实际调用的时候使用InvokeFunction这个宏。这样实际调用的时候就是这样子。可以明显看出是调用FCITX_X11的GETDISPLAY函数。

dpy = InvokeFunction(instance, FCITX_X11, GETDISPLAY, arg);

关于以上写法,诸君,你们以为呢。(实际毫无反省之意……)

Posted in fcitx development | 12 Comments

New Keyboard Image


Posted in fcitx development | 10 Comments

Linux的桌面为什么这么傻逼(翻译)

就算成天被桌面折磨着早就成了M,但该骂还是他妈得骂,下面是别人骂的,总之都说到心坎里面了。本来想多加点脏话表达下心情,不过毕竟是翻译还是不要偏离原意为好。

来源:

http://news.ycombinator.com/item?id=2643671

作为VLC的主要开发者和VideoLan的实际领导者,尽管我不想说什么,但最近有那么点受不了了。(啊,我还没叛逃到Windows去……)……是的,我是开源的强烈支持者,并且在大多数桌面操作系统上为FLOSS做了很多工作(包括匿名和不匿名的),并且相信计算机应该是自由的。我作为Linux用户和系统管理员已经有8年了。

但是,我被最近所谓的Linux桌面的“进步”震惊了:大多数所谓的进步就是渣……而且不光是我一个人这么认为,我所看到的用户反馈也都是些抱怨……尽管我会因为这篇回复而被人讨厌,但是我不吐不快。

– PulseAudio还是半生不熟的时候,就被Ubuntu和Fedora硬塞给了用户,并且许多用户都讨厌它;它具有严重的NIH综合征,和老架构相比它只带来了一点点新特性,那些新特性反而老平台做得更好。它的维护团队拒绝持续更新,也不愿意对某些应用友好(这完全不可接受),不光线程不安全,而且某些情况会占用大量CPU。

– PolicyKit 十分复杂,占用大量进程,而且几乎不能正确初始化(似乎只有gdm3能办到这件事)。它会弄坏大量的程序,特别是 Network Manager …现在我不得不用命令行来在KDE上连接wifi。并且如果你使用Gnome3或者NM的话,你还不得不使用它。

– KDE4.x 在4.3之前完全不能用(事实上我可以接受),但到了4.6,我还是不得不禁用语义学桌面和strigi从而让它不要操掉我那点CPU资源。Network Manager 还是无法工作,并且使用Nvidia的闭源驱动时我这里kwin会发生奇怪的崩溃。

– 尽管PackageKit不那么重要,并且它做得还不错,但它也十分复杂,需要维护者为大多数发行版打大量补丁,这玩意其实没啥必要,但是还是占用了大量时间……

– Unity 和 Gnome3 的可用性大踏步倒退,当然在下个版本出来之前我不会太在意这个(KDE 4.0 和 4.1 也不咋地)但他们还是烂到家了。对他们来说,窗口管理器无法正确处理全屏程序,x11 和 OpenGL 的混合程序,当然还包括了了 Xv。无障碍访问(注:残障人士相关的那个功能)完全被Unity抛到脑后了。不仅如此,Unity还时常崩溃或者死循环,我的家人对这次升级十分不满意。

所以,当人们问到我对于systemd和Wayland的观点时,我也不乐观。

幸好,我在打印上完全没问题 🙂

——————–我是风骚的分割线———————–

(注,这是另外一个人了)

如果你对四年前的linux桌面很满意,事实上我也是这么想的,好消息是,如果你还想找回它来,它始终还在那里。你也许所需要做的事情就是放弃或者降级Gnome,但它确实还在那。(或者对我来说,把KDE的一陀默认设置给取消了。)但不可否认的是,最近关于Windows的尝试就是场灾难。考虑到开源的基本工作方式,现在有大量的架构宇航员(含义请参考[1])在满世界乱窜。他们在干这些事情:

1、搞一个看起来富丽堂皇的设计

2、不管怎样搞个渣实现,然后把它搞成标准

3、经过艰苦卓绝经年累月的修复,让它比之前稍微不渣那么一点点。

4、然后回到1

这已经成为Linux桌面世界的惯例了。我不认为Gnome或者KDE项目管理良好。用一个不对任何人负责的庞然大物来替换对它客户负责的庞然大物并不是一种进步,不论前者是多么“开放”。

(哦,因为我是一名专业程序员并且我比起所谓“语义桌面”更偏好命令行,所以我感觉还行。我承认这并不是通常情况。)

[1]: http://www.joelonsoftware.com/articles/fog0000000018.html

Posted in Linux | Tagged , , | 20 Comments