Re: widget valid signals and properties

[Dirk Koopman <djk tobit co uk>]

On Thu, 2006-07-27 at 21:26 +1200, Grant McLean wrote:
> 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.

No, not me. But there is very little else one can do with a touch screen
based app in an moving ambulance being operated by people in gloves.

But there is a more serious point: this is a application programming
abstraction that uses Gtk2 as its visualisation method, programmed from
the "business logic" downwards, not the gui upwards.

HTML loses me too much control during the working of the data fields,
plus for other (non-touchscreen) apps, the users don't like "the fill in
the whole form and then find out what they did wrong" paradigm (mind you
they were complaining similarly during the 1970's using IBM 3270s et
al).

However if there was already a GTK2::HTML out there were I could fiddle
about underneath to get more interactivity during the input of the data
(and maybe alter the display formats of things like number entry, that I
can, doing it the way I am), then I would use that.

But it appears that there is no maintained GTK2::HTML out there (I have
looked at and rejected Gtk::HTML).
  
> 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.

Perl data structures to do what is required are too fiddly and would
require too much "inside" knowledge to get correct (I tried it as a
first idea), YAML is not something I have looked at enough to comment on
too much, but looks like it would also fail on the inside knowledge
test.

> > 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.

easy to extend *the parser* for my custom "widgets". If that helps.

> 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.

One should be able (at least thinking is at this stage) for a programmer
to hook onto any signal simply by defining a function with a canonical
name in a module that handles that screen. In fact the whole system is
based on canonical names, whether for screens, fields, actions, signals,
properties, key strokes...

So if a field (in my terms) has the name 'foo' in the screen 'screen' (a
screen is an arbitrary collection of Gtk widgets that implement a piece
of logic) to grab a 'clicked' signal simply define the sub with a
standard name, eg:-

package xxxxx::screen;

# run this screen (in reality, this is a method that lives
# higher up and would only be defined if using a screen name different
# to the one derived from the package name).

sub display
{
        my $self = shift;
        $self->fixup unless $self->fixedup;
        $self->run;
}

# handle any click event on foo
sub foo_signal_clicked
{

} 

# do something if the F1 key is pressed on entry foo
sub foo_key_F1
{

}

# do something if the ESC key is pressed anywhere
sub key_ESC
{

}


The "fixup" method simply does all the connections, properties etc once
on startup. If nothing is defined then all the defaults happen.

Dirk