Re: [RFC] Gtk2::Ex::GladeCustom

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

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

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

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