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

Murray Cumming murrayc at murrayc.com
Fri Jun 22 17:09:56 WST 2007


On Fri, 2007-06-22 at 11:03 +0200, Tim Janik wrote:
> On Fri, 22 Jun 2007, Murray Cumming wrote:
> 
> > On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote:
> >> On Fri, 22 Jun 2007, Murray Cumming wrote:
> >>
> >>> On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote:
> >>
> >>>> b) GtkTooltips is going to be deprecated in 2.12 anyways, so there
> >>>>     is little use in continuing to use it anyway.
> >>>> c) note that the actual compilation changes could easily be ironed out
> >>>>     by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced
> >>>>     deliberately, to catch remaining tips_data_list uses in third-party
> >>>>     code which should be removed now, since tips_data_list became a
> >>>>     mere alias for NULL for future Gtk+ versions.
> >>>
> >>> When was GtkTooltips::tips_data_list deprecated, if it was every public
> >>> API?
> >>
> >> reppeating what i wrote above, GtkTooltips will be deprecated in 2.12
> >> in favour of GtkTooltip.
> >
> > So, this is deprecation with a break. Breaking normally follows
> > deprecation after a delay. Deprecation with a break is just a break.
> 
> every change is a "break" in some sense. the question is whether the
> change actually affect applications badly or not (not what name is given
> to it). so far, no case has been made for tips_data_list=NULL badly
> affecting applications or LBs, i'm still waiting.

I was talking about the renaming of the struct field, which breaks
builds. If the rename is going to be reverted, and the change of
behavior has no bad effect then that's fine.

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



More information about the pygtk mailing list