On Fri, 2007-06-22 at 11:20 +0200, Tim Janik wrote: > On Fri, 22 Jun 2007, Murray Cumming wrote: > > > 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. > > the structure field renaming is there to catch current third-party uses. > that way we can gather feedback on field usage and figure if there are > cases where the behavior change has bad effects. > > as for reverting the structure field rename, i don't think that > is really necessary for 2.12. Gtk+ 2.x stable branches are supposed > to be ABI and API compatible, however not neccessarily source > compatible.
This is news to me, though similar things have been done before. I thought we had got better. > when 2.12 deprecates GtkTooltips, the field is not > anymore part of the API, ABI is maintained by its NULL assignment, > and the source incompatibility is covered by README.in (as all > source/API changes have to be). -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
