Re: Highlighting pictograms

Hi!
Am 08.11.2011 20:43, Markus Dolze wrote:
> On 05.11.2011 14:17, Anders wrote:
>    
>> On 11/03/11 02:38, Stefan Herdler wrote:
>>      
>>> And if anyone has a better idea how to indicate highlighting let it us know.
>>>
>>>
>>>        
>> Instead of a single int for each icon, use an array, or a set of
>> properties. That way each icon can have any number of attributes. I
>> could easily see (On/off, Strength, highlighted) etc.  Futhermore, what
>> if an icon is e.g. a square where you can on/off each of the top,
>> bottom, left, right sides individually? If the interface was an array,
>> that functionality could easily be exposed to the application.
>>
>> It seem a bit short sighted to fold everything iconish into a one
>> dimensional abstraction. Why don't we allow the applications to query
>> the caps of the icons and act on those caps? The list of caps could
>> expand as needed over time, and the same query, get, set protocol could
>> be used forever.
>>
>> -A
>>
>>      
Please apologize not answering your mail, it got lost in my spam filter 
somehow.
> Hi,
>
> that makes sound. And there are things like the spinning disc icon of
> the imonlcd driver on which we have not talked in detail yet.
>    
Exactly such Icons I had in mind to use "highlighting" with.

"OFF" -> Icon off
"ON"  -> Icon is illuminated.
"highlighted" -> disc is spinning (and of course illuminated too ;) ).
> We probably need some more advanced data structure in LCDd core.
> However, at the very end the task of the driver is to switch some light
> on or off. If we want to support e.g. RGB colored things, a simple int
> will not be sufficient, but for now I think it's fine.
>    
Do you really think there will be displays with more then 32Bit color? I 
dont!

The highlighting with negative numbers would theoretically be possible 
up to 31Bit.
Playing computer games the difference between 16 and 32Bit is only 
visible in details.
For an icon a 31Bit colorspace  would be enough for ever, I think.

At the other hand, does an icon which could be light in any color with 
any brightness a additional highlighting?
> If we treat "highlighting" as a completely different thing than "the
> value", we may need to define this as an extra property. Then even
> numeric type pictograms can be highlighted.
>    
I don't think "highlighting" is such a important thing to justify an 
extra property for all features.

My main intention was to cover Boolean icons with animation without 
braking compatibility with standard ones.
A Boolean feature uses only 1 Bit so there are plenty Bits in an integer 
left, why don't use one of them?

My definition with negative values makes it possible to use 
"highlighting" easily for Bar icons too.
That's a nice bonus, but not more.
The drivers without highlighting support only has to use abs() of the 
the value and we don't have compatibility issues.

It may be appropriate to use more then one feature for such a complex icon.
(Something like "pictogram_value" and "pictogram_color".)
We may later create a special feature type, "Icon_color" or what ever, 
if there is the demand for it.
> If we treat it as "more intense than just on" for boolean type
> pictograms these become "tri-state" pictograms and I would assign them
> "0" = off, "1" = on, and "2" = highlighted. For driver not supporting
> highlighted pictograms than "on" is anything else than zero or anything
>    
>> = one.
>>      
> Anyway I'd like to avoid the "-1" on the interface as "-1" is used as
> UNSET_INT in other areas of the code.
>    
A negative number is convenient, so it is possible to use same function 
for highlighting bars and Boolean icons in the driver.
(I'm talking about the periodically called function which makes the 
Icons blink in the simplest implementation.)

The actual number doesn't matter on Boolean Icons, as long as it is 
negative.
Lets use -2, -9876 or any other negative number for the "highlighted" 
keyword at Boolean Icons.
> Regards,
> Markus
>
> _______________________________________________
> LCDproc mailing list
> [email protected]
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>    
Regards,
Stefan