The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: 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

Adrian wrote:
> Hi
>
> was just thinking about all this talk re xPL front ends (or a nice
looking
> graphical GUI the respresents the states of certain variables). I can
see
> that a few people having developed there own but of course these would
be
> highly customised to that users environment and not so easy to be used
> elsewhere. (i know code i've written works for me but trying to make
it
> really usable anyway takes time)
>
> I have a concept for a dumb GUI and thought i'd sound people out
(maybe
> inspire someone to write it too as my skills are a little slow (and
finding
> some decent time))
>
> What i was thinging of was (for me in VB6) an application that is made
up of
> a number of screens (for whatever)
>
> each of these has defined
> background image (or more so portions of it can be changed)
> eg if the image represents a room and the light is turned on, the
background
> lightens
>
> clickable areas or icons
> each of these had multiple images (say an on/off button - 2 images one
for
> on, one for off)
> this could have moreof course (like a pressed down image before it
shows the
> on image)
>
> general no clickable bitmaps
> like a scale for dimming - say we have a button (as above) on top of
and
> below this image.
> each press of the up of down buttons changes the general bitmat to
another
> (in this case we might
> have 10 bitmats each representing the 10 different scales
> general text field
> any text can be displaed here
>
> basically, we have a config app which allows you to setup the screens,
> defind the backgrounds, define the buttons and the icons (and there
> location)
>
> hows does this fit into xpl?  When this app come up (excuse me if this
> doesnt guite gell, i'm still learning about xpl) I'm not quite sure
how it
> registers itself with xplHAL but could give it a list of icons it has
and
> the number of variations of this (so for one of the clickables it
would just
> say i have a clickable called "but2", it has 2 settings
(but2.1, but2.2), i
> have slider bitmap (10 settings, slider.1   -> slider10)...
>
>>From here we could configure xPLHAL to interact with it say user
presses
> button 1,a xpl-trig is sent saying but2 is pressed, HAL does whatever
this
> button does (turn on light?) and tells the GUI (xpl-CMD?)to change to
the
> second icon. If there was also a screen on the GUI which represented
the
> room with this light, it could also tell it to change the background
image
> on that screen as well so if we went to this different screen, the
> background has aready been changed.
>
> So for anything that changes in HAL, it can tell the GUI which icon
this now
> represents. The GUI has no intelligence, it just shows the icons and
> remembers there state.
>
> I did think that the GUI could just listen the xpl messages and adjust
> itself as needed but this would require more complex setup on the GUI
side
> (having to tell an ICON what to listen for to change).
>
> any comments/other concepts/is this the right track?
>
>
> Adrian
>
> ________________________________________________
> Message sent using UebiMiau 2.7.2
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>

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



xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.