| |||||||||||||
|
| |||||||||||||
any detailed info on GTK+ plans?any detailed info on GTK+ plans?Posted Jul 25, 2008 0:29 UTC (Fri) by giraffedata (subscriber, #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.
(Log in to post comments)
any detailed info on GTK+ plans? Posted Jul 26, 2008 19:07 UTC (Sat) by mmarsh (subscriber, #17029) [Link] 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] > 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] 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.
|
|
||||||||||||