欢迎前往体验 rubick
刚开始设计插件管理的方式是将插件打包成 .zip
的压缩包,然后再将压缩包上传到 CDN
上,点击安装再 download
下来进行解压。但是这样有几个弊端
直到我看到 PicGo 作者关于 PicGo 插件设计思路的文章,我突然觉得基于 npm
的包管理方式不正是我想要的吗,既轻量有省了一笔服务器存储开销: PicGo 插件设计 但这其实也有另一个问题,因为是基于 npm
的管理模式,所以需要开发者提前安装 node
环境,才可以使用 npm
。但这在目前是可以接受的,因为 Rubick
的目前定位也是为开发者服务的开源工具箱。
当你点安装插件的时候,其实执行的就是 npm install xxx
.
Rubick
另一个最大的能力就是支持系统插件,有了系统插件,我们就可以不用受限于必须搜索使用插件了,只要 rubick
在运行,插件就在运行。这对于一些特殊的场景来说是非常有价值的事情,比如我要实现一个定时提醒喝水的插件,如果我退出了插件界面,可能就无法实现。但是要做成了系统插件,即使退出了插件,但rubick
依旧会在后台运行插件提供的hooks
。这个灵感也是来自于 PicGo
的插件生命周期设计。下面来演示系统插件:
有了系统插件,我们就可以实现 屏幕取色插件
、定时提醒插件
、超级面板插件
... 另外,由于 rubick
的系统插件是运行在 main
进程的,所以,我们可以通过系统插件做到更多的能力,比如把 rubick
就看出是 electron
的二次封装,不需要任何 electron
的构建打包,基于系统插件,我们可以实现另一个桌面端应用!
1
Rebron1900 2022-01-07 12:14:45 +08:00
希望尽快完善
|
2
junhao999 2022-01-08 11:15:47 +08:00 1
感觉有点像 utools
|
3
kerinlin 2022-01-11 11:20:51 +08:00
这不就是 utools 吗,不过 utools 没开源,这个开源了,还是可以的
|
4
muwoo OP @kerinlin 交互设计参考了 utools ,但整体的架构方案完全不一样哦,插件我们是基于 npm 的管理模式,所以自带支持内网部署,只需要将 npm 源改为自由的即可。
同时支持系统插件,这是 utools 做不到的。所以像超级面板、取色器等等功能都可以抽出插件来 |
5
hansonfang 2022-01-12 10:09:06 +08:00
正好我们想做个工具箱,感觉搞个插件就能直接用了
|
6
Yenben 2022-01-18 11:21:03 +08:00
给力😁
|
7
slime7 2022-02-15 15:28:09 +08:00
你把 npm 打包进应用里不就不用安装 node 环境就可以装插件了吗,electron 本身就包含了 node ,。看看 poi 的插件安装设计,直接把你执行`npm install xxx`的部分换成`path/to/npm/bin/npm-cli.js install xxx`就行了
|