Re: widget valid signals and properties
- From: Grant McLean <grant mclean net nz>
- To: Dirk Koopman <djk tobit co uk>
- Cc: GTK2-Perl List <gtk-perl-list gnome org>
- Subject: Re: widget valid signals and properties
- Date: Thu, 27 Jul 2006 21:26:27 +1200
On Wed, 2006-07-26 at 11:42 +0100, Dirk Koopman wrote:
On Wed, 2006-07-26 at 22:12 +1200, Grant McLean wrote:
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.
I'm obviously missing something but as you seem determined to rob the
end-user of any advantages a GUI app could potentially offer, why don't
you just do it as a web application? That way you'd centralise code
deployment and maintenance to a single server and wouldn't have to worry
about getting Perl and GUI libraries out to the users' desktops.
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
necessary).
While I can understand not wanting to write XML by hand (which I'm
pretty sure no one was suggesting), I fail to see that SGML gives you
much advantage. Why not just define them as a Perl data structure?
Some might argue that YAML would be even simpler.
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.
That doesn't sound easy to extend at all. Instead of having small
pieces of code related to handling each type of signal in their own
methods, you're planning to lump them all into one big method per widget
type? Either that or your handler method is going to do so little that
you might as well use a web form.
I would definitely be interested in seeing what you've produced when you
get it working. I'm obviously misunderstanding something.
Regards
Grant
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]