Plugins tab should provide more management capabilities

[danielo515]

Under the control panel you have a nice plugins tab where you can see the installed plugins. But that is all that you can do. I think a button to delete or uninstall a plugin will be easy to implement and useful in plugin management. It should provide also the option to just disable a plugin, but this requires more time and effort to make it possible.

[Jermolene]

Delete/uninstall is indeed quite easy; you can experiment by adding the following into the table at the top of $:/core/ui/ControlPanel/Plugins:

<$button message="tw-delete-tiddler" class="btn-invisible">{{$:/core/images/delete-button}}</$button>

For example:

I think that the ability to disable plugins is the critical omission at the moment. We found with TiddlyWiki Classic that it was useful to be able to selectively disable and re-enable plugins to track down problems.

The implementation that I am considering is for the core to determine whether to enable the plugin "X" according to the content of the tiddler "$:/config/PluginStatus/X". A simple implementation might enable the plugin unless the text of the status tiddler is "disable" (matched case-insensitively).

Adding these features will require a better UI than we've got at the moment in the plugins tab of control panel. The current table approach is clumsy at scaling when the tiddler width changes.

[ssokolow]

My first impulse would be to store enabled/disabled via a field on the plugin rather than via a separate tiddler. What benefits are provided by using "$:/config/PluginStatus/X"?

[pmario]

@ssokolow Does this box work?

[ssokolow]

Which box?

[Jermolene]

What benefits are provided by using "$:/config/PluginStatus/X"?

If we use a field on the plugin itself then the plugin will need to be modified in order to enable/disable it. That means, for instance, that the TW syncer would attempt to sync the modified plugin back to the server.

[ssokolow]

Ahh, point. I forgot that different tiddlers might be given different sync behaviour beyond the basic "don't sync the temporary stuff".

What about "$:/config/PluginStatus/X" instead of storing something more complex in "$:/config/PluginStatus"? Is that to plan for extensibility, a performance optimization, or something else?

(Having thought about it a bit more, I think what I'm trying to grasp is what value that brings which outweighs making the listing of config tiddlers longer and harder for a developer to browse.)

[Jermolene]

What about "$:/config/PluginStatus/X" instead of storing something more complex in "$:/config/PluginStatus"? Is that to plan for extensibility, a performance optimization, or something else?

The proposal is to form the status tiddler title by using "$:/config/PluginStatus/" as a prefix to the plugin title. So there will be a separate plugin status tiddler for each plugin.

(Having thought about it a bit more, I think what I'm trying to grasp is what value that brings which outweighs making the listing of config tiddlers longer and harder for a developer to browse.)

The naming conventions are intended to make it easier to browse the system tiddlers. The idea is that we will offer a view which uses the common prefixes to form a hierarchical tree.

[pmario]

@ssokolow Does this box work?

Which box?

I have no idea, how this comment ended up in this thread. so just ignore it.

[ssokolow]

@Jermolene Ahh. Planned hierarchical display. That's what I was missing.

[danielo515]

@Jermolene In my opinion the delete button should be inside the plugin tiddler. That way You have to go two steps and the control panel interface will be cleaner. I think this is easy to implement but will solve very big issues. To uninstall a plugin you have to go into edit mode and this makes the browser to crash many times.

Regards

[Jermolene]

Hi @danielo515

To uninstall a plugin you have to go into edit mode and this makes the browser to crash many times.

I've not seen this behaviour. Can you reproduce it reliably?

[tobibeer]

Does the core provide the means to update $:/config/PluginStatus as a dictionary?

[Jermolene]

Sorry @tobibeer there's no tiddler called $:/config/PluginStatus.

The implementation of disabling plugins uses tiddlers with names of the form $:/config/Plugins/Disabled/$:/plugins/tiddlywiki/browser-sniff. These are individual tiddlers, and not a dictionary.

Why do you ask?

[tobibeer]

That was clear to me. I just wanted to know if it's technically possible atm to update a DataTiddler / dictionary instead of having a number of system tiddlers for each.

Looking at /prerelease, it seems it is using the ActionSetFieldWidget.

So I am thinking that, in order to reduce clutter, it were a good option to store the disabled status for plugins in a single tiddler, not multiple ones... and use that pattern more often.

After some testing I noticed that $action-setfield won't store any index of type '$:/foo', which is obvious for dictionary tiddlers, as that would mean to calculate some checksum / sanitized key... but not so much for JSON, or is it?

[Jermolene]

Hi @tobibeer

What clutter are you trying to reduce? Having lots of tiddlers isn't a problem, it's what TiddlyWiki was designed for.

After some testing I noticed that $action-setfield won't store any index of type '$:/foo', which is obvious for dictionary tiddlers, as that would mean to calculate some checksum / sanitized key... but not so much for JSON, or is it?

I'm not sure what you mean here. Is it that the data dictionary format doesn't allow colons in the keys, because they are used to separate the keys from the values?

An index like $:/foo should work with a JSON data tiddler.

[tobibeer]

clutter

The list of shadows and system tiddlers is growing rather quickly. But I will start using advanced search more often.

An index like $:/foo should work with a JSON data tiddler.

Yes, I tested it once again and it works now (must have done sth wrong the first time around)...

Setting A JSON DataTiddler

So, using a single $:/config/Plugins/Disabled* would be a viable option over having individual tiddlers.

Last but not least, congratulations to releasing 5.1.5! :+1:

[danielo515]

Hello @Jermolene

What did you not see? The need to edit a tiddler to delete it? It's common in all tiddlers. Try to delete the vis library of the taskgraph plugin, for example. It takes a lot to load, if it does.

[tobibeer]

You don't need to edit a tiddler to delete it: Deleting Another Tiddler

[Jermolene]

Hi @danielo515

What did you not see?

I've not seen the behaviour of going taking a tiddler into edit mode making the browser crash.

[danielo515]

Not even going to slow? Did you tried to edit the core tiddler for example?

El jue 27/11/2014, 16:08, Jeremy Ruston notifications@github.com escribió:

Hi @danielo515 https://github.com/danielo515

What did you not see?

I've not seen the behaviour of going taking a tiddler into edit mode making the browser crash.

— Reply to this email directly or view it on GitHub https://github.com/Jermolene/TiddlyWiki5/issues/645#issuecomment-64800865 .

[Jermolene]

Not even going to slow? Did you tried to edit the core tiddler for example?

Opening $:/core and clicking "edit" works OK for me. But then again I've got a fairly fast machine...

[danielo515]

If you have the chance, test in on a mobile device (smartphone or tablet). Many people that uses tiddlywiki only have those resources.

[twMat]

IMO most of this thread is now outdated. While it would still make sense with a direct delete button next to each item in the plugin list, I say whoever feels the enough urge should post a new fresh issue or OP for it. @danielo515 - close?

[Jermolene]

I think the most important part of the OP was implemented: to be able to disable plugins directly from within the control panel.