In my opinion.. The total amount of energy needed to maintain Gtk is X. X is proportional to the size of the code base S. X is also proportional to the age of the code A. The older it is, the more programmers have touched it, the more hacks it has accumulated. So the equation is:
X=A*S the total energy spent on maintaining Gtk is Y. I believe Y is less than X which would mean that Gtk is detoriating. So decreasing S or A which Gtk 3.0 will do, is a good thing. 2008/6/7, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>: > On Sat, 2008-06-07 at 14:28 +0200, Mikael Hallendal wrote: >> Hi, >> >> 7 jun 2008 kl. 14.02 skrev Gustavo J. A. M. Carneiro: >> >> <snip> >> >> > 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. >> >> We already wrote our thoughts on this down in the initial "Imendio's >> vision on GTK+" document published before the Berlin hackfest: >> >> http://developer.imendio.com/sites/developer.imendio.com/files/imendio-gtk-vision.pdf >> >> >> That documents outlines the problems we see with the current situation >> and why we proposed the current solution. >> >> If you have specific questions after reading that document I'd be >> happy to try to clarify. > > OK, after quickly reading the document what I have to retain is: > > - You plan to do a major release every 3 years or so; > a) will break API by only removing deprecated features; > b) will break ABI; > - Access to fields directly will not be allowed; use getters and > setters instead; > > I am guessing that disallowing access to getters and setters with your > G_SEAL macro will unconditionally break gtk+-2.0 ABI, although API could > be maintained with conditional compiling. But you think that "sealing" > object fields is a fundamental step to improving gtk+ (examples cited > include problems found in the new GtkTooltip API and GtkStyle > cairo-ified due to applications directly accessing those fields). If > sealing the fields requires ABI breakage, then it follows that we need a > new library. > > The other part, that gtk+ maintainers need to remove deprecated APIs, I > still don't get very well. Deprecated code does not have to be bug > fixed (unless there's a security issue), and will likely not cause much > of a performance impact, as has been shown in this list already in the > past, IIRC. So I'm not sure I get this need to break API every 3 years. > AFAICT, in practice all it will achive will be forcing developers to let > go of deprecated APIs. But there are other ways to accomplish the same > thing (g_warning). > > Anyway, thanks for your clarifications so far. > > -- > Gustavo J. A. M. Carneiro > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > "The universe is always one step beyond logic" -- Frank Herbert > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- mvh Björn _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list