Re: g_object_ref_sink and GUnowned
On 1/3/06, Torsten Schoenfeld [EMAIL PROTECTED] wrote: On Tue, 2006-01-03 at 14:32 +0100, Tim Janik wrote: GtkObject derives from GUnowned This breaks the Perl bindings of GTK+. Our GTK+ bindings register GtkObject with our GLib bindings at start up. This involves associating it with the namespace Gtk2::Object and it usually also means setting up inheritance so that Gtk2::Object is a Glib::Object. For that, the GLib bindings look at the parent of the hm, why don't your bindings register with unknown types on demand? do you have to manually bind every type and make a new release before it or anything (already known) depending on it can be used? We specify the GType to package name mapping manually. Until we add a corresponding entry to the mappings, an object with an unknown GType will be represented as an object of the earliest known type found in the ancestry. So if our bindings stumble upon an object of type GInitiallyUnowned, they will happily represent it as a GObject. The situation is completely different when we talk about inheritance. That's where we just consider the direct parent. This is where we break. When trying to set up inheritance for GtkObject, the bindings call g_type_parent which now returns the GType for GInitiallyUnowned. This is not known to us so the Perl package for GtkObject ends up not inheriting from anything while it should inherit from the package for GObject. So, we don't break if a new leaf type is introduced. We break if a previously known type suddenly has an unknown parent. Now, you could argue that our bindings should really walk up the whole ancestry until something known is reached instead of just looking at the direct parent. And I would probably agree; this has caused us problems in a different context as well. i'd even expect future breakage if you don't change your current logic, e.g. pointer or boxed types could be made deep-derivable and then the imemdiate ancestor of boxed types in gdk/gtk may also change. After some discussion on IRC, it turns out that I was actually wrong when I said that we could just walk up the ancestry to fix the problem. muppet gave this example: Consider a hierarchy with three types A, B and C. A is a child of B and B is a child of C: C +-- B +-- A If, for some reason, these were registered in the order C, A, B, things would break if we did the ancestry-walking. C gets registered first and immediately. Then A gets registered, and the bindings would try to find a known ancestor by walking up the hierarchy. At this point, B is not known, so C is chosen and A is set up to inherit from C. It's only after this that B gets registered. A is never set up to inherit from B. The only possibility to solve this issue in an automagical way seems to be to do what pygtk does: Register types lazily as they are encountered and use prefix guessing and name mangling to find out how to map g_type_name to class names. This guessing and mangling can't be done in a reliable and extensible way. So we[1] decided to use the manual approach. [1] Well, the other guys, I wasn't actually around at that time. about dealing with the breakage you outlined. from the last ~2 months worth of discussion on this topic, it should be clear by now that not everyone can be pleased with or without the current changes and variations thereof. In addition to that, I'd link to bring up the issue of the why again. As far as I understand it, the original motivation for making GObject floatable is to have this functionality in GLib once and for all -- to keep people from having to reinvent the wheel over and over again just to get sink functionality. The point that I think you haven't really addressed yet, and that muppet already brought up, is why GtkObject's ancestry absolutely positively needs to be changed in the middle of an API stable series (2.x). Why would it not suffice to add the floating stuff to GLib in some way but keep the implementation in GtkObject untouched for now? You had to introduce quite a few ugly compatibility hacks to support different version combinations; the Perl bindings and possibly other things break -- does the desire to get rid of some code duplication really justify this? Not commenting on the absolute necessity of changing the hierarchy, but do you think it will be possible to do a release of the perl bindings that works with both the old and the new hierarchy ? I'm asking because I want to do a stable gtk release soon, and I don't want it to break the perl bindings without at least a fix release in sight... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
Emmanuele Bassi wrote: Hi, On Wed, 2005-12-28 at 12:45 -0500, Havoc Pennington wrote: On Thu, 2005-12-22 at 19:02 +0100, Tim Janik wrote: in fact, there is no technical reason for this. so many people have argued this to be better though (havoc even went so far as to argue why this would be conceptually neccessary), that i decided to simply sponsor an object type if that helps the majority to understand which objects are floating and which are not. Not that it's all that relevant ;-) but I also thought a flag in the class would be fine (and I thought a separate class would be fine too), just seems to me it should be somehow marked. James made a good point that right now it's already poorly marked, but why make it worse... Instead of having a useless class, there just for making it obvious that the object is floating, can't we add a class flag, like: void g_type_class_set_is_initially_unowned (gpointer *klass); and let gtk-doc catch this like it catches other class-level stuff like properties and signals? This way, all the properly documented classes will get a paragraph in the documentation saying Warning, warning, Will Robinson: this object has a floating reference when created. This way we would avoid unnecessary binding breakage like what happenend with the Perl bindings, and a warning for the users of the library. This sounds a lot more sensible than a new class. If some non-constructor function gives you a GObject, the distinction between a GObject and GUnowned doesn't tell you anything -- it only tells you about initial conditions. Also, modelling the state of the initial reference through inheritance doesn't seem to account for GtkWindow and its subtypes, which derive from GtkObject (which would be a GUnowned subclass), but don't start with a single floating reference to begin with. James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
On Thu, 2005-12-22 at 17:49 +0100, Tim Janik wrote: GtkObject derives from GUnowned This breaks the Perl bindings of GTK+. Our GTK+ bindings register GtkObject with our GLib bindings at start up. This involves associating it with the namespace Gtk2::Object and it usually also means setting up inheritance so that Gtk2::Object is a Glib::Object. For that, the GLib bindings look at the parent of the type and, if it is known to the bindings, put the associated namespace into Perl's inheritance mechanism. GInitiallyUnowned is not known to our GLib bindings, though, which results in Gtk2::Object having no ancestor. That in turn means that things like windows, containers, etc. are no Glib::Object -- they don't have access to, say, the signal and property API anymore. This breaks every non-trivial Gtk2-Perl program. Even if we added support for GInitiallyUnowned now, older versions of our bindings would still break if the underlying GLib is updated without also updating the bindings. Now, you could argue that our bindings should really walk up the whole ancestry until something known is reached instead of just looking at the direct parent. And I would probably agree; this has caused us problems in a different context as well. However, the current approach works with all combinations of GLib 2.[02468] and GTK+ 2.[02468]. The only thing it assumes is that the object hierarchy doesn't suddenly contain unknown types, which is, I think, a sensible assumption. For reference, the code that implements the described approach is in gperl_register_object: http://cvs.sourceforge.net/viewcvs.py/gtk2-perl/gtk2-perl-xs/Glib/GObject.xs?rev=1.53view=markup The GTK+ bindings use gperl_register_object (GTK_TYPE_OBJECT, Gtk2::Object) to register the type. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
Hi, On Wed, 2005-12-28 at 12:45 -0500, Havoc Pennington wrote: On Thu, 2005-12-22 at 19:02 +0100, Tim Janik wrote: in fact, there is no technical reason for this. so many people have argued this to be better though (havoc even went so far as to argue why this would be conceptually neccessary), that i decided to simply sponsor an object type if that helps the majority to understand which objects are floating and which are not. Not that it's all that relevant ;-) but I also thought a flag in the class would be fine (and I thought a separate class would be fine too), just seems to me it should be somehow marked. James made a good point that right now it's already poorly marked, but why make it worse... Instead of having a useless class, there just for making it obvious that the object is floating, can't we add a class flag, like: void g_type_class_set_is_initially_unowned (gpointer *klass); and let gtk-doc catch this like it catches other class-level stuff like properties and signals? This way, all the properly documented classes will get a paragraph in the documentation saying Warning, warning, Will Robinson: this object has a floating reference when created. This way we would avoid unnecessary binding breakage like what happenend with the Perl bindings, and a warning for the users of the library. Ciao, Emmanuele. -- Emmanuele Bassi - [EMAIL PROTECTED] Log: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
On Dec 31, 2005, at 7:56 AM, Emmanuele Bassi wrote: Hi, On Wed, 2005-12-28 at 12:45 -0500, Havoc Pennington wrote: On Thu, 2005-12-22 at 19:02 +0100, Tim Janik wrote: in fact, there is no technical reason for this. Not that it's all that relevant ;-) but I also thought a flag in the class would be fine (and I thought a separate class would be fine too),... Instead of having a useless class, there just for making it obvious that the object is floating, can't we add a class flag, like: Pardon me butting in with my possible stupidity, but what's wrong with leaving GtkObject alone and adding GFloatableObject/ GInitiallyUnowned/GSomeGoodNameForObjectWithFloatingFlag as a sibling, a child of GObject? I fully understand the desire to provide the floating semantic implementation in a common place to avoid multiple reimplementations. However, trying to changing the underlying implementation of GtkObject in the middle of a stable API / ABI series is difficult and dangerous! Given this, is it absolutely, unavoidably necessary to push the implementation of GtkObject's floating flag down to GObject? Is it really so terrible to have two floating implementations in existence, a reusable one in libgobject, and a legacy one in libgtk? - Changing the ancestry of an object can break old code and encodes the implicit knowledge of the ancestry, so adding GInitiallyUnowned between GObject and GtkObject is bad. - Adding floating machinery and semantics to GObject is confusing because it adds ambiguity to the semantics of usage of GObjects, so just adding a floating flag to GObject itself is bad. Sounds to me like the best solution is GObject (non-floating, unchanged from current impl) +--- GtkObject (adds floating and flags, unchanged from current impl) +--- GFloater (new object, adds floating semantics) And then, in gtk+ 3.x, GtkObject can be removed altogether and replaced with GFloater, or whatever it's called. -- However, like all drugs, PANEXA can produce some notable side effects, all of which are probably really, really terrific and nothing that anyone should be concerned about, let alone notify any medical regulatory commission about. -- http://www.panexa.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
On Thu, 2005-12-22 at 19:02 +0100, Tim Janik wrote: in fact, there is no technical reason for this. so many people have argued this to be better though (havoc even went so far as to argue why this would be conceptually neccessary), that i decided to simply sponsor an object type if that helps the majority to understand which objects are floating and which are not. Not that it's all that relevant ;-) but I also thought a flag in the class would be fine (and I thought a separate class would be fine too), just seems to me it should be somehow marked. James made a good point that right now it's already poorly marked, but why make it worse... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_object_ref_sink and GUnowned
as a result of the recent GTK_FLOATING broken in 2.9? discussion: http://mail.gnome.org/archives/gtk-devel-list/2005-December/msg00107.html as well as the ABI and API for g_object_ref_sink() discussion: http://mail.gnome.org/archives/gtk-devel-list/2005-December/msg00174.html i've now changed CVS accordingly, so: - gtk+ = 2.8 + glib = 2.8 GObject is initially non floating; GtkObject is initially floating as always - gtk+ = 2.8.10 + glib = 2.10, GObject is initially non floating; GObject offers floating API: g_object_is_floating(), g_object_ref_sink(), g_object_force_floating() GUnowned derives from GObject, has intiially a floating ref_count. GtkObject derives from GUnowned, so is initially floating as always for GtkObjects, the floating flag is stored as GtkObject.flagsGTK_FLOATING so it stays binary compatible wrg to GTK_FLOATING flags pokage. - gtk+ = 2.10 the GTK_FLOATING, GTK_OBJECT_SET/UNSET_FLAGS APIs are deprecated --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
On Thu, 2005-12-22 at 17:49 +0100, Tim Janik wrote: GUnowned derives from GObject, has intiially a floating ref_count. I hate to quibble names, but it seems really strange to have a class GUnowned where instances are normally owned. (In fact, the goal of anybody using a GUnowned has to be to get someone to own it.) GInitiallyUnowned Is long, but since it doesn't have any methods, that shouldn't matter. I don't fully understand the point of having a class rather than some other way of marking class behavior, but I haven't followed the conversation in detail. Regards, Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
Tim Janik wrote: in fact, there is no technical reason for this. so many people have argued this to be better though (havoc even went so far as to argue why this would be conceptually neccessary), that i decided to simply sponsor an object type if that helps the majority to understand which objects are floating and which are not. Just curious, how it will prevent someone from using floating reference in GObject-not-GUnowned-derived object? This fuzz was not about names, it was about what do I do with this instance of GObject-derived class. Introducing fancy class with fancy name doesn't change things for GtkTreeModel, for example. Those who proposed separate class proposed floating reference to be implemented in this class; they did not ask to add one more class for sake of nice name or something. Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref_sink and GUnowned
On Thu, 22 Dec 2005, Yevgen Muntyan wrote: Tim Janik wrote: in fact, there is no technical reason for this. so many people have argued this to be better though (havoc even went so far as to argue why this would be conceptually neccessary), that i decided to simply sponsor an object type if that helps the majority to understand which objects are floating and which are not. Just curious, how it will prevent someone from using floating reference in GObject-not-GUnowned-derived object? not GInitiallyUnowned derived objects have no floating reference, so there's nothing there that could be used. Merry Christmas. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
