Ubuntu 20.04 上 gnome-shell 的 UI javascript 文件在哪里？

Question

我在Debian网站上找到了gnome-shell UI js文件的源代码：

https://sources.debian.org/src/gnome-shell/3.38.2-1/js/ui/

然后我也在这里找到了这个答案，它指出这个路径/文件不久前就存在于Ubuntu中：

/usr/share/gnome-shell/js/ui/windowManager.js

js但是现在，我在 中没有看到子目录/usr/share/gnome-shell/。

我在整个/分区中搜索了“lightbox.js”和“windowManager.js”，但没有找到。

在哪里可以找到这些文件？如果我想更改其中某些硬编码变量的值，需要克服哪些障碍？

Answer 1

答案兼容：
Ubuntu 20.04.2
gnome-shell 版本：3.36.4
显示服务器：X.Org Server

重要的提示：

更改 gnome-shell 文件时犯的任何错误都可能导致图形会话陷入死锁。仅当您熟悉系统恢复的常用方法时才尝试此操作。

此外，执行此答案中的更改将需要额外的工作流程来谨慎处理 gnome-shell 更新，如下所述。

修改功能

在 Ubuntu 20.04 上，gnome-shell 的 javascript 文件通常打包在文件内：

/usr/lib/gnome-shell/libgnome-shell.so

要覆盖它们，需要提取主题文件的副本，并要求 Gnome 使用这些副本。

下面我提供了一个抽象的、与任务无关的演练。要查看针对特定实际任务的类似过程，请参阅此答案。

要修改的文件副本可以组织在任意位置，在本演练中我使用以下位置：

~/.this-custom-thing/

（出于安全考虑，我特意选择了这个令人讨厌的目录名称。按照本指南，您希望使用一个不那么令人讨厌的目录名称，该名称对于您的系统来说是唯一的。下面会详细介绍这一点。）

要启用此“自定义平台”，需要将以下行放入~/.profile：

/usr/lib/gnome-shell/libgnome-shell.so

要使其生效，必须注销并重新登录。

关于依赖关系的注释：

在我的机器上运行此过程之前，我已经libgtk-3-dev安装了该软件包。它用于开发/调试，就像资源覆盖功能似乎是如此。因此，现在我无法确定尊重G_RESOURCE_OVERLAYS环境变量是否取决于此包的存在......以防万一，准备好安装它。

设置主题文件：

libgnome-shell.so可以列出如下内容：

gresource list /usr/lib/gnome-shell/libgnome-shell.so

下一步是提取要修改的文件。让我们使用一个示例，其中该文件位于 gnome-shell 的ui/ 子目录中。

~/.this-custom-thing/

调整：

要查看自定义文件的调整效果，每次编辑后重新加载 gnome-shell 似乎是必要的。r通过“运行命令”对话框（由Alt+显示）发出命令可以快速完成此操作F2。

此时，您应该有一个工作覆盖，该覆盖在重新启动后仍然存在。

关于恢复的注意事项：

如果修改尝试出错，应该可以切换到虚拟控制台环境（例如使用++ Ctrl）AltF3。从那里，注释掉该G_RESOURCE_OVERLAYS行~/.profile并随后重新启动应该会解除覆盖，从而能够恢复系统。

关于系统安全的重要说明：

这些 javascript 文件是可执行文件，可以使用与 gnome-shell 匹配的权限执行。

然而，虽然这些文件位于用户的主目录中，但它们可能会因仅与用户匹配的权限而被更改。

这可能是一个安全问题。

因此，我强烈建议在功能调整成功完成后，

• 这些修改后的文件被移动到系统根目录（内部/）的某个位置，并且
• 它们在 中的引用~/.profile（以 开头的行中的最终值export G_RESOURCE_OVERLAYS="/org/gnome/shell=）将更新以反映它们在 中的新位置/。
  • 在那里，他们将享受标准的 Linux 政策，即只能使用 root 权限进行更改。

使用 G_RESOURCE_OVERLAYS 的注意事项

情况可能是，此功能主要旨在调试和开发，而不是永久使用。

系统的稳定性可能会受到影响：当我第一次启用此功能时，我发现我的声音设置出现了一些以前未经历过的奇怪现象，并且有些窗口闪烁。然而，重新启动了几次 gnome-shell 并重新启动（几次？）解决了这个问题，从第二天起我就没有遇到任何进一步的异常情况。

此外，在“日志”应用程序中，我可以看到使用 G_RESOURCE_OVERLAYS 的事件记录在“安全”部分中，因此值得考虑。

关于使用 G_RESOURCE_OVERLAYS 时接收系统更新：

以下部分完全是猜测，我无法确认其中任何内容是否有效；但考虑一下可能会有用：

如果 gnome-shell 收到更新，我发现自定义的 gnome-shell 文件可能会失去兼容性，甚至可能导致桌面崩溃。

我相信在这种情况下，可以暂停使用 G_RESOURCE_OVERLAYS 功能~/.profile（如恢复部分中所述），随后重复从新文件中提取主题文件libgnome-shell.so，并以兼容的方式重新应用修改。

如果更新导致此类不兼容事件，我推测在执行更新的配置阶段时已经存在涉及桌面崩溃的风险；我可以预见在这种情况下会对其他系统造成严重的附带损害。（我可能错了。）

尽管如此，出于这个原因，我会考虑让 gnome-shell 更新与其他更新分开安装，以便该事件不会干扰其他软件包的安装。

一层控制，以确保稳定性：

为了管理上述风险，可以将 gnome-shell 设置为holdstatus，这会阻止其更新安装，直到准备好处理它们为止。

该过程如下所示：

• 按住 gnome-shell：sudo apt-mark hold gnome-shell
• 平静地生活多久
• 当 gnome-shell 有可用更新时，它将显示在更新对话框中，但其复选框将被取消选中，因此不会安装
  • 人们应该能够继续这样，直到准备好执行更新
  • 准备更新时，请按照以下步骤进行操作
• 运行更新程序，并安装每个更新，除了 gnome-shell 的更新
  • 如有必要，请重新启动，然后再次运行更新程序，以确保除了 gnome-shell 之外，目前没有其他更新可用
• 禁用 G_RESOURCE_OVERLAYS~/.profile并重新启动 gnome-shell
  • 通过验证是否缺少 UI 自定义来确认 G_RESOURCE_OVERLAYS 确实未使用
• 取消 gnome-shell：sudo apt-mark unhold gnome-shell
• 运行更新程序并让 gnome-shell 这次更新
• 重新启用 G_RESOURCE_OVERLAYS~/.profile并重新启动 gnome-shell
  • 如有必要，处理任何不兼容的后果
    • 这可能涉及再次禁用 G_RESOURCE_OVERLAYS（如果需要，从虚拟控制台），并使用更新的、这次兼容的修改重新建立覆盖的文件
• 再次达到稳定状态后，再次将 gnome-shell 重新搁置
  • 当新的更新到达时重复上述过程

将修改后的文件编译回libgnome-shell.so

我认为，如果不是永久依赖资源覆盖功能，而是将修改后的文件编译回libgnome-shell.so（因为更新不会导致不兼容事件；相反，它只是libgnome-shell.so一次性重写），则可以避免更新的风险。 。

然而，不幸的是，这项任务似乎依赖于大量的 Gnome 和/或 Ubuntu 开发人员的专业知识；仅仅围绕代码编辑器的敏捷性似乎并不能解决问题。

编译器 glib-compile-resources 需要要编译的资源的 XML 格式列表，并且其输出无法轻松地重新附加到现有的 .so ELF 文件。

来源

据猜测，您缺少 gnome-shell 较低级别部分使用的 C 代码，该代码与 JavaScript 资源位于同一库中。

如果您通过从源代码（例如在 jhbuild 中）编译来获得 gnome-shell [...]

如果您从 Debian、Ubuntu [...] 等发行版获得了 gnome-shell，则需要将 JavaScript 更改作为对该发行版的 gnome-shell 软件包的本地更改进行应用，然后使用对版本号，然后安装新软件包。

来源

从源代码编译整个 gnome-shell 并不是一个小功能。事实上，它的影响是如此广泛，显然有很多事情可能会出错，以至于我个人认为它使选择的合理性受到质疑。

不过，如果您能分享在 Ubuntu 环境下成功编译 gnome-shell 的实际步骤，请提交答案。

参考文献/文献：

• 归功于超级用户问答
• Gnome 开发者参考
• Arch wiki 上的 Gnome 食谱