On Fri, Aug 20, 2004 at 09:12:09 -0400, muppet wrote:
Jan Hudec said:On Thu, Aug 19, 2004 at 13:24:08 -0400, muppet wrote:Jan Hudec said:Writing custom widgets in Gtk2-perl is easy enough to be useful. What's missing from the distribution is a way to include such widgets in GladeXML files. Therefore I suggest a module to simplify this.this sounds more like a missing feature of the bindings, to be honest. i'd like to see the code for this; did you mean to attach it?I wanted to know whether there is interrest first. I am attaching it now. Libglade (I mean the C interface) is unfortunately greatly broken in this respect. The constructed widget does not get values for the standard widget properties, though they can be set in glade.then how do they get set at all?
They don't. That's the problem. You have to set them in the code. That's why the application using the widget has to provide the constructor.
Thus the Gtk2::Ex::GladeCustom really has to be used by the main program, not the widget implementation. The module should remain optional. Of course, if you think it should be added to Gtk2::GladeXML itself (probably as Gtk2::GladeXML::Custom), i'd not be against that.well, if there's any way we can make it easier to use custom widgets, i'm all for it. another question that comes to mind is how would you handle the names? the glade file should really be portable, not necessarily tied directly to perl; how would you specify the widget class names, then? "My::CustomWidget" or "My__CustomWidget" (which is the actual C name that would get registered by perl)? if you were in a mixed environment and tried to use this glade file from another language where you didn't have that object defined, what would happen? is that something you can even do?
use Gtk2::Ex::GladeCustom name => \&ctor and then use 'name' in the GladeXML file. That way you can have the glade file independent on the language. The fully-qualified name thing is there for quick hacks.
Since any GObject can be constructed with g_object_new, providing a generic method to build call to g_object_newv would be orders of magnitude more useful. Well... someone could write a glade module, but it's a lot of work.i'm not sure i follow you here -- do you mean in libglade or in gtk2-perl?
In libglade. Libglade has a handler routine for each widget type. But it only has a "Custom" handler that calls arbitrary function with 5 parameters. Having another handler to call g_object_newv with arbitrary list of name-value pairs would be useful, but has to be done in libglade itself (a glade module could be written, but that shouldn't be specific to gtk2-perl).
Glib::Object::new() does simply marshal its parameters into g_object_newv()... in fact, the $fn->new(@args) in your code should wind up using that for custom objects that don't override new().
Yes. The hack I included actually allows to use this. But it breaks the independece on language.
incidentally, Glib::Type::package_from_cname() can be used to convert the C name "GtkWidget" from a gladexml file into the perl package name "Gtk2::Widget", but the counterpart cname_from_package() doesn't appear to exist. (that would involve gperl_type_from_package().)
We don't need that.
BTW: I found the set_custom_handler method in the source, but it does not seem to be documented (I have 1.00 from debian installed).as i'm sure you already found, it's just a wrapper for http://developer.gnome.org/doc/API/2.0/libglade/GladeXML.html#glade-set-custom-handler many of these things are not documented because at the time we bound them we didn't fully understand what they did. ;-)
Sure I found. Just it could be mentioned that it exists, so I wouldn't
need to look it up in the code.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature