[Lcdproc] Highlighting pictograms

Wed Nov 9 22:04:31 UTC 2011

Am 09.11.2011 04:13, schrieb Stefan Herdler:
> 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.

If you really want to introduce a flexible and extensible driver 
interface do not encode information _directly_ in bits, but use functions:

  * int pictogram_init_attr(PictogramAttr &attr)
  * int pictogram_destroy_attr(PictogramAttr &attr)
  * int pictogram_set_attr_enable(PictogramAttr &attr, bool enable)
  * bool pictogram_has_attr_enable(PictogramId id)
  * int pictogram_set_attr_value(PictogramAttr &attr, int value)
  * bool pictogram_has_attr_value(PictogramId id)

If there arises the need to introduce a new feature like highlighting 
add a new attribute with a new function

  * pictogram_set_attr_highlight(PictogramAttr &attr, bool enable)
  * pictogram_has_attr_highlight(PictogramId id)

Finally set the pictogram by

  * pictogram_set(PictogramId id, const PictogramAttr* attr)

The implementation is still free to encode the information bits.

For the client the language would contain constructs like 
"PICTOGRAM_SET_ATTR attrid ENABLE ON" followed by "PICTOGRAM_APPLY 
pictogramid attrid".

But for the moment I really would restrict ourselves to the simple cases 
of boolean and parametrised pictograms. They cover a lot of use cases.

Regards,
Wolfgang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111109/efbc08bf/attachment.html>