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