[Lcdproc] How to handle separate icon area on LCD/VFD glass

[Peter Marschall]

Hi Arthur,

On Thursday, 18. December 2008, Arthur van Dongen wrote:
> I searched the net for the best way to implement icons, but the
> contributions are either focused on LEDs attached to a small number of
> GPIO ports of the display, or drawing custom characters on the LCD dot
> matrix. The current drivers for MD8800 and ShuttleVFD already attempt to
> support the icons, but implement the other interface.

LCDproc currently supports icon widgets.
These widgets can be placed on the display inside the "regular"
display area (i.e. at specific positions among the text).

This is one of the core features of LCDproc, used by other features,
and cannot easily be replaced.

So, the "icon" widget is out of reach for your ideas.

> Currently both implementations do not fulfill the (my) requirements, and
> I see the need for an extension to the protocols. Back to the drawing
> table....

Let me play devil's advocate, and ask questions, bring 
counter-arguments, ... ;-)

> Requirements
> ============
> * Device-independent interface from client to server. If a client wants
> to light the "Play" light on the display, it does not need to know if it
> is implemented by a GPIO output attached to a LED or by a triangular LCD
> segment somewehere on the glass.

This is only true, if e.g. the PLAY icon is not required to be at a specific 
position. You assume the icon is always context free.

How can programmers of clients know what external icons are available and 
where they are placed in relation to the regular text.

> * Extensible. If a new LCD or VFD display appears that has a new set of
> icons, it should not require much effort to add support.

What about displays that do not support such external icons ?
Shall the clients on those displays leave e.g. the last line empty ?

> * Special handling of grouped segments. For example, both VFDs have a
> "Volume" region, with different number of bars. The client can be hidden
> from this detail by allowing a "volume 50%" command.

Hmm, this is much more than an a simple icon.
It 

> * Queryable. A client can request whether an "Envelope" icon is
> supported by the device, and decide to display a "New mail" text based
> on the result of this request.

Here I concur in principle.
But to make the interface generic you need to standardize on names
and properties for these new icons/widgets.

Only with a standardized set of these widgets and their properties clients
can be written that support more than one specific display.

> * Separate control of the icons. One client can control the "Play" icon,
> and another can control the "Envelope" icon.
> * Combined control of icons. Switching from "FF" to "Play" icon should
> be possible in a single command. There is no sense in controlling these
> from different clients.
> * Efficiency. The list of all icon names can only grow, and searching
> for an icon in the list should not take too long. Grouping?
> * Flexibility in defining combined icons. For example an icon set for
> the video source can contain "TV" and "Film" on one device and "DVB-T",
> "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another.
>
> Design outline
> ==============
> Client-Server interface
> -----------------------
> Example:
>  screen_add scrn0
>  widget_add scrn0 iconWidget icon
>  widget_set scrn0 iconWidget 0 0 PLAYMODE.FF
>  widget_set scrn0 iconWidget 0 0 MAIL.OFF
>  widget_set scrn0 iconWidget 0 0 VIDSRC.TV
>  widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat
>
> Server-Device API
> -----------------
> <device>_icon(Driver *drvthis, const char iconDef[]);

Please don't force the individual drivers to interpret text.
This is up to the server core so that it can be done once (and correctly).

What about the query function ?

> When using icon names of the form GROUP.SELECTION and passing this
> unaltered to the driver, the driver can then decide what to do with it.
> I do not know how the screen priorities affect this, when multiple
> clients set icons on the same location.
> The driver should split the GROUP from the SELECTION and parse these. If
> they are known the driver can turn on the right segments in the group,
> and otherwise revert to a default. Using partial matching, like the TV
> and TV_SAT selection, the driver can revert to a more common icon.

Drivers have no notion of clients & client screens, so 
doing the grouping in the driver cannot work.

BTW how do screen changes (every x seconds) interact with the
extended icons?

> So what do you experts think? Am I heading in the right direction?
>
> Thanks for any corrections, ideas, directions, eye openers and other
> info ;-)

As I wrote above, changing the icon widget is not possible.
Changing the protocol will also not happen inside the 0.5 series.

I can understand your pain, but from a "harmonization" point of
view, I consider the extended icons on the different displays
too different to be able to get a common system.

So, for the short term I suggest using the output command
to get the icons.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de