LCDproc development and user support list

Text archives Help

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

Chronological Thread 
  • From: herdler at (Stefan Herdler)
  • Subject: [Lcdproc] [Fwd: Re: How to handle separate icon area on LCD/VFD glass]
  • Date: Wed, 07 Jan 2009 01:17:26 +0100

Arthur van Dongen wrote:
> [...]
>>> * 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.
I don't see a problem if the names of the icons are not 100% standardized.

The standard icons like "play" are common on these displays.
And defining different names for the same icon in different drivers
doesn't make much sense to me.

For the display specific icons you have to write a extra client anyway.
Or make some icons configurable in the client, which isn't a big deal, I
>>> * 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).
> You've got a point here. But the alternative is using a set of
> predefined constants, and that is much less expandable. For now I vote
> for using strings. This can be reasonable efficient by doing a two-step
> comparison of the group ("PLAYMODE") and member ("FF") parts.
What do you think about defining the names of the icons in a header file
of the driver?

So the driver gets a number (64 or more?) of commands for icons (or
whatever) which can be named individual.

Only the command types had to be standardized and the interpretation
could be done in the server core.
(I'm thinking about something like "boolean", "int", "icon"(on, off and
blinking) , "bargraph" and the "play indicator".)
> [...]
>> 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.I have considered that, of course. But there are a few
> cons to this
> approach:
> - the current output() commands provides 32 bits, and my displays have
> 29 and 33 segments. Only 20 of them are common. Extending to 64 bits
> would only give some room for now but we would hit this limit sooner or
> later.
> - The clients can call the output functions, but only if they have
> knowledge about which bit means what. This is something only the driver
> can know, and sometimes not even at compile time. Consider the case if
> the GPIOs of a LCD display are connected to LEDs by an integrator, then
> this is something that could be specified in the driver config section.
> - I was looking for some mechanism that is future-proof and can be used
> by any client and any driver that supports this in any way.
- The client programmer has to dive into the documentation of every
display he wants to support.
Having different icon names would be much easier to handle.
Changing icon names in a configfile could even be done by any
experienced a user.

>> Regards
>> Peter
> Thanks,
> Arthur
> ------------------------------------------------------------------------
> _______________________________________________
> LCDproc mailing list
> LCDproc at

  • [Lcdproc] [Fwd: Re: How to handle separate icon area on LCD/VFD glass], Stefan Herdler, 01/07/2009

Archive powered by MHonArc 2.6.18.

Top of page