[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 22 Jun 2007, Tommi Komulainen wrote: On 6/22/07, Tim Janik <[EMAIL PROTECTED]> wrote: 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. The real killer I suppose is the change in semantics. Otherwise you would've used tips_data_list vs. _tips_data_list depending on GTK_DISABLE_DEPRECATED ? yeah, additionally, *all* of GtkTooltips is going to be DEPRECTAED in 2.12, so we don't have the option deprecate uses of this one field only. -- Tommi Komulainen [EMAIL PROTECTED] --- ciaoTJ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Hi, On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > so far, my take on the issue is that PyGtk should adapt to that > change by not using tooltips->tips_data_list I have attached a patch to http://bugzilla.gnome.org/show_bug.cgi?id=449318 that removes access to private GtkTooltips struct members from the pygtk bindings. I can't tell if this will break any PyGTK apps but I guess that these bindings have only been added for the sake of completeness. Sven ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On 6/22/07, Sven Neumann <[EMAIL PROTECTED]> wrote: Hi, On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > so far, my take on the issue is that PyGtk should adapt to that > change by not using tooltips->tips_data_list I have attached a patch to http://bugzilla.gnome.org/show_bug.cgi?id=449318 that removes access to private GtkTooltips struct members from the pygtk bindings. I can't tell if this will break any PyGTK apps but I guess that these bindings have only been added for the sake of completeness. Thats fine. Can we still please revert the field name change to make existing pygtk versions compile against 2.11.x ? ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On 6/22/07, Tim Janik <[EMAIL PROTECTED]> wrote: 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. The real killer I suppose is the change in semantics. Otherwise you would've used tips_data_list vs. _tips_data_list depending on GTK_DISABLE_DEPRECATED ? -- Tommi Komulainen [EMAIL PROTECTED] ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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. Murray Cumming --- ciaoTJ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Thu, 21 Jun 2007, Elijah Newren wrote: Just realized that pygtk and gtk-devel-list subscribers may not be on d-d-l. So I'm forwarding this. See http://mail.gnome.org/archives/desktop-devel-list/2007-June/msg00109.html for the thread and discussion. Please jump in. -- Forwarded message -- From: Elijah Newren <[EMAIL PROTECTED]> Date: Jun 21, 2007 8:05 PM Subject: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?) To: Gnome Desktop Development List <[EMAIL PROTECTED]> Hi, As noted in bug http://bugzilla.gnome.org/show_bug.cgi?id=449318, there was a recent gtk+ API change. jdahlin just barely told me that the changed API has existed since 1998, long before gtk+-2.11.x (and pointed me to http://bugzilla.gnome.org/show_bug.cgi?id=447214). This API change breaks pygtk and means that much of GNOME cannot be compiled. But it doesn't seem clear who should fix this. Should gtk+ revert it or somehow fix the API break, or is this an API break we want and expect pygtk to adapt to? so far, my take on the issue is that PyGtk should adapt to that change by not using tooltips->tips_data_list, because: a) i haven't seen a single argument yet about why giving up using tips_data_list would be bad for PyGtk or any other application for that matter; 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. Elijah --- ciaoTJ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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. Murray Cumming --- ciaoTJ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On 6/22/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: On 6/22/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > > > so far, my take on the issue is that PyGtk should adapt to that > > change by not using tooltips->tips_data_list > > I have attached a patch to > http://bugzilla.gnome.org/show_bug.cgi?id=449318 that removes access to > private GtkTooltips struct members from the pygtk bindings. I can't tell > if this will break any PyGTK apps but I guess that these bindings have > only been added for the sake of completeness. > Thats fine. Can we still please revert the field name change to make existing pygtk versions compile against 2.11.x ? And is there any chance we could get a new tarball so we can release GNOME 2.19.4? Thanks! ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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 pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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 [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > > As noted in bug http://bugzilla.gnome.org/show_bug.cgi?id=449318, > > there was a recent gtk+ API change. jdahlin just barely told me that > > the changed API has existed since 1998, long before gtk+-2.11.x (and > > pointed me to http://bugzilla.gnome.org/show_bug.cgi?id=447214). This > > API change breaks pygtk and means that much of GNOME cannot be > > compiled. But it doesn't seem clear who should fix this. Should gtk+ > > revert it or somehow fix the API break, or is this an API break we > > want and expect pygtk to adapt to? > > so far, my take on the issue is that PyGtk should adapt to that > change by not using tooltips->tips_data_list, because: > a) i haven't seen a single argument yet about why giving up using > tips_data_list would be bad for PyGtk or any other application > for that matter; > 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? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/