Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
- From: Murray Cumming <murrayc murrayc com>
- To: Tim Janik <timj gtk org>
- Cc: GTK+ development mailing list <gtk-devel-list gnome org>, pygtk <pygtk daa com au>
- Subject: Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
- Date: Fri, 22 Jun 2007 11:33:07 +0200
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
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]