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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
