There is something that does not add up for me. Let us imagine a scenario in which when Nautilus was ported from GTK3 to GTK4 you had not “de-GTK-ized” the libnautilus-extension API (basically source-wise the API would have remained the same); and let’s call this scenario “A” – here an extension might have used GTK or not. Now let us imagine another scenario in which the libnautilus-extension API had always been “de-GTK-ized”, and let’s call this scenario “B”.
Case A1: The libnautilus-extension API still passes a
GtkWindow, but now (GTK4) this refers to something different than with GTK3; however the extension never used GTK. Extension porting required: none.
Case A2: The libnautilus-extension API still passes a
GtkWindow, but now (GTK4) this refers to something different than with GTK3; the extension does use GTK. Extension porting required: porting from GTK3 to GTK4 required.
Case B1: The libnautilus-extension API has always been “de-GTK-ized” (also version 3); the extension never used GTK. Extension porting required: none:
Case B2: The libnautilus-extension API has always been “de-GTK-ized” (also version 3); the extension however uses GTK on its own. Extension porting required: porting from GTK3 to GTK4 required.
How did the B scenario help avoiding extension porting?
The annotations editor is heavily embedded in Nautilus. Annotations add their typical emblem to the annotated files and create an annotation column in the file manager. Furthermore, all changes must be updated in real time (e.g.
S saves the annotation currently open and updates emblems and column in real time). And finally, I want to add to the annotation window an emblem picker that lets select custom emblems in any amount. With that feature the extension will become as embedded to Nautilus as a property dialog. But, most importantly, the whole idea of “annotating” files makes sense only within a file manager, because annotations are metadata, not data.
GtkApplicationWindow are hardly private – they are exposed by the GLib and GTK libraries and they are unique. I would agree with you instead if I started to peek into heavily nested widgets (those are indeed definitely private and the code would look horrible). But I still think it feels hacky especially because the current direction seems to be that of isolating the extensions more and more, while my solution represents a step in the opposite direction, or at least an attempt to stay still.
This would be the same error as before. If I want to create a separate process already now I can call
g_spawn_async(). But I am not forced to do that (by the way, how do you move populating a menu into a separate process? If my extension adds a menu item named “Go to Mars” and my code waits for Mars’ close approach, even if it is in a separate process Nautilus will have to wait for Mars to approach Earth before showing the menu item).
It is exactly like when the libnautilus-extension API was still tied to GTK but people were still free to create extensions that did not depend on GTK – I also created three “GTK-free” extensions in the past…
In general, forcing developers to follow a path is hardly the right thing to do. Good developers will know when it is better to move the code to a separate process or not use GTK anyway.
This is a strange argument. If as you say that most extensions don’t use GTK, without your commit they would not have ended up broken with Nautilus 43. While the ones that use GTK would break in any case (see initial examples).