Re: Steps to get to GTK+ 3.0

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

On Sat, 2008-06-07 at 11:05 +0200, Mikael Hallendal wrote:
> 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.

But if it's as simple as that, I don't understand why we need a separate
gtk+ 3.0 shared library?  Just make a new gtk+-3.0.pc file which is
exactly the same as gtk+-2.0.pc but adds -DGTK_DISABLE_DEPRECATED and
-DGSEAL_ENABLE to the CFLAGS...

I am just worried that some people already complain about running KDE
apps and Qt apps side by side due to the memory required for different
runtimes; what are they going to say now that even the GNOME desktop
itself requires two different gtk+ libraries?  Yes, I understand that
today's desktops with over 1GB RAM already make that irrelevant, but
still...

Regarding "gtk+-2.0 dying", I am amazed by that statement.  I realize
that gtk+ developers like yourself have studied the matter with greater
detail and know better.  But I think it would help quell our fears and
end the discussions (maybe) if the reasons why gtk+-2.0 is dying, as
well as how would this proposed gtk+-3.0 mitigate those problems, were
written down in a wiki page.

Thanks,

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