[lcdproc] Widget language
Thu, 29 Mar 2001 16:24:45 +0200
> > 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
The framebuffer should stay on the server side. The server should still
fill the framebuffer. It should just not need to store the widgets
itself. If I look at current clients, they update at least half of the
widgets at every screen-update.
Or the client could request not to erase the screen. It can then
overwrite the existing widgets on the framebuffer.
> 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
No not more complex I think. It just always sends all widgets.
Are there other advantages of having the widgets being managed by the
> > 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 ...).
I like words more. 4-letter words like from ftp are comparable as a
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