Electron: 考虑在 Linux 版本中用 GTK3 替换 GTK2

升级到 Chrome 47 后，我觉得不错。

Chrome 47 于三天前发布。 :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

深入研究了一下，但仍然不确定将 use_gtk3 标志放在哪里.. @zcbenz愿意这样做吗？

@zcbenz或者你能告诉我们把它放在哪里吗？

我不是 Chromium 构建系统背后的构建行为方面的专家，但是从那里的 Chromium 相关错误中读取，我们应该可以将它添加到variables到common.gypi 。 相关线路在这里。

实际上，我也在 Linux 机器上进行测试。 我当前的开发箱运行Elementary OS ，每当执行 Gtk2 应用程序时，它都会显示警告Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref )。 如果事情进展顺利（希望如此），让我们看看我是否也能获得 PR。 不过肯定会喜欢你在那里的投入。

这事有进一步更新吗？ 作为 atom 用户，我希望看到它使用 GTK3 而不是 GTK2。

@netsgnut效果好吗？

“%”是什么意思？

唯一的变化是这个吗？

diff --git a/common.gypi b/common.gypi
index 7c41c36..d00d7f7 100644
--- a/common.gypi
+++ b/common.gypi
@@ -9,6 +9,7 @@
     'chromeos': 0,
     # Reflects node's config.gypi.
     'component%': 'static_library',
+    'use_gtk3': 1,
     'python': 'python',
     'openssl_fips': '',
     'openssl_no_asm': 1,

任何新闻 ？ GTK2 打开文件对话框使用起来非常痛苦！

@flying-sheep 啊，很抱歉长时间的无线电沉默。 一直致力于 GitHub 之外的其他项目，我的错。

回到我们的案例，这就是我最初认为应该工作的，但神秘地未能在我的机器上构建正确的 Gtk3 应用程序。 就我而言，我的初衷是制作一个不会在我的开发箱（运行 Elementary OS Freya）下发出错误的 Electron 构建。 然而，似乎以这种方式构建并不会真正使警告消失。

在 #4642 中， @zcbenz说：

use_gtk3标志只在 Chromium 下有意义，要启用 GTK3，我们需要先在 libchromiumcontent 中启用它，然后在 Electron 中更改链接设置。

那么究竟需要做什么呢？

1. 启用libchromiumcontent使用GTK3：将添加一个标志chromiumcontent.gypi是否足够呢？ 这很重要还是电子不使用该目标构建？
2. 更改 Electron 中的链接设置：在哪里执行此操作？

我不是这个领域的专家，不确定我是否误解了@zcbenz的评论； 只是我的 2 美分。

关于问题：

1. 可能不是。 libchromiumcontent从外观上看，似乎是一堆从上游下载 Chromium 源代码的脚本，补丁和重新打包以在 Atom 中使用。 除了您提到的更改 Chromiumcontent.gypi 上的标志外，至少依赖库也已正确打包。 查看libgtk2ui的实例。
2. Electron 中有一些@zcbenz评论中的“链接”可能指的是那些。

Chromium 上的

IIRC，它需要构建一个 libgtk3ui 库来匹配 chrome/browser/ui/libgtk2ui/，并在启动时切换这两个库。

而且，在撰写本文时，libgtk3ui 还不存在 :(您也可以查看 libgtk2ui 上的代码。

在我最初发布这篇文章之后，我在个人笔记本电脑之间徘徊，并且从那以后几个月一直在使用我公司发行的 MBP。 但我终于有了我的新机器，停机并决定尝试一下。 到目前为止我的进展：

我能够使用 gtk3 构建 libchromiumcontent，它包含以下内容：

• 在chromiumcontent.gypi 中添加'use_gtk3': 1 。
• 通过手动注释掉脚本/更新中对install_sysroot()的调用来禁用 sysroot。 注意：根据 libchromiumcontent 版本，您可能需要将use_sysroot中的chromium/src/build/common.gypi为'use_sysroot': 0 。 我假设未来正确的方法是切换到 debian_jessie 以获得构建中的交叉编译能力？
• 运行 pkg-config：

pkg-config --cflags gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk --libs gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk && export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig

• 跑了script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• 等了几个小时:)

然而，不幸的是，在构建完成后我有点过于乐观，认为它是电子构建的拖放，但当然不是。 我认为下一步是建立一个本地的 Brightray 并更新任何其他 gyp 文件以使用我的系统库而不是 sysroot。

关于 libgtk2ui - 我无法找到对我阅读此内容的引用（可能是 gentoo 论坛、chromium 问题跟踪器或 arch linux 社区线程）-但我相信 Chromium 构建 libgtk2ui 而不管 gtk3/gtk2，因为开发人员正在尽最大努力让 gtk3 构建工作。 我可能是错的，我不知道这会如何影响专为 gtk2 编写的任何基于 Electron 的补丁。

我每周为我的个人浏览器构建一次 Chromium-gtk3，libgtk2ui 仍然存在，我假设已使用。

我希望在接下来的几天内回到这里，并使用预构建的二进制文件和一些屏幕截图链接到我的 POC 存储库。

完成了，我希望很快就能启动并运行atom-gtk3 ！

最大的障碍是在整个 libchromiumcontent/electron/brightray 中使用 debian_wheezy_sysroot。 这些存储库的维护者可能需要进行一些讨论并决定是否切换到 jessie 或是否可能使 sysroot 成为可选。

在周末，我将尝试组合一个节点或 bash 脚本来构建一个可分发的电子 gtk3 可执行文件。 我认为我提出的任何拉取请求都不会被接受，所以现在这可能是 gtk3 用户获取和使用构建的必须有效的方式。 在接下来的几周里，我什至可能会尝试为我的 Arch 用户提供一些 AUR 包。

这些是电子构建期间的 gtk3 警告https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry有没有办法让我们保留 sysroot 但在 GTK+ 3.x 中复制到 sysroot 中？

@paulcbetts我认为只有当 Wheezy 升级为 Jessie 时（我可能是错的，但我敢打赌，如果您试图将 gtk3 潜入其中，您会发现自己陷入依赖地狱）。 除了 gtk3，我们还需要以下用于 gtk3 的现代库来构建： wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 。

@nikolowry听起来很棒，谢谢你的工作。 源代码在某处可用吗？ 我很想准备一个 PPA，让我们 Ubuntu 用户的生活更轻松。

我还想补充一点，这个问题不仅仅是提供现代小部件的问题。 GTK2 在 HiDPI 系统上不可用（至少不适用于 ubuntu 16.04），因为按钮和工具栏中的所有图标都呈现得非常小。 幸运的是，在 Atom 的情况下，这似乎只影响文件打开对话框，至少就我所见，因此 Atom 本身仍然相当可用。

@EiNSTeiN我将在周末结束时很快链接回电子 gtk3 存储库。

首先是一点背景故事 - 我决定让这个工作的主要原因是因为我使用 Atom 作为我的日常驱动程序并且再也无法忍受看到文件对话框了！ 但是，由于 asar/compiled-cache/npm-not-running-post-install-scripts 的复杂性，该构建花费的时间比预期的要长，但我现在可以开始了。

我一直在考虑最好的方法 - 所以维护者将有一个很好的参考（在所有单独的 repo 中协调拉取请求会很困难），而且 gtk3-would-be-users 可以启动并运行很快就不可能了。

但我不会进行自动化构建，所以每个人都应该为 4-6 小时的构建时间做好准备，或者准备一些服务器。 我可能最终会偶尔发布，直到这些更改反映在官方回购中。

我已经缩小了使用电子作为子模块的存储库并编写单个 bash 脚本来构建具有所有 gtk3 优点的电子。 然后每个发行版都可以有一个简单的起点来最终分发包，直到这些更改实际上正式生效。

在 hidpi 注释上 - 我的atom-gtk3 exec cmd 是GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U 。 GDK 比例标志还修复了chromium-gtk3 ui 字体大小。 这是atom-gtk3的一些屏幕：

https://goo.gl/ydHspu

你好，

我能够编译电子1.1.2 GTK3在Arch Linux的，路过use_gtk3=1以libchromiumcontent和改变gtk+-2.0为gtk+-3.0在brightray.gyp 。

现在，每当我按下一个键时，Electron 的默认应用程序就会崩溃。

详情请见： https :

构建脚本仓库：
https://github.com/nikolowry/electron-gtk3

希望能在周末结束。 这是一个 WIP，还没有构建任何有意义的东西。

@EiNSTeiN和@tensor5 - https://github.com/nikolowry/electron-gtk3现在应该正在构建。 请注意，它仅构建release版本，除非您明确告诉它构建debug和release 。 查看 README 并在出现问题时打开一个问题。

@zcbenz使用 Debian Wheezy 是否有任何历史原因（我知道 Chromium 喜欢与 LTS 兼容）？ 也许添加一个构建标志来使用 Jessie/GTK3？ 如果您不反对这个想法，我可以处理适当的拉取请求，否则您至少有一个关于构建 GTK3 所需内容的参考构建脚本。

编辑： @tensor5您使用的是 X 还是 Wayland？ 我知道 Chromium gtk3 构建在 Wayland 中的关键输入事件上崩溃了。

@nikolowry ：是的，我使用的是 Wayland，确实它在 X 上运行良好，谢谢。 你知道这个 Chromium 问题是否在某处讨论过吗？

发现这个： https :

@nikolowry我们只是在关注 Chromium 的构建配置，有很多 Linux 发行版，我们无法测试所有发行版，而 Chromium 在任何地方都经过全面测试，因此关注 Chromium 是安全的。

我很高兴为 GTK+3 添加一个标志来构建，并且添加一个指向您的构建脚本的链接对我来说也很好。 它可以是Linux 构建指令的高级主题的一部分。

@zcbenz听起来不错——他们确实有一个可以运行的 python 脚本，它使用 Jessie 而不是 Wheezy 作为 sysroot，但我想最好等待它被设置为上游 Chromium 中的默认值。

一般来说，由于 glibc++ 版本控制，在分发软件时，针对您能找到的最古老的发行版进行构建是一件好事 - 升级到 Jessie 可以（尽管我认为它通常更安全）使曾经在 Electron 中工作的人成为孤儿过去。 我们与 RHEL 用户经常遇到这个问题

@tensor5想出了如何在 Wayland 中启动。 我评论了那个 Chromium 票并更新了我的 gtk3 存储库。

只需要运行GDK_BACKEND=x11 electron因为 Chromium 不会自动连接到 XWayland 模块。

@nikolowry太棒了！

所以如果我理解正确的话，问题是 GTK3 认为 Electron 是一个纯粹的 Wayland 应用程序，而事实并非如此。

@tensor5正是！ GTK3 假设所有使用该工具包的应用程序都已准备好 Wayland（因此负责在需要时加载 XWayland）。

本周末我正准备深入研究 Chromium 源代码以弄清楚它，当我试图生成一些日志时，我通过https://fedoraproject.org/wiki/How_to_debug_Wayland_problems偶然发现了一个简单的解决方案

Chromium 和 Atom 是我最后一个非 Wayland 就绪的应用程序 - 很高兴我的 Skylake 笔记本电脑在混合 dpi 模式下连接到多显示器时不会再通过 xrandr 崩溃了！！！！

编辑：我知道你也维护一些 AUR 包，所以你可能想要编辑桌面文件以包含“env GDK_BACKEND=x11”，这将允许应用程序在 X 和 Wayland 中运行，并为其他人省去很多麻烦未来！

@nikolowry我已经开始了！

最终这应该在电子源中修复，使用启动器脚本不是最优雅的方式。

顺便说一句，AUR 包不是我的。 我维护一个存储库

@nikolowry Firefox 也是一个依赖 Xwayland 的 GTK3 应用程序，但它运行良好。 所以我看了一下：正如你在这里看到的display_name用于gdk_display_open 。

可能类似的事情可以在 Chromium 中完成。

在基本操作系统上，我们需要 GTK3 来使用 pantheon-file-chooser，否则我们会得到这些：

Gtk-Message: Failed to load module "pantheon-filechooser-module"

为什么不只是支持/移植到Qt5-WebEngine ？ 它无论如何都使用了chromium的引擎，而在Qt上，一切看起来都比gtk更原生……

加上 qt5 并没有像 gtk3 那样一直破产，每次都改变他们的 F**king API，因为他们不关心除了 gnome 开发之外的任何其他事情。

这是一个很棒的视频演示，为什么 gtk 不好而 qt 更好（2 岁了，但仍然很好且相关）

Qt 5.6.x 现在处于 LTS 并且他们的许可证随着 5.7 改变，这对开源用户/开发者来说更​​好

我个人不明白为什么人们在 gnome 之外使用 gtk，而 gtk 不是为此而设计的。

@ahjolinna实际上，GTK+ 也旨在用于 Gnome 之外的应用程序开发。 无论哪种方式，将 API 更改为 QT 对 Electron 团队来说都是一场噩梦，因为它需要从 Chromium 上游进行大量修补。 不值得麻烦。

GTK+3 _is_ 本质上是与 GNOME 结合的，因为基本上（？）所有 GTK 开发人员都是 GNOME 开发人员，受雇于红帽。

提到的 GTK API 损坏发生是因为红帽优先推动 GNOME 向前发展。 @ahjolinna是对的，Qt5 更稳定，_但是_它只提供对铬实例的有限访问。

原因也是稳定性：chromium 本身已经足够崩溃，以至于他们只能在某些领域投入资源来维持其稳定的 API。

@nikolowry如果我要使用https://github.com/nikolowry/electron-gtk3来构建具有 gtk3 支持的电子，我需要在原子构建中更改什么才能构建 atom-gtk3？

对于那些使用 gtk3 构建的用户，当使用浅色主题时，您可能会在菜单栏上看到白色文本。 这个补丁解决了这个问题。

我将在接下来的几天内修复其他 gtk3 构建警告。

带有 Gtk2 的 Chromium 中的菜单不是“原生 gtk 风格”，而且非常难看。 Gtk3 build 会解决这个问题吗？

@孟子。 不，带有 gtk3 的菜单栏看起来与带有 gtk2 的完全相同。 你是对的，它不是完全原生的，只是文本和背景的颜色遵循 gtk 主题。
我过去几天查看了代码，看看是否可以修复。 一个问题是原生 gtk 代码隐藏在跨平台包装层的后面。 也许那里的 gtk 专家可以帮助解决这个问题。

@tensor5我认为菜单应该在跨平台包装器中实现。 就像 OS X 的菜单是本机的一样，本机 Cocoa 代码也隐藏在跨平台包装层的后面。

@Menci当然，这是接受此类补丁的唯一方法。

有一个 Gnome 应用程序菜单也很好。

你可以看看 LibreOffice 是如何做到的，它的方式类似。

我认为 LibreOffice 的菜单并不是真正的原生菜单。 Thay 没有阴影和显示/隐藏动画。

http://caolanm.blogspot.sk/2016/02/native-gtk3-menubar-in-libreoffice.html

GTK+ 应用程序在 gnome（和其他 gtk 衍生产品）之外从未看起来是原生的，它们在 KDE、LXQt 上看起来总是很糟糕），而 Unity 8 到货时也会遇到同样的问题（基于 Qt5）。 KDE 团队试图与 gtk 团队合作解决这个问题，但他们已经 100% 完全是个混蛋，他们不在乎他们的 API 会随着每次该死的更新而改变/中断，这会破坏（一些）KDE 的东西，比如微风-gtk 主题，顺便说一句。 由于 gtk 团队愚蠢的推理，必须进行硬编码。 *

顺便提一句。 使用 KDE、LXQt 和 Unity 8 + Ubuntu Touch 和 SailfishOS，Qt5“市场份额”变得比 gtk 大得多，至少从长远来看这将产生巨大影响

附注。 关于 libreoffice，您可以在没有 GTK 的情况下构建它并使用本机文件选择器来构建它，例如 ChakraOS 所做的， PKGBUILD ，为什么？ 因为它专注于 KDE/Qt 的发行版喜欢尽可能避免使用 GTK

已编辑

*GTK 开发人员阻止访问主题引擎，这些引擎以前用于 KDE 中的 GTK 集成，所以现在唯一的方法是尝试“CSS 方式”

我知道的几个使用 Qt 的应用程序：
Dropbox、OBS、MEGA、VIber、Wireshark、makemkv、yacreader、masterpdfeditor、vapoursynth-editor、SVP、teamspeak3、mkvtoolnix-gui、hplip、scribus WPS-office...

其他使用 Qt5 的 DE： http ://papyros.io/ 和https://lumina-desktop.org/

@ahjolinna我认为你试图说服错误的人群。 如果 Chromium 没有进行转换，那么我非常怀疑 Electron 会进行转换。 要求 Electron 团队维护这个项目以及 Chromium 的 QT5 分支是要求太多了。

另外这个问题是关于用 GTK3 替换 GTK2。 如果您想让他们考虑转换，请提出新问题。 否则它就离题了，并且在这个线程中充满了噪音。

@alzadude您必须编辑一些 grunt 构建脚本，以便它不会下载预构建的电子，编辑 package.json 版本以匹配您在本地使用 gtk3 进行的电子构建，并且可能进行一两个 python 编辑（抱歉，现在的记忆）。 这并不难，但是当我做一个新的构建时总是需要我一分钟，因为我似乎总是忘记我在过去的构建中采取的几个步骤。

如果@tensor5开始在他的 arch-atom 存储库中使用 gtk3，我建议您尝试一下——否则，下次我进行构建时我会回到这里并为您记录更改（通常在周末）

@nikolowry谢谢，一些记录在案的更改会很棒:)

我在 Fedora 上，所以我希望合并基于此 Fedora copr 的更改：

https://copr.fedorainfracloud.org/coprs/mosquito/atom/

这个 Copr 目前似乎是最接近 Fedora 上标准包的东西。 它基于这些上游 rpm 规范文件：

https://github.com/FZUG/repo/tree/master/rpms/atom

并且在这个 Bugzilla 错误中提到：

https://bugzilla.redhat.com/show_bug.cgi?id=1132661

基于现有的工作，我可能希望制作自己的 Copr，用于 Electron 和 Atom 的 gtk3 构建（基于记录的更改，分叉上游 rpm 规范文件以合并必要的补丁）。 除非有人打败我当然:)

我正在尝试为此编写一个 gentoo ebuild，但没有成功。 如果有人帮助我做到这一点，我将不胜感激。

@eternal-sorrow 你是否已经看过 dev-util/electron，目前在官方 Gentoo 树中的 ebuild？

@devurandom ，我做到了。 这是电子的非常旧版本（0.36.12）。 我为当前版本 (1.3.1) 修改了它，调整了所有补丁，但仍然遇到 v8 链接问题（很多未定义的 v8 符号）。

@永恒的悲伤

1. 与该软件包的维护者[email protected]联系。
2. 在 GH 上使用您的 ebuild 设置覆盖存储库，也许我们可以一起解决。

@eternal-sorrow 在 Arch Linux 中我们用 GTK3 构建了最新版本的 Electron，看看它。

这方面有什么进展吗？

@nikolowry ，您在 atom-gtk3 中使用的是哪个版本的原子和电子？ 我意识到当前版本的 atom 需要电子 0.37 并且不能与当前版本的电子一起运行。 我错了吗？

@eternal-sorrow Atom 最近更新到了新版本的 Electron。

https://github.com/atom/atom/blob/efae2e08c3f902149431732cbd550aea09748acc/package.json#L15

有没有办法使用gtk3？ 特别喜欢它，因为它有更好的文件对话框。

既然 archlinux 已经有一个 gtk3 构建，那么缺少什么是电子核心？

我认为他们希望转换发生在上游。 现在正式计划，请参阅https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3。

额外信息，chromium/google chrome dev 频道正在使用 gtk 3，所以现在只是时间问题。

在https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110 上针对 Chrome 59 进行了确认

现在只是时间问题...

Chrome 59 出炉了！ :tada:

现在 Chrome 59 已经发布，很高兴看到使用 GTK3 为 Linux 构建的 Electron 预发布版。

GTK3 支持现在在 Chromium stable (59) 中，这意味着它很快就会在 Electron 中得到

我有几个问题：

• 为什么需要 GTK3 支持？
• 我看到这个线程中提到了很多“文件对话框”。 它在 GTK2 中有什么问题，它在 GTK3 中是如何改进的？
• 此更新是否改进了性能、兼容性等方面的内容？ 还是只是用户界面？
• 人们可能会期待哪些其他改进？
• 哪些 Linux 发行版使用 GTK(3)？

@泽克：

为什么需要 GTK3 支持？ 我看到这个线程中提到了很多“文件对话框”。

我感兴趣的一项改进是，在Flatpak沙箱内运行的 Electron 应用程序现在将无缝使用主机上文件选择器的门户。 如果用户安装了 Qt 门户，这甚至会使用正确的 Qt。

此更新是否改进了性能、兼容性等方面的内容？ 还是只是用户界面？

理论上，Gtk3 的 hidpi 支持可能是相关的，但我不知道这如何与 Chromium 的渲染交互，从而绕过大部分。 所以它可能只会改变主题。

哪些 Linux 发行版使用 GTK(3)？

实际上所有发行版都有 Gtk3。 Unity、GNOME、MATE、Cinnamon、Budgie 和最终的 XFCE 使用 Gtk3 作为他们的主要应用程序工具包。

@zeke

哪些 Linux 发行版使用 GTK(3)？

所有主要的 Linux 发行版都使用 GTK3 作为他们的桌面（shell）。 有些也有 KDE 风格，但它们的默认值是 GTK3。

我看到这个线程中提到了很多“文件对话框”。 它在 GTK2 中有什么问题，它在 GTK3 中是如何改进的？

是的，虽然 GTK2 和 GTK3 应用程序可以一起生活在同一个系统中，但 GTK3 应用程序可以更好地与当前的桌面集成。 “文件选择器”对话框就是一个很好的例子。

@zeke

为什么需要 GTK3 支持？

我重视一致性——GTK 3 上的文件对话完全不同，主题在 GTK 版本之间通常略有不一致。 我也喜欢让我的系统最小化，Atom 放弃 GTK 2 意味着安装 GTK 2 的理由少了一个。

我看到这个线程中提到了很多“文件对话框”。 它在 GTK2 中有什么问题，它在 GTK3 中是如何改进的？

如上所述，对我来说最重要的是一致性。 GTK 3 对话实际上被一些人认为是劣等的，因为它在目录中使用递归名称搜索而不是增量搜索。

人们可能会期待哪些其他改进？

菜单也应该使用 GTK，而不是似乎不支持助记符和使用箭头键在相邻菜单之间跳转的自定义实现。

Atom 放弃 GTK 2 意味着安装 GTK 2 的理由少了一个。

@jtojnar ：如果您有默认使用 GTK3 的较新版本 Linux，那么您必须手动安装 GTK2 以支持尚未更新到 GTK3 的应用程序？ 除了 Atom（以及所有其他 Electron 应用程序）之外，还有哪些其他流行应用程序存在此问题？

@zeke安装依赖项通常由您的发行版的包管理器自动完成，安装 GTK 3 应用程序也将下载libgtk3并且安装 GTK 2 应用程序将获得libgtk2 。 您可以安全地安装两者，只是由于 SSD 空间不足，我想摆脱所有旧包。

为什么需要 GTK3 支持？

GTK3 更新并支持 HiDPI。
GTK2 不再开发，也不是现代的。

我看到这个线程中提到了很多“文件对话框”。 它在 GTK2 中有什么问题，它在 GTK3 中是如何改进的？

不知道这个。

此更新是否改进了性能、兼容性等方面的内容？ 还是只是用户界面？

据说 GTK3 可以更好地利用某些 CPU 和 RAM 功能，但我不确定其他方面。 不过，这将是一个很大的 UI 更新。

人们可能会期待哪些其他改进？

更好的主题支持。

哪些 Linux 发行版使用 GTK(3)？

所有发行版的存储库中都有 GTK3。
许多主要的桌面环境都使用 GTK3，例如 Gnome 3、Budgie、Deepin、MATE 和 Soon(tm) XFCE。

这样做的先决条件是 Chromium 59，它有一个针对 #9946 的拉取请求。

@zeke主要内容是更好的 UI 一致性，因为在 Linux 上，您很可能会看到使用 GTK（2 或 3）或 Qt 作为 UI 工具包的应用程序。 Windows 和 macOS 有自己的，你通常会发现这些平台上的大多数应用程序都使用它们，但 Steam 没有那种原生外观，例如，它没有使用原生 UI 工具包。

我看到这个线程中提到了很多“文件对话框”。 它在 GTK2 中有什么问题，它在 GTK3 中是如何改进的？

与 GTK3 相比，GTK2 最好解释为早期版本的 Windows 或 macOS，其中 UI 具有不同的视觉外观（文件浏览器等的布局/功能差异）。 如果您运行 Windows 10 并获得一个看起来像 Windows Vista 或 XP 的文件对话框，它看起来会不合适，并且可能缺少某些功能/用户体验。

在像 KDE 这样的桌面环境 (DE) 上，这仍然会创建一个 GTK3 对话框，而不是该 DE 的更常见的工具包 Qt。 所以那里仍然存在一些不一致，但它比 GTK2 好。

以下是一些关于 KDE 的示例，使用默认 Breeze 主题：

带有当前 Electron 应用程序的 GTK2 对话框 - GitKraken：

GTK3 对话框 - 融合：

Qt 对话框 - 凯特：

Mono/.NET(?) Dialog - BundleModder - 在 Linux 上不常见，Java 应用程序也可以使用不常见的工具包：

如您所见，不同 UI 工具包的样式一致性非常不同。 作为普通用户，这可能会令人困惑，为什么它们不同，导致您想知道它们是出于相同的目的还是对导航/演示细节不同而感到沮丧（您可能双击 GTK，而 Qt 可能设置为单个单击文件夹导航）或只是将缺乏一致性视为不专业。

Gnome（专注于 GTK 的 DE）能够比 KDE（专注于 Qt 的 DE）更好地处理这个问题，并且在 GTK3 和 Qt 之间保持一致性，因为 Qt 的工具包旨在很好地跨平台集成，提供原生的感觉/体验。 GTK 开发人员不愿意在 Gnome 以外的 DE 上支持他们的工具包，尽管 KDE 开发人员希望贡献代码来解决他们的 DE 上的问题。 如果用户不使用使用 GTK2 或不常见工具包的旧应用程序，他们将获得更好的体验。

通常，当工具包没有其他工具包等效应用程序那样强大的产品时，您会发现 GTK 和 Qt 应用程序的混合，对于某些用户来说，仅使用单个工具包应用程序是可行的（KaOS 是迎合 Qt5 的发行版）经验，提供可选的 GTK 应用程序，如 Chrome）。 随着 Electron 应用程序的流行，避免 GTK 并不总是可取的。

为什么需要 GTK3 支持？

一致性，文件对话框是我作为 KDE 用户最突出的一个。

此更新是否改进了性能、兼容性等方面的内容？ 还是只是用户界面？
人们可能会期待哪些其他改进？

虽然我不太了解 FlatPak（沙盒、发行版不可知的应用程序，有点像 GUI 应用程序的 Docker/容器），但我认为 GTK3 在那里比 GTK2 有更好的故事，包括与 DE 的集成（FlatPak 主题是另一个为了保持一致性，FlatPak 中的 GTK3 最近获得了主题支持，其他工具包也需要添加这个）。 前面提到的 FlatPak 还可以通过它的门户支持来缓解文件对话框问题。

我个人对 GTK2 和 GTK3 不太了解，但是我认为 HiDPI 故事对于 GTK3 会更好（GTK2 甚至可能不会这样？）。 我想主题支持更好，或者至少你更有可能获得 GTK3 的主题而不是 2，尤其是在未来。 在 Gnome 上，文件对话框可能与客户端装饰 (CSD) 改善这些用户的 UX 有所不同。 在 KDE 上，我认为 GTK3 支持可能会更好地与全局菜单功能配合使用（仍然是 WIP，macOS 之类的菜单栏，而不是绑定到应用程序窗口）。

哪些 Linux 发行版使用 GTK(3)？

据我所知，大多数现代发行版都在使用 GTK3 或支持它。 GTK2 已经很老了。 如果您使用的是 Chrome 或 Electron 应用程序，则您使用的是 GTK（可能是 2/3 的混合，但更倾向于 3）。

@polarathene ，您没有提到 GTK3 支持允许在未来添加 Wayland 支持，而 GTK2 则没有。

JFYI Chromium GTK2 构建在最新的稳定版 60.0.3112.90 和测试版 61.0.3163.31 中被破坏。
不过，它适用于最新的主人。

顺便说一句，它不再正式维护。
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

大家对 GTK3 的优点有很棒的反馈。 感谢您的输入。

不幸的是，听起来 GTK3 更新不会在带有 Chrome 59 的 Electron 1.8 中登陆。它目前正在阻止构建，所以我们必须等到下一次 Chromium 达到 61（我们跳过 60）才能支持 GTK3在电子。

对吗，@alexeykuzmin？

@zeke你对铬 61 凸起何时会发生有任何粗略估计吗？ 我们希望计划迁移到原生 ES6 Web 组件以与该版本保持一致。 从历史上看，在发布后一个月左右会出现颠簸？

@zeke
是的，我们在 Chromium 59 分支中的 GTK3 确实遇到了一些问题。
但是我们应该在即将到来的 Chromium 61 升级中从 GTK2 切换到 GTK3。

@cpoole我们目前还没有对 Chromium 61 何时登陆 Electron 的估计，但它现在正在https://github.com/electron/libchromiumcontent/pull/335 中进行。 我们的目标是最终与 Chromium 版本更加同步。 来自微软的一些很棒的人（ @tonyganch 、 @cifratila 、 @alexeykuzmin 、 @alespergl ，其他人？）一直在帮助这个过程，这让 GitHub 的 Electron 团队腾出时间专注于改进 CI 并简化 Electron 的发布过程。 所以我很乐观:)

为什么需要 GTK3 支持？

@deikatsuo 那是什么浏览器？ 看起来铬和顿悟生了孩子......

@mdsitton顿悟👍

有这方面的消息吗？

@ziggy42它应该已经存在于最新的铬 61 (https://github.com/electron/electron/pull/10213) 中。 我想这只是合并 master 并在某个时候发布的问题。

等不及了，那些丑陋的文件选择器灼伤了我的眼睛 :fire:

此更改是否允许在 Electron 应用程序中使用 CSS？

那么，chromium 61合并了，gtk3要不要一起来？

Electron 现在在 master 分支中使用 GTK3，将在下一个次要/主要版本中发布。

@阿乔琳娜

感谢您在这次讨论中花费了一些理智。

您可能对已经提到的 KaOS 非常感兴趣。
它是由多年来使 Chakra 变得伟大的人维护的，恕我直言。

@全部

GTK+ 3 什么时候发布？

7年前。

让它在你嘴里融化一会儿。

大量的软件项目仍然坐在 2 上。
因为移植是一种乐趣..

XFCE、Mate 和一大群其他人花了 6 年的时间来移植代码。
其他项目在 2 内完全从 GTK 切换到 Qt。

是的：GTK+ 是由 GNOME 开发的，甚至 repo 都在那里。
它本质上和定义上都是为 GNOME 开发的，没有别的。

Qt 是为真正和本地集成到多个平台而开发的。

电子是什么？

GNOME 商店？

好一个。

聪明的思考。

它与命令式和函数式编程以及此场景中的许多其他方面相同：冗余、陈旧、过时的软件通常被视为一种上瘾的药物，这使它成为一种毒品。

新的、聪明的、创新的软件被误解和纯粹的无知所对待。

10、12 个项目从 GTK+ 切换到 Qt，而我不知道有一个案例发生了相反的情况。

让这一切再次融化在您的舌头上：这意味着完全重写他们的整个集成 UI 代码。
深深嵌套，经常。

这意味着与对现有工具进行重大升级相比，他们更喜欢这样做。
直到今天，他们都对这个决定感到满意。

问他们。

在你随大流之前而不考虑其他选择。

@ahjolinna 向您发布了其中一个人的视频，VLC、Wireshark、LXQt 和其他出色的软件项目以前也基于 GTK。

GTK 仅在 Chromium 中用作 Aura 的绑定，并且仅在 Linux/freeBSD/Solaris 等中使用：
Windows 和 macOS 版本是免费的。

：眨眼：

虽然我明白你的观点@ShalokShalom ，但不必粗鲁，Electron 遵循 Chromium 团队提供的内容。

叉子按钮在顶部顺便说一句，随意。

是的，这太磨人了。

但我同意。 GTK 有太多不必要的破损导致疼痛，Qt 会是更好的选择

• IF QtWebEngine 提供对底层chromium 实例的足够访问
• 如果QtWebEngine 能够足够快地跟踪最新的 Chromium

我建议我们将讨论移到更合适的地方。 @ShalokShalom ，你在这里打开一个新问题并以比刚才更文明的方式描述问题如何？

VLC 、Wireshark、LXQt 和其他出色的软件项目以前也基于 GTK。

那不是真的。 VLC 在 Qt 之前使用 wxWidgets，而不是 GTK： https :

在我看来，GTK 的人已经承认他们在 3.x 系列中没有足够好地传达破损和版本控制，并且将来会更加努力以更好更清晰的长期稳定性，可以在https:/ /blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/。

我还要说 Qt 和 GTK 由于不同的历史、支持和目标而不能一一比较，在我看来，根据您的观点，它们各有利弊。

声明 GTK 是为并且仅用于 GNOME 项目在我看来也是不公平的一揽子声明。

哈！ 我真的不知道那些计划。 好像他们终于学会了。 让我们希望他们开始将 CSS 中的任何重大更改视为真正的重大更改。

我听到的最后一件事是……嗯……偏心的GTK 4.0 不是 GTK 4 。 所以终于达到了几乎和 semver 一样好的东西！ 它们几乎和 20 年前的 Qt 一样好！ 😁

根据这篇推特帖子，我们应该很快就会看到默认支持原生 GTK3 的 Electron：

Electron 2.0.0-beta.1 发布了更新的 Chromium 和 Node.js、macOS 应用内购买、对 Linux 的 GTK3 支持等等。

是的。 真正的工作是由 Chromium 作者完成的，Electron 通过 Electron 2.0.0 中的 Chromium 升级获得了它。

另外，Electron 自己的代码在https://github.com/electron/electron/pull/11879 中得到了 GTK3ified

是的，这太磨人了。
但我同意。 GTK有太多不必要的破损导致疼痛，Qt
会是一个更好的选择
IF QtWebEngine 提供对底层chromium 实例的足够访问
如果 QtWebEngine 能够足够快地跟踪最新的 Chromium

嗯，这是主要问题。 人们会考虑对他们来说什么是最快的实现方式，这很好，但他们经常忘记让其运行的实际实现与长期维护非常不同。

从我的角度来看，很明显，提到的问题可以得到解决。

一旦您比较了实际在 GTK3 移植上工作的编码员和将整个 UI 代码移植到新工具包上的编码员的数量，您会发现差异有多么惊人。 我想我已经发布了一个关于它的视频，名为“从 GTK 到 Qt：一段奇怪的旅程”。

为什么专注于过时的软件，仅仅因为它看起来可以使用，而不是在 Qt 的支持中进行黑客攻击？

它是“我使用_似乎_准备好”的教条，它完全忽略了长期决策。 是的，首先看起来可能需要更多的努力，而你们肯定会从实施后的现代工具包中受益。

它也没有那么激烈，QtWebEngine 并没有那么快地跟随 Chrome：
它足够快，而且 Qupzilla 证明你可以用它做惊人的事情——尤其是在合适的环境中，比如 KaOS。

你真的认为你需要“更多地访问底层 Chromium”并且“QtWebEngine 没有足够快地跟随 Chromium”，因为 Qupzilla 和其他软件被证明提供了由一个编码员维护的惊人软件？

您认为作为 Electron 中成熟的 Web 浏览器，您需要更多的访问权限和更快的关注度吗？ 为何如此？

现在，您在这么多项目中坐在这个笨拙的软件堆栈上，小团队设法快速高效地将 40-60% 的深度嵌套代码移植到 Qt；

从 GTK 2 到 GTK 3，他们没有设法做到这一点，这非常了不起。 如前所述：大多数项目需要 6-7 年的时间来升级一个主要版本

几乎每个人似乎都忽略了这一点？ 太可悲了，在一个最初的科学界，如此原始的决定继续传播。

和平 ：）

@ShalokShalom ，“过时的软件”是什么意思？ GTK+？ 你有什么理由这么说？

请停止这个 Qt 垃圾邮件，这是一个关于 GTK 3 端口的问题。 如果您觉得有必要说服维护者改用 Qt，请打开一个单独的问题。 我想收到有关实施进度的消息，而不是来自 Qt 粉丝的消息。

由于过多的离题讨论而锁定此对话。

锁定仅解决了一个症状，但由于向 GTK3 的迁移即将结束，并且关于从 GTK2 迁移到 GTK3 的这个问题的主题没有太多可讨论的，因此它是一个合理的快速解决方案。