Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Mon, 2 Jul 2007, Elijah Newren wrote: Hi, Sorry to be a pest, but I noticed gtk+-2.11.5 was out, and was surprised to not see the tips_data_list vs. _tips_data_list issue reverted. So... On 6/25/07, Elijah Newren [EMAIL PROTECTED] wrote: On 6/22/07, Matthias Clasen [EMAIL PROTECTED] wrote: 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? Is this in the plans any time soon, or was the reversion decided against? i've made a new suggestion about the rename to deal with the fallout of the field rename on the relevant bug and haven't seen a specific reply to that yet: http://bugzilla.gnome.org/show_bug.cgi?id=447214#c16 i apprechiate further comments... [Yes, I know I need to also pester the pygtk folks some more to get a new pygtk tarball as well.] Thanks for all your hard work, Elijah --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Hi, Sorry to be a pest, but I noticed gtk+-2.11.5 was out, and was surprised to not see the tips_data_list vs. _tips_data_list issue reverted. So... On 6/25/07, Elijah Newren [EMAIL PROTECTED] wrote: On 6/22/07, Matthias Clasen [EMAIL PROTECTED] wrote: 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? Is this in the plans any time soon, or was the reversion decided against? [Yes, I know I need to also pester the pygtk folks some more to get a new pygtk tarball as well.] Thanks for all your hard work, Elijah ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On 7/2/07, Elijah Newren [EMAIL PROTECTED] wrote: Hi, Sorry to be a pest, but I noticed gtk+-2.11.5 was out, and was surprised to not see the tips_data_list vs. _tips_data_list issue reverted. So... Kris said he hopes to have the tooltips api changes sorted out tomorrow or the day after, but I decided that it would be better to get another snapshot out now, and defer the final tooltips api to the next snapshot ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
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? Elijah ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
