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

[Ghee Teo <Ghee Teo Sun COM>]

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.
>   
 The real test for this is if some one who has developed a GTK+ based 
on GNOME 2.0
and now copy over the binary to GNOME 2.20, will it run?
If not, it is breaking ABI. Breaking ABI at GTK+ is not good.
You can fix the API by recompiling, but you can fix ABI if the user 
doesn't have the code
to recompile or too complex to recompile which is likely to happen in 
the real world.

-Ghee

> 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.
> 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...
>
>