开源开发人员罗曼·吉尔格，他因在KWinFT在ITS之前更名为特修斯的船今天有一些更重要的消息要通过Phoronix分享。以下是他的嘉宾帖子宣布合成器模块。
上周Phoronix报告说，KWinFT被更名为特修斯的船，但也意味着很快就会有“更大的事情”可以谈论。
现在是时候了。我很高兴在Phoronix上独家宣布 合成器模块-或短科莫，C++库集合，可以轻松编写Wayland和X11合成器。
第一个版本现已推出关于GitHub.让我带你参观一下这个图书馆。我相信这个图书馆将填补Wayland生态系统中的一个巨大空白。
像X11 One一样编写Wayland Compositor
让我们面对它：构建一个Wayland排序器很难做到好了！
尤其是如果您只想实现一些定制的窗口逻辑。
除其他事项外，您还需要：
- 通过一些图形API和DRM渲染堆栈
- 通过libinput输入堆栈
- 通过DRM进行显示管理
- 在客户端之间进行拖放调解
- 提升操作(如屏幕截图)的逻辑
- 最有可能的是Xway land内部的一个完整的X11窗口管理器。
相比之下，编写X11窗口管理器要容易得多！
您不需要执行任何这些操作，因为XServer已经为您执行了这些操作。
但另一方面，对于Wayland，我们现在肯定不想要的是一个像XServer那样的巨大怪物。显而易见的解决方案是构建支持库，以链接并简化合成器的创建。
对于这一点，已经有一些选择：
- Wlroots
- 利布韦斯顿
- 米尔
- Qt Wayland合成器
- 卢浮宫(新)
我相信，尽管合成器模块更适合于轻松开发功能丰富的Wayland合成器，但基于两个简单的原因，它比任何现有的合成器都更适合。第一个问题是，要编写自己的Wayland合成器，只需要三行CMake代码和下面的主函数：
int main（int arc，char* argv[]）
{
使用命名空间como;
base：：wayland：：app_singleton app（argc，argv）;
使用base_t = base：：wayland：：platform;
base_t base（{.config = base：：config（KConfig：：OpenFlag：：FullConfig，“kwinft-minimalrc”）}）;
mysql.mod.render = std：：make_unique base_t：：render_t（base）;
base.mod.input = std：：make_unique base_t：：input_t（base，input：：config（KConfig：：NoGlobals））;
base.mod.space = std：：make_unique base_t：：space_t（*base.mod.render，*base.mod.input）;
return base：：wayland：：exec（base，app）;
}
正如我们的MVP所展示的那样米尼科。
第二个原因是Composator模块在功能丰富的桌面会话和最小的嵌入式用例中同样有用。让我再详述一下这一点。
来自大桌面
虽然合成器模块在后端使用wlroot，但它们的Wayland协议端并不基于wlroot， 缠绕。这是因为合成器模块应该支持为KDE等离子桌面构建一个全功能的合成器，正如特修斯所展示的那样。
Wlroots并不支持所需的所有协议。它也没有提供与KDE桌面服务的所有集成，它的规则和脚本API，它的配置系统，以及最后但同样重要的是，当在KDE桌面中运行时，传统应用程序所期望的广泛的X11窗口管理器功能集。
KDE等离子体在功能方面处于领先地位。
必须对其他竞争者说类似的话。虽然libweston、Mir和Qt Wayland Composator一直主要是为最小的嵌入式用例而开发的，但经过深思熟虑，其中一些已经在受限的桌面用例中变得某种程度上可用，但Louve作为一种较新的选项似乎并没有受到这种偏见的限制。但这是一个新的项目，将它现在提供的小功能扩展到像KDE桌面环境这样的大型环境及其所有的怪癖和功能几乎是不可能的。
另一方面，合成器模块是从KWinFT分离出来的，KWinFT一直是Kwin的一个分支。通过这个祖先，它们保持了与大型KDE等离子桌面相同的非凡级别的功能和集成，就像当前的标准KDE合成器一样。如果你正在寻找一种完全开箱即用的桌面体验，而不是妥协和修修补补，我相信Wayland库可能提供的服务也不会少。
到小内嵌
“大桌面”是一个极端，但合成器模块的构建涵盖了Wayland合成器的整个应用范围，从KDE等大型桌面到LXQt等小型桌面再到嵌入式应用。
嵌入式用例是Wayland作为一项技术的一个重要领域。就商业潜力而言，这可能是与旧的X Window系统最重要的区别因素，显然，Wayland的一些设计决策也受到了它的影响。
嵌入式是一个广泛的领域，但通常显示要求没有桌面那么复杂。
因此，也难怪在上面列出的五个库竞争者中，所有三个商业支持的库都非常专注于嵌入式应用程序。
当然，他们在这个特定领域提供的是有效的，但我仍然相信合成器模块将是一个更好的解决方案，因为它们基于wlroots，并与桌面合成器共享其核心。第二点意味着您可以在桌面上对这个核心进行压力测试，并将您的经验和开发人员设置直接转移到嵌入式。
梅赛德斯-奔驰集团的子公司MBition公司所做的实验表明，这不是一个空洞的要求。试着在新款梅赛德斯上使用Kwin。
这是一个很好的实验，它表明在这种情况下使用更大的合成器是有动机的，但是用标准的KDE合成器来实现这一点将是困难的，因为KWin从来没有为这种用例而构建，它的整体性质强加于桌面用例。
我花了大量的工作来确保Composator模块是相反的：模块化并对任何用例从大到小都是开放的。
让我们来看看使这成为可能的一些技术设计决策。
通过C++模板实现模块化
如果你给一个C++程序员看一个来自KWin的源代码文件和一个来自The Compositor Modules的源代码文件，几秒钟后他会发现最明显的区别可能是The Compositor Modules中大量使用了泛型编程。
事实上，我将尽可能多的逻辑转移到了编译时间上，这不仅是因为它使运行时更快、代码更安全，而且还因为它允许我们在依赖项和消费者定制选项方面完全模块化库结构。
先进的C++技术允许Wayland和X11代码之间的无缝集成。
我们来看第一个方面。您可以构建一个没有任何X11依赖的Wayland合成器，只需 * 不 * 链接到单独的 科莫：：xway land图书馆。在内部，这是由几个类模板实现的，例如，所有窗口的空间被模板化到一个`std：：ariant`窗口类型上。
如果您不需要Xway land，那么您可以只使用空间而不
X11窗口类型变体。这一切都是在编译时完成的，利用了C++类型系统的所有安全保证，并且不使用宏。
作为比较，上周对不依赖libxcb的构建的支持也合并到了Kwin中。但由于Kwin的单体建筑，这需要大量宏用法。
让我们看一下第二个方面，即定制选项。当你用合成器模块构建一个Wayland合成器时，你有无限的选择来定制你的合成器，要么通过虚拟继承的子类型，要么甚至用你自己的定制类型完全替换类型。
正如所说的，一切都是模板化的，所以你可以引入你自己的空间来拥有不同的定位窗口的逻辑，或者你提供一个不同的免费功能只是为了改变它的一个方面。
合成器模块的代码进行了大量重构，将逻辑从数据中分离出来。这允许对帮助器函数进行此类特定类型的重写。
或者，通过限制您编译的内容，从您的定制开始。例如，上述MiniCo的代码省略了添加一个脚本 田间到 Base.mod 这是忒修斯的船在另一边 会吗？。省略添加此字段意味着省略编译整个脚本模块。通过这种方式，我们以一种简单的声明方式描述了我们的合成器将提供什么功能，以及它不会提供什么功能。
通过现代CMake实现模块化
通过模板实现模块化是一回事。但是，由于我们提供了一个图书馆藏书，模块化的目标需要通过使用现代CMake技术来支持。
在过去的一年里，我做了大量的工作，不仅模块化了代码，而且模块化了代码背后的库结构。我通过持续使用现代CMake技术和细致地展开内部和外部依赖关系来实现这一点。最后，韦兰的排序器出现了以下关系层次：
根据这个图，可以很容易地看到哪些库模块相互依赖。CMake代码直接记录并确保这一点。
通过使用现代基于目标的CMake代码，即使是一个错误的头Include也会直接暴露出来。例如，在*INPUT*模块内使用任何*RENDER*类型是不可能的，因为INPUT模块只链接到*WIN*模块。
对于合成器模块的未来开发，这些依赖关系使跟踪错误和确定特性范围变得更容易。对于编写器模块的消费者来说，依赖关系提供了一个合理的结构，以此作为他们关于库功能及其定制的假设的基础。
高代码质量和自动化
当提供像合成器模块这样的库时，在代码安全性和正确性方面满足现代标准是很重要的。
这从一开始就是一个目标，现在每个代码更改都在CI中编译，所有编译器警告都作为错误启用。我们与GCC和Clang并行执行此操作。
此外，在拉入请求时，必须通过当前超过100个活动测试的测试套件。这样可以确保主分支始终是“绿色的”，这是无回归代码的一个重要标准。
对合成器模块的Pull请求执行的GitHub操作。
当然，这并不是说不可能出现错误，但从长远来看，这是增加稳定性的重要机制。多年来，代码库发生了如此大的根本性变化，同时有可能保持整体功能，并在很大程度上保持在Kwin和其他KDE组件的变化之上，这证明了这一点。
下一步：更多功能
随着合成器模块的发布，困难的部分现在已经完成了。具有必要抽象的底层整体库结构已经建立。
现在可以将重点转移到稳定和更多的特色工作上。虽然合成器模块已经提供了大量的功能集，但仍缺少一些重要的功能，如Wayland要素表。
其中一些功能可能可以直接移植，或者至少部分来自Kwin，后者在过去几年接受了大量外部资金来增加功能。好消息是，在已经有参考实现可用的情况下，实现新功能相对简单。
其他功能将需要更多地与wlroots集成，这是我所期待的，因为wlroots是一个伟大的项目，更严重地依赖它推动Wayland生态系统中更大的统一和代码重用。
下一步：更多消费者
当然，合成器模块的第一版仍然是一个不稳定的版本。稳定局势需要时间。但我仍然相信，既然现在所有的大重构都已经完成，总体结构已经建立，现在是基于合成器模块的试验性合成器项目的好时机。
合成器模块应该非常适合LXQt、XFCE或Cinnamon这样的台式机，这些台式机需要Wayland上定制的合成解决方案。一个解决方案一方面足够开放，以适应他们的需求，另一方面提供足够的开箱即用功能，不会让他们的贡献者资源变得过于紧张。
目前，我正在考虑使用LXQt的合成器模块构建这样一个解决方案。LXQt对我来说是一个有趣的项目，因为它是一个完整的桌面解决方案，类似于KDE等离子体，但具有不那么广泛的功能集。因此，LXQt的合成器将展示如何在使用合成器模块时有目的和有选择地缩减功能。
下一步：提供更多资金
让我们现实一点：没有公司的资金支持，像合成器模块这样的大项目不可能以一种持续的方式长期维护。
在过去的两年里，我在作为自由职业者的同时，利用我的空闲时间参与了这个项目。我能够承受这种工作量，但您不可能永远这样做，也不能指望每个希望为项目提供几行以上代码的贡献者都能做到这一点。这确实适用于合成器模块，就像它对Kwin这样的其他大型项目所做的那样。
但合成器模块现在为构建Wayland合成器提供了一个很好的基础，适用于所有类型的应用程序，从不同风格的Linux桌面到嵌入式产品。
我希望有一些公司愿意为Wayland库的创建提供资金支持，比如Composator模块。这个库不仅仅是为了解决公司自己的特定当前用例，无论是使用MinCo这样的最小解决方案，还是使用定制类型或像Theseus的Ship这样具有最大功能集的解决方案。而是一个图书馆，这会让所有的船都涨潮。
关于作者：罗曼·吉尔格是一位软件架构师，他对许多开放源码项目做出了显著贡献。他还在复杂系统方面做过行业工作，最常见的是利用C++。此外，他还是一名经验丰富的平台工程师和项目经理。在那一刻，他带头WinFT项目宣布的目标是为Linux桌面和嵌入式提供通用的显示解决方案。他可以通过推特 或 LinkedIn。
