[Lcdproc] Highlighting pictograms
wolfgang.hauck at gmx.de
Wed Nov 9 22:04:31 UTC 2011
Am 09.11.2011 04:13, schrieb Stefan Herdler:
> 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.
> Please apologize not answering your mail, it got lost in my spam
> filter somehow.
>> 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
> (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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LCDproc