Re: Gtk+4.0

[Christian Hergert <christian hergert me>]

Sorry for the long post, I tried to condense it, unsuccessfully.

On 06/21/2016 07:26 AM, Peter Weber wrote:
> After five years we see now Firefox and
> LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was
> released in 2011. 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.

In retrospect, telling everyone we are going to break things in 3.x when
we branched was not the greatest strategy. However, we have gotten a lot
of core plumbing fixed and 3.x looks a lot less like the 2.x series,
which is right out of 1998.

I've worked on a few very large gtk+ applications this millennium, and
we avoided 3.x for both stability and availability reasons. Neither of
those are much of a concern for me these days.

However, it cannot be underestimated the amount of work that moving from
2.x → 3x was. The entire ecosystem of desktop software was changing
during that time-frame and applications needed to adapt not only to new
API, but to new paradigms. Lots of abstractions have been added that
allow us to have more leeway over the original X design of event
dispatches everywhere. But if you aren't using them (and stuck with the
ancient X-style event handling in your port) you might not get 100%
expected results.

For example, a very large percentage of computers released today come
with touchscreens. Whether you like it or not, we need to support the
hardware that exists. Moving to GtkGesture was a huge step in the right
direction but ultimately changes how you write input for widgets (very
much for the better!).

Now, how about things like overlay scrollbars? Every platform uses them
by default now, and implementing them required changing our drawing
model a bit and some size-request machinery. How about the people that
rely on those scrollbar troughs to draw marks on-top? If we have
"opt-in" nobody will use it correctly. If we have "opt-out" nobody will
use it at all but would remain "ABI stable" in the semantic sense.

Going forward we have even more ambitious goals. We'd like to see
GtkContainer, as it exists today, become obsolete. GtkWidgets will be
able to have children (and internal CSS Gadgets were step 1). No longer
will we need to implement widgets like GtkEntry with custom drawing, we
can simply have composition of widgets.

Even more radically, we need to change the drawing model from one based
on immediate mode rendering to something that is more easily implemented
with GPUs. This necessitates removing things like cairo drawing in the
normative case. If we always render the UI with cairo, we have to do
full texture uploads on every frame. Clearly this will not do. (For
those about to suggest cairo-gl we tried that in the last decade and no,
it's not a good idea). Some of this can be implemented in 3.x (which is
happening now), but has the potential for unforeseen side-effects.

We should be able to remove cairo from the normative case and preserve
immediate mode rendering for those that require it (or fallback). It
could also allow those who wish to use other drawing libraries like skia
to do so independently of gtk+.

Version numbering aside, we want to enable application authors to
release software that has been tested to work correctly. (As opposed to
"untested" with the current model). This is possibly the best way to
move forward, however flatpak is another excellent way to do so.

My current concern is more about theme authors. Let me start by saying I
think the result is a zero-sum game, but this will require new work by
theme authors. On one side it will be easier to know a theme works
correctly (and will be stable). On the other side theme authors will
need to write more theme variants.

-- Christian