Next][Thread Prev][Thread Next][Message
RE: xPL Frontend concept?
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
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
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.
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Gerry Duprey
Sent: 04 September 2005 14:54
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
I can't see the GUI needing xPLHAL to do much work though. While the
interface is "dumb" (meaning little embedded knowledge of the
it is xPL aware and as such, xPL messages can be "bound" to
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
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
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
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
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).
xPL Main Index |
xPL Thread Index |
xPL Home |