HTML document, Unicode text, UTF-8 text
1
<!DOCTYPE html>
2
<html lang="en">
3
<head>
4
<meta charset="UTF-8">
5
<title>
6
GTK 4 makes no sense
7
</title>
8
<link rel="stylesheet" href="/static/style.css">
9
<meta name="viewport" content="width=device-width, initial-scale=1.0">
10
</head>
11
<body>
12
<header>
13
<nav>
14
<ul>
15
<li><a href="/">Home</a></li>
16
<li><a href="/projects">Projects</a></li>
17
<li><a href="/index">Index</a></li>
18
<li><a href="/about">About</a></li>
19
<li><a href="https://roundabout-host.com/roundabout">Roundabout-host</a></li>
20
</ul>
21
<ul>
22
<li><a href="mailto:root@roundabout-host.com" id="mail-link">root@roundabout-host.com</a></li>
23
</ul>
24
</nav>
25
</header>
26
<main>
27
28
<h1>GTK 4 makes no sense</h1>
29
<div id="article-date">2025-03-04</div>
30
<p class="tags">
31
32
<a href="/index/gtk.html" class="tag">gtk</a>
33
34
<a href="/index/software.html" class="tag">software</a>
35
36
<a href="/index/opinion.html" class="tag">opinion</a>
37
38
<a href="/index/gnu/linux.html" class="tag">gnu/linux</a>
39
40
<a href="/index/python.html" class="tag">python</a>
41
42
<a href="/index/c.html" class="tag">c</a>
43
44
<a href="/index/c++.html" class="tag">c++</a>
45
46
</p>
47
48
<article class="content-area">
49
<p>I recently started to write a GTK 3 library, but then I realised it will be
50
obsolete in 5 years at most, and I thought GTK 4 isn't that bad, so I decided to
51
port it to GTK 4. Turns out I was wrong.
52
</p><h2>GNOME's hate for other desktops</h2><p>GTK 4 clearly is made to reflect GNOME's vision of the future of desktops.
53
Future versions will even require a "platform library", meaning your app will
54
have to be tied to either GNOME, Elementary or whatever. In GNOME's vision,
55
there won't be any generic apps.
56
</p><p>GNOME should understand that I don't want to design anything, or make my app
57
feel like an Apple product. Rather, I value more the users' comfort when using
58
the app, which is increased when the app looks like the rest of the system and
59
can be themed to fit the user's preferences or needs.
60
</p><p>I've seen suspiciously few apps that use GTK 4 and not libAdwaita (and "adwaita"
61
means "the only one" in Sanskrit, a fitting name for GNOME's design). Also,
62
Cinnamon/Linux Mint, MATE, Xfce and other GTK desktops have not shared <em class="emphasis-1">plans</em>
63
for a migration when GTK 4 has been out for 4 years already. This is a clear
64
indication they're unsatisfied with GNOME, and GNOME is hostile to them.
65
</p><ul><li><p><a href="https://gitlab.gnome.org/GNOME/gtk/-/issues/2922">GNOME closing an issue about menus, saying it's a discussion, but it's not</a>
66
</p></li></ul><h2>The new "menus"</h2><p>GTK 4 removed the traditional menus, because GNOME doesn't need them, as their
67
apps are too basic (even thought of a <a href="https://flathub.org/apps/com.konstantintutsch.Caffeine">division app marketed as a coffee tool</a>)?.
68
</p><p>They are now expecting powerful app developers to replace their menus with
69
"menus" implemented with a popover. Some shortcomings of this approach:
70
</p><h3>The submenu handling</h3><p>By default, sub"menus" aren't handled like they were before, where hovering its
71
parent would open the sub"menu", making it easy to browse through the options.
72
Now, you have to click the parent, which will slide the sub"menu" into view,
73
replacing the parent, and then, should you want to go back, you have to click
74
a back arrow. I guess this is probably intended for phones, where it could be
75
useful indeed as the screen is small you can't hover, but it should have been
76
a global preference in <code>gsettings</code>, not something the app developer has to
77
choose.
78
</p><p>Even though you can opt for the classic "menu" behaviour, it's not the default,
79
making apps like Inkscape use a wrong design. Having this at the DE level would
80
make it so much easier for the user, the app developer, and the distributor.
81
</p><p>Additionally, there are many other problems.
82
</p><h3>The menu construction</h3><p>Now, to construct "menus", you have to use a <code>GMenu</code> object. Among other things,
83
this means your "menu" items can no longer be accessed as widgets. Instead, the
84
"menu" is declaratively constructed from a tree-like structure. This is a good
85
idea, but it has some flaws; every "menu" item must now be bound to a <code>GAction</code>,
86
which must have a string ID. Now instead of just managing your variables, you
87
have two namespaces to manage. When many items are similar to each other or even
88
dynamic (think zoom levels, move targets in a file manager, or a list of drives),
89
it's a pain to have to think of a unique ID for each one.
90
</p><p>Why isn't there just a way to bind a "menu" item to a (lambda) function? This
91
would make it so much easier to manage, and more flexible.
92
</p><h2>No more containers</h2><p>GTK 4 removed containers and all related APIs with them. Now, everything is
93
inconsistent, and you can't even have a signal when children are added or
94
removed. Instead, if you want some other widget to sync with the children of a
95
container, you have to subclass that container and override its add/remove
96
methods so they emit custom signals. If the specific type isn't under your
97
control, good luck.
98
</p><p>Lots of functions, including <code>Gtk::Box::pack_start</code>, <code>Gtk::Box::pack_end</code>, and
99
others, were renamed to <code>append</code> and <code>prepend</code> for no reason. Also, you can no
100
longer get a vector of children from a container, you have to iterate over them
101
manually.
102
</p><h2>No Glade</h2><p>Glade was a great tool and it's a shame to see it go. Cambalache exists, but
103
it's got its own problems, especially that the conversion from its own file to
104
a <code>.ui</code> file is one-way.
105
</p><p>The alternative isn't a design tool, I don't want to design anything, but just
106
to declare the layout and the signals, which the GtkBuilder still does well,
107
writing XML by hand is just cumbersome though.
108
</p><h2>The good parts</h2><p>I did decide to use GTK 4 because it has many benefits if you don't use it with
109
libAdwaita:
110
</p><ul><li><p>Cell renderers have been deprecated, making everything use the same widget
111
model.
112
</p></li><li><p>CSS syntax has been updated to newer standards.
113
</p></li><li><p>Drag and drop now makes much more sense.
114
</p></li><li><p>No more padding properties which duplicated CSS's job.
115
</p></li><li><p>Widgets are initially shown; you don't need to manually <code>show()</code> them.
116
</p></li><li><p><code>GtkFileChooserNative</code> would allow the system's file browser to be used in all
117
apps; more distribution support is needed though.
118
</p></li><li><p>All widgets now receive all events.
119
</p></li></ul>
120
</article>
121
</main>
123
<footer>
124
<p>Page generated on Monday, 17 March 2025 at 17:06:45</p>
125
<p xmlns:cc="http://creativecommons.org/ns#" >This work is marked with <a href="https://creativecommons.org/publicdomain/zero/1.0/?ref=chooser-v1" target="_blank" rel="license noopener noreferrer" style="display:inline-block;">CC0 1.0 Universal</a> (🄍). No rights reserved.</p>
126
<p>Hosted at <a href="https://roundabout-host.com/roundabout">Roundabout-host</a> using the static site service, and generated with <a href="/projects/ampoule.html">Ampoule</a>.</p>
127
<a href="#">Back to top</a>
128
</footer>
129
</body>
130
</html>