Re: Running several drivers with pictogram support

Hi!
On 09.11.2011 07:36, Markus Dolze wrote:
>
>>> 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.
>>>
>>>        
>> A client would switch all Icons on all displays at the same time.
>> Is that intended that way?
>>
>>
>>      
> If we define it to be, yes.
>    
Of course, we could define it that way.
But does it make sense?

I haven't used more then one driver so far, so I don't know how this 
mode works.
If all Displays show the same contents it may make sens to show the same 
Icons too. Otherwise not.


The simplest solution would be to add a display descriptor to every feature.
Something like "disp1_", the play icon of the first display would become 
"disp1_play" or "disp1 play".

That could be easily archived with a minimum of code in the server and 
the client(s) would be able to address every feature(icon) of every 
display individually.
A mode which sets the icons on several identical displays simultaneously 
would be also easy to add.

As I said before, most of the users don't even know that it would be 
possible to use more then one display.
Why wasting more time with a much more complicated solution which would 
limit most of the users, if the small rest would be satisfied with the 
simple solution?
Apart from that it would be interesting if the multiple driver issue 
would be real problem or it would be stay an academical one, because the 
combination almost isn't used in real live service.
But for me as single display user it is hard to assess that things.




Regards
Stefan