[lcdproc] Widget language

[Andre Breiler]

On Mon, 26 Mar 2001, Joris Robijn wrote:

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

So we have no layering anymore ?
It looks to me that we loose also the ability to update only a few
elements of the screen (because you would only have a framebuffer).
This mean I have to send all the information again for every screen
change.
So you move over the complete complexity of the screen management
(content) to the client.
I love the current status of lcdd where I can do frames,layering. 
And I don't like the hassle to do it in the client (it's no problem to
write it but the client becomes complex -> longer development)

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

I personaly like the way of the common internet protocols with number data
info (like: 500 id=afcd9bc5 Action denied). The reason is, that I only
have to convert the first 3 chars into a number and this tells me what I
got (info, error, ok, pending, event ...).

[comm snip]
> When it receives CLOSE, the driver starts sending it's new framebuffer 
> to the device.

That's fine.

> > > 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 depends if we have only an framebuffer (no objects etc.) or if we
have objects so that the server can render these objects in different
ways.
For the latter case we don't need a framebuffer (maybe the driver but this
depends on the driver type).
In the first case we need a framebuffer in the server which is transmitted
to the driver after CLOSE.

Bye Andre'
-- 
Andre' Breiler                       |   Tel: +44 1737 839532
BBC Internet Services                | Email: andre.breiler@rd.bbc.co.uk 
Kingswood Warren,Tadworth,Surrey,UK  |   URL: http://support.bbc.co.uk/
Mail me.  Don't phone if possible. And use a Subject line.



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net