[lcdproc] Widget language
Mon, 26 Mar 2001 16:46:21 +0200
OK I've changed the subject line again.
The language requires a complex design. You need some object storage to
store the widget objects on 3 sides: client (must create these strings)
, core (should know where to send various widgets and when) and driver
(should render the widgets). That will require to refind objects as you
set parameters of them, display them etc. So I don't think this is the
best approach. This would become _HUGE_.
Creating screens OK. But then I would say, send the whole bunch of draw
commands, and an end-marker (CLOSE).
And something else, there must be one success/error indication per
command. I suggest using OK or ERROR. Next to that, you can use INFO
for human readable texts.
--> NEW TYPE=SCREEN ID=s1
<-- OK ID=s1
<-- INFO TEXT="Screen created, id=1"
--> OPEN SCREEN=s1
<-- INFO TEXT="Screen open, end drawing with a CLOSE"
--> WIDGET type=Title Position=0,0 heartbeat=no value="My Nifty Doc"
--> WIDGET type=hbar Position=0,3 min=0 max=1000
--> WIDGET type=Marquee Postion=0,1
--> WIDGET type=Text Postion=0,2 value="Progress"
--> WIDGET type=Text Postion=0,-2 value="text aligned from the right"
--> WIDGET type=vbar Position=19,0 percentage=45
--> WIDGET type=vText Position=18,0 text="ABC"
<-- ERROR CODE=coords TEXT="The coordinates are invalid"
--> CLOSE SCREEN=s1
When it receives CLOSE, the driver starts sending it's new framebuffer
to the device.
> > Enough of the sample document... server receives it and sends it
> > through a parser, whereupon it goes to a control schema. This control
> > schema understands widgets and virtual screens and various types of
> > formatting text, as well as virtual characters. The control schema
> > formats the widgets into framebuffers, which include all the
> > characters on the screen (usually 80), the backlight state, the
> > contrast state, plus a list of custom characters (usually 8) for any
> > hbar/vbar ops. This control schema also knows how to compromise when
> > the user wants to display both at the same time...
Yeah that's right. But the question remains I think if we should place
this buffer on the core side or on the driver side. I would prefer that
last. In the current implementation it's a bit on both sides.
> This looks great, although I do have one suggestion to add to this mess.
> To reduce network traffic (a bit), it might be nice to tell a client
> when one of its screens is on a display, and when it's not on *any*
> <-- INFO: Your screen id=2 is on display=1.
> --> [sends updates]
> <-- None of your screens are on any displays.
> --> [client misbehaves and sends updates anyway]
> <-- WARNING: Updated widget is not on any screen.
EVENT TYPE=screen_switch SCREEN=s1 VISIBLE=no
EVENT TYPE=screen_switch SCREEN=s2 VISIBLE=yes
EVENT TYPE=key_press KEY="+"
A driver can then disable sending the updates, and re-enable it when it
receives an event with VISIBLE=yes.
A client does not actively respond to anything, also not to EVENT. But
it can use it to decide to stop sending data, or when there's a
keypress to change it's state or something.
Joris Robijn <email@example.com>
Home: 053 4311 553
Mobile: 06 288 41 964
// To understand recursion, we must first understand recursion
To unsubscribe from this list send a blank message to