Hello!
I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
write about my thoughts, in a careful way. In the first moment, I thought
this is a good idea and just the numbering is misleading. Stability is what
developers want, we need it, we love it. With a few days distance,
numbering is just a small issue, I see this now entirely different and
three major issues:
1. Separating official applications from GNOME, away from all other major
applications
2. Very short stable-release-cycle, every two years an API/ABI-Break is
really bad for all
3. No actual reason to break the API/ABI of Gtk3.x, but stability is the
most important part for a toolkit
I hope you don't hate me now.
Quite the opposite, thanks for starting the discussion. I think many people who were at the hackfest are still recovering from travel and catching up what they missed at work, so no-one started a thread on this.
I'm trying to elaborate this:
1. Separating official applications from GNOME, away from all other major
applications:
Applications will be splitted in modern and outdated ones. Users will see
modern applications from GNOME and a lot of old stuff, mainly well-known
applications. As time of writing, neither Gimp, Inkscape, Geeqie, Pidgin
nor Geany merged to Gtk3. After five years we see now Firefox and
LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was
released in 2011.
In my opinion, this is what the proposal tries to solve. I think a common message is that outside applications don't want to risk porting to GTK 3 because it's not stable enough. I hope that once GTK 4 is released and declared stable, then applications like Firefox and LibreOffice would be confident enough to start porting right away. Especially if we can have some decent porting guides in place when the new stable release rolls around.
I'm not sure about this, but I suspect the jump between GTK 2 and 3 was quite a lot larger than the jump between GTK 4 and the following stable version will be. Since GTK 2 reigned for 10 years, there were a whole lot of breaking changes that had to happen at once when the opportunity arose.
From the developers side, we will forced to choose
between to nasty options, an already outdated stable API/ABI or a shiny new
API/ABI, which will break fast.
Even if the tradeoff is as bad as you describe, it's better than the one that application developers get in the current situation: a 10-years (instead of 1.5 years) outdated stable API/ABI or a shiny new API/ABI which is not expected to break between releases but in practice it does anyway.
I'm hoping the tradeoff will not be as bad as you describe though :-) Two years is a much shorter cycle and the stable version will not get as outdated. As for tracking the unstable series, well, it's definitely opt-in for a reason, and you shouldn't do it unless you are OK to deal with the breakage. I expect though that given the option of a two-year stable series, most developers outside of GNOME will use the stable series. I certainly plan for my side projects to track the stable series.
If I can finish writing it, I'll add a FAQ page to the wiki today that will try to illustrate better what the benefits and drawbacks are for application developers.
2. Very short stable-release-cycle, every two years an API/ABI-Break is
really bad for all:
If the API/ABI becomes stable every fourth release or two years, this is
to short for the developers to adapt. Constant breaking is bad for
developers! We will see a lot of different stable API/ABIs used within
years (or not, which isn't better). And the Gtk+-Team will have to support
a lot of stable-branches: Gtk2, Gtk+3, Gtk4 (two years later), Gtk5(four
years later) and so on.
This sounds like very much work and is bad for the Gtk+-team. Currently
the Gtk+-Team has to support Gtk2 and Gtk3, only.
I believe the idea is to support one stable and one unstable release at the same time. In my opinion, if GTK 8 is the current stable version and you're still on GTK 3, then that should be equivalent to if you're still using GTK 1 in 2016...
Furthermore the alignment to Debian/Ubuntu LTS sounds like a permanent
delayed cycle building on top of each other. I don't expect many developers
to catch up with unstable/upstream or even using "git clone://", in case of
Ubuntu or Debian this could happen:
-> LTS -> Stable API/ABI -> Developers start adapting
-> Subsequent LTS -> Adapted applications available -> But already new
stable API -> Developers start adapting again
This is a good point and it seems like the stable GTK should pick a judicious time to release that fits with distros' release cycles.
3. No actual reason to break the API/ABI of Gtk3.x, but stability is the
most important part for a toolkit:
Nobody named a reason, why it is really necessary to break the API/ABI.
Wayland? Already done (great job!). A lot of new featuers? Already done and
doing (great job!). But the main reason for choosing a toolkit is, beside a
good API, stability and portability. A more stable API/ABI will attract
more developers, more applications will be written and therefore easily
portable from Windows/MacOS to Linux&GNOME. Microsoft (stability) and Qt
(stability&portability) are investing lot of in this, for decades.
I would like to invite others to answer this, who have actually worked on those features, but it's my understanding that Wayland and other various new features actually do require breaking things. GTK 2 was a very X11-centric toolkit and to a large extent GTK 3 still is.
The idea of more stability is very positive! But after thinking about the
current proposed approach I'm a really scared. Instead being against a new
approach of an ongoing development, some suggestions from a
non-library-developers (i.e. a complete fool):
1. Tiring, but with the most impact, keep Gtk3 as stable as possible while
carefully adding new things
This is the current approach, and I think the reason the proposal exists is because we don't find this approach to be a good use of the resources we have, and application developers are also unhappy with the way it's worked out.
2. Add experimental features through external libraries (libsexy and so
on?)
3. Add experimental features behind compiler MACROS, like
UNSTABLE_GTKPATHBAR
These are both good ideas and should be done, in my opinion. (Libegg, libgd, etc. are the current incarnations of #2.) However, not all features are "modular" and can be added in from an external library like that. The CSS machinery is a good example of something that has to live inside GTK.
4. Seperate Gtk a little bit more from GNOME (this hurts, but I think this
will help). I've GNOME wants something and the Gtk-Team is not convinced
(yet), GNOME can do it on it's own without hassle. The future will show who
is right and maybe the new thing get moved into Gtk or dropped again from
GNOME. Maybe this increases the chances to get in better contact with other
heavy Gtk-based environments.
I'm not sure I understand what you are proposing here. Can you explain some more?
Keeping things stable is hard work. I know that and admire your work.
Thanks for your work on Gtk+!
Peter
PS: Allan already has written about the unlogical version-numbering it[2]
and mentions the better even/odd-numbering. So I skipped this completely.
[1]https://wiki.gnome.org/Projects/GTK+/Lifecycle
[2]https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
