How make sub-plugins (and make it clear that they *are* such)?

Developers
#1

In the plugin library, a plugin with sub-plugins display as

image
image916×127 9.58 KB

…and opening it, within the plugin library, presents a “sub-plugin list”.

My Seentid plugin fully relies on a plugin named Focused tiddler by @Gk0Wk (nic here?) so I want my plugin to display as a sub-plugin like in the library but in the general Controlpanels plugin list.

How?

In my plugin, I did add both a dependents and a parent-plugin field but I cannot see that this affects anything (?)

For the sake of stimulating plugin creations, I think it’d make sense to simplify building on top of other peoples plugins.

Thank you.

#2

If you have a closer look at a subplugin fields, you’ll see:

  • parent-plugin: $:/plugins/tiddlywiki/codemirror

The rest should be done automatically by the core plugin handler.

In CodeMirror we also need the dependents field if a subplugin depends on an other subplugin. The main library, does not need to be in dependants. The dependants field is a list-field

eg:

  • dependents $:/plugins/tiddlywiki/codemirror-mode-css

image
image1550×546 28.9 KB

#3

Yes, thanks, I’ve seen that and I did already add that field to my plugin but this has no effect on the controlpanel plugin list in my wiki. I want it to be clear that the “Seentid” plugin is a sub-plugin of the “Focused Tiddler” plugin:

image
image1233×663 53.5 KB

#4

The first screenshot is only shown in the “Get more plugins” modal dialogue.

The standard list does not use that format, since it would hide installed plugins. We want a full list in the ControlPanel → Plugins tab. That’s intentional.

#5

OK, do you have any suggestion for how to make it clear that a plugin indeed is a sub-plugin to another in the ControlPanle → Plugins tab? Because this information is as important there as it is in the “Get more plugins” listing.

Hm, maybe I can use a “list after” field, and somehow make it css indented…

#6

Hm, this tiddler defines the plugin-table macro, which is basically the following. You can test it directly in your own TW, just copy-paste it:

<$list filter="[!has[draft.of]plugin-type[plugin]sort[name]]" template="$:/core/ui/Components/plugin-info"/>

…but it does not seem to respect the list-after field. Why is this so?

#7

Sorry. Not really. The plugin-info list code is slightly complex.

There is a discussion at GH about plugins, where my post lists 7 more issues – which are loosely related.

Some are from you: Improve the plugin dropdown information #4086, Move plugin library from modal to tiddler #3208 → We do not have a solution yet.

All tiddlers involved are “macro” code. So they are old.

  • $:/core/ui/ControlPanel/Plugins … Is the ControlPanel tab
    • it defines the \define plugin-table(type) macro, which lists the plugins by name
    • So sorting may be changed there

Vanilla base CSS has 29 tc-plugin related rules. So the CSS is a bit of complex too.

If you can come up with a usable solution, IMO we would be happy.

#8

list-after only works in conjunction with the list-field of a tag.

I am not sure, if the “rewritten/unpublished” toc-macro would be able to handle that structure.

#9

Oh :cry: …that aspect is missing in the docs.

#10

May be the sortby operator can be of use. Not sure.

#11

The problem even if that would work is that it’d require overwriting the core tiddler. I’d rather have the mechanisms within the intended sub-plugin itself (“Append this plugin onto that one”, so to say) or, if it not is solved in the core, then at least independent of the core.

#12

Or add a “tree” tab to plugin-info, so it could switch between two mode.

Why not PR to the core to chage it? I think current plugin management needs a lot improvment.

#13

I’m not savvy enough for a PR but I did post an issue: [IDEA] In Ctrlpanel plugin list; show sub-plugins as such · Issue #9157 · TiddlyWiki/TiddlyWiki5 · GitHub

#14

As @pmario says, it was a deliberate decision not to use the sub-plugin badge in the listing of installed plugins because the result would be that the listing would not be in alphabetical order, making it harder to locate a particular plugin in the list.

The parent-plugin field is only used in two situations: the “add plugins” listing, and one of the two ways to ensure that installing a plugin will automatically install another plugin on which it is dependent.

The other way is to use the dependents field of the plugin to specify a list of plugins on which the current plugin depends. I suspect that your use case might be best addressed by exposing the dependents field in the listing of installed plugins. I don’t think it makes sense to list plugins under their dependents because a plugin can depend on multiple other plugins, that in turn can depend on further plugins. But perhaps there’s a way we can decorate the two ends of the relationship (eg making it easy to see that the reason the jszip plugin was installed was because the xlsx plugin was installed).

#15

Good point, and thanks for replying.

For the record, I did a css solution included in the plugin itself:

a[href="#%24%3A%2Fplugins%2FTWaddle%2FSeentid"] .tc-plugin-info-description:after {
content:"■ Requires the plugin:  Focused Tiddler";
color:#333333; opacity:.85; font-size:80%;
}

…resulting in:

image
image1076×143 9.57 KB