Re: widget valid signals and properties

On Wed, 2006-07-26 at 22:12 +1200, Grant McLean wrote:
On Tue, 2006-07-25 at 21:33 -0400, muppet wrote: 
On Jul 25, 2006, at 4:59 PM, Dirk Koopman wrote:

1. How do I get a list of valid properties and signals for a widget?

Glib::Type::list_signals() and Glib::Object::list_properties().  See  
the Glib::Type and Glib::Object manpages.

For each named widget, the code then uses Glib::Type::list_signals and
Glib::Type::list_ancestors to find all the signals that that widget
could emit.

For each named widget (e.g.: 'first_name') and each signal (e.g.:
'activate'), the code checks if the object has a method called
<widget_name>_<signal_name> (eg: if $app->can('first_name_activate') )
and if it does, the method is hooked up using signal_connect.

It might be the craziest idea I've come up with this week.  But it could
be useful.

Nope, not crazy (or at least: no crazier than me), that is more or less
exactly what I am doing. Except that for common cases like this it would
be simply called 'first_name'. Exceptional (non-common case) signal
handlers would have the signal name appended as per your example.

However, not using glade, nor even xml, but boring old HTML::Parser,
'cos I want to write the screens by hand in a simple sgml type form (but
without all anality of closing tags and " and ' where it really isn't

All subs that implement custom tags work as your example as well so a
<vbox> handler is $parser->can('handle_vbox') so it is very (very) easy
to extend.

All with the relaxed html style that HTML::Parser allows.



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