Re: Steps to get to GTK+ 3.0

["BJörn Lindqvist" <bjourne gmail com>]

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 <gjc inescporto pt>:
> 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
> <gjc inescporto pt> <gustavo users sourceforge net>
> "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