三翻领的个人空间

今天在ubuntu的中文论坛上看到一篇帖子，《关于歌词显示的一点建议，请拍砖》，这个正好符合我的专长，因此很有兴趣，等在电脑前，看看回复中能不能被提及lrcShow-X，呵呵。

当然，事实上我也同时在考虑lz的一些建议，毕竟，现状的确是众多歌词软件如雨后春笋般涌现，那么是不是存在“资源浪费”，或者组建团队提高开发质量问题等。

先谈谈关于歌词软件的发展。这里除去非lrc歌词显示，那么总的来说，此领域最早，也是最有名的应该是小锁开发的xlyrics，虽然我未曾用过，但是的确是开山之作，就算是现在也有不少用户在使用。据我所知，小锁已经放弃该项目很久了，期间zhllg曾经修改过一个版本。lrcShow-II（lrcShow-X的前身，amarok脚本，已停止开发）最初是在2006年末开始启动。当时来说，卡在这个领域软件的最大瓶颈是“滚动”问题，当初lrcShow-II在最开始的时候，还是跳动的，而且歌词居中部分的代码相当繁琐和复杂。试想，某位大牛在googlecode上发布了其hack的TTPlayer歌词搜索模块，而仅仅为rhythmbox写了一个平板歌词的显示插件，可见当初动态问题是比较棘手的。

这里暂时不提xlyrics，就当前活跃的歌词软件中，真正实现滚动效果的，应该是和lrcShow-II几乎同时代发布的lyricszilla这款软件。为此我还专门下载源码研究其动态滚动的实现方法，可惜我是很不善于阅读其他人的代码，最后什么也没学到。最后到0.3.1版本，又是通过一个及其繁琐的方法，将跳跃的过程分块实现，才形成了早期的”平滑滚动“效果，只能算是应景，差强人意。

当lyricszilla成为模板，最后的瓶颈被突破后，linux下的歌词软件出现了新的生机，当前比较有名的Showlyrics应运而生。之后，一个非常有意思的情况出现了，那就是osd的大行其道。我最早发现的将歌词使用osd形式显示出来的一款软件是Lyricod（实话实说，这款软件低调的很，若不是在googlecode主页上提及了lrcShow-II，根本就没法找到），这里用到了一个pyosd模块，推测这个模块比较低级，应该是基于x的。而后，gnome－osd被很多同类软件使用到。这里需要说明的一点是，如果一款歌词软件仅仅用到osd作为其歌词承载方式的话，那么歌词软件的开发将大大简化，简而言之，就是获取播放器时间点后搜索下lrc文件，将搜索到的当前行歌词直接set到现成的osd窗口中即可，这个和在shell下调用kdialog几乎没什么区别。加之由之前的一些软件积累起来的一些模块和库类，歌词软件又迎来一个创作高潮，时至今日。

目前，这些软件都同样是单人单任务模式，而且虽然数量多，但是的确也有很多不同。就像那篇帖子讲到的，脚本的也有，窗口式的也有，纯osd的也有，bash开发的也有，c开发的也有，等等因此我个人认为，合并这些开发力量并不一定是个好事，毕竟还是有很多的不同，而且将他们的特性集中到一款软件上，也非易事。我个人觉得，这里应该不存在一个开发资源浪费的问题，因为从逻辑上倒着讲。不会有人因为我不开发这款软件而感谢我节约资源。

组团队是个不错的建议，不过能够找到开发方向一致、开发力量相仿、开发步调统一的组合，还是非常不好找的。一般来讲，开源的合作方式，往往都是合作者中途加入的（又往往是在关键方向上的分歧而又分道扬镳，这样的例子太多了），说到lrcShow-II（lrcShow-X）上，也是一样的，中途有意大利朋友突然问我，是不是有兴趣加入一些其他的歌词搜索殷勤，我说可以啊，于是乎，他就提供了mini的服务器hack流程。加入该搜索引擎后，大家都一致认为当前的多搜索引擎架构比较生涩，于是互相讨论改进问题，再慢慢的，就开始融入到开发中了，成为lrcShow-II（X）的开发伙伴。我认为这种效果是比较好的，也比较符合开源协作的一般流程。而往往生硬的拼凑倒反而不妥。

最后，那个帖子还是提到了lrcShow-X，比较开心，毕竟ubuntu的论坛，qt软件是小众，关注度是很可怜的。意外的是，论坛上的朋友通过使用，使我发现了最新版本中一个比较冒进的地方，会导致第于qt-4.5.0的用户发生错误，于是花了一个小时时间修复，并紧急发布了1.3.1版本。在此表示感谢。

以上仅为一家之言，如有不妥，也接受拍砖。