Re: Steps to get to GTK+ 3.0

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Thu, 2008-06-05 at 16:44 -0300, Johan Dahlin wrote:
> Yevgen Muntyan wrote:
> [..]
> > Say, this Gtk-3.0 idea sucks. It brings nothing to application
> > developers, yet application developers will be effectively forced
> > to migrate to avoid problems. You are doing a disservice to
> > application developers with this. It's a road to 4.0? Give me
> > a break, canvas can be done now, and Undo in text widget doesn't
> > need disabled deprecated API either. Thing is, nobody wants to
> > do boring stuff, everybody wants to do exciting new stuff. Like
> > writing a new programming language or mangling structure member
> > names.
> > Now what, do I get kicked out off the list? (Well, you can't
> > do that)
> 
> Right, 3.0 will bring very little, if nothing to developers in short term.
> 
> As it has been brought up on this list many times. There are really no 
> alternatives to making this change in process. We have to do this, or Gtk+ 
> will die slowly and become irrelevant.
> 
> Some major features discussed are not depending on the 3.0 release to be 
> done. But Canvas is one of them. You might want to do an attempt to 
> violently push in a canvas into Gtk sure, but what we're really aiming at is
> something Clutter like which would give you proper integration. And that 
> cannot be solved without breaking all widgets in various interesting ways.

Wait, wait... There are two different kinds of canvas concepts:

  1. A simple canvas widget, like GooCanvas.  It's a simple rectangular
widget which contains a scene graph composed of canvas items and groups.
Interaction between canvas widgets and canvas items is nonexistent or
limited;

  2. Add canvas-like traits to the Gtk widget system, such
layering/compositing, affine transformations, ability to scale to
thousands of items/widgets without expensive X server roundtrips for
creating X resources associated with each widget, animations, etc.

I think 2 would be fantastic but:

   a) apparently is not going to happen in the proposed Gtk+ 3.0;

   b) most people will settle for 1 and be extremely happy already.

> You just need to remember, nobody is forcing you to use Gtk+ 3.0 or even 
> Gtk+ at all.

That will not be true in practice.  Once Gtk+ 3.0 comes out, Gtk+ 2.0
will die a slow death, and projects have to switch to Gtk+ 3.0
eventually.

I think I agree with Muntyan here.  Gtk+ 3.0 brings nothing exciting, so
why break API?  It's just so pointless and painful for everyone.  So
much effort done with memory profiling and now we'll have to have two
libraries, gtk+ 2.0 and gtk+ 3.0, side by side, for a few more years?

If, as I suspect, Gtk+ 3.0 is more of a marketing stunt than anything
else, great, we can release the next gtk+ 2.x as two separate libraries
and header files:
   1. gtk+-3.0: only the non-deprecated APIs
   2. gtk+-2.0 deprecated: only the deprecated APIs

$(pkg-config --libs gtk+-2.0) would yield -lgtk+-2.0 -lgtk+-3.0,
while $(pkg-config --libs gtk+-3.0) would give -lgtk+-3.0.

Everyone will be happy.  Projects that compile with gtk+ 2.0 with
GTK_DISABLE_DEPRECATED automatically become "gtk+ 3.0 ready".

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
"The universe is always one step beyond logic" -- Frank Herbert