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