Re: Separate icon area: interface for drivers?

Hi,

-------- Original-Nachricht --------
> Datum: Sat, 29 Oct 2011 22:17:33 +0200
> Von: Wolfgang Hauck <[email protected]>
> An: Stefan Herdler <[email protected]>, Markus Dolze <[email protected]>
> CC: [email protected]
> Betreff: Re: [Lcdproc] Separate icon area: interface for drivers?

> Am 23.10.2011 02:21, schrieb Stefan Herdler:
> > Hi,
> >
> > Am 22.10.2011 09:01, Markus Dolze wrote:
> >>
> >>> 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 Driver would only contain an array like this:
> > (Code for illustration only!)
> >
> > # define bar  1
> > static const icon_type icons[] = {{"name" ,type},
> >                                                {"volume" ,bar},
> >                                                         .....
> >             {"0",0 }};  // < Do we really need that "0 0"?
> >
> >
> > The server has to get a pointer to this array, that's it.
> > I think that is the clearest and best understandable way defining the 
> > Icons of a display.
> > Just type the icon names and types in that array and they are defined.
> >
> > Well, there a few icon names would show up in several drivers, so what.
> > The icons have to defined anyway and this will always result in an 
> > array or something similar in driver.
> > The other advantage of my approach is that the server doesn't contain 
> > a huge (and growing!) list of icon-definitions.
> > This is inefficient especially because most of the defined icons 
> > aren't supported by the actually used display.
> >
...
> >>
> >> 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.
> >>
> > I don't know any display with a bar which could grow either to the 
> > left or right side.
> > I would treat that rare case as a normal bar.
> > 50% is the middle position, that's straight forward I think.
> >
> > If the can grow to both sides at one time with different lengths is it 
> > not one bar.
> > There two independent bars and we should treat them like this.

The imonlcd driver uses bars that grow in both directions. It may be a good idea to handle these like two separate bars anyway.

> 
> Hi!
> 
> So there is common sense on a driver function like (but see my addition 
> at end of mail):
> 
>       * int set_pictogram(PictId id, signed int value)
> 
>           o id identifies the pictogram. PictId should be unsigned int.
> 
>           o value sets the pictogram's value
>               + Range is from 0 to 1000.
>               + Boolean pictograms are switched off with 0 (0..499) and
>                 switched on with 1000 (500..1000).

Please keep it simple. IMHO, boolean type should be just OFF (0) or ON (1). This will keep IF clauses simple and easy to understand. And if ON is 1, 255, or 1000 doesn't matter as server core and drivers should use constants anyway.

>               + Parametric pictograms visualise the value in some way,
>                 which is not specified further.

I don't agree with this. "Not specified further" will result in people use this function in a way not foreseen and difficult to fix or change later as it happened to the output() function.

>               + A negative value highlights the pictogram. Highlighting
>                 is not specified further, it can be implemented as
>                 frame, brightness, colour, blinking, etc.

I'm still not sure if (-1) is a good idea for highlighting. For Boolean type hightlight may also

> 
> 
> The remaining question is: _How to map client's wishes to pictogram 
> identifiers? _
> 
> 

This is exactly what Stefan described in his mail.

Clients will use a text based command like

SET_PICTOGRAM PLAY:ON
SET_PICTOGRAM VOLUME:400

(given that we don't use screens, widgets or the like).

The language parser will then use a table like this to map the pictogram words to pictogram IDs:

struct pictogramentry {
	char *pictogramname;
	int type
	int pictogramid;
}

struct pictogramentry pictogramtable[] = {
	{"ALL", PICT_BOOL, PICT_SW_ALL},
	{"PLAY", PICT_BOOL, PICT_NAVIGATION_SW_PLAY},
	{"VOLUME", PICT_NUM, PICT_LEVEL_LV_BAR}
	...
}

One thing not yet decided is if there will be just ONE such table or if we allow drivers to have their own list.


Assuming that we allow different driver to load within LCDd that support pictograms I see one major disadvantage allowing drivers to specify their own pictogramtable:

* What if two drivers define a different type for the same word? Like one driver defining WLAN as a boolean type and another driver as numeric type (level bar)?

Regards
Markus