[Lcdproc] Separate icon area: interface for drivers?

Wolfgang Hauck wolfgang.hauck at gmx.de
Sat Nov 5 16:28:47 UTC 2011


Hi!

After having read all explanations, I have come to a mindset - client 
language left out for the moment. See here my theses:

  * Client developers and (indirectly) client users need a unique
    pictogram name.
  * Same pictogram name means same semantic.
  * Pictogram names are part of the client language.
  * There has to be some kind of rule to define pictogram names.
  * There will be a global list of pictogram names.
  * The global list is the base for a pictogram emulation for
    non-pictogram displays.
  * However, drivers maintain their local list of supported pictograms,
    which is a subset of the global list.
  * Drivers have to use the predefined pictogram names.
  * However, there are pictograms reserved for a driver specific use.
    These pictograms have no claim for standard use, and their
    utilisation requires a configurability feature provided by the
    client (user has to map functionality to pictogram).
  * The pictogram name gives a pictogram class. Example:
    "PICT_SW_INOUT_HDD".
  * The pictogram class describes semantics and defines the type ("bool"
    or "number"). Examples: "PICT_SW_AUDIO_VOLUME" has boolean type
    (seen from "*_SW*"), "PICT_LV_AUDIO_VOLUME" (seen from "*_LV*") has
    number type.
  * A list of pictogram names and an enumeration are basically
    equivalent. E.g. names can be derived from constant names (just
    stringify them).
  * The class has to be supplemented by an instance, which yields a
    pictogram identifier. Example: HTPC with three hard disks:
    "PICT_SW_INOUT_HDD_1", "PICT_SW_INOUT_HDD_2", "PICT_SW_INOUT_HDD_3".
  * Type and instance are obtained by parsing the full pictogram identifier.
  * I am quite optimistic with the description of pictograms and name
    definitions. See attachment. Once you get the notion there is not
    too much room for interpretation left.

Well, theses are no laws of nature, you know. But they may serve to get 
a reasonable base before going on to the specification of a client API.

Regards,
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111105/2924e2b6/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lcd_pictograms.h
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111105/2924e2b6/attachment-0001.h>


More information about the LCDproc mailing list