[Lcdproc] Separate icon area: interface for drivers?

[Markus Dolze]

Hi,

On 22.10.2011 01:55, Stefan Herdler wrote:
> Hello everybody!
>
>
> Since writing the MD8800 driver I am thinking about a "clean" and
> universal useable solution.
> (I guess I was the one who started to (mis)use the output function to
> control the icons. O:-) )
> I'll tell you, my preferred solution would look like:
>
>
> There so many different displays out there, why don't we let the
> drivers define the names of Icons?
> For the common icons we may suggest some recommend icon-names like
> HDD0, HDD1, CD0...
> This open system makes it easy to add new Icons and it is expandable
> for new currently unknown features.

I'd like to avoid this because it will cause copying code from driver to
driver like it is done with the current icon function. If LCDd announces
the available pictograms to the client there is no need for a new
protocol version if drivers writers add new pictograms to the language
in the central place.

>
> The client should be able to get the list of the Icons the Display.
> The List could look somehow like this: "iconname,icontype HDD1,icon
> Volume,bar Antenna,bar Mail,icon ...."
> According to the "icontype" the client knows what functionality each
> Icon provides and could choose which one to use.

I asked myself if it is really necessary to tell the client the
pictogram type at all. If the client does use a pictogram it already
knows what to do with it (as it must have been programmed that way). I
doubt that clients will use unknown pictograms even if they know their type.

>
>
> The server only needs to provide a view generally useable Prototypes.
> Let me explain in a few words what i'm thinking about:
>
> The basic type could be a simple integer type.
> This type of icon (/ special-function) accepts an 32 bit "int"eger value.
> There is no further definition what happens when set.
> This is made intentionally, so the programmer of the Driver is free to
> use this type for his own purposes.
> For example it could be used to tune some exotic functions of the
> display.
>
> The "icon" type accepts one 32 bit integer too. It's basically
> identical to integer type with some additional definitions.
> A value of "0" means "off"
> A value grater 0 means icons is light
> At value below 0 the icons is light and highlighted.
> Depending on the Display this could mean a red frame around, a kind of
> animation or just a blinking Icon.
> Maybe we should also accept keywords like "on" "off" and "highlight".
>
> "Bar"graphs could be controlled similar.
> We only need to define the value of the full Bar.
> I suggest 100 or 1000 so the clients could calculate in percent or
> promille.

Agreed, the value for bars shall be treated relative. Wether it is 100,
1000 or 255 doesn't matter right know. For on/off type, I prefer the
named values "on" "off" in the client language. "highlight" may be an
additional option. Using numbers in the client language should be
possible, too.

> Again a value below 0 activate a kind of highlighting.
> At a antenna like bar this could be "scanning animation" for example.

The use of negative values is something we should think of. I'm not sure
if it should be used for highlighting. But it may be a valid option on
bars to indicate "grow in the opposite direction" for bars which can
grow to left and right.

>
> We could also define a Spectrumanalyzer, which is just a group of bars.
>
>
> I would treat the "play" "record" "stop" ... Icons as separate Icons.
> I don't wart to limit the client in setting these Icons.
> On a HTPC system it is not unusual to activate the "record" and "play"
> Icon at the same time.
> Playing some media with a recording-process in the background would
> result in that condition.

Agreed. I think, altough we talked about pictogram 'groups' there was no
talk that only one may be active at the same time, did we?

>
>
> Btw:
> I own a Futaba MDM166 and I may help adapting this driver.

Nice to know. I have two around here, too.

Regards,
Markus