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: