Internet radio browser GUI for music/video streams from various directory services.

⌈⌋ ⎇ branch:  streamtuner2


Changes To plugin meta data

Changes to "plugin meta data" between 2017-01-01 21:11:23 and 2018-07-04 20:47:22

1
2
3

4
5
6
7
8
9
10
1
2

3
4
5
6
7
8
9
10


-
+







# Plugin meta spec

Streamtuner2 now uses a proper plugin description scheme. Note that this is completely unrelated to the streamtuner2 or channels API, or how plugins are actually initialized (pkgutil, imp, implib, pluginbase/plugnplay).
Streamtuner2 now uses a proper [plugin description scheme](http://fossil.include-once.org/pluginspec/). Note that this is completely unrelated to the streamtuner2 or channels API, or how plugins are actually initialized (pkgutil, imp, implib, pluginbase/plugnplay).

Basically the top-level comment block is scanned on initialization. It simply lists a few <kbd>key: values</kbd> for documentation and technical descriptors. It's basically a subset of YAML embedded in a script comment.

    # api: streamtuner2
    # type: feature
    # title: My Plugin
    # description: Lists all the things
︙
26
27
28
29
30
31
32
33

34
35
36
37
38
39
40
26
27
28
29
30
31
32

33
34
35
36
37
38
39
40







-
+







   * Params can be optionally quoted as in <kbd>value: "Desc, desc, desc."</kbd> in case they contain commas (which otherwise separate option attrs.)

And of course, the <kbd>config:</kbd> field can list multiple options. Simply make it multi-line (every plugin meta field can be) by indenting wrapped lines.


### Why?

This scheme is designed to be language-agnostic. It originated in PHP way back (see [libconfig](http://milki.include-once.org/genericplugins/)), precisely to avoid a few common misdesigns.
This [scheme](http://fossil.include-once.org/pluginspec/) is designed to be language-agnostic. It originated in PHP way back (see [libconfig](http://milki.include-once.org/genericplugins/)), precisely to avoid a few common misdesigns.

  * Meta data does **not** belong *in code*.  
    Because that incurs always importing them, even when they may go uninitialized/unused.

  * And it certainly should not reside in externalized ini/json data blobs.  
    *(Or do you want ants? Because that's how you get ants.)*

︙
48
49
50
51
52
53
54


55
56
57
58
59
60
61
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63







+
+







### Plugin list

The purpose of this scheme is feeding the plugin management in the settings window of course:

<img src="raw/st2-plugins.png?name=946c0e32c868a22facd7498250451723a50ab00a" style="margin:10pt" width=260 height=375>

This is meanwhile a sortof Python package of its own, [http://pypi.python.org/pypi/pluginconf/](http://pypi.python.org/pypi/pluginconf/). Doesn't include the current GUI code though.

See also: [pluginspec](http://fossil.include-once.org/pluginspec/)


### argparse config: struct

Similarly to internal plugin configuration settings, the <kbd>config:</kbd> list is now used for ArgumentParser definitions. Fields are slightly remapped to remain in line with regular options.

    # config:
︙