基于|基于 Electron 的 Rubick 2.4k star 啦,同步更新新功能!
为什么要做 Rubick
其实做 Rubick 1.x
的初衷就是解决自己的问题的:特别需要一款支持自定义插件的桌面端应用来简化使用者安装庞大桌面端应用的臃肿。而且涉及到数据安全的问题,插件只能在公司内网贡献,无法对外公开。
在 Rubick 2.0
的阶段,重新设计了一套基于 npm
的插件管理体系,让开发者更加便利的加入插件的开发。拓展了插件的边界和种类,开发者可以开发 Rubick
系统插件,此时的 Rubick
就成了一个 electron
高级封装,开发者可以高自由的实现系统能力而不局限余 openAPI
也不局限于必须搜索呼起使用,只要 Rubick
在运行,插件就在运行。
Rubick 的自我介绍
Rubick
是基于 electron
的开源工具箱,基于 npm
插件管理的方式自由集成丰富插件。Rubick(拉比克)
出处是 dota
里面的英雄之一,其核心技能是插件化使用其他英雄的技能,用完即走。非常符合本工具的设计理念,所以取名 Rubick
。
核心技能展示
1. 基于 npm 的方式管理插件
刚开始设计插件管理的方式是将插件打包成 .zip
的压缩包,然后再将压缩包上传到 CDN
上,点击安装再 download
下来进行解压。但是这样有几个弊端
- 需要一个数据存储服务器,来存储这些压缩包文件,那么这需要一笔费用,这对于一个开源开发者来说很难维持下去。
- 打包机制和解压机制繁琐,对开发者不友好
npm
的包管理方式不正是我想要的吗,既轻量有省了一笔服务器存储开销: PicGo 插件设计 但这其实也有另一个问题,因为是基于 npm
的管理模式,所以需要开发者提前安装 node
环境,才可以使用 npm
。但这在目前是可以接受的,因为 Rubick
的目前定位也是为开发者服务的开源工具箱。当你点安装插件的时候,其实执行的就是
npm install xxx
.2. 系统插件能力
Rubick
另一个最大的能力就是支持系统插件,有了系统插件,我们就可以不用受限于必须搜索使用插件了,只要 rubick
在运行,插件就在运行。这对于一些特殊的场景来说是非常有价值的事情,比如我要实现一个定时提醒喝水的插件,如果我退出了插件界面,可能就无法实现。但是要做成了系统插件,即使退出了插件,但rubick
依旧会在后台运行插件提供的hooks
。这个灵感也是来自于 PicGo
的插件生命周期设计。下面来演示系统插件:有了系统插件,我们就可以实现
屏幕取色插件
、定时提醒插件
、超级面板插件
... 另外,由于 rubick
的系统插件是运行在 main
进程的,所以,我们可以通过系统插件做到更多的能力,比如把 rubick
就看出是 electron
的二次封装,不需要任何 electron
的构建打包,基于系统插件,我们可以实现另一个桌面端应用!最后 做开源最大的动力是因为热爱,完全是非盈利的,希望做的东西能给需要的小伙伴提供一些帮助和方向,程序员都是最单纯可爱的,希望不要恶意攻击打破程开源动力最后一份热衷。
另附:
rubick github 仓库
【基于|基于 Electron 的 Rubick 2.4k star 啦,同步更新新功能!】rubick 使用文档
推荐阅读
- 热闹中的孤独
- JAVA(抽象类与接口的区别&重载与重写&内存泄漏)
- 放屁有这三个特征的,请注意啦!这说明你的身体毒素太多
- 一个人的旅行,三亚
- 布丽吉特,人生绝对的赢家
- 慢慢的美丽
- 尽力
- 一个小故事,我的思考。
- 家乡的那条小河
- 《真与假的困惑》???|《真与假的困惑》??? ——致良知是一种伟大的力量