How to define a plugin as required for other plugins?

[Stephan Hradek]

You might have seen my anouncement

https://skeeve.github.io/tw5-plugins

Currently you will find 3 plugins there:

1. documentation - which is required by the other 2 plugins
2. action-increment - which will, hopefully, help resolving issues with incrementing tiddler titles etc.
3. pick - which can be used to extract information from other tiddlers

Feedback is welcome

github page for issues is https://github.com/Skeeve/tw5-plugins

As you saw: "documentation" is a prerequisit for the other 2 tiddlers, but I couldnÄt figure out how to make this auto-install when one of the others is selected for installation.

1. Is this possible at all?
2. I thought "dependent" in plugin.info is for this, but either I did it wrong or my understanding is wrong.

[Jeremy Ruston]

Hi Stephan

As you saw: "documentation" is a prerequisit for the other 2 tiddlers, but I couldnÄt figure out how to make this auto-install when one of the others is selected for installation.

1. Is this possible at all?
2. I thought "dependent" in plugin.info is for this, but either I did it wrong or my understanding is wrong.

At the moment the "dependent” field of plugins is only used to cascade switching in dependent plugins when switching in a theme or language. There is currently no mechanism within the plugin library to automatically select dependent plugins in the UI. Such a UI could be added fairly simply, I think.

In the meantime, there are many such dependencies amongst the core plugins, and the approach that is taken is to have a startup module that checks for the required dependencies, and displays an alert if any are missing. Have a look at the text-slicer plugin for an example of this.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/2064d889-8402-42e6-85a2-4e3cccd366c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephan Hradek]

Am Montag, 26. Februar 2018 13:51:14 UTC+1 schrieb Jeremy Ruston:

the approach that is taken is to have a startup module that checks for the required dependencies, and displays an alert if any are missing. Have a look at the text-slicer plugin for an example of this.

Hmmm…

Okay. I saw it. I'm not sure I completely understand what need be done to achieve it myself.

Anyhow: Don't you think it's a good idea to have this as a core feature? Every plugin then simply needs to define one string per required plugin. The core could then take care required plugins are loaded.

Of course (I think) you could only require plugins which are either
a) Official or
b) In your own library

Is it worth an issue?

[Jeremy Ruston]

Hi Stephan

Anyhow: Don't you think it's a good idea to have this as a core feature? Every plugin then simply needs to define one string per required plugin. The core could then take care  required plugins are loaded.

Indeed it would be a useful feature if implemented carefully (I wouldn't like TiddlyWiki to start silently downloading dependencies without user intervention, for instance). I'm imagining it as a feature of the plugin library user interface.

But, I'd say a much more serious problem with the plugin library is that it doesn't properly work in client-server configurations (ie, it copies the plugins from the library instead of updating tiddlywiki.info with the new plugin details).

In terms of future development of the plugin library, I believe that it needs to have a generic HTTP API so that we can connect it up in lots of useful ways. In particular, it would be great to be able to publish plugins directly from a wiki in the browser as well as from the command line using Node.js.

(At the moment the plugin library is defined as an HTML endpoint that is loaded into an iframe and then one talks to it using window.postMessage. It's a weird architecture but it has allowed us to have a functional plugin library without any server side logic).

Of course (I think) you could only require plugins which are either
a) Official or
b) In your own library

Is it worth an issue?

The most useful GitHub issues are those that are directly actionable; using at as a repository for suggestions of things that could be done just fills it up and makes it hard to see the wood for the trees.

The best next step would be for someone to experiment with an implementation, and then open an issue referencing it. 

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/a3fb8bd0-f51b-4f8b-9557-44c262fe5dc5%40googlegroups.com.

[Stephan Hradek]

Am Dienstag, 27. Februar 2018 12:33:58 UTC+1 schrieb Jeremy Ruston:

The best next step would be for someone to experiment with an implementation, and then open an issue referencing it. 

Agreed. But I do not feel capable of being that someone.

;) Stephan

[Thomas Elmiger]

Hi Stephan

Concerning your original question: Here is what I did in my plugin ToDoNow. It depends on another plugin of mine called Listreveal.

In the readme I test for the presence of the other plugin and display a hint accordingly:

!!! ~ToDoNow needs Listreveal
ToDoNow extends the power of another plugin called //listreveal// to produce lists.

<$list filter="[all[shadows]title[$:/plugins/telmiger/listreveal/readme]!has[text]]">
[[Get Listreveal from tid.li/tw5/plugins.html|http://tid.li/tw5/plugins.html#Get%20More%20Plugins]]
</$list>

<$list filter="[all[shadows]title[$:/plugins/telmiger/listreveal/readme]has[text]]">
Read more about Listreveal: $:/plugins/telmiger/listreveal/readme
</$list>

Users should see either a hint to download the missing plugin or a link to the other plugin’s readme.

Good luck!
Thomas

[Stephan Hradek]

That's a good idea. Thanks!

[WiM]

<$reveal state="$:/plugins/something.js" type="match" text="" > WARNING missing plugin xyz please download from http://weblink</$reveal>

would generate a similar result

this could easly be transformed into a standard macro with three prameters.

if a unique tag like 'requires' is used then the results of these macros could be shown at startup by including (pseudo code)

list filter tag[requires] variable=ttt
br transclude tiddler=ttt
list

e.g. somewhere in sysytem defaulttiddlers

all users will automagically be notified and can take actions accordingly.

missing plugins create weird results in filters because they are interpreted as (hopefully also missing) fieldnames...maybe this default behaviour has to be optional as in opt-in.

just my 2ct's
wjam