主页 / ubuntu / 问题 / 1305948
Accepted
Levente
Asked: 2021-01-08 13:40:22 +0800 CST

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

  • 772

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

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

20.04

2 个回答

  1. Best Answer

    答案兼容：
    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 使用这些副本。

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

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

    ~/.gnome-shell-custom-overlays/

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

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

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

    关于依赖的说明：

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

    设置主题文件：

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

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

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

    mkdir ~/.gnome-shell-custom-overlays/ui

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

    调整：

    要查看调整对自定义文件的影响，似乎有必要在每次编辑后重新加载 gnome-shell。它可以通过运行命令对话框（由+显示）发出r命令来快速完成。AltF2

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

    恢复注意事项：

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

    关于使用 G_RESOURCE_OVERLAYS 的说明

    此功能可能主要针对调试和开发，可能不是永久使用。

    系统的稳定性可能会受到影响：当我第一次启用此功能时，我发现我的声音设置出现了一些以前从未体验过的怪异现象，以及一些窗口闪烁。几次重新启动 gnome-shell 和（几次？）重新启动（s？）解决了它，从第二天开始，我没有遇到任何进一步的异常。

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

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

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

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

    我相信在这种情况下，可以暂停使用 G_RESOURCE_OVERLAYS 功能~/.profile（如恢复部分所述），随后重复从 fresh 中提取主题文件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 包并在本地更改版本号，并安装新软件包。

    资源

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

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

    参考文献/文献：

    • 9

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

    我无法让它正常工作，它使系统表现得更加怪异。

    我只为那些觉得自己熟练且经验丰富的人分享它，并尝试在它的基础上进行构建，直到它成为一个真正可用的替代方案。

    同时，可用的答案仍然是我对这篇文章的另一个答案。

    以下方法的来源：

    libgnome-shell.so这种方法提取所有 gnome-shell 的 javascript 文件——而不是仅提取特定文件以进行更改——并根据二进制文件中定义的原始排列将它们排列在精心设计的目录布局中。

    更新了 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 特定的自定义和配置。

    如果您知道实现该目标的必要步骤是什么，请发布答案。

    • 0

相关问题