Re: Proposed widget type: image

Ethan Dicks <[email protected]> Fri, 21 Feb 2014 11:34:18 -0500
Newsgroups gmane.comp.sysutils.lcdproc
Message-ID <CAALmim=c5wmH6sCdNK1BfGd3v4Cs=3hM6znDczm_gFSOrPkxkA@mail.gmail.com>
On Fri, Feb 21, 2014 at 1:07 AM, Markus Dolze <[email protected]> wrote:
> Still I believe, if we turn LCDproc into a program where the client
> submits a fully client drawn image that is just displayed by the server,
> one should use some other existing program that already has that feature.

I agree we shouldn't turn LCDproc into a simple "display my bitmap"
application, but I've wanted the ability to mix graphics and text for
some time.  The canonical app would be a weather watcher - display
live text from the client of temps, wind-speed, etc., *along with* an
icon showing the weather.  This would would especially well with a
wide graphical display, like a 256x64.  Reserve 64x64 (on this
display) for the WX symbol and use the remaining display space for the
textual weather report.  Of course there would have to be some thought
put into how to add positioning into the LCDproc protocol (because not
all displays have the same aspect ration, absolute pixel height, etc),
but even a "top left" or "middle right" or "dead center" designation
would be useful.  A complicated client could be free to query the
display size and position the image accordingly.

Within limits, this mechanism could work with textual displays that
have reprogrammable elements - in the case of an HD44780-type display,
that limit might be a 2x2 character cell (nominally 16x16 pixels, or
really, 10x14 with gaps) - the client might be told "this is a textual
display" or just told the max image size is 16x16 and the textual
driver does a "best fit" into 4 cells... that part is invisible to the
client program.

Agree, though, that some encoding mechanism for supplying the bitmap
needs to be invented, and probably a mechanism for flushing and/or
verifying a specific named image has or has not already  been
transmitted and stored by the driver (to prevent the recurring
overhead of sending a fistful of these bitmaps over and over "just to
be safe").

However it's done, it's likely to need extensions to the existing
protocol, meaning it should be thought through carefully, not just
hacked up.

And to be clear - I'm envisioning this as a mechanism for displaying a
handful of fixed images to accompany text, not as a backdoor to
unrestricted client-side bitmap display.  As you said, if that's what
you really want, go get a program that does that.

-ethan