Re: GtkPlug for Windows

Andrei, >> Either one creates GtkPlug object under normal circumstances. The >> difference appears when you try to subclass GtkPlug class in PHP-land >> and register it as a Gtk+ type. Now, since you have to call parent's >> constructor, the first call would properly get the gtype from your >> custom class and create your custom Gtk+ object. The second call would >> erroneously create GtkPlug. >> >> I think that we do not need the gtk_plug_construct() override. Just >> incorporate that call into the GtkPlug constructor. > The problem is that using the phpg_gtype_from_zval and then trying to > use gtk_plug_construct on it doesn't work - instead it throws Fatal > error: Internal object missing in GtkPlug wrapper - so it's NOT > creating a GtkPlug under normal circumstances - any ideas why this > isn't working? I'd rather have a working implementation that can't be > subclassed in userland than have a non-working version that can :) Elizabeth is right. g_object_new() doesn't work in GtkPlug's case; I assume that's because gtk_plug_new() performs some additional steps that is critical to the widget's functioning. If we can figure what those steps are; we can call g_object_new() and those steps and do away with gtk_plug_new(). For now, however, this seems to be the only way to get the thing to work. As for subclasssing, we can wrap gtk_plug_construct() and mention in the docs that you'd have to use that if they're planning to extend GtkPlug. Or just warn the user as in GtkMessageDialog's case :) -- Anant