GNOME Bugzilla – Bug 573493
suggest call-out for GObject "constructor" func
Last modified: 2021-07-05 12:22:07 UTC
With Perl-Gtk 1.200 and Gtk 2.12.11 the foo.pl below gets an error GLib-GObject-CRITICAL **: g_object_set_property: assertion `G_IS_OBJECT (object)' failed at foo.pl line 12. I believe GtkFileChooserDialog dispatches chooser properties like 'action' to its child GtkFileChooserWidget, but that widget is only created by the GtkFileChooserDialog "class->constructor" func and is thus not available in a subclass INIT_INSTANCE. It'd be good to have a way to run code in the constructor() stage of a subclass. The gobject docs say this is supposed to be rarely needed, but cooperating with what a superclass like GtkFileChooserDialog does in a constructor() would be a good use. If the docs are to be believed constructor stuff normally runs bottom-up, ie. the first thing you do is call to the superclass constructor. In theory it looks like maybe you could mangle the GObjectConstructParam pspec+values going to the superclass, or something like that. So maybe an arbitrarily chainable scheme could be wanted, at least eventually. The workaround I got to for a perl subclass of GtkFileChooserDialog was to make my own new(), and set ChooserWidget properties in there. Of course subclassed new() is outside the GObject mechanism, not reached by non-Perl constructor code. For example making such a subclass with the GtkBuilder mechanism doesn't reach that new() code.
Created attachment 129695 [details] failing ChooserDialog subclass program
Created attachment 129778 [details] GObject constructor and constructed discussion This came up about two years ago in a discussion between Emmanuele, muppet, and me. I don't recall every detail now, but I think the conclusion was that it is better to have a CONSTRUCTED that mimics GObject::constructed. I attach the mail discussion in HTML form (converted by mhonarc). Can you see a way out of this labyrinth?
Me? Nope, it's a maze of twisty passages. The construct-only properties was something I wondered about too, but don't really need. I see the bit about how a vfunc can find its superclass came up yet again. That seems like a hydra. If the C funcs have to implicitly know their superclass it might be necessary to build a new func for each subclass at runtime. Not hard to make some asm bytes, but being thread-safe, portable, and coping with normally no-exec data segments could be painful.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME?utf8=%E2%9C%93&filter=perl- Thank you for your understanding and your help.