Port to GTK+ 4
## **Associated merge request: !266 (closed)**
End-of-GSoC status report
Nautilus is operational at this point, but not exactly ready to face the public. Drag-and-drop is not so much a straightforward port of the original code, so I’m about ready to give up on making it work exactly the same as in the GTK+ 3 versions. The
LINK action is no longer accessible via the ctrl-shift modifier, likely due to it not being supported in Wayland; it’s not quite possible to have Nautilus default to
MOVE when the action bitmask contains
ASK, and both of those will take precedence, making things very awkward, as one can’t even pop up a menu at pointer at the moment due to a bug in GTK+. I’ve wasted two weeks trying to investigate what’s happening in GTK+ and filed several issues, but the problem is that some of them are “things working as expected, even though there exists a shortcoming in this particular backend”, others are unsolved problems due to developers being focused on other things, such as reworking how keyboard shortcuts work, which leads me to…
Another pain point pending being addressed - action accelerators. In a post-event-controller world, our hackaround of “checking whether the current focus widget is a
GtkEditable, and, if so, forwarding the key event to it and stopping propagation” does not work anymore, meaning that you’re screwed if you want to undo or select all while renaming a file, the former will undo the last file operation and the latter will select all files in the view, instead. These issues could probably be fixed by using key bindings, which work only on the currently-focused widget, since they’re not willy-nilly added to the toplevel.
The operations button reveal animation is broken as well, given that
GtkWidget::draw has been removed. I removed things that weren’t used in our copy of libegg, but this one remains a head-scratcher. Maybe
IdeBoxTheatric could be turned into a widget and do its thing in
snapshot()? Who knows. Simply adding a CSS class to set the background doesn’t work, given that the position and size are also part of the animation.
### Related GTK+ issues and MRs
gtk!281 (Actually contains a fix for the sidebar rejecting drops)
gtk#1260 (closed) (I wanted to use this to play compositor in Nautilus and retain compatibility wrt drop actions, since now
It’s high time Nautilus once again got ahead of the game by using cutting-edge technology. The plan is as follows:
Before the switch (up to 4 weeks)
gnome-desktop (up to 1 week)
gnome-desktop links against GTK+ 3, which is a major roadblock, but this can be worked around until things happen.
The plan so far is to
- copy the thumbnailing code to Nautilus.
However, this will require adding a dependency to seccomp (build time) and bubblewrap (runtime). An alternative could be having a separate D-Bus-activatable service that links to gnome-desktop.
eel (up to 1 week)
Our pet eel pulls in GTK+ 3 via GAIL. Taking caring of this will require
making use of ATK (implementing
AtkTextIfaceinstead of writing a custom one).
Nautilus (up to 2 weeks)
Replacing uses of deprecated
Dropping deprecated event handlers by either using gestures or overriding the
At the time of switch (up to 6 weeks)
libgd (up to 2 weeks)
Since Nautilus does not use much from libgd, utilities that are needed can be copied. The tagged entry requires more work and will at first be reimplemented similar to Matthias’ experiment.
- Copy code from libgd
Write a GTK+ 4-ready tagged entry widget.
An implementation exists at https://gitlab.gnome.org/ernestask/tagged-entry.
Nautilus (up to 4 weeks)
This will be a singular big push, so makes no sense to split work into subtasks.
Changes include, but are not limited to (as GTK+ 4 evolves):
- Updating the GTK+ code getter for
GtkPlacesSidebarto the getter
- Getting rid of
GdkPixbufand using paintables more liberally
- Image and video file thumbnails framing needs to be redone
- Adapting custom widget size allocation code to API changes
forall()override in containers
include_internalsisn’t passed anymore
- Ceasing to create new
- Happens in a few places for event handling, the canvas being the sorest point
- Adapting to changes in
- No longer takes icon size, and
GtkIconSizelost many a value, meaning that, in some cases, the size will have to be hardcoded/taken from the theme
- Adapting to changes in
- Should be used as a container from now on, doesn’t have any special
GtkImageAPI to set the image
- Removing style properties
- Adapting to changes in
- Getters don’t take state arguments
- Removing custom instances of
- Canvas view is guilty of this; not using widgets means that synthesis is hand-rolled
- Adapting to changes in clipboard APIs (GtkClipboard is gone, should be replaced with GdkClipboard)
- Not just a simple rename
- Adapting to changes in DnD API (lots of changes; GdkDragContext split into GdkDrag and GdkDrop, changes in signal handler signatures, etc.)
- Drag gestures should be used instead of listening to widget signals (gtk#1095)
GtkCenterBoxwhenever the center widget is set for a
- Adapting to
- Padding and expansion/alignment should be controlled manually
- More event controllers
- Chaining up to parent event handlers is no longer possible (although
GtkEventControllerKeyallows forwarding events, which would only be useful if
After the switch (up to 4 weeks)
- Port to GTK+ 4
Total time estimate: up to 14 weeks
- If canvas view is a pain (editor’s note: it always is), we will disable canvas view with a compile time switch while we slowly implement everything we need to switch to the new views by default over time.
- Remove instances of enabling widget visibility, as that is default behavior in GTK+ 4.