Re: About GTK+ 3.0 and deprecated things

[Martyn Russell <martyn imendio com>]

Morten Welinder wrote:
>> Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
>> (e.g., I remember doing that for gftp, not a trivial app.)
> 
> That sounds like a serious case of selective memory.  Or maybe gftp
> has the ui from "hello, world".

:)

> Here's a partial list of suffering that we went through.  Let's see...
> 
> * All widgets has to be reworked and audited.  There was new reference
>   handling and double destroy calls added to the trouble.
> 
> * All glade files needed to be redone, or at the very least subjected to
>   heavy post-translation surgery with Emacs and Perl.
> 
> * All code needed to be audited for UTF-8.
> 
> * All font handling had to be reworked.  Drawing changed too.
> 
> * Whenever something crashed, leaked, or otherwise simply did not work,
>   we had to audit not only our own code, but glib, pango, and gtk+ too.
>   There were piles and piles of bugs in the new code.
> 
> * We had to struggle with sluggishness of the resulting gtk2 application.

All of these things are reminiscent of my GTK+ 2.x upgrades too yes, but
really, this is not the case for GTK+ 3.0.

> The above is just what I can remember off the bat and is *before*
> changing to use the new widgets of gtk2, some of which were only
> partial replacements of what they deprecated: the tree view, for
> example, was touted as right for all kinds of tables, but it has
> become clear that it cannot handle large ones.
> 
> Gnumeric has about 34k lines dedicated to dialogs, not including code
> that implements the actions of those dialogs.  Add to that 20k lines of
> widgets and another 20k lines of further gui code.  That excludes code
> for graphs.  You just do not audit that in a weekend or two.
> 
> You want us to go through some variant of that every 3-4 years?  That's
> insane!

Again, you are assuming we will be implementing features which represent
the huge changes seen from GTK+ 1.x to 2.x every 3 or 4 years. That's
simply not what we are saying. We are just saying that we want the
ability to break every 3-4 years. It is highly unlikely we will write
changes into the toolkit that were seen from GTK+ 1.x->2.x every 3-4 years.

> What, exactly, is it that is hard about maintaining 2.x that will not be
> hard for 3.x?  I have seen nothing but unsubstantiated assertions
> about this.  What I have observed is that sub-systems like GtkPrint
> get dumped in and abandoned right away.  With bayesian mind
> that tells me that the maintenance situation will not be better for 3.x

Kris has given examples, I have given examples and I am sure others have
too about why these changes make sense. I really don't think it would
matter if another example was given.

> What really bothers me is that people go out of their way to break working
> code.  Looking at svn logs tells me that the effort of keeping the old widgets
> and methods around is minimal.  It's not just the old gtkclist -- the recently
> deprecated gtktooltips shows the same thing.  The second unsubstantiated
> assertion is that the deprecated widgets cause a lot of maintenance work
> beyond the self-inflicted pain of deprecation.  The data does not support
> that assertion.
> 
> I would like to see all this gtk3 talk pushed 3-4 years out into the future.

And then what, have the exact same talk then?

If you want to maintain the old GTK+ 2.x toolkit then that is fine I
would say, but if you think about it, the time spent maintaining that
dead branch would surely be better spent upgrading your application(s)
to GTK+ 3.x instead? I suppose you could argue that that time on 1 old
toolkit is less than on 100+ applications using it, but then if you
stick with an old toolkit, doesn't that just mean your applications are
slowly dying anyway?

-- 
Regards,
Martyn