Re: Steps to get to GTK+ 3.0
- From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- To: Mikael Hallendal <micke imendio com>
- Cc: gtk-devel-list gnome org, Johan Dahlin <jdahlin async com br>, Yevgen Muntyan <muntyan tamu edu>, Jean-Yves Lefort <jylefort brutele be>, Kristian Rietveld <kris imendio com>
- Subject: Re: Steps to get to GTK+ 3.0
- Date: Sat, 07 Jun 2008 13:02:53 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]