为什么全局菜单难以维护？

linux 中的全局菜单是从特定应用程序内部逻辑导出（与其他应用程序共享菜单结构），然后由外部应用程序使用（理解和显示）的菜单，例如可以是 linux 桌面。所以，这里要理解的一点是，它是特定应用程序（此应用程序的特定开发人员）导出菜单的任务，如果此任务没有以良好的方式完成，则无法在外部显示菜单为然后桌面中的全局菜单。

请理解，应用程序开发人员和桌面开发人员是不同的人，可能根本没有联系。如果您认为维护全局菜单是桌面开发人员的任务，我需要说的是，事实并非如此。桌面开发人员的任务是仅显示应用程序开发人员先前导出的菜单。导出菜单然后是应用程序开发人员的任务，就像有很多应用程序一样，有很多具有不同偏好的开发人员可以决定或不导出他的菜单。

要创建能够导出菜单的桌面应用程序，您首先需要在该应用程序中导出一个菜单。此外，菜单必须是通用菜单，因为导出操作要求菜单结构可以序列化（转换为可以以标准方式描述菜单结构的“文本”）。通常，导出现有菜单的所有这些任务都是该特定应用程序（例如 firefox）的开发人员的任务。因此，应用程序的开发人员可以决定不导出菜单、不导出菜单、不遵循菜单结构中的约定（这意味着不能序列化）、根本没有要导出的菜单等等...

总结目前很少有开发者，决定导出他们的菜单。许多人甚至决定不提供菜单或以无法序列化的方式制作菜单。因此，导出菜单的操作不是默认情况下发生的，那么问题出在哪里。

在某些时候，ubuntu 开发人员意识到特定应用程序开发人员通常不希望自己为他们制作的大多数应用程序导出菜单。这是一个大问题，因为没有该操作就没有任何全局菜单可以显示。尽管如此，当时大多数 linux 应用程序都遵循几个约定，例如，菜单栏的概念是一个标准功能，然后有可能破解应用程序并检测菜单栏的位置，然后尝试解析它并强制它导出为全局菜单。这正是 gnome 开发人员不希望 ubuntu 开发人员实现全局菜单的原因，因为他们所做的确实是 hack。

然而，不能在所有应用程序中进行相同的破解，因为应用程序内部并不真正相等。只有使用相同工具包（Gtk、Qt、Java Swing...）制作的应用程序才是真正被黑客入侵的对象。然后，ubuntu 开发人员为 Gtk2 应用程序创建了一个 hack，另一个用于 Gtk3 应用程序，另一个用于 Qt 应用程序，其他外部开发人员为 Java Swing 创建了一个。但并非所有应用程序都是通过标准工具包方式制作的，因此，某些应用程序可以决定覆盖其菜单的工作方式，在这种情况下，将无法导出非标准菜单。比如mozilla产品没有使用标准的gtk工具包，而是修改了工具包，然后他的菜单就不能以同样的方式导出。

更复杂的是，GNOME 开发人员决定不再在他的应用程序中使用菜单栏，并促进所有 Gtk 开发人员实施该想法。当然，这与拥有全局菜单所需的方向背道而驰，因此除了现在 Gtk4 已发布并且此版本的工具包目前还没有破解之外，这使事情变得更加复杂。此外，GNOME 开发人员决定删除 ubuntu 开发人员用来创建他的 gtk hack 的功能，因此现在需要另一种机制来破解 Gtk4 应用程序。

更复杂的是，所有应用程序都在不断地改变他的内部实现，所以今天运行的一个应用程序不可能在第二天运行。工具包也是如此（请记住，hack 依赖于工具包），因为工具包在不断变化。

因此，维护全局菜单涉及同时维护许多应用程序和工具包的 hack。我认为我不需要解释 hack somenting 是多么复杂，以及对可以不断变化的东西进行 hack 是多么复杂。这就像只制造一种疫苗对几种不断变异的病毒有效。