Relocatability
We started the day out by discussing Allisons ideas for making it possible for applications and libraries to find plugins and similar things relative to their install location, to make them effectively relocatable. This would help a lot for packaging systems like snap, which want to place precompiled applications into their own app-specific locations without recompiling them.
The general reaction to the suggestion ranged from 'this is crack' to 'sure, but it will never fix all the random applications out there', but there was no strong opposition to doing this and fixing up the libraries in our stack to be well-behave in this regard.
We briefly touched on how such apis would be used from bindings, e.g. python. No obvious answer was found, but maybe it isn't needed as much).
librsvg
Benjamin gave us a 10 minute explanation of everything wrong with librsvg. It is just an image loading library, thus it doesn't do any of the interactivity or javascript. It doesn't use gobject, but it also is only 20k lines of code. This ties into our gdk-pixbuf problems. No answers here.
GdkWindow
We want to just use windows for toplevels, and possibly popovers and similar subsurfaces. A lot of cleanup can follow once we get rid of all uses of GdkWindow for non-toplevels. Since 3.20, subwindows are already not used for drawing at all anymore, clipping is done by widgets. The big holdup is input and the way we use windows in there for routing.
Embedding should probably use a client-side compositor like Wakefield.
Windows are used for finding the right widgets to deliver input events to, to get coordinates right, and to selectively opt out of events.
Picking the right widget under the pointer is a tedious but straightforward function to write. It is a solved problem for keyboard focus with the focus-window property on toplevels.
We probably always want to get all events at all times.
Getting rid of subwindows will break things like gtk_tree_view_get_bin_window() and widgets that create their own windows in realize, so we can't do this before gtk4. There are some preparatory things we can do in gtk3, like automatic handling of enter and leave events for hovering.
Docs
... some silent hacking ...
live demo!
Lars showed us his work of integrating gtktemplate-like xml in nodejs. Cool stuff.
GtkImageView
Benjamin explained the questions he has about this widget. We can aim for a very powerful abstraction that supports video and animations, and so on, or a narrowly targeted one which just supports our existing use cases, such as eog and photos.
If we don't expose an abstraction at all and do things similarly to GtkImage, we cannot support use cases like resizable svg (need to hold an RsvgHandle) or using gegl underneath.
No clear conclusion at this point.