any detailed info on GTK+ plans?

Posted Jul 25, 2008 0:29 UTC (Fri) by giraffedata (guest, #1954)
In reply to: any detailed info on GTK+ plans? by brouhaha
Parent article: GNOME 3.0 worries

If people have a problem with a 3.0 release of GTK+ not having new features, there's a simple solution. Call it 2.90, and work from that toward a 3.0 with whatever fancy new stuff is desired.

The way I read it, the problem they have is with a release of GTK+ having a different ABI and no new features. I.e. pain without gain.

I assume the advantage of doing that lies in a smoother transition, for users and developers.

any detailed info on GTK+ plans?

Posted Jul 26, 2008 19:07 UTC (Sat) by mmarsh (subscriber, #17029) [Link] (5 responses)

My impression was that the "gain" in the ABI breakage would be a smaller, more-responsive GTK+
due to the expulsion of cruft.  That can be pretty significant for a lot of people, say those
of us limping along on six-year-old laptops.

any detailed info on GTK+ plans?

Posted Jul 27, 2008 8:19 UTC (Sun) by dannyobrien (subscriber, #25583) [Link]

Honestly, it might make sense to make 3.0 the "lost the cruft" update for GNOME, too. Just do
a major, no extra features, overhaul of the whole system. It might not be as badly needed, but
if you do it now, and flag that's what you're doing, I don't think anyone would be upset. 

I don't know enough about GNOME internals to pinpoint what that cruft would be, but I bet
every developer has a little list of their own...

any detailed info on GTK+ plans?

Posted Jul 29, 2008 18:38 UTC (Tue) by oak (guest, #2786) [Link] (3 responses)

> My impression was that the "gain" in the ABI breakage would be a 
smaller, more-responsive GTK+ due to the expulsion of cruft.  That can be 
pretty significant for a lot of people, say those of us limping along on 
six-year-old laptops.

Do you have any link that would list this "cruft" and any *numbers* on 
what expelling it would gain?  I doubt the speedup would be anything user 
visible (10% sounds pretty optimistic and something like that isn't really 
user visible).

any detailed info on GTK+ plans?

Posted Jul 29, 2008 18:59 UTC (Tue) by brouhaha (subscriber, #1698) [Link]

I too doubt that there would be any speedup. I think the issue is more a matter of getting rid of deprecated interfaces and fields so that new code doesn't have to support them. There's too much internal detail exposed, which makes it difficult to add new features while maintaining full compatibility. That's why they want to make the structures opaque and use setter/getter functions.

any detailed info on GTK+ plans?

Posted Jul 29, 2008 23:14 UTC (Tue) by mmarsh (subscriber, #17029) [Link] (1 responses)

No.  The article mentioned cruft, and it's a natural assumption that there's likely to be
speed gains in ditching it.  How much -- who knows?  Not having to maintain backwards
compatibility means that developers can focus on other things, and it's difficult to predict
what those gains might be.  Efficiency isn't an unreasonable guess.

Honestly, the only speed impact I really notice from GTK+ is when firefox is rendering a
particularly complex web page in a backgrounded tab, bringing the current tab essentially to a
halt.  That's not too frequent an occurrence, though.

any detailed info on GTK+ plans?

Posted Jul 30, 2008 0:38 UTC (Wed) by oak (guest, #2786) [Link]

> The article mentioned cruft, and it's a natural assumption that there's 
likely to be speed gains in ditching it.  How much -- who knows?

Anything performance related should be backed up with test-case(s), 
numbers and conclusions based on those numbers, everything else is bound 
to be dead wrong.


> Honestly, the only speed impact I really notice from GTK+ is when 
firefox is rendering a particularly complex web page in a backgrounded 
tab, bringing the current tab essentially to a halt.

I don't think this has anything to do with Gtk.  Firefox doesn't use
Gtk to draw www-page content (for obvious reasons, Gtk widgets are quite 
different from www-form widgets) and if it's in background tab, there 
isn't even anything to draw.  I think it's more to do with JavaScript &  
Flash content (Flash doesn't use Gtk either), CSS and complex page 
layout / layering.  Firefox has all tabs in same process (to save memory I 
assume) and AFAIK doesn't really thread its work that much.