GTK+ 3 thoughts

["Matthias Clasen" <matthias clasen gmail com>]

During GUADEC, a lot of discussion has happened around the
possibility of a GTK+ 3, and we (the core GTK+ maintainers)
thought it would be a good idea to summarize our take on the
ideas and on possible ways forward.

Current GTK+ is a dead end in terms of developing important new
features. We can keep fixing bugs (there is an endless supply of
more or less important bugs in bugzilla), and we can keep adding
new features until the API documentation grows to the size of a
phone book, but this is not going to turn GTK+ into a new and
better toolkit.

There are number of well-known "problem" areas, where the
current GTK+ is increasingly perceived as lacking, e.g
- animation
- scalable UI
- canvas as foundation
- extended size negotiation, width-for-height, etc
- better theming api (css ?)
- less redraws (for e.g. e-paper)
All of these very much affect the core of GTK+, and are not
easy to "bolt on" the current GTK+.

Most of us doubt that a GTK+ 3 that breaks API and/or ABI in small
ways for cleanup and maintainability but preserves compatibility
with existing GTK+ in almost all ways is a worthwhile project.
A GTK+ 3 that is worthwhile doing would offer developers new and
better ways to write applications, and offer users different and
interesting user interfaces. The current GTK+ was largely designed
and implemented 10 years ago; for GTK+ 3, we should step back and
think about how people might use and design applications 10 years
from now, taking inspiration from devices like the iPhone.

How do we get there ? It would clearly be inacceptable for us to
just stop what we are doing now, and spend a few years developing
a completely new toolkit from scratch. A large number of users
rely on the continued maintenance of the stable GTK+ 2.x, and we
are committed to continue this, with GTK+ 2.12 due in a roughly
a month, and GTK+ 2.14 around next years Guadec.

What about compatibility ? Thousands of GTK+ applications are not
going to be ported to a new toolkit overnight (if ever), so it would
clearly be good if the transition could be gradual. We hope that it
will be possible to have "bi-embeddability", ie allow using the
"new stuff" like a canvas widget in a traditional GTK+ application,
and allow using ordinary GTK+ widgets inside a "new style" application.
This, in fact, means that 'GTK3' would not really be libgtk at all,
but rather a new library in the GTK+ stack that takes over the widget
toolkit role from libgtk.

We believe that the best approach towards a new GTK+ is an experimental
one. People have already started doing experiments around some of the
topics listed above, with projects like clutter, pigment, HippoCanvas,
and others. We would like to encourage more experiments like these,
and we are toying with the idea to have an "exhibition" or "bake-off"
at the next Guadec, where could discuss and evaluate the outcome of
these experiments.

There are no hard rules for these experiments, but it might be good
to reuse the existing infrastructure around GTK+, such as Pango and
cairo, and tackle some of the problems that we've listed above. Ideally
with concrete application designs in mind that are hard or impossible
to realize in current GTK+.


Matthias