Re: Running several drivers with pictogram support

Am 09.11.2011 04:15, schrieb Stefan Herdler:
> Hi,
> Am 08.11.2011 20:53, Markus Dolze wrote:
>> On 03.11.2011 02:38, Stefan Herdler wrote:
>>> Hi,
>>> Am 30.10.2011 13:10, Markus Dolze wrote:
>>>> * 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.
>> Hi,
>>
>> I want to stress that topic even more.
>>
>> We need to keep in mind that it *is* possible and valid to load and run
>> several different drivers at the same time.
> Really? I haven't found anything in the documentation about that.
>
> Are all Displays showing the same content or are they grouped to one 
> big display like it is possible with the hd44780?
> And what happens if the Displays doesn't have different sizes?
> Well, I guess, I try it out in the next days.
>
> .... now I know what purpose the loops in the drivers file have.
>>   In this case two drivers
>> that assign a different type to the same pictogram name are a problem as
>> LCDd core won't know which syntax shall be treated as correct.
> I guess in my implementation (see next mail) the core would use the 
> syntax of the last driver.
>> We need to state if
>>
>> a) Loading multiple drivers that support pictograms shall be allowed (I
>> say: yes) or
>> b) it should be prevented.
>>
>> If a) then core should accept either
>>
>> c)  all pictograms supported by all loaded drivers (superset) and ignore
>> errors from those that don't support one of these or
>> d)  the common subset of pictograms supports by all loaded drivers (I
>> say: yes). In this case clients can make alternate decisions for those
>> pictograms not supported.
>>

Ah, I would say the union of the pictograms supported by all loaded 
driver counts. Example: One display with time symbols only, the other 
display with weather symbols. If anybody really builds in two displays 
chances are given that the display features complement each other.  
Intersection would mean that no pictogram is visible.

Another example commonly in use will probably an setup of two very 
similar displays just in order to display more information. Then the 
question of union or intersection of supported pictogram sets plays an 
minor role.

> The main problem isn't the server, it's the client, I think!
> Configuring a client with different displays, different named icons 
> used for the purpose, equal named icons with a different feature type 
> and some special features too, would be a nightmare.

Why are there equal named icons for the different purposes, and 
different named icons for the same purpose?

I *strongly* urge to define a common set of mandatory icon names, 
together with instances. Otherwise programming of clients and their 
usage are inconvenient. How would you write an application, say an 
extension to a personal video recorder, that has a chance to be widely 
spread and commonly accepted by users? I have tried to explain the 
consequences in one of my previous e-mails.

Stefan has given in a following e-mail an example implemenation 
containing the lines, which reflect the core idea:

+	static ExtraFunctionTable icons[NUMBER_OF_ICONS+1] = {
+	{ EXTRA_FUNC_ICON, "play" },
+	{ EXTRA_FUNC_ICON, "pause" },
+	{ EXTRA_FUNC_ICON, "record" },
+	{ EXTRA_FUNC_ICON, "mailer" },
+	{ EXTRA_FUNC_ICON, "at" },
+	{ EXTRA_FUNC_ICON, "mute" },
+	{ EXTRA_FUNC_BAR, "antenna" },
+	{ EXTRA_FUNC_BAR, "volume" },
+	{ EXTRA_FUNC_RESERVED, "end of icon list" } };

I _do_ understand the idea and I _do_ understand the motivation. Very 
extensible, very driver friendly, only a few icon types, very generic.

But let me explicitly ask the question: /Do we intentionally accept the 
consequences for client programmers and client users? /

One aspect of this question: How can I develop an application using 
LCDproc that runs on as many hardware setups as possible?

Particularly I do not have skilled programmers in mind writing their own 
application solving their own concerns. Instead, I see an Ubuntu user 
willing to adapt very few configuration files at most.

Please take the question seriously. Really, I accept your solution and I 
do not want to oppose at all cost; no offence at all. But I want to make 
sure you got my concerns.

Regards,
Wolfgang

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc