Re: Steps to get to GTK+ 3.0

[Mikael Hallendal <micke imendio com>]

Hi Gustavo,

6 jun 2008 kl. 19.22 skrev Gustavo J. A. M. Carneiro:

> > 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.

Please note the difference between Gtk+ 3.0 and Gtk+ 3.2 and beyond.  
Gtk+ 2.0 is already doing a good job at dying slowly and many have  
already agreed that Gtk+ 2.x is a dead end. What is meant by "nobody  
is forcing you to use Gtk+ 3.0" is simply, since there won't be  
features packed into it you don't need to move to it in order to get  
the latest and greatest.

It is a way for you as an application developer to get *more* time to  
ensure that your code works with the 3.x branch before the feature  
release 3.2 is out that you probably want to move to.

> 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?

As outlined numerous times it is a conscious decision to separate  
features from break for the exact reasons you mention. Everyone who  
was around during the Gtk+ 1.x -> Gtk+ 2.x transition remembers that  
it was a painful exercise to migrate (and some still haven't taken the  
step). Gtk+ 2.0 was had a lot of new features and broke the API in  
many ways that made it really hard for application developers.

This is not the kind of break we are talking about with Gtk+ 3.0, it's  
a way smaller break that most importantly doesn't change the  
application logic in any way.

> 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:

I can assure you that Gtk+ 3.0 has nothing to do with marketing and if  
anything it is a bad marketing move to bring out a new major version  
without major features. Gtk+ 3.0 is about bringing us out of the  
current dead end, improve the maintainability of the library and  
provide for a *smooth* migration to a new development policy that will  
enable the Gtk+ team to incrementally improve the library.

>   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".

That is exactly what will happen, if your application compiles with  
GTK_DISABLE_DEPRECATED and GSEAL_ENABLE you are good to go with Gtk+  
3.0. Though the linking will probably not look as you suggested above  
but I don't see that there is a difference.

The idea is to make the transition from 2.x to 3.x as painless as  
possible and if your code compiles with the latest 2.x with  
GTK_DISABLE_DEPRECATED and GSEAL_ENABLE it will also work on Gtk+ 3.x.

Best Regards,
  Mikael Hallendal

--
Mikael Hallendal
Imendio AB - Expert solutions in GTK+
http://www.imendio.com