RE: xPL Frontend concept?

["Ian Lowe" <ian.lowe@xxxxxxxxxxxxxxxxxx>]

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.

You could therefore have actions which operate as you describe
(basically, send an xpl message), or launch an external app, or tell
xplhal to do something directly (like set a variable, run a determinator
etc).

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

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
serverless config (or to use xpl4java scripting) then you could
construct a screen with widgets configured to do this instead.

It's a rather nice concept.

Ian.


-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Gerry Duprey
Sent: 04 September 2005 14:54
To: ukha_xpl@xxxxxxx
Subject: Re: [ukha_xpl] xPL Frontend concept?

Sounds like we are thinking along the same lines.  What you outline is
pretty similar to what I have/am working on (though I'm doing it in
Java).

I can't see the GUI needing xPLHAL to do much work though.  While the
interface is "dumb" (meaning little embedded knowledge of the
system),
it is xPL aware and as such, xPL messages can be "bound" to
widgets on
screen.
For example, you could have a simple label widget that is bound to an
xPL that your temp reading system sends out periodically.  It would be
able to filter the message (based device/schema/etc) and read a named
attribute value from the body and display it (actually, you can display
any portion of the message (source, schema info, target, etc, though
normally it'll be a data item from the message body)).  Each widget, in
addition to having a patternto match xPL messages, has a template for
it's text (actually, or
image) that looks like

myWidget.xPLTemplate = "Temp is %B:TEMP%F"

Where %B:TEMP means replace with a token with a named value
"TEMP" from
the received message body (hence B:TEMP").  There are other tokens as
well including script invocation (if needed) to do more complex stuff
and the ability to have multiple tokens in a template.

Similarly, controls can be bound to an xPL message they send out when a
widget is "activated".  Simple case of pressing a button widget
sending
out an X10 based xPL message to turn on a light.  The button can be a
momentary (press and release and send the same message each time) or
toggle (message sent when pressed the first time, alternate message sent
when pressed a second time).  The button can also be bound to listen to
an xPL message so the button text can be updated when such messages are
received.

You could easily create xPL messages (to send or receive) that do not
match any xPL device on your system.  Such messages could then be used
as determinators for xPLHAL (or a scripting engine).

This is very powerful because all controls extend a base xPL based
control that allows much of this.  So even if you want to create a
control not already in existing, much of the "work" is already
done.

Finally, for certain kinds of operations, the GUI itself is a service
(that is, publishes itself as a device on the xPL network).  This allows
things like telling the GUI to change to a certain frame, blank the
screen, reboot, etc).

Gerry