☰

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

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

我在 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”，但没有找到。

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

答案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：

export G_RESOURCE_OVERLAYS="/org/gnome/shell=$HOME/.this-custom-thing"

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

关于依赖关系的说明：

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

设置主题文件：

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

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

下一步是提取要修改的文件。我们以该文件位于 gnome-shell 的ui/ 子目录中为例。

mkdir ~/.this-custom-thing/ui

gresource extract /usr/lib/gnome-shell/libgnome-shell.so \
/org/gnome/shell/ui/fileName.js > ~/.this-custom-thing/ui/fileName.js

调整：

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

此时您应该有一个可以在重启后继续起作用的覆盖。

恢复注意事项：

如果修改尝试出错，应该可以切换到虚拟控制台环境（例如Ctrl++Alt​F3）。从那里，注释掉该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状态hold​，这会阻止安装更新，直到有人准备好处理它们。

该过程如下所示：

  • 保持 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 资源位于同一个库中。

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

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

来源

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

尽管如此，如果您可以分享在 Ubuntu 环境中成功编译 gnome-shell 的实际步骤，请提交答案。

参考文献/文献：

答案2

我想分享我发现的另一种方法。

我无法让它正常工作，而且它使系统的行为变得更加奇怪。

我分享它只是为了让那些觉得自己技能娴熟、经验丰富的人能够尝试并在此基础上继续发展，直到它成为一种真正可用的替代方案。

与此同时，可用的答案仍然是我的其他答案到这个帖子。

以下方法的来源：

这种方法会提取所有 gnome-shell 的 javascript 文件（而不是仅提取特定文件进行修改），并根据libgnome-shell.so二进制文件中定义的原始排列方式，将它们排列在复杂的目录布局中。

针对 gnome-shell 3.36 的更新脚本，实际上在 Ubuntu 20.04 上运行：

#! /bin/bash

# Extracts contents of libgnome-shell.so
# Compatible with gnome-shell v 3.36
# https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/gnome-3-36/js

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

echo '--> Creating custom shell directory'
mkdir $HOME/.gnome-shell-custom

cd $HOME/.gnome-shell-custom

echo '--> Preparing custom shell internal directory layout'
mkdir -p \
dbusServices/extensions/css \
dbusServices/extensions/ui \
dbusServices/notifications \
gdm \
misc \
perf \
portalHelper \
ui/components \
ui/status

echo '--> Extracting resources'
for r in `gresource list $gs`; do
    echo $r
    gresource extract $gs $r > ${r#\/org\/gnome\/shell/}
done

运行上述脚本后，以下命令可以启用它：

# Either
GNOME_SHELL_JS=$HOME/.gnome-shell-custom gnome-shell

# Or
GNOME_SHELL_JS=$HOME/.gnome-shell-custom gnome-shell --replace

此行可以在终端中执行，也可以~/.profile按原样附加到的末尾。

根据我的观察，当放置在 中时~/.profile，这两条线（无论是否--replace带有选项）似乎都会产生类似的效果。

结果：

这将导致出厂默认的 gnome shell，

  • 使用 Adwaita 主题（以蓝色为主色，而不是 Ubuntu 橙色），
  • 使用 Yaru 图标集，
  • 其中字体很奇怪，
  • 其中所有扩展均被禁用（并且可能未找到），
  • 自定义 gnome-shell 主题不生效，
  • 其中出现码头仅有的以及活动概览，可通过 访问Left Super，
  • 其中Ctrl+ Alt+t 才不是打开终端，
  • 面板右上角有注销和关机控件，但单击它们时没有任何效果（！）

从中删除该GNOME_SHELL_JS行之后~/.profile，我必须通过终端重新启动，并发出sudo reboot now。

返回到系统默认的 Ubuntu 安装的原始 gnome-shell 后，我发现所有扩展仍然被禁用；我不得不一个接一个地重新启用它们——至少它们的偏好设置仍然存储着，没有丢失。

结论：

我可以想象，人们可以在这个出厂默认的 gnome-shell 实例上重新引入所有 Ubuntu 特定的定制和配置。

如果您知道实现该目标所需的步骤是什么，请发表答案。

相关内容