Re: Gtk+4.0

[Peter Weber <peter weber ttyhoney com>]

https://media.ccc.de/v/7-inspector_gadget#download

I want suggest viewing the record of Benjamin Otte's talk about "Gtk
Para...Inspector" at GUADEC 2016! Which is, indeed, only about Gtk-4.0 and
the follwing development model!


I think Benjamin has done a great job in calming everyone down and
explaining the thinking behind the planning. You should take the time to
view it completely, but timecode 07:00 (two year-cycle and feature vs.
time-based) and timecode 10:00 (depending libraries like GktSourceView)
are interesting. Furthermore he explained to me (afterwards) very nicely
why the bump to Gtk4 itself is required, the old internals of X11 are
still built inside Gtk3 and working behind it's Wayland-backend from old
times. So cleaning the things up is necessary. I can't say if bumping to
Gtk4 would also be a good idea looking at GSK, manuelle Bassi knows this
better.


The other thing is the development-model following after first release of
Gtk4. I can feel the churn and tension between your lines "suicide"
and Emanuelles "who does the work in gtk development". Gtk is the
GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work inside Gtk it
could also named the GNU-Toolkit. That naming thing is not the point.

Library-developers want a clean and lean library (API/ABI breaks), while
application-developers need stability (avoid API/ABI breaks) and both
together want new and nice features (the thing which
makes it difficult)? As longer a library keeps stable and moves also ahead
with some new features, as more tolerable and enjoyable breaks of the
API/ABI become from time to time. Everyone is willing to pay a price for a
good thing.
Just extending the stability period on four years will not fix it. It's
hard for me to explain, so bear with me. What causes a chilling effect is
the split-up into unstable and stable and that every release of the
stable-series will be a major-release, which really breaks everything. The
reasonable expectation is a system with major, minor, patches:
Major: add new features, cleans up API/ABI, break API/ABI
Minor (missing here): add new features, shouldn't break, but maybe if
absolutely required
and easy to keep up with it
Patch: and patches, doesn't break anything, doesn't add anything

This is the model of Qt and it works. Noteable, Qt has done more majors (5
vs 3) than Gtk and Qt5 has done less minors than GTK3 (10 vs 7). Maybe
also the unstable-release could be used internally as long as the
developers wish (why not rolling permanentely?), good things can be ported
back to a new minor release of Gtk4. And if the issue arises that unstable
collected cool new stuff which requires a major-release after a unkown
number of years, than this new major-release will be created and labled
Gtk5. If this happens after ~three years, okay. If this happens after ~six
years, nice. Anything longer would be a pure miracle and maybe not good
(Gtk2 is more like a dinosaur).

I think breaking the API/ABI because of required changes, is right,
breaking API/ABI because a fixed number of months has passed doesn't make
much sense. I think Benjamin is right here, application developers are
willing to pay for an API/ABI break if they receive incredible, required
new stuff they can't get in another way.

Peter

PS: Thanks for your talks on GUADEC. Sadly I missed the last day :(