Re: Running several drivers with pictogram support

Am 09.11.2011 23:05, Wolfgang Hauck wrote:
>
> 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.
Both displays will show the same content.
If a user wants a time and a weather with different display content he 
needs to run two instances of the LCDd anyway.

>
> 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.
AFAIK, that is a feature of the hd44780 driver not of the LCDd!

The IMHO only reasonable scenario for two displays on a server is, one 
display on the HTPC and another status display which is in another room.
For example the HTPC is in the livingroom and the second display is next 
to the TV in the bedroom.
>
>> 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?
That was more or less just a thought experiment.

My implementation does not allow two features with the same name on each 
display.
Only with two different displays it might occur.

The "play", "stop", ... icons are a good example for that.
The MDM166A has independent "play", "stop", "record"... icons.
The MD8800 has one multicon that can show "play", "stop",... OR "pause" 
and a separate "record" icon.
That isn't a issue for the client, because the multicons can be 
controlled just like a regular icon. The only restriction is that only 
the last activated one will show up.
>
> I *strongly* urge to define a common set of mandatory icon names,
I totally agree, we need a well documented list of at least the standard 
icons.
But I don't think a cryptic headerfile will fulfill this demand.

What I'm thinking about is something like a HTML-Documentation with 
photos of the Icons and a description, that enables the writer of a new 
driver to choose the right name and feature-type for his icons.

Choosing the right name is important, because the client has to decide 
only on the name and type which feature to use.
For example the "volume" bar on the MDM166a actually isn't a dedicated 
volume bar. It is a vertical bar and a separate "vol" icon somewhere 
left of it.
Both features could be used independently. The bar may also be used to 
indicate the BER of a HTPC-application or the CPU-load.
> 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.
>
It is also easy to maintain, I think.
A short view into a patch and anyone knows which icons are supported and 
which type they have.
 From that and a few photos it is easy to estimate whether the 
allocation is reasonable or not.
> 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?
Quite simple:
Standard features such as the PLAY icon will rarely make problems.
The PLAY icon will be either a Boolean or part of a multi-icon.
Standard features such as these will run on all displays, unless the 
programmer of the driver used suggested names properly.

For special features, the user will probably have to adjust some 
settings and pick the right feature.
But this isn't a problem either, there not so many popular displays with 
icons on the market. They can quite easily be covered by customized 
presets.
For unknown displays the users can also share configuration files via 
internet.
>
> 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
>
Regards,
Stefan

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