Re: Separate icon area: interface for drivers?

Am 11.10.2011 22:54, schrieb Markus Dolze:
> On 08.10.2011 00:34, Wolfgang Hauck wrote:
>> Hi Markus,
>>
>> thanks for your detailed answer.
>>
>> Yes, you are right.
>>
>>      * You never will catch all upcoming features supported by new displays.
>>      * The client must not deal with display types.
>>
>> What about the following interface extension ("pictogram" in order to
>> distinguish from "icon"):
>>
>>      * enum Pictogram {PICTOGRAM_PLAY, PICTOGRAM_PAUSE, PICTOGRAM_STOP,
>>        PICTOGRAM_RECORD, PICTOGRAM_VOLUME, ..., PICTOGRAM_CD , ...}
>>            o Enumeration may be extended by new features we are not aware
>>              up to now.
>>            o Furthermore, you can already tell from the enumeration value
>>                  + if a pictogram just can be switched on or off (e.g.
>>                    PICTOGRAM_PLAY),
>>                  + or if some kind of strength can be specified (e.g.
>>                    PICTOGRAM_VOLUME)
>>            o If there happens a type to become popular, you extend the
>>              enumeration. E.g. a fancy play icon whose colour tells the
>>              point of time in a recording could be called
>>              PICTOGRAM_PLAY_FANCY, which implies a new type with
>>              assignable strength parameter.
>>      * int get_pictogram(enum Pictogram type)
>>            o Reports strength (e.g. brightness, volume, WLAN strength)
>>              for pictogram use case.
>>                  + Returns a non-negative value in case of success.
>>                  + Returns an error if pictogram is not supported. Say -1
>>                    if pictogram is not supported; or -2, if a hardware
>>                    problem has occured. Or you keep to the>=0 (success)
>>                    versus -1 (failure&  errno set) convention.
>>            o Clients may scan which pictograms are supported.
>>      * void set_pictogram(enum Pictogram type, int strength)
>>            o If the pictogram is not supported the call is simply
>>              ignored; which has some compatibility advantages.
>>            o Strength equal to zero switches off, strength equal to - say
>>              - 255 switches to full strength; other values in between
>>              denote intermediate values.
>>            o For on/off pictograms, strength from 0 to 127 could switch
>>              off, and 128 to 255 could switch on.
>>
>> OK, this approach fails if multiple parameters can be assigned to
>> pictograms (brightness, colour information, rotation speed, blink rate,
>> fading rate, 3D depth information [if ever], etc.). But probably it
>> covers a lot of applications.
>>
>> Maybe a candidate for a poll in the IdeaTorrent? What pictograms are
>> required, and which parameters are known up to now?
>>
>> Whatever you are going to do... I would offer some support from my side:
>> Documentation, examples, implementation; just what helps you most.
>>
>> Regards,
>> Wolfgang
>>
> Hi Wolfgang,
>
> sounds like the beginning of a specification.
>
> However, I am less concerned about the driver API than with the client
> language.
>
> There will surely be one client command to set a pictogram, which
> requires the name of the pictogram and a level (the server must have a
> 'name' to 'value' mapping as for icons).
>
> For the client to get a list of supported pictograms another command is
> required to which LCDd answers with a list of supported pictograms (and
> perhaps its type). The type may not be necessary as the client has to
> know how to use the pictogram anyway.
>
> To build the list of supported pictograms LCDd may scan all loaded
> drivers for the existence of set_pictogram() and for driver that
> implements it cycle through all known pictograms and record if the
> drivers supports it (returns 0) or not (return -1) on the call to
> set_pictogram().
>
> This way, get_pictogram would not be necessary and 'set_pictogram' could
> simply be named 'pictogram'.
>
> However, there is one open point: Shall the client command supports
> setting multiple values at once? For example on changes from 'play' to
> 'pause' the first must be turned off while the second must be turned on.
>
> If these changes are sent in separate messages, there may be a delay in
> processing. However, client messages sent directly in sequence _should_
> be processed in the same order with no other command mixed in between by
> design.
>
> Sending these changes in the same message be overflow the command length
> if the application sends may changes in the same command.
>
> Regards,
> Markus
>
Its me again, with some more thoughts...

Currently I am assembling an enumeration with constants for each icon 
type, e.g. "play", "stop", "pause", "volume" (only name), "volume 
level". For a better survey, I sort the icons by groups, e.g. "stream 
source/destination", "navigation", "status", "application", "speaker", 
"video", "audio", etc. This is going to demand some more time before I 
am able to show a first version.

However, I made a couple of observations:

    * Icons being modified simultaneously lie within a group as e.g.
      "play", "pause" and "stop"; at least up to now.
    * Group sizes seem to be limited to at most 16 pictograms, which is
      quite plausible taking into account display sizes.
    * The number of icons is quite respectable (magnitude order of 100),
      even in a modest approach.

Instead of giving syntactical descriptions, I give an outline how a 
pictogram client interface might work.

A screen is setup as usual:

     > screen_add sdemo
    success

A noteworthy aspect is the usability by multiple clients, where each 
client may use its own screens, and all screens are rotated as they used 
to for conventional screens.

Now you add a widget to the screen, which is going to host pictograms.

     > widget_add sdemo pdemo pictograms
    success

This behaves pretty much as any other widgets, particularly there are no 
further parameters. Returning here all supported pictogram types is not 
feasible due to the large number, anyway.

The client initialises the display, which serves also as test for 
availability of pictograms.

     > widget_set sdemo pdemo PLAY OFF STOP OFF PAUSE OFF VOLUME OFF
    VOLUME_LVL 0
    success OFF OFF OFF ERR 0

The notion is similar to other widgets as string or title: Some data is 
printed.

The parameters after success return the value after command execution, 
here in the example "volume" is not supported. The disadvantage of this 
approach is that the scan takes place late and might in fact be 
preferred when the widget is set. Probably clients want to set up 
widgets first, and set them later during operation. However, they are 
free to use a hidden screen for a scan.

Let us assume the user starts to play a DVD, modifies the volume (assume 
per-mill-units), and stops the DVD.

     > widget_set sdemo pdemo PLAY ON STOP OFF
    success ON OFF

     > widget_set sdemo pdemo VOLUME_LVL 500
    success 500

     > widget_set sdemo pdemo PLAY OFF STOP ON
    success OFF ON

Any pictogram from the message is modified at the same, a screen flush 
occurs (mapped to driver function "flash"). Drivers need a pictogram 
buffer in analogy to a frame buffer.

Consequently, "play" and "pause" are not visible at the same. I expect 
hardly more than 16 pictograms per message required for a simultaneous 
change, so there should be no overflow.

And finally, clean up.

     > widget_del sdemo pdemo
    success

     > screen_del sdemo
    success

So, now it is time for your feedback...

Regards,
Wolfgang

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