CI010

After the #1338 is checked in, I've try to integrate the npm package with custom dispatcher/handler to implement cache. Currently, I think we still have a gap to implement cache...

> The response type of `dispatch` is correct: no error or promises should be propagated. Yes, that's what I mean. Currently, we can only have a `boolean` return type for...

> That isn't true. dispatch is async. It just isn't async over Promise. dispatch uses old school callbacks. > […](#) > On Sun, 18 Sept 2022 at 23:36, CI010 ***@***.***>...

I'll take a look this week. It might be the normal network issue, but I still need to take a look about how to avoid the download fail like this

Good idea. I'll take a look this week.

Now the CI for winget is general available, and the xmcl is on winget registry. I think we can close this issue now.

 You can click this chip to goto version setting page. Or you can goto setting page and click selected version   In version setting, you can select (or...

首先我觉得xmcl和其他几个启动器的定位是不一样的，xmcl最初定位是为了方便用户管理大量 Mod，资源包等资源，并用其制作整合包等。 相关功能相对与其他启动器来说比较重，选择electron也是在以下几个方面取舍 1. 开发+迭代各种UI速度（以及UI的美观程度） 2. 产品自定义的能力（设计耦合等） 3. 跨平台的难易程度 native 虽然可以做到内存优化，但跨平台以及迭代速度并没有 web 这套方便，需要我花更多的 effort。 electron 较为平衡的满足了我的需求。xmcl追求功能的多样性（以及易于拓展），对软件大小（你看我这启动器安装包大小），内存使用（内存就和你的截图一样）是进行了取舍的。 当然，启动器是会优化内存的（也许专门出一个低内存模式，当然牺牲的肯定是速度，毕竟数据在内存里就不用去磁盘里读取）。 不过我觉得200mb实在不是很多的内存。。。你装个100个mod，然后在mod管理页管理的情况，xmcl会占用更多内存，因为这是必要的……如果这种情况下发现内存非常不理想，或者卡顿，我想这才是xmcl应该专门优化的情况。 所以我觉得因为针对的场景不同，用xmcl和其他三个比较是不合适的，我觉得比较合适的对比对象是 curseforge 的启动器，multimc 启动器，ftb 启动器，甚至一些国内称为“盒子”的东西（虽然我没用过任何盒子，但我听说盒子的功能还蛮多的） 目前可能优化的点 - [ ] 换 vue 3...

> 但是目前xmcl有的下载curseforge导出整合包等功能，我记得hmcl和pcl也拥有。 导出的功能当然有，但是查看每个mod的metadata，根据mod id自动分类，自己打tag整理mod等资源，根据tag搜索这些就没有啊 现在主要的 overhead 上面的回复也说了，一个是electron本身比较激进的内存管理，另一个使用vue/vuetify UI 的内存 overhead。当然还有现在装的 mod 啥的 metadata，都会加载在内存里。当然这些以后可以lazy load……不过可能提升不大，以后有兴趣再改成lazy load吧

> 然后使用方面也有一点不明确，有一些功能不知如何使用。有考虑开一个wiki或者docs吗？ 非常考虑，打算放在 xmcl-page ，也就是官网的网页里，但一直没有什么时间做【