Re: xPL Frontend concept?

[Gerry Duprey <gerry@xxxxxxxxxxx>]

> What I was thinking was maximum flexibility, to be honest - if we are
> all thinking towards ther same sorts of thing, what strikes me as
> important is a standard format for describing the widgets, their
> placement, and the actions they perform.

All my panel definitions are stored as XML files that include the actions,
widget positions, background images (panel drawings/artwork), etc  Each
panel has it's own XML file.    Technically, you could create the XML with
any tool, though I think it would be more difficult than using the integral
GUI designer.

> You could therefore have actions which operate as you describe
> (basically, send an xpl message), or launch an external app,

The actions mechanism I've worked out allows each "widget" to
cause any
number of actions to be done when the widget is activated.  Stock actions I
have so far are things like send an xPL message, run a program, shutdown
the
GUI, return to the home panel, backup a panel, jump to a panel, reboot,
etc.

The actions are all based on a common actions implementation, so anyone can
implement additional actions and add them in and immediately have the
engine
know about them, show them as options and be able to execute them.  So
under
windows, if you wanted some action that sent keystrokes to a certain
window,
you could easily extend the template action and add in logic like that.
Simply drop the new action code into the actions/ subdirectory and the app
will dynamically load it and add it to it's repertoire.

Widgets are the same way (extend a basic one and write your own code, then
have the GUI dynamically discover/load it).

Each widget has at least one "state".  Each state has a list of
0-n actions.
A simple momentary button would probably have one state (button pressed)
and when pressed, all actions for that state would be executed in the order
specified.

A toggle button (press on, press again for off), would have two states and
each state could have as many independent actions as needed.

Other widgets (like radio buttons/multi-choice buttons, combo-boxes, etc)
would have many states and the ability to have many discrete actions.

> or tell
> xplhal to do something directly (like set a variable, run a
determinator
> etc).

Hmmm...

Well, while I probably won't have a means to talk to non-xPL based devices
at first, it would be pretty easy to write a custom action that did know
how
to talk to xPLHAL.

> If we got a standard format together, you have the delicious
possibility
> of cross platform support - you end up with a client app like Adrian
> describes that loads up previously drawn control "screens"
which render
> pretty much the same across platforms..

Well, as you know, cross platform is my mantra, so rest assured anything I
produce will be cross platform by default :-)

> So, if you had an xplhal server on the networkl and wanted to use it,
> you could create screens which did a mix of widgets, some sending xpl
> messages themselves, some talking to xplhal... And if you wanted a

I guess this is an area of xPLHAL I don't really know about (being a linux
and mac person primarily).  Is there any reason that xPLHAL
commands/control
can't be done via xPL packets directed at the xPLHAL program vs a non-xPL
command channel?

When I first started the xPL4Java container (server to running xPL4Java
applications), I made the container have a different configuration method
and communication process than xPL.  I've regretted this over and over and
in the 1.2 xPL4Java, I removed 90% of that and moved all control/command
functions for the container to xPL based messages (some remain, but will be
purged out in the next release).  Doing this opened up a bunch of options I
really hadn't even thought of before hand.

Not suggesting xPLHAL change its way (or that one is way is right or
wrong),
but juts sharing my thoughts and limited (compared to xPLHAL) experience on
the topic :-)

Gerry

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org