Now, that alone doesn’t mean much, since Nautilus is nowhere near a usable state:
Some input event handlers rely on being able to chain up to the parent handler for certain things: the list view, in particular, on right clicks, to select the file before popping up a context menu for it. I don’t know of a way to achieve that yet, so the code is currently just commented out.
Support for XDS has been removed, as the implementation relied heavily on window properties, which have been removed. In particular, this should make DnD from file-roller to Nautilus useless (which doesn’t work in Wayland, either, AFAIR). Support for root window drops is gone as well, given that Nautilus does not handle the desktop.
Scrolling in canvas view broke completely and mouse rubberband selection is a tad wonky still, but only at the highest zoom level (at least it works great after moving it out to a drag gesture, despite breaking single-click selection, as the current selection is cleared at the beginning).
Header bar menus appear empty (not exactly a priority, although might be an easy win).
Canvas view item prelighting and selection coloring needs rethinking again and might end up looking differently. But, hey, at least the GtkSnapshot API is fun to use.
That’s all that comes to mind right now, but there’s still plenty to keep me busy.
Since my last post, the tagged entry became a subclass of GtkSearchEntry, as was the case with GdTaggedEntry (yay GTK+ 4) and the tags became GtkWidgets (instead of GtkBins). It didn’t take much effort to move from GtkBin to GtkWidget – only implementing size_allocate(), measure() and snapshot(), which are really trivial when working with actual widgets as children. That, and tweaking the appearance some more, as the move broke the styling a tad. Some perhaps questionable methods of dealing with that were employed, but nothing too nefarious.
With this out of the way now, I’ll be able to focus on porting the rest of Nautilus.
With the exams having been left in the past, I can get back to hacking on Nautilus again. This time, it’s coming up with a GTK+ 4-ready tagged entry for the search. Heavily inspired by Matthias’ prototype, here is a sneak peek at the work-in-progress implementation:
The styling still needs tweaking (I’m trying to reuse the entry-tag class from Adwaita as much as possible, but there are signs of breakage now that actual widgets are used) and the input – hooking up (oh, and the close button), but, so far, the code is infinitely simpler than that of GdTaggedEntry, which will hopefully remain to be true until the end. As of yet, the code isn’t anyplace public, but that should change by the end of the week, when all details are finalized. The code can be found at https://gitlab.gnome.org/ernestask/tagged-entry.
One downside to doing it the putting-things-into-boxen-and-adjusting-margins-and-padding way is that the new class can’t be used as a GtkSearchEntry transparently (for properties and signals), because then we run into ownership problems, but that’s nothing a simple getter can’t fix.
Gestures like these is now how almost all input is handled in Nautilus. The exception is the stuff that has no event controller counterpart in GTK+ 3.
This summer I’m working on porting Nautilus to GTK+ 4 as part of Google Summer of Code, and I’ve spent the entirety of the time on getting rid of deprecated 3.x API and obsolete ways of handling events. Despite slightly hack-ish ways of working around deprecations, it’s been smooth sailing so far – No Regressions™! Almost ready to switch†!
™ - one reported and fixed
† - “switch” here means staring at an endless stream of compiler errors
Going back to event handling, the next immediate goal is to dismantle the old icon view we use, since it holds non-widget objects, which largely requires emulating GTK+ for event handling. The reason for that is simply that Nautilus predates GtkIconView and was never ported to using that (possibly for performance reasons). I’ve got code that uses gestures for button presses locally already, but will look for something better than adding a small GdkEvent clone that allows setting fields, which is required mostly for synthesizing “enter” and “leave” events for the children.
It’s a bit unfortunate that there only exists a subset of event controllers in GTK+ 3, but at the same time it’s a great opportunity to make the code GTK+ 4-compliant (still hoping to see the key event controllers soon). Where impossible to use one, I switched to handling ::event (bar some instances of ::key-press-event, where that prevented accelerator handlers from being run).
All in all, the pain has been minimal and I’m looking forward to getting back with a fresh perspective on things after the university exam period ends.
Edit: clarified the bit about the canvas view not holding widgets.