[Lcdproc] Separate icon area: interface for drivers?

[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 driver-function (one for all icon-types) which is called by the 
server to put the icons on the screen can be kept very simple and slim:

function set_Icon( unsigned char Icon_Number, int Icon_Value) {
// "Icon_Number" : position in the array
// "Icon_Value" : value to set

switch(Icon_Number)
....
}
>> 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.
>
>    
It is not absolutely necessary for operation.
But it will help to make the client smarter selecting icons, especially 
if it is a client with user interaction.

For example if the client needs a bar-type icon to show the 
wlan-strength, but the display doesn't have icons named "antenna" nor 
"wlan". If it knows which icons are bar-type-icons it could choose an 
other unused bar-type-icon.
If the client has a configuration-menu (like the VDR-LCDproc-client) it 
could suppress all non fitting icons for a function which is much more 
convenient for the user.
>
> 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.
> 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?
>
>    
At this point I just wanted to explain my needs as driver programmer.

Regards
Stefan