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. 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 --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
