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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> "The universe is always one step beyond logic" -- Frank Herbert _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
