A new type of plugins for distributing contents like course notes, presentations, ordinary bundle of tiddlers

[kookma]

Right now Tiddlywiki supports plugins with two types: plugin, theme. Plugins have many useful features. Recently it was proved that plugins can be used very effectively for distributing e-books. During the pandemic I tried to distribute course notes using plugins. Student can open tiddlers, edit them, add comments and if they delete, they always have the original course notes intact.

For Tamasha, I got request to be able to distribute presentations as course notes or learning resource as plugins.

Based on the above discussion I like to propose

• have a third type for plugin (I can suggest, bundle, package, addon, ...)
• liberty in naming tiddlers bundled in a plugin except the plugin tiddler itself, readme, license, content
• have a new tab like plugins, themes in $:/ControlPanle -> Plugins

I should note and emphasize that all above can be done using the current Tiddlywiki plugins technology, but having a specific type for distributing collection of tiddlers like e-books, course notes, presentations, ... is semantic and helpful.

[pmario]

I did create a Bundler Plugin, which uses bundles (tiddler.json files). ...
BUT bundles are conceptually different to plugins. Tiddlers of a bundle can be deleted. The plugin exists since 2017

AddOn(s) will probably be taken by the "language AddOn" tab, which is part of a pending PR: "Translateable plugins - first try #5418"

So I'd suggest "package", since it's free ;)

[kookma]

Thank you @pmario - I use bundler plugin and it is a handy tool to distribute notes!
I will take a look at #5418

So I'd suggest "package", since it's free ;)
That sounds great!

[pmario]

I did create a new version of the bundler-plugin some days ago. Then I thought, it should be simple, to export a "content-only" bundle as a plugin, Which is exactly what you suggest.

A bundle can contain "content tiddlers" and they can also contain "plugin tiddlers".

The core: $:/core/ui/ControlPanel/Plugins tiddler probably contains the only hardcoded "tab-list". ... May be we should change this and make it configurable. .. So users can add tabs there. .. It should be relatively simple.

[kookma]

@pmario - I support configurable $:/core/ui/ControlPanel/Plugins and I think this way developers have the flexibility to follow some minimum rules to create new plugin type/subtype.

A bundle can contain "content tiddlers" and they can also contain "plugin tiddlers".
This is useful to create objects. An object is an entity which has both data (content tiddlers) and methods (actions = plugins). I think bundler has a lot of users and worth to be improved.

[Jermolene]

Hi @kookma

Right now Tiddlywiki supports plugins with two types: plugin, theme.

There are also language plugins. Internally, the $:/Import tiddlers and $:/temp/info-plugin tiddlers are also each their own special plugin type.

Plugins have many useful features. Recently it was proved that plugins can be used very effectively for distributing e-books. During the pandemic I tried to distribute course notes using plugins. Student can open tiddlers, edit them, add comments and if they delete, they always have the original course notes intact.

For Tamasha, I got request to be able to distribute presentations as course notes or learning resource as plugins.

Based on the above discussion I like to propose

• have a third type for plugin (I can suggest, bundle, package, addon, ...)
• liberty in naming tiddlers bundled in a plugin except the plugin tiddler itself, readme, license, content
• have a new tab like plugins, themes in $:/ControlPanle -> Plugins

I should note and emphasize that all above can be done using the current Tiddlywiki plugins technology, but having a specific type for distributing collection of tiddlers like e-books, course notes, presentations, ... is semantic and helpful.

Beyond being in a separate tab, does this additional plugin type require different functionality than existing plugin-type: plugin plugins?

If not, perhaps it would make more sense to just introduce a new subtype field for plugins that could be "ebook", "presentation" etc.?

[kookma]

Hi @Jermolene - Thank you for your reply and pointing me to other type of plugins. Regarding the questions:

Beyond being in a separate tab, does this additional plugin type require different functionality than existing plugin-type: plugin plugins?

I think no! I think the current functionality is great and for what I proposed is sufficient.

If not, perhaps it would make more sense to just introduce a new subtype field for plugins that could be "ebook", "presentation" etc.?

I do not know the internal implementation, but it make sense to have subtype as separate category!

[kookma]

If not, perhaps it would make more sense to just introduce a new subtype field for plugins that could be "ebook", "presentation" etc.?

@Jermolene - I think the package is a good name for content (data) only plugins or content+method (object). But flexible naming like ebook, presentation, etc... is also very cool.

By the way if you support the idea, I like to have a semantic tab in $:/ControlPanel/plugins. One can customize its content package to have suitable sidebar tab (UI) to simply interact with contents (e.g. notes, slides, chapters, pages, ...)

[pmario]

@Jermolene wrote:

If not, perhaps it would make more sense to just introduce a new subtype field for plugins that could be "ebook", "presentation" etc.?

IMO that's a good idea. I'll have a look if language AddOns could also go with a subtype field.

@kookma wrote:

I do not know the internal implementation, but it make sense to have subtype as separate category!

We would only need to add it as a filter for the new tabs and add it as a "hide subtype" in the existing tabs.

and

I will take a look at #5418

"#5418 Translateable plugins" .... is a work in progress PR, which already contains some new elements eg: It contains a new tab called "Language AddOns" ... But it is also hardcoded.

IMO it will be easy to make it configurable.

[Jermolene]

IMO that's a good idea. I'll have a look if language AddOns could also go with a subtype field.

The proposal to add a subtype field would just affect how the plugins are presented in the control panel. We should not overload it to serve any other function.

[AnthonyMuscio]

Folks,

I have spent some time on this myself. It is easy to achieve this with an existing hack. Just create a JSON tiddler, like renaming the $:/Import and add the plugin-type of your new name. As I favor, a plugin type of "data" which I could use to import say a list of "archaeological epochs" and their dates.

Given even in this thread there are different views on alternate plugin types, can I suggest the tabs in $:/core/ui/ControlPanel/Plugins
be generated from the plugin-type(s) found in tiddlers with a plugin-type field, thus automatically making other plugin types visible.

It appears as long as a tiddler has the plugin-type field, regardless of its value it behaves as a plugin with shadows etc...

• Some consideration of minor edits in $:/core/ui/Components/plugin-info specifically plugin-table macro will be needed.
• I have also raised elsewhere the need for an ability to hide a plugins shadow tiddlers without deletion.

Regards
Tony

[AnthonyMuscio]

I used this filter in $:/core/ui/ControlPanel/Plugins, the tabs macro, while investigating this increased hackability [each[plugin-type]get[plugin-type]sort[]]

Regards

[pmario]

As Jeremy pointed out, a subtype may be useful, since some types may need to "play" together. eg: plugin-type: language and plugin-subtype: addOn ... In my current "translatable plugins PR" I use plugin-type: language-addOn, which causes problems in the js-code. ...

[Parlazo]

Given even in this thread there are different views on alternate plugin types, can I suggest the tabs in $:/core/ui/ControlPanel/Plugins
be generated from the plugin-type(s) found in tiddlers with a plugin-type field, thus automatically making other plugin types visible.

Best idea i see so far

please avoid static categories or genres.
as soon there are static categories it will be endless
a biologist will want a categorie for ants and an other for bees and an other for fish but then the next want plants and an other only funflowers
a musican will want pop but the other rap and the next will want techno
a neerd will come up and need a cetegory for c++ the next will need java
at the end there are millions of categories and e-books will be lost in the masses

the best would be a field in a json plugin with a coma delimited tag string
so one can bundle his content under different tags like math, history, astronomical, geometry the nect can bundle his stuff under math, quiz and an other under astronomical, phenomens

then a user should get a plugin search field with a tag cloud ... as soon the user enters some thing the tag cloud will shrink ... and the remainig tags should be clickable too ... so a user can click math, homework, solution or an other can click homework, cleaning, tricks, simple, cheap

in such a way every one need just one field and every one could click together what he is searching for
all would be dynamic and simple

and maybe optional nice to have would be a second tag search field and cloud with tags to exclude
so one can click insects, fly + exclude vasp, honey

this would be simple to manage for who ever will manage the fields because it would be only one field
and it would be awesome for users because they just can click what they look for and exclude that they do not look for
and with tags it would be optical nice
and what ever the people want to bundle they can tag as they like with e-book, or test, or special theory and so on.

i like this idea and strongly suggest such a thing

[kookma]

#5694 addresses first step of this idea: e.g list tabs using system tags $:/tags/ControlPanel/Plugins

Now developer can adds new tab in ControlPanel/Tabs displaying another kind of plugins e,g packages or Contents.
If @Jermolene approve the first step, then we can discuss what other type should be added!

[Parlazo]

Recently it was proved that plugins can be used very effectively for distributing e-books. During the pandemic I tried to distribute course notes using plugins. Student can open tiddlers, edit them, add comments and if they delete, they always have the original course notes intact.

Awesome 😃

I should note and emphasize that all above can be done using the current Tiddlywiki plugins technology, but having a specific type for distributing collection of tiddlers like e-books, course notes, presentations, ... is semantic and helpful.
you could do this by maming the bundle or by taging the content or do i get it wrong?
in example name your plugin Kookma: e-Book: Internet: Wikis: How to name your tiddlers for dummies
and then tag all the content with some thing meaningful like Kookma Bundle, e-Book, Internet, Wikis, How to name your tiddlers for dummies, Chapter 1, self test A

if you have many bundles they are all to find by the tag Kookma, and so on ... so one could copy the plugin or parts of it like the test or the whole chapter.

or how should it be?
many categories like plugins, e-book bundles, music bundles, test bundles, language card bundles, and and and .... it will be a endless list... i am not sure if this realy would help to sort things but i am sure it would split things infinite up
what would be the next step?
comedy books and philosophy books and it book bundles ... and then new categories for html, javascript, svg, xml, and so on
the next will demand categories for every music style
can this not get done with the naming and taging as actualy given?
maybe a plugin sort page would be fine to search plugins by titles or tags ... but i think this is already possible?

[kookma]

Hi @Parlazo - the current configuration for plugins are hard coded tabs. The above idea asks TW lets developer have another type e.g packages. That is the whole story!

This is like sidebar tab! How do you feel if TW restrict adding new tab to sidebar and use a list hard coded titles?

My plan is to have a category for non-technical people. It makes sense to say add the book and see the book package there to ask install a plugin (which many reluctant to do if it is not official one)

So, a music package a course note bundle, are different from plugin, as these are simple contents! May be in future we can have standard to not include JS macros and widgets , CSS, and just plain wikitext!

[Parlazo]

The above idea asks TW lets developer have another type e.g packages. That is the whole story!

Ok i see ... every package is in its basics a plugin ... themes languages plugins .. basically its all the same ... and now you need a category with every thing else that is not plugin or theme or language ... it sounds to me not extremely urgent but acceptable.

This is like sidebar tab! How do you feel if TW restrict adding new tab to sidebar and use a list hard coded titles?

i feel bad

My plan is to have a category for non-technical people. It makes sense to say add the book and see the book package there to ask install a plugin (which many reluctant to do if it is not official one)

but plugins can add tabs or other functionality .... a plugin could contain a e-book and provide a tab in the sidebar to access the book easily by non technical people ... it also could add a own search functionality with filters specific searching in only this book plugin and it could also add nice icons and so on .... i understand the difficulty is some one just packs a book into a plugin with out adding a nice sidebar tiddler to the plugin ... but it would be possible and depends on the one who provides the bundle.

So, a music package a course note bundle, are different from plugin, as these are simple contents! May be in future we can have standard to not include JS macros and widgets , CSS, and just plain wikitext!

ye but you see ... in future we may want more and more and some one must manage all the categories... thats wy they should be dynamical ..... just one field more in the plugin it self where the plugin provider can add a tag list and decide by him self what category his plugin/bundle is.

the rest can be done by the bundle it self ... it it needs to be in the sidebar it should add a sidebar tab by it self ... if it needs a own search field it can add it it self... what ever it needs .. the provider can add it... its up to the provider to make his content looking nice or accessable or what ever he wants

as i guess.... sone one packs a book as a plugin and gives it to you and then you cant access the book easily .... this is of course not nice ... but its not because TW .. it is because the one who gives you a book as a plugin forgot to add a nice tiddler which provides a good access to its content ... he should add a sidebar tab with a nice index to the book

an example is the TW docs (documentation) plugin .... it adds it indexed content to the sidebar ... it does not add a new sidebar tab but this would be possible ... it also adds no proper search functionality ... but it would be possible... it seems more as if who ever did it had forgotten to add a proper search functionality and saw no need to put it in a own sidebar .... but its possible and up to who ever shares some content

an other thing is the official plugin chooser with some tabs
basically you can drag and drop plugins from any where into TW ... most e-books are any way not in the official plugin list ... i never saw one except the TW docs

and the plugin loader indeed could get optimized .... basically if one sticks to the rules plugins are all under $:/plugins some where.
but if you look at a json file in which the plugin holds all its content you see its possible to place your content any where you like with or with out $path .. you could over write old functionality or add new
so the plugins chooser or theme or languages could have a new design with tag pills to select one tag pill would be theme an other would be languages and other would be official plugin
this information can be inside the plugin or can come from the plugin path
and other plugins or packages coud add custom tags which to pop up in a tag cloud if they are some how installed
and if the user has acces to such a tag cloud it will be easy to him to search plugins
you can click official plugin and you will see official plugins ... you can click theme and you will see themes .... and if some one has a plugin tages as e-book a tag pill will appear with e-books .... or what ever the tags are in the plugin ... or may even serval tags like e-books history math ... so the user has different pills to find the same content as he likes

in such a way all tabs in the plugin chooser woud be not needed ... just tag pills like official plugin, official theme, official language ... and the rest will be dynamic by content package or what ever
also plugis could add pills like "official plugin" "documentation" "TW" or "official plugin" "railway" "diagram" "graphical" or themes "official theme""vanilla" or languages "official language" "english" ..... but a user could add own tags to his bundle like "e-book" "theory a" and if one installs this ebook it would appear in the tag cloud where all plugins are ... and if one is searching for this content of which he has forgotten if it is a plugin as TW docs or a ebook as yours then he can search the tagcloud like "documentation" and he will see some books and and then TW and he will see TW docs ... and then he can do some thing with it ... install or uninstall or reinstall or update

i hope you get a picture

[AnthonyMuscio]

Personally I feel that a plugin type of data would be enough to cover imported databases, backups, books etc.. since they are basically content without macros and active widgets or functions.

If we are going this way and naming a small subset of additional plugin types we need to try and predict future needs. I would rather maintain the status quot which is you can freely make up additional plugin types already.

To access additional plugin types in the control panel $:/core/ui/ControlPanel/Plugins tabs need to be modified to include additional tabs for other plugin-type values found in the wiki.

I would be happy to do this!

[AnthonyMuscio]

Here is an example, drop on TiddlyWiki.com then optionally edit the core tiddler $:/core/ui/ControlPanel/Plugins and add this tiddler "Other plugins" to the tabs. Now control Panel > Plugins > Others

Other plugins.json.txt

This will list all other "unregistered" plugin types.

[AnthonyMuscio]

Later I would add a repackage button that replaces all edited shadow tiddlers with there tiddler and makes them new shadows (deleting the "edited tiddlers").

[Parlazo]

If i could have a whish... as you are already on it ;)

Plugin tiddler/tab/official add menu

Search field
empty plugins tag cloud
plugins tag cloud with all plugins tags

plugin list with description

small checkbox "Add/remove plugin-search to sidebar tab"

If i use the search box the possible selection in the tag cloud will shrink and the list with description will shrink
then i could enter Awesome plugin
now all plugins are in the list which contain a tag "awesome plugin" and any other tags, if i press enter "awesome plugin" tag goes to the empty tag cloud and in the selectable tag cloud all plugins which no "awesome plugin" tags will disappear as in the list too
then i could click in the tag cloud one of the left over tags like "book" it will go to the search field where "awesome plugin" is at the side of it
and all plugins which are not "awesome plugin" and not "book" get dropped again
then i want to click a left over tag like "history" and not the search result contains three tag pills "awesome plugin" "book" "history"
now i decide to search a other history book which is not "awesome plugin" so i klick on the pill in the search result and it will go back the the cloud of possibilities and the tag cloud will fill up again with all that contains "book" and "history" but may also "not awesome plugin" or "bundle" as long it contains "history" and "book" ... and the list will grow again
now i click the "class 1a" tag.... so the list will shrink dramaticaly and only two tags are left ofer to choose "lassion1+ and "lession"
now i klick in the list and read about the two plugins and choose to install lession2

and because this is so cool i add the plugin finder to the sidebar with a checkbox

how ever in the plugin cloud to choose are the first three tags always "official plugins" "official themes" "official language packs" and the rest will be dynamical as installed or additional provided by official content.

actually plugins do not use such a tag system ... they are the officials ... so the tag pill for official plugins/themes/languages could be created from theyr path
new plugins will use a taging system which gets read out just for the search

this would be user friendly ... simple .. dynamic ... very cool

Edit:
If such a thing exist a second checkbox would be very good" "replace original plugin find tabs" ... so the original mechanism can stay as is and could get replaces with some thing like above .... i would use this instantly and replace the original plugin box and add it to the sidebar or view it as a tiddler in the river flow.... that way i could read the description better

[pmario]

@kookma and others. This is WIP atm. It's part of the "translatable plugins" project I'm working on.

I did make the plugins tab dynamic. .. So it will be possible to extend it easily. I did use Content, because I think "Package" indicates something executable.

The next step will be to list all plugins with "plugin-subtype : xxx", where xxx can be defined by the plugin Author. The text of the "plugin-subtype" field will be used "as is". So no lingo-definitions in the core are needed.

[kookma]

Hi @pmario - Thank you. I am happy to have plugin tab dynamic and also the new type: Content!
I have also submitted a PR #5694 to address the first part but I think @Jermolene has not seen it!

So, if you go with this, I can close that PR.

[pmario]

You could close it in favour of mine and reopen it, if mine fails to be merged :) ... So don't delete the branches, so you can reactivate them later.

There are 2 plugin elements that are affected. The "installed" tiddlers and the "add" tiddlers in the "Get more plugins" dialogue. .. Both of them will need a dynamic handling.

Yesterday I wanted to start with the "plugin-subtype" handling, but I did get interrupted by RL ;)

[kookma]

@pmario

I did make the plugins tab dynamic. .. So it will be possible to extend it easily. I did use Content, because I think "Package" indicates something executable. The next step will be to list all plugins with "plugin-subtype : xxx", where xxx can be defined by the plugin Author. The text of the "plugin-subtype" field will be used "as is". So no lingo-definitions in the core are needed.

I like this approach! If it can be appear in Core!

[kookma]

Hi @Jermolene, @pmario
Is there any chance to have a decision on the direction of this OP?

My recent findings and proposal on Talk

• I propose to use component word for a bundle of tiddlers contains course notes, presentation, brochure, small ebook, ...

• A component contains a bundle of related tiddlers packed and shipped in form of Tiddlywiki plugin (so has all the unique features of Tiddlywiki plugins)

• We need a simple tool to create such components

• New tabs in $:/ControlPanel > Plugins can be simply created along side with Themes, Languages, Plugins, for example Course Notes

• A component of type Course Note then will appear under tab Course Notes using <<plugin-table note>>

So, I am thinking may be just having a plugin-subtype is enough as @Jermolene said: No new functionality is required and this is only how they displayed in control panel!

[Jermolene]

I'm not sure that "component" is quite the right word here. The key characteristic of a component is that they are designed to be composed together to form larger subsystems.

[kookma]

Thank you @Jermolene
What do you suggest? Content plugins is a title I think proposed by @pmario?
My main purpose here is to be able to use feature of plugin and package tiddlers in one bundle and distribute! so I am happy with any terminology you think is most appropriate here!

[pmario]

At the Talk thread you write:

• standard plugins and themes
• lectures
• books
• presentations
• brochures
• pamphlets
• ....

Which imo can be any/every thing.

May be Media would be the right term here. IMO we don't use it in the TW context at the moment and according to Wikipedia: https://en.wikipedia.org/wiki/Media it could basically be everything. ...

In our context we could define it in the way, that is: User created content, that is bundles as a plugin to be consumed by other users.

just a thought

[kookma]

Hi @Jermolene
If we want to add this feature, I think by now there is a consensus on

1. Having extra tab under Plugins tab as below, media or content or package are some suggestions
   Plugins | Themes | Languages | Media |
2. Adding a introduce a new subtype field for plugins that could be "ebook", "presentation" etc.

On the other items, it seems there are open questions

So, I appreciate if @Jermolene advice on this! I am available to help to implement this part (of course with no JS ;-) )

[Jermolene]

Hi @kookma I'd like to step back to consider the goals behind the OP. I think that this is about being able to present specialised content as plugins, reusing the existing infrastructure, but without end users having to deal with the usual plugin UI to handle these specialised plugins.

If that's the case, you might be interested in the work I've been doing on https://twpub-tools.org/. It presents a user interface for downloading and reading EPUBs that have been converted to a TiddlyWiki plugin-based format (the converter is currently a separate Node.js app).

The idea is that the user need never know that these TWPubs are represented as plugins. To try it out:

1. Click the green button labelled "Load from TWPub Demo Library"
2. In the modal that appears, click the "install" button against one or more TWPubs
3. Click the close button to close the modal
4. Click on the white box in the sidebar representing one of the publications. Choose "Read in new column" to see the content of the TWPub in a new column
5. Open the control panel "Plugins" tab to see that the TWPubs are actually plugins

So, the approach is to build a separate UI outside the control panel to handle the special TWPub plugins. The downside of this approach is that the plugins list in control panel gets longer, and I'm certainly not against measures to manage the resulting complexity.

[kookma]

Hi @kookma I'd like to step back to consider the goals behind the OP. I think that this is about being able to present specialised content as plugins, reusing the existing infrastructure, but without end users having to deal with the usual plugin UI to handle these specialised plugins.

Quite correct!

So, the approach is to build a separate UI outside the control panel to handle the special TWPub plugins.

I go for this to see how can I make contents as plugin! and how it works for different type of contents!

Thank you for clarification and TWPub!

[Jermolene]

Thanks @kookma

I go for this to see how can I make contents as plugin! and how it works for different type of contents!

Great. I think that the current TWPub implementation might involve duplicating some core tiddlers, but we should be able to break things out into more easily reusable components if necessary.

[kookma]

Hi @Jermolene

• Click the green button labelled "Load from TWPub Demo Library"
• In the modal that appears, click the "install" button against one or more TWPubs
• Click the close button to close the modal
• Click on the white box in the sidebar representing one of the publications. Choose "Read in new column" to see the content of the TWPub in a new column
• Open the control panel "Plugins" tab to see that the TWPubs are actually plugins

I like this approach and want to use with Gatha, my question is:

How TwPubs load plugins to be searchable from standard searchbox?
I understand I need a UI to show such content plugin TOC in sidebar! I can have a sidebar tab like Media and it can list vertical tabs each contain a content plugin (e.g course note)

[Jermolene]

How TwPubs load plugins to be searchable from standard searchbox?

One way to do that is via a custom search results tab with the additional results.

[kookma]

Thank you Jeremy! I am playing with TWPubs and saw you have a dedicated result tab when one search in an ebook.

[pmario]

@kookma Now that I see your implementation it should be a media-type field instead of a plugin-subtype field.

If I import one of your plugins into tw-com I do get this:

But there should be a top level as shown in your demo page linked above. ... WITHOUT the need to install the plugin into an existing default wiki.

So the core should know about the new media-type field and use it accordingly.

[pmario]

... So the core should know about the new media-type field and use it accordingly.

Messing around with the bundler plugin at the moment. ... I think "Media" is too close to the MIME type spec, which is used with TW as "type" at the moment. ...

So instead of Media it may be Package ... IMO package isn't used in TiddlyWiki at the moment at all. Bundle is used for tiddlers, that can be deleted. ... IMO Package "only" means, that something is "compressed" / "combined" into a simple to use "package". ...

I did have a look at the core code. .. For packages as described in the OP we have to have the tiddler field: plugin-type set to plugin

As mentioned in the OP packages can also have a category, like e-books, course notes, presentations,

So my suggestion is,

• to have a new top-level tab named Package
• a new field-name: package-type ... which creates secondary tabs like e-books, course notes, presentations, and so on.
  • There should be a package-global search input, which searches for text in all "secondary" tabs and lists them in 1 list.

[kookma]

Thank you @pmario
While I like media more as it is closer to what the plugin have, but package is also acceptable.

I think also we need a sidebar and mechanism to load the content plugin or packages as @Jermolene explained above! The reason is we need to be able search in the content!

[pmario]

the main problem with media-type is MIME-type, that we use as the type field in TW already. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types the first paragraph

A media type (also known as a Multipurpose Internet Mail Extensions or MIME type) indicates the nature and format of a document, file, or assortment of bytes. MIME types are defined and standardized in IETF's RFC 6838.

The tab would be "Media" the type imo would be media-type and that may be confusing.

[kookma]

Thank you @pmario
Based on current implementation https://talk.tiddlywiki.org/t/gatha-plugin-experimental-release/2272
If a new tiddler tagged with $:/tags/ControlPanel/Plugins called $:/core/ui/ControlPanel/Plugins/Installed/Media with caption

{{$:/language/ControlPanel/Plugins/Media/Caption}} (<$count filter="[!has[draft.of]plugin-type[media]]"/>)

Then we will have a Media tab! It can be configured somehow to list all plugins are not belong to standard categories (plugins, themes, languages)

[linonetwo]

The fishing plugin @oflg is trying to distribute 33MB of English learning flash cards in https://github.com/oflg/fishing-cannedfish/tree/gh-pages

These are JSON multitiddlers. They are too much, so placing in the CPL will overwhelm other plugins, so currently only distribute in github and netdisk...