Drive field special treatment via lookup table

[mattblovell]

See Idea #16 from @nico1080. Need to arrive at a suitable signature for use by all rendering callback functions.

Dictionary-driven handling permits for both overrides of any existing functionality as well as end-user extensions without having to modify kodi_panel_display.py itself. Each callback function, provided it is passed the in-progress image, can then accomplish whatever the user might desire, however complicated that might be.

The additional function calls definitely add to the overall code path for a single update_display() invocation, but for small lookup tables it shouldn't be terrible.

[mattblovell]

Idea #20 effectively raises the possibility that element callback functions may just manipulate the screen image, rather than return a string. Capturing an observation made elsewhere:

A distinction may be needed between "special treatments" or display callback functions that yield a string to display versus the new possibility (from Idea #20) that result with the in-progress image being manipulated (e.g., a codec image rendered). Only those functions that return a string lend themselves to format_str interpolation, naturally!

[mattblovell]

Could just require that all element callback functions return a string, even if empty. That should at least make the format_str handling uniformly safe.

[mattblovell]

As of 19 Jan 2021, I think all special treatments are solely for text fields (string manipulation), with the full set below. The list of specials for Status screens got reduced quite bit with the introduction of prefix, suffix, and format_str features.

• Audio
  • codec
  • full_codec
  • artist
• Video
  • acodec
• Status
  • version (for kodi_panel's version)
  • summary
  • kodi_version (build info of the connected Kodi instance)
  • time_hrmin (to split AM/PM from numeric portion of current time)

The video:acodec and audio:codec lookups are, I believe the same, yielding 7 distinct callback functions that need to be implemented to match existing features.

I think I'll add a new enumerated type (class) that captures the overall "audio", "video", and "status" intent of a display update, passing that as an additional argument to the callback functions. Finally, I also envision passing the name of the current layout; that will enable conditional code based on auto-selection results.

EDIT: Oops, forgot about summary on the status screen. Added that to the list above.

[mattblovell]

Work started on the dev/special_tables branch.