[lcdproc] Widget language

Joris Robijn joris@robijn.net
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.

<-- OK ID=s1
<-- INFO TEXT="Screen created, id=1"
<-- OK
<-- INFO TEXT="Screen open, end drawing with a CLOSE"
--> WIDGET type=Title Position=0,0 heartbeat=no value="My Nifty Doc"
<-- OK
--> WIDGET type=hbar Position=0,3 min=0 max=1000
<-- OK
--> WIDGET type=Marquee Postion=0,1
<-- OK
--> WIDGET type=Text Postion=0,2 value="Progress" 
<-- OK
--> WIDGET type=Text Postion=0,-2 value="text aligned from the right" 
<-- OK
--> WIDGET type=vbar Position=19,0 percentage=45
<-- OK
--> WIDGET type=vText Position=18,0 text="ABC"
<-- ERROR CODE=coords TEXT="The coordinates are invalid"
<-- OK

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*
> screens:
> <-- 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.

What about:

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 <joris@robijn.net>
 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