[lcdproc] Widget language

[William W. Ferrell]

--TiqCXmo5T1hvSQQg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--- joris@robijn.net's mailer spewed these beefy chunks ---
> OK I've changed the subject line again.=20
>=20
> The language requires a complex design. You need some object storage to=
=20
> store the widget objects on 3 sides: client (must create these strings)=
=20
> , core (should know where to send various widgets and when) and driver=20
> (should render the widgets). That will require to refind objects as you=
=20
> set parameters of them, display them etc. So I don't think this is the=20
> best approach. This would become _HUGE_.
>=20
> Creating screens OK. But then I would say, send the whole bunch of draw=
=20
> commands, and an end-marker (CLOSE).=20
>=20
> And something else, there must be one success/error indication per=20
> command. I suggest using OK or ERROR. Next to that, you can use INFO=20
> for human readable texts.
>=20
> --> NEW TYPE=3DSCREEN ID=3Ds1
> <-- OK ID=3Ds1
> <-- INFO TEXT=3D"Screen created, id=3D1"
> --> OPEN SCREEN=3Ds1
> <-- OK
> <-- INFO TEXT=3D"Screen open, end drawing with a CLOSE"
> --> WIDGET type=3DTitle Position=3D0,0 heartbeat=3Dno value=3D"My Nifty D=
oc"
> <-- OK
> --> WIDGET type=3Dhbar Position=3D0,3 min=3D0 max=3D1000
> <-- OK
> --> WIDGET type=3DMarquee Postion=3D0,1
> <-- OK
> --> WIDGET type=3DText Postion=3D0,2 value=3D"Progress"=20
> <-- OK
> --> WIDGET type=3DText Postion=3D0,-2 value=3D"text aligned from the righ=
t"=20
> <-- OK
> --> WIDGET type=3Dvbar Position=3D19,0 percentage=3D45
> <-- OK
> --> WIDGET type=3DvText Position=3D18,0 text=3D"ABC"
> <-- ERROR CODE=3Dcoords TEXT=3D"The coordinates are invalid"
> --> CLOSE SCREEN=3Ds1
> <-- OK
>=20
> When it receives CLOSE, the driver starts sending it's new framebuffer=20
> to the device.

I like this. Very clean and easy to deal with. Particularly the errors.
I'd written about error messages in the protocol spec rough draft but
hadn't thought of the way you've done it above.

> > > 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...
>=20
> Yeah that's right. But the question remains I think if we should place=20
> this buffer on the core side or on the driver side. I would prefer that=
=20
> last. In the current implementation it's a bit on both sides.

Okay, I'm fine with that; after all if a device driver writer is being
lazy, s/he could always just include something from LCDproc's base code
(perhaps we should implement *generic*, unaccelerated widgets that can
be in some LCDproc-dev package or something).

> > 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:
> >=20
> > <-- INFO: Your screen id=3D2 is on display=3D1.
> > --> [sends updates]
> > <-- None of your screens are on any displays.
> > --> [client misbehaves and sends updates anyway]
> > <-- WARNING: Updated widget is not on any screen.
>=20
> What about:
>=20
> EVENT TYPE=3Dscreen_switch SCREEN=3Ds1 VISIBLE=3Dno
> EVENT TYPE=3Dscreen_switch SCREEN=3Ds2 VISIBLE=3Dyes
> EVENT TYPE=3Dkey_press KEY=3D"+"
>=20
> A driver can then disable sending the updates, and re-enable it when it=
=20
> receives an event with VISIBLE=3Dyes.
> A client does not actively respond to anything, also not to EVENT. But=20
> it can use it to decide to stop sending data, or when there's a=20
> keypress to change it's state or something.

Pretty good. This raises another question: should a "noisy" client be a
warning condition or an error condition? I.e. if the server says "your
screens aren't being shown, so shut up!" and the client keeps belching
data anyway, should the server just warn/ignore, or should it disconnect
the client after a few warnings?

--
William W. Ferrell, Senior System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202   1.303.223.0564

Public key available:
  gpg --keyserver certserver.pgp.com --recv-key 7478FC7A

So far we've managed to avoid turning Perl into APL.  :-)
             -- Larry Wall in <199702251904.LAA28261@wall.org>

--TiqCXmo5T1hvSQQg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq/XEQACgkQgAeqhXR4/HqRGACfSccacDt5eFpijt+qWGtcXV6N
dQQAniJech7+OAZnrdFUp2nmXYgA3fNR
=4vHY
-----END PGP SIGNATURE-----


--TiqCXmo5T1hvSQQg
Content-Type: text/plain; charset=


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