Re: object_data -> qdata?

Skip Montanaro <skip pobox com> writes:
> Where in 1.2 you have 
>     &GTK_OBJECT (widget)->object_data

Yikes, you shouldn't be using this I don't think.

What are you trying to do, maybe we can give you what you should be
using in that context.
> Owen pointed me at some stuff on his website earlier today that helped, and
> the Changes-2.0.txt file looks like a goldmine.  Are there other places to
> read up on to get a nuts-n-bolts education on the Gtk type/class structure
> and the changes it's gone through recently?

I have a half-done porting document, but it's fairly concise on this
matter, not going to be super-useful for language binding authors.

 <sect1 id="gobject">

The GTK+ type system and object system have been moved to GLib, as
"libgobject," and modified somewhat in
transit. <literal>GtkObject</literal> still exists for compatibility
reasons, but should not be used as a base class for new object

<literal>GObject</literal> differs from <literal>GtkObject</literal>
in two main application-programmer-visible respects. First, it is
strictly reference counted, with no "floating flag"; so when you
create a new <literal>GObject</literal>, you own a reference to it and
must always unref. With <literal>GtkObject</literal>, you don't own a
reference on a new object, there's only the owned-by-no-one floating
reference.  Second, there's no "destroy" signal. The "destroy" signal
on <literal>GtkObject</literal> was semantically broken, leading to a
lot of implementation difficulties; it means both "request that all
weak references drop their handle to this object to break cycles" and
"this object is about to be finalized." <literal>GObject</literal>
does not have a "please break cycles" signal, and notification of
finalization should be done with "weak references." Notification of
finalization is not done with a signal, because signal emission adds
references to an object and depends on the object being alive. It's
not possible to add references to an object that's already being

GObject will be most visible to authors of custom widgets. 
The "correct way" to write a widget has changed a bit; 
look at some of the widgets new in GTK+ 2.0 to get an idea how
signals, object properties, and so on work with GObject.


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