终于把ibus找回来了

上一篇文章说过,我因为pygtk用不了而没法用ibus,其实具体原因是这样的:

在某次emerge -u world的时候,我安装了python 3.1,但是没运行python-updater(就算运行了,那些模块现在能全部移植过去么?),而且没有设为主python版本(毕竟相关应用还不成熟,而且不向下兼容)

然后又是某次emerge -u world,pycairo说要python2.6,于是就装了

接下来就杯具了:

  • 因为pycairo升级了,只能在python2.6下用,所以python下依赖pycairo的pygtk用不了;
  • 因为装了python 3.1,所以运行python-updater时,是从python 3.1更新到python 2.6,而这两个都没有用过python-updater从python 2.5中更新过,所以python 2.5里的模块都无法更新进python 2.6里

于是没办法,手动emerge pygtk,但是不管emerge了几次,运行ibus-setup都说找不到gtk模块。

终于,在网上搜到,原来少的不是pygtk,是pygobject-_-(我说这提示就不能友善点么)

把pygobject重装,又依次提示没有ibus、dbus和xdg,重新emerge ibus、dbus-python和pyxdg就OK了,注销再重新登录后就能用ibus了,感动啊~~~

于是得到的教训:升级python一定要记得python-updater,emerge完之后一定要留意软件包的message

未分类 Comments(0) 2009年9月01日 00:51

Wireless in Gentoo works

 In the past my Gentoo failed to connect some wireless connection.

Today I run wpa_cli to check what the problem is, and saw this message: ``Association request to the driver failed''. It's obvious that I didn't install WEP driver.

So I enable the following option, and recompile the kernel:

    Device Drivers  --->
[*] Network device support  --->
      Wireless LAN  --->
<*>   IEEE 802.11 for Host AP (Prism2/2.5/3 and WEP/TKIP/CCMP)

After rebooting my Gentoo, the wireless network is successfully connected!

BTW: my pygtk doesn't work and I can't use ibus, so it's written in English :(

linux Comments(6) 2009年9月01日 00:22

OSD Lyrics 0.2发布

经过一个多月的开发,OSD Lyrics终于实现了多下载引擎支持,是时候发布0.2版了。

0.2版相较于0.1版有如下改动:

  • 支持从千千音乐在线下载歌词
  • 支持 Rhythmbox
  • 支持全局快捷键
  • OSD模式改进
    • 添加单行模式支持
    • 歌词过长时水平滚动
    • 鼠标移动到歌词上时歌词变为透明
    • 显示/隐藏歌词
    • bug修复
  • 修复之前将LRC文件的offset处理错误的问题
欢迎前往http://code.google.com/p/osd-lyrics/downloads/list下载体验=v=

osd-lyrics Comments(1) 2009年8月28日 09:27

OSD Lyrics 支持从千千下载歌词了

由于之前歌词下载是simplyzhao做的,熟悉起来花了一些时间,走了一些弯路,现在终于把从千千下载歌词搞定了。现在多下载引擎的接口已经准备完毕,就差配置部分,等配置弄好就可以准备推出0.2了=v=。

osd-lyrics Comments(0) 2009年8月26日 09:35

Work with Gentoo

花了一个星期的时间,终于差不多迁移到Gentoo来了,Ubuntu还留着,两个Home目录里也有多个符号链接来保持软件配置和数据的一致性。

目前还有些东西没弄好,包括但不限于:

  • 无线网卡:驱动装好了,NetworkManager也能用,但是经常连不上,今天更是成功连上了nm-apple却一直显示连接中-_-
  • LATEX:还没装,怕搞中文支持,反正现在也不用写论文
  • VirtualBox:昨天装了,貌似因为没把qt支持加到USE里而没有GUI-_-
  • Alsa配置未能保存,每次想听点什么都要打开控制来调整过

装了Gentoo才不得不赞叹Ubuntu的人性化,很多好用的默认配置(显示可挂载的分区,bash自动完成等)都在Gentoo下折腾了很久,针对Gnome的一些补丁(用户状态切换applet,触摸板配置,OSD Notify等)也很好用,希望它的一些补丁可以反馈到上游作者那里,让所有系统都可以受益(TX同学已经在Gentoo下自己干起来了)。

用了Gentoo几天,对它的好处目前只体会在新软件的使用上,连续几天emerge了一大堆东西,机子不停地跑呀跑。发现用Gentoo真的会让人有洁癖的,毕竟自己编译东西是相当费时的,更重要的是,装什么都是自己选择的(据说选择是Gentoo的重要理念之一)。另外就是囧这些东西让我明白了许多原来不了解的东西,对系统的工作有了更多的把握。

linux Comments(3) 2009年8月14日 06:32

GNU hello学习笔记(1)——autoconf和automake

什么是 GNU hello

GNU hello 是 GNU 推出的 hello world 软件,就是将入门的 hello world,以正规的 GNU 规范来实现,从而来展示 Unix-like 系统下开发软件的一些常用技术和软件的组织方法。麻雀虽小,五脏俱全,GNU hello 虽然只是一个 hello world,却包含了如下几项技术:

如何学习 GNU hello

最好的方式莫过于自己参照 GNU hello 弄个自己的 hello world 出来,把其中的各项有用技术都自己玩个遍。只看书永远没有实践来得实在,不是么?

程序主要的新东西自己手写,一些体力劳动就直接复制粘贴了。最终出来的内容不一定与 GNU hello 完全相同。

本篇学习内容

基本的程序文件组织方式

  • 基本的 Autoconf 和 Automake 配置文件写法及其原理

好了,现在开始!

程序文件的组织

严格来说,一个程序并没有什么标准的组织规范,任何组织形式都是可以的。但是良好的程序文件组织结构可以让人快速定位开发文件,更好地管理项目。在长期的实践中,Unix社区对一些常见文件的组织逐渐形成了一些传统,这些传统不仅是经受了时间的考验,也能让别人更好的了解自己的项目文件组织结构。

在 GNU hello 中,文件是这样组织的(设“/”是代码根目录)

  • \:根目录存放automake和autoconf等配置文件,以及程序的一些说明文件(NEWS、Changelg、COPYING、INSTALL、AUTHORS等)
    • build-aux:automake 和 autoconf 自动生成的一些脚本
    • contrib:暂时不明
    • doc:程序文档
    • gnulib:Gnulib 的各文件
    • man:manpage存放地
    • po:gettext 翻译文件
    • src:程序源文件
    • tests:测试脚本

在其他项目中,我见过的有doc、man、po和src,这些应该是约定俗成的命名。另外会生成库文件的项目不少是把库文件放在lib目录下的。

Autoconf 和 Automake

它们是干啥的?

Unix下的软件,编译安装一般来说是要运行如下三条命令:

./configure
make
make install

make是通过Makefile里指定的命令与目标来进行相应操作的程序,可以简单地理解为一串指令的集合(当然, 它远远不止于此)。用它就不必为编译代码写一条条的指令,只要把相关的指令写在Makefile里,直接make就行了。

然而不同的系统里装的软件不一样。可能一台机子里装了gcc,另一台机子里装的是cc。为了使Makefile能在所有机子里通用,就了有configure脚本。代码里并不带有Makefile,只有一个模板文件Makefile.in,里面用变量来定义要使用的命令,由configure脚本将检测到的工具填入Makefile.in生成Makefile。

但是不论是configure脚本还是Makefile,都并不是两句话可以写完的,而其内容多是类似的重复内容,于是就有了autoconf和automake。它们通过一些相对简单的语法来生成标准的configure脚本和Makefile。

准备工作

写一个最简单的hello world,存为src/hello.c:

#include <stdio.h>

int
main (int argc, char *argv[])
{
  printf ("hello world!");
  return 0;
} 

编写configure.ac

configure.ac是autoconf的配置文件,可以通过autoscan来辅助生成。旧版本的autoconf使用configure.in,现在这两个文件名都是通用的

在顶层目录运行autoscan,软件自动生成configure.scan,这是一个根据现有代码生成的configure.ac模板,将它另存为如下的configure.ac文件:

# 初始化autoconf,这句必须写在其他之前。定义的参数分别为软件名,版本号,维护地址(网站/邮件)
AC_INIT([TS Hello], [0.1], [tigersoldi<at>gmail<dot>com])
# [可选]定义生成的辅助文件的目录,默认是与configure.ac同目录
AC_CONFIG_AUX_DIR([build-aux])
# 初始化automake
AM_INIT_AUTOMAKE([readme-alpha])
# 定义需要的autoconf最低版本,这是autoscan自动生成的,未必需要这么高的版本
AC_PREREQ([2.63])
# 定义源代码的路径,通过指定源代码目录内一个存在的文件来指定
AC_CONFIG_SRCDIR([src/hello.c])
# 检测C编译器
AC_PROG_CC
# 生成配置文件,配置文件都是将`配置文件.in'进行变量替换后得到的
AC_CONFIG_FILES([Makefile src/Makefile])
# 生成上面要求输出的文件
AC_OUTPUT

 编写Makefile.am

与autoconf类似,automake的配置文件是Makefile.am,它会用此来生成Makefile.in文件,该文件是configure脚本用来生成Makefile文件的模板。

与configure.ac不同,我们要为每个文件夹写一个Makefile.am文件

根目录下的Makefile.am文件很简单,它不用做任何事情, 只要告诉make它有个子目录src,让make去操作src目录:

#处理如下子文件夹
SUBDIRS = src

src目录下的Makefile.am指定了我们要编译的程序及其文件:

# 定义要编译的程序hello,可以有多个,用空白符(空格、TAB、行末加了`\'的换行)分开
bin_PROGRAMS = hello
# 定义hello的源文件,必须以`<程序名>_SOURCES'的形式来定义,
# <程序名>就是bin_PROGRAMS中定义的程序之一,同样可以有多个源程序
hello_SOURCES = hello.c

 编译程序

文件都准备好后,就可以开始编译了。在编译之前,我们先让autoconf和automake生成我们需要的文件(确保在程序根目录):

# 将configure.ac里所需要的M4宏复制到文件夹中
aclocal
# 通过configure.ac生成configure脚本
autoconf
# 创建build-aux文件夹
mkdir build-aux
# 创建GNU要求的说明文件
touch NEWS README AUTHORS ChangeLog 
# 通过Makefile.am生成Makefile.in模板
automake --add-missing --copy

其中,aclocal是为autoconf进行准备工作的。

automake默认是GNU模式,GNU规范要求程序包含(NEWS README AUTHORS ChangeLog)等说明文件,我们用touch暂创建几个临时文件上去。

automake还需要创建一些辅助脚本,这些脚本由--add-missing选项添加到目录中。由于在configure.ac里用AC_CONFIG_AUX_DIR定义到了build-aux目录下,我们要先创建这个目录。如果没有指定--copy,那么创建的是指向automake安装目录相应文件的符号链接,指定后是直接复制一份。

可以看到autoconf创建了configure脚本,而automake则在程序根目录和src子目录下创建了Makefile.in,接下来就用configure脚本配合Makefile.in来生成Makefile:

./configure

由于我们在configure.ac里用AC_CONFIG_FILES指定了生成Makefile和src/Makefile两个文件,configure脚本通过相应的.in文件替换到检测到的相应变量后生成。注意生成的文件不仅限于Makefile,任何文件名都是可以的,只要它有.in模板。

有了Makefile就可以make啦:

make all

直接用make也可以。all是指定的目标,也是一个约定俗成的目标(这是Makefile指定的,不同Makefile可以指定不同的目标,只要把它放在第一个就行),它的作用是编译程序。

于是现在可以执行Hello world了:

./src/hello

 可以看到我的hello world出现了:-)

换一个目标试试:

make install

install也是个约定俗成的目标,它把我们的软件安装到系统中。现在可以直接输入hello来运行软件了。

有安装自然也有卸载,卸载的目标是uninstall。

还可以用make clean来清除编译出来的文件。

程序设计 Comments(0) 2009年8月07日 01:04

OSD Lyrics 有了非中文翻译

今天到OSD Lyric在launchpad上设的翻译点看了看,发现除了自己弄的中文翻译外,多了俄文、法文和西班牙文翻译,其中俄文翻译更是完成了100%(虽然只有区区几条词条)。这让我再一次感到了launchpad协作模式的强大:你永远不知道什么时候会受到别人的帮助。

之前因为对有些软件的翻译不爽,也曾经上launchpad去给别的软件贡献过几条翻译。当时就觉得,launchpad的协同翻译是一个很好的体验(尽管网速实在是有点……)。玩过windows汉化的人应该知道,在windows下翻译软件的感觉并不好。首先,windows下的软件界面字符串有好几种保存方式:标准的Windows资源、Borland系的资源、代码内嵌(这个是最恶心的)……标准形式的还好,处理代码内嵌的字符串有时无异于hack。由此诞生了许多软件,处理不同情况下的字符串资源。然后通过人力+词典的方式汉化后再导入回原软件。正是由于这种方式,使得无法自动导出待翻译的词条。其次,windows没有很好的界面本地化支持(.NET平台似乎改变了这一点),如果软件作者要支持语言包,需要自己来编写相关代码,这使得很多软件都没有多语言界面支持。一款软件被汉化后往往就失去了原来的语言,也无法与其他语言集成在一起。更重要的是,由于没有一个统一的表示翻译串的格式,无法像launchpad这样多人多软件协同翻译。第三,自己汉化了一款软件,要被纳入官方翻译也需要大量的沟通,甚至不被接受。因为有些软件压根就没打算推出多语言版本,而汉化一款软件往往是修改了软件本身的。

而且在Linux下,这些问题都不见了,或者说就没存在过。因为Linux下有一个很好的国际化/本地化工具:GNU Gettext。它将翻译抽象成了pot(模板)-po(翻译文件)-mo(软件使用的二进制文件)的体系。软件字符串资源的更新,可以自动更新到pot文件中,然后翻译人员可以用pot来更新他们的po文件,翻译也只需要翻译po文件就好了。如果软件升级了,用pot更新一下po,原来的翻译都还在,有改动的字符串也会标记上原来的字符串作为参考,极大地减少了重复工作量。最后从po文件生成mo文件,随软件打包发布即可。由于有了gettext的存在,Linux下的软件大多会利用它进行本地化,也就是说,从一开始就已经准备将软件给本地化了的。而翻译人员,只要有po文件就可以了,管你软件是怎么用这些字符串的呢。翻译好了,提交给开发者,开发者高兴了:嘿,又有人给我翻译了,打包,好,又多支持一种语言。而对于用户来说,更是方便了:不需要下载什么汉化版——人家软件包里把汉化日化俄化全带齐了;不需要选择语言——gettext会根据系统的语言设定自动选择对应语言的翻译包。Windows下的问题这里一个都没有。

Linux和Windows下的这些差异表面上看起来是机制的差异,其实是两者的理念的差异。在Linux世界(应该说,Unix世界),社区协作是司空见惯了的,Linux的发展更是离不开社区,因此Linux下的软件很多都有着协同开发的传统,大型项目尤其如此。吸引了全世界的人员,自然会面对本地化的问题,因此本地化一开始就是很多软件考虑的选项(当然,很久很久以前不是这样)。协同开发,自然是连翻译也算上的,在Linux下软件受到别人贡献翻译和文档是很正常的事情,任何人都可以为自己喜欢的软件作出贡献。而Windows下的大多是专有软件,因此开发者不会首先想到服务非自己母语的用户,也不会期待有人免费给自己做翻译,而且自己做国际化支持也是一件挺麻烦的事情。也就是说,其实这是社区开发vs专有开发的问题,是自由软件vs专有软件的问题。

GNU Gettext已经做得很好了,但是launchpad又更上了一步:它把翻译的工作也彻底协同化了。没有launchpad之前,可以这样来翻译一个软件:从源码包里取出pot和po文件,更新对应语言的po文件,翻译后用email等方式提交给开发者。这是一个人的翻译,可能不同的版本贡献翻译的人不同,但是在翻译好提交给开发者并被开发者之前,其他人是看不到最新版本的。而在launchpad上,翻译是在网络完成,翻译者知道最新的翻译是什么,还有哪些没翻译。这样你一条,我一条,协同工作就变得能了。开发者要出新版本了,把launchpad上的翻译导出成po文件就OK了。代码中的字符串有更新,不必等到发布源码包,翻译者也不需要用svn什么的更新pot文件,直接把最新的pot上传,开发和翻译就可以同步进行了。不只是这一点,launchpad可以记录不同翻译者对同一字符串的翻译作为比较,更酷的是,它还可以用在launchpad上别的软件的相同字符串来作为建议,这进一步促进了协同工作——你的翻译不止用在一个软件上,还帮助了其他软件的翻译,毕竟很多基本的功能字符串(文件、打开、保存……)是一样的。

launchpad的这种方式,使得一个软件可以由多个人共同翻译,一个人也可以翻译多个软件。它为软件翻译提供了一个很好的统一平台。给OSD Lyrics翻译的几位外国友人可能并不是OSD Lyrics的用户,但是这并不妨碍他们翻译OSD Lyrics。还是那句话:你永远不知道什么时候会受到别人的帮助。

osd-lyrics Comments(1) 2009年8月05日 00:09

在Chromium for Linux里使用Flash

 早就知道Chromium支持Flash了,看到消息说要手工复制插件,觉得这方法不官方就没试(其实不就两句命令么-_-)。但是没了flash很麻烦啊,rss里的视频都看不了……今天终于想通了,还是方便第一。试了之后发现没用,about:plugins里说没开插件支持,看了about:linux-splash页后才发现要用--enable-plugins选项手工打开插件支持,因为还不够稳定。

于是在命令行下chromium-browser --enable-plugins打开插件支持,嗯,flash视频可以看了。打开about:plugins一看,吓了一跳,里面不只有flash的插件,还有淘宝等一系列插件。难道说FF里的插件Chomium都能用了?把之前ln过去的flash插件删了,重开,哈,flash还可以用。

于是一句话,不只是flash,只要是ff里装了的插件(不是扩展哟),在chromium里加上--enable-plugins都能用。哈哈

linux Comments(1) 2009年8月03日 02:56

从PPA安装OSD Lyrics

之前我自己给OSD Lyrics弄了个PPA源,始终感觉不够正式。今天在PPA上注册了一个OSD Lyrics团队账号,并为它申请了一个PPA源,打算用它来作为OSD Lyrics的正式PPA源。

要使用PPA源,首先编辑apt的source.list文件:

sudo gedit /etc/apt/sources.list

 可以把gedit换成自己喜欢的编辑器。

将OSD Lyrics的PPA源粘贴到文件最后。目前OSD Lyrics支持 Ubuntu 9.04 (Jaunty) 和 8.10 (Intrepid)。

Ubuntu 9.04:

deb http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu jaunty main

Ubuntu 8.10:

deb http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu intrepid main
deb-src http://ppa.launchpad.net/osd-lyrics/ppa/ubuntu intrepid main

然后添加密钥:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4865CF4F

更新后就可以安装了:

sudo apt-get update
sudo apt-get install osdlyrics

osd-lyrics Comments(8) 2009年7月30日 20:05

升级到了ibus1.2

 最近ibus老出问题,ppa源里又老不更新,忍无可忍到ibus的wiki页看了一下,发现ppa源又改了。ibus现在每个版本都分别弄了ppa源,而且一个版本对不同的ubuntu发行版都分别开了一个源。把版本分开还可以理解,把发行版也分开就没有必要了吧?毕竟PPA源是可以同时装着多个发行版的,难道只是为了不在版本号后缀加上发行版名称?

更新起来还算顺利,用新的PPA源替代旧的PPA源就行,新的PPA源是:

更新后anthy终于可以用了,虽然我不怎么需要输入日文。五笔可以切换繁简,不会把繁体简体混在一起,搞得每次都一不小心打个繁体字出来。有时候升级还是必要的,嗯。

 

linux Comments(1) 2009年7月30日 19:04