写在launchy3.0.3发布之后

维护launchy也有一段时间了,目前已经发了4个版本,整体功能也趋于稳定。在维护launchy的过程中有很多思考,今天集中写下来,算是里程碑样的记录。

代码迁移 - 3.0.0初版

从原始代码fork, 迁移到qt5,完成核心功能的编译。这是我做的第一步,是整个项目的起点,我开始慢慢阅读源码,不断了解各个模块的结构。

在这一阶段的目标是让launchy在qt5的基础上跑起来,主要涉及到qt4向qt5的移植,有些qt4函数在qt5变换了形式,不过整体上变化并不大。

在这阶段完成后,我发布了第一版程序3.0.0版,这一版程序有好多功能缺失,所有的插件都没有移植过来。

从一开始,我的想法就是避免使用boost库,一方面是由于boost库过于庞大,另一方面是C++11已经提供了很多boost中的特性。这使得launchy在迁移的过程可以摆脱boost的依赖。

第二版 - 3.0.1

在这个版本的开发过程中,我不断打磨代码风格和代码结构,不断将旧的功能一点点迁移过来。主要改动如下:

使用第三方的qt模块 singleapplication ,实现了程序的单例启动。能够在第二次launchy启动时向第一次启动的进程发送通知。在windows下使用了管道进行通信,在通信的时由于分两次进行数据发送,导致概率性数据发送失败。在对该第三方模块进行调试修改后,使其能够顺利完成IPC交互。

calcy的移植,原版calcy中使用了boost中的phinex作为数值运算库。我使用了另一个更轻量级的数值运算库exprtk进行了替代,因为exprtk是header only的。

在移植插件的过程中,我发现出现了代码重复编译的情况,也就是说插件和主界面公用的代码是在各自的模块中分别编译的。这就是代码结构设计问题,将公共代码提取出来,很明显是更好的选择。

第三版 - 3.0.2

这一版对calcy增加了额外的功能,这个主要是方便日常生活中的数值转换操作。verby插件也移植了过来,这个插件的功能还是比较实用的。

这一次发版让我意识到需要将额外的qt和vcredist文件一起打包。

第四版3.0.3

这一版主要是增加python插件功能,经过了不断的摸索,我终于将这个功能迁移过来了。原先的pylaunchy采用的是boost.python,还是老原因,我不想引入这样厚重的依赖,使用类似的pybind11完成了功能迁移。

在这个功能的移植过程中,我经历了很长一段时间迷茫期,因为之前没有做过C++和python的混合开发。我最终的方法是将目标拆分为多个小目标,这些小目标是相对容易实现的,通过一步步完成每个小目标,最终完成大目标。这样做让我有个相对较小的切入点,而且在完成小目标后,会形成一个具有激励作用的正反馈,不断推动我走下去。

另一个改动就是移植了tasky插件,这个插件使用了大量的windows系统函数。不过在我后来的使用经历来看,这个插件的使用率很低,因为windows的 ALT+TAB 已经够用了。

目前的想法

所以目前的状态是,我没有了改进的方向,不知道下一步该开发什么功能。有用户向我反应有关python包管理相关的问题,但是python embedded不支持pip,我又不喜欢使用安装版的python,因为这样会让软件的目录看起来很乱。再者python embedded也是官方推荐的集成方法,所以我有点不想对这块逻辑做出改动。

另外,我慢慢发现,在github上尝试维护这个项目的人有很多,但最后都没有坚持下来。另一个知名度比较高的类似产品wox也好久没有更新了。这也让我慢慢意识到作为个人开发者,热情会慢慢消退。这种开源软件的盈利模式也是值得探索的,从我现在的感受是,没有经济上的回报作为反馈,开发动力将会逐步减少。

在我维护的过程中,也会发现类似功能的软件,如keypiranha。keypiranha使用C++作为内核,使用python3作为作为它插件系统,它的插件模式很大程度上模仿了sublime text。

Comments

Comments powered by Disqus