[Lcdproc] Separate icon area: interface for drivers?

Thu Nov 3 01:38:50 UTC 2011

Hi,
Am 30.10.2011 13:10, Markus Dolze wrote:
> Hi,
>
> -------- Original-Nachricht --------
>    
>> 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.
>    
0 = OFF, every thing else is ON, that's my suggestion.
>    
>>                + 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.
>
>    
Perhaps we should define a "reserved" icon type to cover that case.
The clients should ignore such icons unless the programmer really knows 
what it is for.

I thinking about a kind of sandbox for developing or to control some 
exotic features of the display.
A new icon-type could be assigned later if there is a demand for it.
>    
>>                + 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
>    
In my opinion highlighting is a feature that makes it much easier for 
client-programmer to get attention to a specific icon.
Many mail-icons are prepared to show new mail in some way and if not a 
blinking icon would indicate that as well.

Values below 0 are not used by Boolean nor percent Values.
I don't see any other useful application for negative Values on Boolean 
or bar-icons.
And if anyone has a better idea how to indicate highlighting let it us know.

If we find an icon which needs negative Values we are free to assign a 
new icon-type for it.
This is recommend anyway because the clients needs to know, this this 
icon is not a regular bar or whatever icon.
>    
>> 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)?
>    
Nothing will happen.
The client has to verify the availability of an icon before using it. 
The test has to include the icontype.

A client searching for a WLAN-bartype-icon wont find one on a Display 
with a WLAN-booltype-icon.
So nothing will happen and the icon stays dark.

A driver with fancy icon names which are not supported by the clients is 
pointless.
Thant circumstance will force the drivers programmer to use the 
recommended names for his icons.

But with your question pointed to the main problem I think, which is 
finding the right name for an icon.
The icons on the different displays are similar, but not identical. That 
makes it some times hard to find a descriptive and universal name.

The WLAN-bartype-icon is a good example:
An antenna like symbol with some "radiation bars" around is not 
WLAN-bartype-icon. It could be used other purposes as well, DVBT for 
example. A good name would be antenna(-bartype-icon) that describes 
exactly how the icon looks.

A "correct" WLAN-bartype-icon would be a bar which is directly marked 
WLAN or an WLAN-symbol.

The  same problem do we have with CD DVD blueray... icons.
An optical disc like icon is not a DVD-icon, its just an 
optical-disc-icon. A DVD-icon has somehow explicitly marked as DVD-icon, 
with the letters DVD for example.
Imagine a display with one optical disc like icon and icons with the 
letters DVD, CD beneath. The client has to light the optical-disc icon 
and the DVD-icon when playing a DVD. When playing a blueray it may only 
light the optical-disc icon lack of a blueray-icon.

Yes I know, that sounds pedantic, but it ts the only way to prevent 
confusions without limiting the protocol unnecessarily.
And I think, we need some good documentation of the icons. Preferred 
with photos.

Regards
Stefan
> Regards
> Markus
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>    