Category Archives: Linux
很菜的VIM配置
前略,前半就是vim自带的example。 syntax enable set hlsearch set autoindent set nocp set ts=4 set sw=4 set number set encoding=utf-8 set fileencodings=utf-8,gb2312,gb18030,gbk,ucs-bom,cp936,latin1 filetype plugin indent on set grepprg=grep\ -nH\ $* let g:tex_flavor = “latex” set runtimepath=~/.vim,/usr/share/vim,/usr/share/vim/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,~/.vim/after autocmd FileType python setlocal et sta sw=4 … Continue reading
炮文:为什么你不应该用独立的WM作为你的桌面
因为你享受不到Linux桌面带来的好处。 如果你不知道什么是freedesktop.org,我建议你先去补课。 别以为Linux的桌面是没有标准的。为了让程序们能够在不同的桌面下正常工作,真的是有一些人去制定一个标准,让程序们可以放心的处理跨桌面的行为。 即使你想用独立为WM,从而满足你那小小的需求,你也应该去用一个桌面,然后替换掉上面的组件。而不是写一些愚蠢的脚本将别的桌面的组建在你可怜的桌面上启动。 lxde,xfce都是不错的开始。尤其是xfce,当年我在上面各种替换组件的经历都十分愉快。 其次选择一个登录管理器(噢,你别把slim当成和startx有什么区别的东西),而不是startx。如果你想知道为什么的话,那就是一些必须的初始化。如果不想纠结于,dbus,polkit,networkmanager,为什么在你的桌面上不能正常工作的话。 事实上,没有几个人能够好好的初始化这些东西,与其花费精力去了解这些东西到底是什么,为什么不用一个bug free的session管理器呢? 有什么会Break? 文件关联,你总是需要一个文件管理器,xdg-open是桌面程序开发者的好帮手,帮你选择正确的程序打开文件,但你不要自作聪明去破坏开发者的好意。使用一个xdg兼容的文件管理器能省下你无数功夫。 dbus & consolekit DBus的连接是一个抽象的地址,为了让一些程序能够通信,他们需要连接到这同一个地址上面。但是DBus找到这个地址的方式有两个,一个是通过session,一个是通过环境变量,如果你不懂怎么才能初始化consolekit和dbus,你最好省省去用一个session管理器。 这些还不够吗? 你要好好学习到你是一个非主流用户了,如果你连这点都认识不到,你不要指望桌面开发者能够照顾你什么,你和他们已经不是生活在一个时代的人了。 不要指望开发者会给你一个地方配置使用什么浏览器,不要指望开发者给你一个地方设置使用什么文件管理器,不要指望开发者给你一个地方去设置你愚蠢的文件关联命令。自从你自作聪明的使用你愚蠢的脚本启动桌面,你早就活在他的用户群之外了。
什么是D-Bus?
有朋友在鸟嘀咕上要求我解释一下,我觉得简单来讲是解释不清楚的,所以打算写篇blog回复。 从功能上来说,它提供了程序之间互相交互的一个简单接口,程序可以尽量不关心关于底层的通信细节,而方便地和其他程序进行通信。它不仅仅在Linux和UNIX上实现了,同时也有Windows的移植版本(KDE4的Windows版就有用到)。 它对于底层的通信协议进行了封装,提供了相应的基本数据类型,简化了对于序列化的繁复操作,开发者只需要关心对应的操作即可。 从基础概念来说,一个程序会注册至少一个Service,这个service可以是一个公共的名称(这样的话就是一个面向开放的Service,期待其他人主动调用。)这个名称可以设置为互斥的,或者是可以无缝地由其他程序进行接管。或者不使用一个公共的名称,这样一般就是作为一个client。 每个Service下面有多个Object,每个Object可能实现多个interface,interface里面定义的是这个Object的属性(property),方法(method),或者信号(signal)。通过一个xml文件定义。对于一个object来说,它有义务实现org.desktop.DBus.Introspectable接口,别的dbus程序就可以通过调用这个接口的Introspect方法询问你对于接口的支持情况。 dbus里面的方法就像是一般的ipc/rpc调用一样,有参数,返回值。可以call给某个service的某个object的某个method。这一般可以用于dbus内的client和逻辑上的server进行通信(因为实际上dbus是使用一个daemon的形式运行,中间由他进行转发)。signal的概念可以认为是一种广播的机制,其他的dbus service可以选择按照某个filter监听signal,在signal触发的时候进行对应的处理。property则有它对应的get,set,以及在改变的时候触发标准的org.freedesktop.DBus.Properties.PropertiesChanged signal。 对于Glib,Qt,Python等等库,都有对dbus按照它进行抽象和封装,例如对于Qt来说,就可以将method和slot联系起来,signal和qt的signal联系起来,object就可以作为一个实际的“QObject”。通过qdbusxml2cpp这个命令生成对应的c++代码。 dbus上也提供了非常多的工具进行调试或者是命令访问,例如可以通过dbus-moniter监控某个channel上的dbus通信,或者直接使用dbus-send发送dbus的消息。qdbusviewer则是提供了一个可视化的界面,可以查看session和system两个channel的dbus操作。 dbus本身也是一个依赖非常轻量的库,除了一个xmlparser之外,就只有对应平台上的一些库。 如果想要通过dbus的底层api实现一个dbus程序(比如fcitx这样的),一般而言有两种简单的方法。 一个是在获得可用的dbus_connection之后,通过dbus_connection_read_write 直接一条条地处理dbus message(前面的method,signal其实都是一种dbus message),或者实现一个main loop,并且通过dbus_connection_set_watch_functions 注册一些函数,用来监视实际的dbus操作的fd,然后或者通过select,或者使用libevent,libev,在确认有dbus的消息到来后调用 dbus_watch_handle 和 dbus_connection_dispatch 处理消息。(实际上glib等库中就是这样实现的) D-Bus 本身大大简化了不同程序之间通信的开发,并且稳定性也已经接受了多年的检验,对于开发一个需要通信桌面程序来说是一个很好的选择,并且也已经有无数程序选择了dbus作为它开放的接口,比如媒体播放器就有mpris接口来监控或者操作播发器的状态。
export QT_IM_MODULE=fcitx
这次写它的理由就更有意思了…… 因为我单纯的觉得让用户发现QT_IM_MODULE和GTK_IM_MODULE竟然不一样会很蛋疼,于是就趁热打铁一口气写了……同时也让两大UI Toolkit的IM MODULE都齐全了…… 还在调试……另外感想就是果然c++比c方便写继承什么的……
今天被GNOME3操暴了。
录视频骂他。 首先是gnome3的alt tab,我从firefox 切到gnome-terminal很正常,反过来就会默认高亮在gnome-terminal上,导致我按一下切不过去。怎么用都不顺手. 其次改窗口大小,即使有aero snap,有时候我也想要点别的大小的窗口,首先边框太窄,左右下角很难按到,然后是左上正常,右上不能调整。 然后是搜索程序界面,这对于geek来说怎么样也应该是个纯键盘的操作,然后我搜出来3个,横向排列。结果直接他妈必须用上下而不是左右键选择。 再其次是gnome-tweak-tool的小问题,tab不能靠拖着切换。然后随便用kwrite对比了一下。(小问题而已。) 最后就是纯傻逼的把托盘图标分成两份,和indicator不一样的是,老式图标其实可以放在上面,其实只需要一个过滤器。这直接把所有应用程序强暴了。(这个我早知道了,前面的是今天遇到的问题,我以后一定要在程序里面放彩蛋骂gnome) 今天我刚一开始用就感觉呼吸不畅胸闷,然后它就立马把我给操了。要不是我想要为可怜的fcitx+gnome3用户开发插件,我才他妈不装这破玩意呢。