Re: Gtk+4.0


Writing this on webmail-client. Please bear with me.

On Tue, 21 Jun 2016 12:12:46 -0700, Christian Hergert
<christian hergert me> wrote:
Sorry for the long post, I tried to condense it, unsuccessfully.

Thanks! That is a valuable insight into the development and changes of
Gtk3. An inspiration for the Gtk-Blog?

On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie
<simon mcvittie collabora co uk> wrote:
Thanks for starting this discussion.

A new stable-branch every 2 years is certainly not set in stone, just
like there's no reason there *has* to be a new stable release of Debian
approximately every 2 years. It's a trade-off between two factors. If
stable releases are too frequent, you're right that third-party
developers will either spend a disproportionate amount of time catching
up with the latest version, or go looking for something else. If stable
releases are not frequent enough, third-party developers will find that
they can't have the latest features or fixes (including the things that
can't be fixed without breaking API!) other than by using the unstable


Ideally, we'd choose the trade-off such that projects that want to stick
to a stable-branch version are happy with its stability, while also not
feeling that they are missing out on too much new stuff by doing so. A
year is probably too fast? 5 years is probably too slow? I don't know
what the right middle ground between those two is, but 2 years sounds
like a good first guess.

I started to think about it this. I tend to compare Gtk with Qt, but they
are not the same. On the other hand, Gtk and Qt are only major
platform-independent toolkits and largely used on GNU/Linux. The active
phase of Gtk2 lasted from 2001 - 2011 and it is still maintained in 2016,
which is a scary long time. Qt's cycle is much shorter, they moved from
2.x till 5.x in same time frame.

The current proposal will split Gtk into stable branch, which will break
in an insupportable* short-period of two years. Even if some major
applications will move immediately to a stable release, they will already
use the out-dated within two years. Furthermore GNOME will not use "Gtk",
GNOME will use it's own Gtk which will likely look and feel different in
several ways(HIG?). I'm afraid support for at least the development Gtk,
the stable Gtk and the old-stable Gtk will be required also.

* Thank you English language for this word!

10 Years are too long and 2 years are too short. Right? Is it better to
break the API/ABI clearly once and keep it stable for some years, maybe a
range between 4 to 6 years? In this area compatible (non-breaking)
can be added. I'm feeling far more comfortable with this idea. This sounds
similiar to Qt and maybe it's a good approach:

+ all applications will largely use the same toolkit (good for users)
+ reliable planning (application developers)
+ necessary API/ABI break (library developers)
+ less maintenance burden (library developers)
- not so many freedom through API/ABI break (library developers)

I would prefer a faster and more firm cycle.

I'm not one of the people doing the work, so I can't make an informed
comment on what future plans would require an API/ABI break. However, if
the people writing the code say they would benefit from API/ABI breaks,
it seems sensible to believe them.

True and valid! Christian also has written much about this.

How is the contact between the Gtk-Team with the application-developers of
GIMP, Inscape, Pidgin, MySQL-Workbench, Geeqie, Firefox, LibreOffice,
Wireshark, Gummi...[growing list of my day-to-day stuff]? I would ask them
for their oppinions. In the end, they will use it.


PS: Posting about the plans was a good decision, even if the churn is

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]