Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)

[Murray Cumming <murrayc murrayc com>]

On Fri, 2007-06-22 at 13:58 +0100, Gustavo J. A. M. Carneiro wrote:
> On Qui, 2007-06-21 at 23:39 -0300, Johan Dahlin wrote:
> > Joseph Sacco wrote:
> > > The currently available version of pygtk is the stable branch.  I would
> > > expect the development branchof pygtk to adapt.
> > >   
> > I'm ready to adapt but only if the general consent is that API changes 
> > are okay.
> > 
> > My personal opinion is that the API shouldn't be allowed to change, once 
> > an API is added it should stay stable until the major version is bumped 
> > (3.0 in the case of gtk+).
> 
>   I'm 100% with Johan on this one.  Gtk+ 2.11.x broke API and ABI.
> Before 2.11.x, the structure is:
> 
> struct _GtkTooltips
> {
>   GtkObject parent_instance;
> 
>   GtkWidget *tip_window;
>   GtkWidget *tip_label;
>   GtkTooltipsData *active_tips_data;
>   GList *tips_data_list;
> 
>   guint   delay : 30;
>   guint	  enabled : 1;
>   guint   have_grab : 1;
>   guint   use_sticky_delay : 1;
>   gint	  timer_tag;
>   GTimeVal last_popdown;
> };
> 
> None of these fields is marked private, therefore they are public.

Actually, that's not the convention in GTK+, though I doubt that it's
written down anywhere official. struct fields are private unless marked
as public. It's obviously difficult to know, and easy to make the
mistake.

But even if an app did something wrong, we should still avoid breaking
that app unnecessarily.

> Public fields are part of the API and cannot be changed as per GNOME
> Developer Platform.  Probably there is a way to introduce the new
> tooltips without having to break the old tooltips API!
> 
> Just because pygtk _can_ adapt doesn't mean that it _should_.
> 
> In fact there are at least a couple of other changes in gtk+ 2.11.x that
> break the API; we should really be more careful about these things...

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com