Re: Steps to get to GTK+ 3.0

["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