[Lcdproc] Separate icon area: interface for drivers?

[Markus Dolze]

On 19.10.2011 00:55, Wolfgang Hauck wrote:
> 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.

Allowing different clients to use different values for the pictograms is
a nice idea, but has some drawback (see below).

> 
> 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.

Assigning pictogram as a widget to a screen has the drawback that when
running different clients at the same time, each client MUST take care
of the pictograms itself.

Imagine a user is running a media player and our lcdproc client.

a) Whenever our lcdproc client is shown the pictograms will be turned
off, thus not showing the state of the media player.

b) The media player software has to add the pictogram widget to each
screen otherwise on some screen the pictogram will disappear as well.

I assume the pictograms will disappear as the have to be reset on
rendering, otherwise as different clients may not turn off pictograms
unused by themselves will stay on.

> 
> 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.

Note that due to the design of LCDd there is no relation between a
message sent to LCDd and its response.

Thus this will not work with current LCDd. 'Success' messages are
generated upon successful parsing of the client's message, not on their
execution.

> 
> 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.

This is why I proposed the server to explicit tell the client which
pictograms are supported by the loaded driver(s). Clients than may adopt
to the available pictograms - e.g. by using some icons instead.

Using things like hidden screens make things more complex for client
developers.

> 
> 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.

This is a good idea regardless of the implementation.

> 
> 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.
> 
...

> 
> Regards,
> Wolfgang