Re: GTK_FLOATING broken in 2.9?



On Thu, 15 Dec 2005, Dave Benson wrote:

On Thu, Dec 15, 2005 at 12:49:45PM +0100, Tim Janik wrote:
On Wed, 14 Dec 2005, Morten Welinder wrote:


before starting to investigate in ugly hacks to continue maintaining the
current GTK_FLOATING semantics with GtkObject, i'd really like to raise
the issue that people/langauge bnindings most probably never should be
setting GTK_FLOATING with GTK_OBJECT_SET_FLAGS. besides the obvious
implementation, the only case i saw so far where this was need is
in GtkMenu.

Gnumeric's use is in go_combo_popup_reparent which pretty much mirrors
gtk_menu_reparent.

Note, that GTK_OBJECT_SET_FLAGS is a macro.  Fixing it will not help
programs compiled against, say, gtk+ 2.6 headers.  If the user updates
gtk+, the application breaks, i.e., no ABI stability.

yes, i'm fully aware of that, it was listed as possible impact
in the original thread:
  http://mail.gnome.org/archives/gtk-devel-list/2005-September/msg00165.html

this thread never really addressed my concern,
which was that this makes it so that container classes
before 2.10 have one style, and >=2.10 have another.
considering that this change is trying to simplify
memory management, i'm dubious.

as i origianlly mentioned, my example is
 g_value_set_object()
which clearly should ref_sink(), but clearly cannot
for abi compatiblity reasons (though i'm not exactly going to
be shocked when a patch goes in that does it anyways...)

you're right that simply changing that function take over one
reference for floating objects would break existing user code.

compatibly, you can add extra value setters that properly sink
though, if you think adding that API is worthwhile.

and you could then deprecate the old API if you think that'd be wise.

(i'm intentionally leaving this open)


- dave

---
ciaoTJ



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]