如果使用HVML开发并打包桌面应用程序，那么形式是什么？

[Tryanks]

像Electron那样将整个Webkit扩展内核xGUI Pro打包进应用程序吗？是否有可能会出现和Electron同样的问题：过于臃肿呢？
我能理解的是，Hybrid可以内置解析器和渲染器，并将HVML作为系统级接口。如此一来，在其中的应用程序可以只保留HVML代码本身，而共享相同的runtime库。
但如果在合璧系统之外的通用操作系统，有哪些方案呢？未来是否有考虑实现？

[taotieren]

这种要看打包的 xguipro 是否代 electron 相关的文件，如果带的话就是很臃肿。
如果是依赖系统的 electron 文件，就会很简洁。可以参考 Arch Wiki 的 Electron 打包规范

[kenlsoft]

我的理解是：

• 在合璧上，PurC 就是主要的界面程序的虚拟机，xGUIPro作为系统UI服务。应用程序是.hvml文件和.html .css 以及相关的图片等媒体文件的封包。
• 在其他操作系统上类似，需要提前安装HVML虚拟机，xGUIPro安装为系统服务，使用操作系统的界面系统作为显示基础。

[VincentWei]

如 @kenlsoft 所言，在 Linux 桌面上，可以将 xGUI Pro 及其依赖的 webkit-gtk 包作为独立的软件包安装，设定好依赖关系即可。但在其他操作系统上，如果是针对开发者的，也可以借助 Brew 或者 MSYS2 这样的软件包分发机制，但如果是针对最终用户的，将解释器、渲染器和应用本身的代码打包成单个可安装的可执行程序可能更好。

至于题主提到的“又如 Electron 般臃肿"的问题，有两点需要说明：

1. HVML 的解释器和渲染器分离设计，可以允许我们通过开发定制的渲染器来减小整个软件包的体积，同时提高渲染性能。比如，我们一方面可以使用 CSS 的布局和样式，但针对复杂的交互需求，可以通过插件使用系统构件来实现。
2. 我们所指臃肿，主要指的是架构上的臃肿， 当然体积是一部分。PurC 提供了多种解释器和渲染器的通讯方式：xGUI Pro 使用的是渲染器作为服务器的架构，而 purc 命令行中的 Foil 渲染器使用的是多线程架构。后一种情况，Foil 渲染器和解释器同属一个进程，但运行在单独的线程中，此时，解释器和渲染器共享某些数据，且通讯速度极快。