Re: Steps to get to GTK+ 3.0

[Mikael Hermansson <mike tielie gmail com>]

On Fri, 2008-06-06 at 18:22 +0100, Gustavo J. A. M. Carneiro wrote:

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

Now I dont get it?? First you say 

"Once Gtk+ 3.0 comes out, Gtk+ 2.0
will die a slow death, and projects have to switch to Gtk+ 3.0
eventually."

Next you say we should implement using wierd macros like
GTK_DISABLE_DEPRECATED?

what is the difference? As a application developer you still has to
check for both Gtk+2 and Gtk+3 and have alot of #ifdef to check if
version is 2 or 3 is installed and your back at the begining of your
coinclusion meaning: "Gtk+ 2.0 will die slowly" 

Also if we dont break API now when should we break it? When should the
developers start implement new important features if theyr never get the
right to break API?

Looks like people is whining alot without reading the docs at all...
   
Take a look at the documentation at:

http://developer.imendio.com/sites/developer.imendio.com/files/gtk-hackfest-berlin2008.pdf


There is some statements in there that atleast made me understand why
this is needed :-)

Kindly regards,

Mikael Hermansson