Re: Steps to get to GTK+ 3.0
- From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- To: Mikael Hallendal <micke imendio com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Steps to get to GTK+ 3.0
- Date: Sat, 07 Jun 2008 14:58:04 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]