我真是闲得蛋疼了,在后天就要考试的情况下还有工夫来做MOC支持。
如之前所说,MOC目前我还没有找到IPC的方法来获取信息,只能用命令行来获取。
而fork+管道+mocp本身的开销实在不小,在0.1秒间隔的频率下对CPU的占用比其他的播放器要高不少。不过话虽如此,还是能用的。
另外,在aqtccgh同学的帮助下,终于定位了会导致之前可以搜索却不能下载的原因所在。现在应该没有那么多失败的情况了吧。
关于网络不好时崩溃的问题,是因为DNS解析超时加上多线程而造成的一个bug,要留到放假再解决了,在此提供一个临时解决方案:
su echo 118.228.148.185 mp3.sogou.com >> /etc/hosts echo 125.39.78.33 www.qianqian.com >> /etc/hosts
于是下一个目标:Quod Libet
各位使用XMMS2的同学不用再寻问会不会支持了。
这两天搞定了XMMS2支持,同时搞定的还有关于Exaile的一个bug。如果使用Exaile有问题的话可以试着更新到SVN最新版。
不使用XMMS2的可以在configure时用--disable-xmms2屏蔽。
需要依赖xmms-client库(还好不需要xmms-client-glib),这个库在Ubuntu下的包名叫libxmmsclient-dev,Gentoo官方软件仓库没有xmms2,在gentoo-taiwan的overlay里有,安装xmms2后自动有这个包。另外这里也介绍了Gentoo下的另外两个xmms2 overlay,不过我没有测试。希望其他系统的同学能告诉我这个库对应的包名。
计划等到完成MOC支持再发布新版本,现在只能下载源代码或用SVN版本来编译。
=======================碎碎念的分割线=======================
之前在查阅MPRIS的资料的时候,发现它就是在XMMS2的wiki上的,于是一直以为,XMMS2是支持MPRIS的。然而各方面的证据无情地打破了我的乐观猜想。可以说,如果XMMS2支持MPRIS的话,它将是和Audacious、Amarok 2同一批被支持的播放器。
之后对于XMMS2这种C/S架构的播放器没有什么概念,第一次尝试使用可耻地失败,导致之后一直不愿去碰它。后来MPD也是因为不了解而没有去尝试。
直到之后看到一篇介绍MPD的文章,才对它有兴趣起来。之前挣扎了很久的依赖项问题也通过编译参数来解决了。libmpd很好用,半天就完成了对MPD的支持。
完成之后又想到了XMMS2,同样作为C/S架构的XMMS2的文档应该也差不到哪去。在官网上转了一圈之后收集到了不少资料,让我兴奋的是xmms-client的例子比libmpd还丰富。于是不禁在twitter上夸了夸XMMS2的文档化。
然而做起来了才发现xmms-client的设计和文档化实在是不如人意。xmms-client的设计不像xmms-client一样完全屏蔽了网络的操作概念,每个函数的返回值都是一个类似GValue的通用指针。说实话我对用C实现通用类型一直没什么好感,虽然对这个设计来说是必要的。且不论xmms-client这种设计的优劣,毕竟通用性高的结果必然会造成方便性降低,取决于设计者的权衡。但是让我不满的是,xmms-client的文档里,没有一个函数说明它返回的真正类型是什么,让人无法使用。好吧我可以猜测xmmsc_playback_playtime返回的是一个int,但是我如何可以猜到xmmsc_medialib_get_info返回的东西是什么?就算例子里有如何从里面得到title和artist,我又凭什么会猜测到音轨号是叫tracknr而不是track-number?xmms-client这样的文档简直是在对别人说“去看我们的例子,如果没有,那就去看代码吧”。好在有google codesearch,让我可以从前人的成果里找到这些函数的用法。另一个问题就是xmms-client居然没有一个可以简单判断连接有没有失效的方法,差点逼着我用上xmms-client-glib,而且这家伙还一点文档都没有。
抱怨了那么多,说点好的方面,XMMS2终于是又一个支持毫秒级的播放器了,内牛满面啊。我有个梦想,终有一天,能让我的elapse emulator彻底消失……
另外说说Exaile,出错的是一个十分……呃,怎么说呢……囧的地方。在获取歌曲信息的时候,如果其中某一项没有值,会返回一个错误而不是NULL或者空字符串。这里有点违反直觉,我之前是在出错时直接就判断为出错了(播放器可能关掉了嘛),结果导致Exaile在播放无歌手信息的文件时OSD Lyrics会重新检测播放器而不是搜索歌词。这个应该算是我测试不足导致的吧。
update: TualatriX同学已经接手了PPA源的维护工作,在此表示感谢
OSD Lyrics 功能更新了不少了,但是PPA源里的版本一直停留在10月的,原因我之前已经说了,因为我连不上launchpad的PPA ftp服务器,准确来说是在数据连接这一层失败,提示拒绝连接。
我不确定问题的原因在哪里,在另一所学校的sarlmolapple也无法连接,不知道是教育网把PPA墙了还是整个Chintranet把它给墙了。总之,我现在无法往PPA源上上传。
试过用GAppProxy来翻墙,然而很遗憾它不支持FTP代理。不要问我为什么没有买VPN之类的专业翻墙服务,每个人都有自己的难处。
因此,如果有人有launchpad账号,有维护PPA经验或者愿意学习,希望拉手OSD Lyrics的PPA源维护,请与我联系,邮箱是见侧边栏。不胜感激。
不断有人问能不能让OSD Lyrics支持MPD和MOC,之前计划是在寒假的时候进行支持。不过在前几天英语复习时稍微了解了一下MPD,对它的架构很感兴趣,正好昨天考完英语手痒痒了,于是今天就把它给干掉了。
为了支持MPD,使用了libmpd,因此又引入了一个依赖项。那些不使用MPD又有洁癖的同学,可以在configure时加上--disable-mpd选项去除对MPD的支持。
时间有限,还有下面几个问题没解决,待下一个版本处理:
===========================无聊的分隔线==============================
MPD果然和它的名字Media Player Daemon一样,是一个后台服务。它只负责播放音乐,其他的东西,什么界面啊,操作啊,管理啊,你们就自己写个客户端来搞定吧。MPD采用这样一种架构是对Unix“只做一件事,把它做好”的精神的贯彻。听说开发团队坚决把修改ID3tag之类的功能扔到一边,认为这并不是MPD的任务。
既然是个后台程序,那么必须要有强大的通信能力与前台进行交互。它在后台通过socket、TCP/IP来和客户端来通信,不得不说这是一种非常灵活的方式,理论上来说可以完全不依赖任何库就能与它交互——没有哪个操作系统是不支持socket、TCP/IP的。因为是用socket这种无语义的通信方式,MPD要自己定义一套协议,这套协议必须足够灵活、强大和易用。
虽然说可以直接用socket来和MPD进行交互,但是这样要自己解析它的协议,代码成本就高了。好在这么个强大的播放器一定有针对各种语言的通信库。对于C/C++来说就莫过于libmpd了。原本一直在犹豫要不要使用它,因为不想在OSD Lyrics里又添加一个新的依赖,最终的解决方法是加入了编译选项来屏蔽MPD支持,这样不使用MPD的人就不必安装这个库了。当然最好的解决方案是把对播放器的支持插件化,想用哪个播放器就装哪个插件,也许以后会采用这种架构吧,在这之前还有很多工作要做。
另外不得不说libmpd的接口定义得相当不错,使用起来很自然,而且和我自己给播放器支持所定义的接口大同小异。因此MPD的支持代码应该是最少的,如果不算上audacious等使用我自己的MPRIS库的那些播放器的话。
还要再抱怨一下,MPD提供的时间精度依然只到秒,关于这个我已经抱怨过好多次了。我就奇怪了,为什么这些播放器就不愿提供个毫秒级别的精度呢?大概是没考虑到会有OSD Lyrics这样一种应用吧。好在已经抽象出了模拟毫秒精度的方法。
===========================另一个分隔线===============================
为什么是MPD,而不是MOC?这完全取决于它们对开发者的友好程度。MPD本身就是要靠客户端来支持的,因此它先天就是对开发者友好的,有着良好定义的接口,以及详细的开发文档。而MOC,我不知道它是否有IPC接口,但是至少我无法在它的网站上找到对我有用的信息。在论坛上看到似乎它的MPRIS接口正在开发中,如果是这样,那么对它的支持就是易如反掌了——MPRIS支持早就已经到位了。
不止是一个播放器存在着MOC这样的问题。之前支持的好几个非MPRIS播放器没有一个能找到它们的DBUS协议文档的,最后逼得我去看代码。诚然,良好的代码是最好的文档,但是既然已经做好了DBUS接口,准备好了让第三方开发者使用,那么为什么不把它写出来,把为开发者们定义的接口告诉开发者呢?Songbird的MPRIS插件的DBUS名称我可以猜出来,Rhythmbox、Exaile和Banshee我可以从代码里看出来,但是每一次都浪费了很多无谓的时间来定位这些接口是在哪里定义和实现的。
反观MPD,整个查找文档的过程非常快乐。libmpd的文档还带有一个极具代表性的例子(当然这不是MPD的功劳)。实现起来所需要的时间远远小于我的预期。
说了那么多,其实我的OSD Lyrics也有几个模块可以分离出来作为一个库了,代码也需要有更多的文档注释。
MOC也是一定会支持的。不过如果被迫使用管道的话,我担心效率会怎样……
好久没更新blog了,不过OSD Lyrics的改进一直没停下来。
自上一篇blog之后,OSD Lyrics又有了以下改进:
接下来要做的有:
另外还有一个好消息和一个坏消息
好消息是,liangsuilong同学为OSD Lyrics提供了rpm源,现在用fedora的同学也可以直接从源里更新OSD Lyrics了:)
坏消息是,我从11月开始就连不上launch PPA的FTP了,也就是说,ubuntu的源无法更新了:(。暂时不知道是不是墙的问题,现在也没什么时间弄。
要期末了,估计进度又要慢下来了
Songbird本身似乎没有IPC支持,不过却有一个MPRIS扩展,因此理论上来说通过MPRIS来支持Songbird是很简单的,因为在实现Audacious和Amarok 2的支持的时候就已经把MPRIS支持模块提取出来了。事实上,Songbird的支持代码早就已经写好了(Audicaous的代码copy过来改个接口名就行,能不快吗),但是运行时却总是会出现段错误,因此一直没能实用。
因为之前同样是使用MPRIS协议的Audacious和Amarok2跑得很正常,以为是Songbird的MPRIS实现有问题导致的,昨天一查才发现我在获取歌曲信息时对音轨数据进行了不必要的内存释放。估计是Audacious和Amarok2都没有传递这个数据才幸免于难。
这样一来,OSD Lyrics又多了一个支持的播放器。想用Songbird的同学不要忘了安装MPRIS扩展。
好事成双,在OSD Lyrics有了自己的图标的同时,也有了RPM包。
说来惭愧,因为一直用着Ubuntu,所以只有条件给OSD Lyrics做deb包,其他的发行版只能通过编译源代码来安装。虽然说OSD Lyrics的依赖不多,但是源码安装毕竟是很多人不喜欢干的事。
OSD Lyrics 0.2发布后,Ray Chen同学提出了很多有益的建议,同时也提出找人为OSD Lyrics打个RPM包。今天liangsuilong提交了一个Issue,说RPM包已经打好了。打包的地址在http://liangsuilong.fedorapeople.org/osd-lyrics/,我把源码以外的四个包都上传到了网站上,方便下载。
另外某日在搜索的时候,发现原来已经有人给OSD Lyrics做了Arch Linux的Tarball了,而且还发现我手滑把版本号里的年份写成了2008,那时我才用Ubuntu不久,连GTK都不会呢-_-。
突然想我是不是应该加大宣传了。软件要做好是很重要,让有需要的人知道也是很重要的。ERS在《TAOUP》里说软件要常发布,不能总是想着万事俱备。同样地,我也不应该等着都完善了才让别人用吧,软件的完善是无止境的呀。
在OSD Lyrics刚推出的时候,系统托盘的图标是sarmolapple在实现时临时找的WMP图标,我就很不显眼地挂出了征集图标的启事。在推出0.2之后,觉得一个自由软件顶着WMP这专有软件的图标实在有伤风化,忍无可忍自己凑合了一个。
现在,OSD Lyrics终于有了正式的图标了!图标的设计者是easy同学,他今天(应该说是昨天)早上把他自己设计的图标发给了我,图标如下:
挺好看的吧?比我设计的强多了。而且还有它的含义:“图标的光碟和火焰组成了OSD三个字母,画笔代表歌词的自定义,
感谢easy同学,虽然他因为使用的是KDE而无法用这个软件,但依然热心地为它设计了图标。
虽然只是个小项目,但是OSD Lyrics依然得到了大家的帮助,这就是开发自由软件最大的动力吧。
由于有朋友要求,给OSD Lyrics添加了Exaile支持
在此不得不牢骚一下,Exaile设计的接口实在是太囧了,给出当前播放时间居然是用百分比来给出的,而且只精确到百分之一。这意味着在绝大多数歌曲中使用Exaile给出的时间换算后连1秒的精度都达不到,而OSD Lyrics需要的精度是0.1秒,不然卡拉OK效果会卡得厉害。
好在之前已经遇到了类似的问题,Amarok2和Rhythmbox给出时间的单位是秒(这里不得不说Amarok2,明明MPRIS协议规定精度是1毫秒的,结果这小子给出的毫秒时间后三位全是0-_-),于是用了系统时钟差来模拟毫秒数,但是多少是有些不准的,所以用这三个播放器可能有时会出现时间跳跃的现像,这已经是我能实现的极限了。
另外忍无可忍临时做了个图标。说实在的OSD Lyrics这么一个自由软件居然顶着专利软件WMP的图标,简直就是奇耻大辱。能力有限,图标肯定是不咋的,因此征集图标设计依然有效,有好的图标请发到我邮箱:tigersoldi[at]gmail.com
开学之后时间也少了,更新肯定不会太勤快,现在身上压着一大堆事情,完成设想中的功能不知道是要到猴年马月了。
另:salmorapple同学已经在着手开发0.3的一项重要功能了,嗯嗯
经过一个多月的开发,OSD Lyrics终于实现了多下载引擎支持,是时候发布0.2版了。
0.2版相较于0.1版有如下改动: