Shadow Tiddler behaviours

[TonyM]

Folks

Could someone with an understanding of plugins and shadow tiddlers possibly explain what happens in the following circumstance and do I have any control over it?

Keep in mind with the pre-release reload will not be necessary for all plugins.

Lets say I have a core tiddler which is a shadow

Now I install "plugin one" which has a copy of that same tiddler

Then I install "plugin two" which also has a copy of that same tiddler 

• Is there a way to explain the resulting behaviour?
• Also on editing the original tiddler I believe it will retain the edited version no matter which plugin or core is installed
• What happens if I disable one or both plugins?
• What happens if I have the same (not core tiddler) in the two plugins?

Some guidance would be greatly appreciated, I have not being able to gleen this from the existing documentation.

Thanks in Advance

Tony

[TonyM]

Bump

Folks I have dozens of code that I plan to make into plugins, I would like to understand this before proceeding. Any help whatsoever would be appreciated.

Tony

[SylvainComte]

Hello Tony,

I did not answer because I have not enough theorical background to say what will happen. I have a practical case of multiple copies of a shadow tiddlers working in the same wiki : see my i18n macro used in several plugins of
http://sycom.gitlab.io/TiddlyWiki-Plugins/

BUT it doesn't overwrite a core plugin AND I did not investigate what happens here, which version is retained or anything like this since I'm sure the tiddler is the same. By construction.

Cheers

Sylvain
@sycom

[PMario]

On Thursday, January 9, 2020 at 3:46:33 AM UTC+1, TonyM wrote:

Keep in mind with the pre-release reload will not be necessary for all plugins.

Lets say I have a core tiddler which is a shadow

Now I install "plugin one" which has a copy of that same tiddler

Then I install "plugin two" which also has a copy of that same tiddler 

• Is there a way to explain the resulting behaviour?

In TW "the last one wins". So the last plugin, that is activated will create the "shadow" tiddler

Or you could also say: In TW "start order matters"

 

• Also on editing the original tiddler I believe it will retain the edited version no matter which plugin or core is installed

In TW the "user will always win" ... So if a "shadow" tiddler is modified, it will become a "normal" or a "system" tiddler.

"system" tiddlers are normal tiddlers strating with $:/.

That's just a convention, which is "hardcoded" in the TW UI.

No matter what plugins do. As long as the non-shadow tiddler exists it will be used. Except all plugins are deactivated.

• What happens if I disable one or both plugins?

The last one activated wins. ... This may cause problems if you de-activate plugin-a and user modified plugin-config

That's why we use plugin-namespaces. eg: $:/plugins/<author>/<plugin-name>/config ... No conflict will happen.

 

• What happens if I have the same (not core tiddler) in the two plugins?

The last one wins. See namespaces.

 

hope that helps

mario

[Jeremy Ruston]

Hi Tony

Could someone with an understanding of plugins and shadow tiddlers possibly explain what happens in the following circumstance and do I have any control over it?

Keep in mind with the pre-release reload will not be necessary for all plugins.

Lets say I have a core tiddler which is a shadow

Now I install "plugin one" which has a copy of that same tiddler

Then I install "plugin two" which also has a copy of that same tiddler 

Plugins are loaded in a specific order determined by the numeric value in their “plugin-priority” field (if present), with further subsorting taking place on the title field. The core plugin has a “plugin-priority” value of “0”, and thus will always be sorted before plugins that lack a “plugin-priority” field. Plugins appearing earlier the sort order have their shadow tiddlers overridden by those of subsequent plugins.

• Is there a way to explain the resulting behaviour?

See above.

• Also on editing the original tiddler I believe it will retain the edited version no matter which plugin or core is installed

That’s correct, editing a shadow tiddler makes it into an ordinary tiddler.

• What happens if I disable one or both plugins?

Then their shadow tiddlers will not be loaded.

• What happens if I have the same (not core tiddler) in the two plugins?

The highest priority plugin wins (see above).

Best wishes

Jeremy.

Some guidance would be greatly appreciated, I have not being able to gleen this from the existing documentation.

Thanks in Advance

Tony

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/7940f436-6668-48cc-8c16-704329b5c1ed%40googlegroups.com.

[TonyM]

Thanks all for you answers.

I see how I can control this now. I am interested for example in having two lots of config tiddlers ((plugins with the same tiddlers with different values) and providing a way to "toggle" between them. Other uses include alternative datasets and test data. Use the small set for design then the second for more exhaustive testing, and the ability to toggle.

The fact is that the possibility of an edited shadow overriding both, has both merits and complications. Perhaps I can build into the plugins the means by which to activate and deactivate each other including removing any matching edited tiddlers. After all in this case we thats what we want, to disable any override and establish a new epoch.

This prompts me to ask if it makes sense to add to the plugin delete or deactivation processes an option to clean up?

I imagine in some cases a tiddlywiki used for experimentation could be full of unwanted plugin tiddlers that changed while installed, due to a configuration setting or customisation.

Another idea is to access the subtiddlers in a selected plugin (one of two) and copy them to the edited tiddler when toggling the settings. Thus the latest will be the last plugin source used to create the edited tiddlers. This could be a general button on any plugin tiddler (or built into the plugin settings), copy all shadows to tiddlers, along with a button to clean up such edited tiddlers.

Thanks

Tony

On Thursday, January 9, 2020 at 1:46:33 PM UTC+11, TonyM wrote:

[TonyM]

Post script

Don't take this too seriously, but I discovered a plugin is a plugin by virtue of having the plugin-type field and by using another value in the field than the defined ones, one miraculously creates a new plugin type. Add a tab to $:/core/ui/ControlPanel/Plugins to list them (containing `<<plugin-table newtype>>`) and you can even manage them.

Unfortunately there is no tag for plugin tabs so I must modify $:/core/ui/ControlPanel/Plugins

Perhaps I could provide a config plugin type which adds some buttons to control the toggling of alternative configurations.

Regards

Tony

[Jeremy Ruston]

Hi Tony

I see how I can control this now. I am interested for example in having two lots of config tiddlers ((plugins with the same tiddlers with different values) and providing a way to "toggle" between them. Other uses include alternative datasets and test data. Use the small set for design then the second for more exhaustive testing, and the ability to toggle.

One useful technique to bear in mind is that we can extract the payload tiddlers (“subtiddlers”) from within plugins regardless of their shadow status. See the transclude and view widgets, and the subtiddlerfields operator.

The fact is that the possibility of an edited shadow overriding both, has both merits and complications. Perhaps I can build into the plugins the means by which to activate and deactivate each other including removing any matching edited tiddlers. After all in this case we thats what we want, to disable any override and establish a new epoch.

This prompts me to ask if it makes sense to add to the plugin delete or deactivation processes an option to clean up?

It might be hard to capture all the ways that a plugin can be removed or deactivated: given that it is just an ordinary tiddler there are myriad ways for users to modify it.

I imagine in some cases a tiddlywiki used for experimentation could be full of unwanted plugin tiddlers that changed while installed, due to a configuration setting or customisation.

That’s one of the reasons why the $:/config, $:/temp and $:/state namespaces are so important.

Another idea is to access the subtiddlers in a selected plugin (one of two) and copy them to the edited tiddler when toggling the settings. Thus the latest will be the last plugin source used to create the edited tiddlers. This could be a general button on any plugin tiddler (or built into the plugin settings), copy all shadows to tiddlers, along with a button to clean up such edited tiddlers.

I’m not sure I’m entirely following but I think the components exist for you to experiment along those lines,

Best wishes

Jeremy

Thanks

Tony

On Thursday, January 9, 2020 at 1:46:33 PM UTC+11, TonyM wrote:

Folks

Could someone with an understanding of plugins and shadow tiddlers possibly explain what happens in the following circumstance and do I have any control over it?

Keep in mind with the pre-release reload will not be necessary for all plugins.

Lets say I have a core tiddler which is a shadow

Now I install "plugin one" which has a copy of that same tiddler

Then I install "plugin two" which also has a copy of that same tiddler 

• Is there a way to explain the resulting behaviour?
• Also on editing the original tiddler I believe it will retain the edited version no matter which plugin or core is installed
• What happens if I disable one or both plugins?
• What happens if I have the same (not core tiddler) in the two plugins?

Some guidance would be greatly appreciated, I have not being able to gleen this from the existing documentation.

Thanks in Advance

Tony

-- 
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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/3ce76d4e-d398-4866-a95b-b4abf610b77e%40googlegroups.com.

[Jeremy Ruston]

Hi Tony

Don't take this too seriously, but I discovered a plugin is a plugin by virtue of having the plugin-type field and by using another value in the field than the defined ones, one miraculously creates a new plugin type.

I thought I had documented that, perhaps in the PR? It’s not yet clear when we would want to establish new types.

Add a tab to $:/core/ui/ControlPanel/Plugins to list them (containing `<<plugin-table newtype>>`) and you can even manage them.

Unfortunately there is no tag for plugin tabs so I must modify $:/core/ui/ControlPanel/Plugins

It would certainly make sense to make those tabs be tag-driven.

Perhaps I could provide a config plugin type which adds some buttons to control the toggling of alternative configurations.

Why wouldn’t that be an ordinary plugin?

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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/08b9d321-9e34-4535-b4f4-031c694a417a%40googlegroups.com.

[TonyM]

Jeremy,

Don't take this too seriously, but I discovered a plugin is a plugin by virtue of having the plugin-type field and by using another value in the field than the defined ones, one miraculously creates a new plugin type.

I thought I had documented that, perhaps in the PR? It’s not yet clear when we would want to establish new types.

This is just experimentation at this point. Possible alternative plugins I am playing with are 

Configuration plugins, which have more than one configuration and a simple toggle to activate one or the other so we can package a set of tiddlers with a set of values as a configuration plugin, perhaps this is also useful for building editions with settings outside the installed plugins.

Data Plugins, primarily to deliver data and test data in a package. An example may be a plugin containing all international airport codes. The shadows are the source of truth but changes can be made. Another is a set of shared tiddlers for test data when designing or trouble shooting in the forums.

 

Add a tab to $:/core/ui/ControlPanel/Plugins to list them (containing `<<plugin-table newtype>>`) and you can even manage them.

Unfortunately there is no tag for plugin tabs so I must modify $:/core/ui/ControlPanel/Plugins

It would certainly make sense to make those tabs be tag-driven.

Ok, If someone can tell me an appropriate naming standard I can submit a change to achieve this (when I work out how to submit pull requests against master rather than tiddlywiki.com

Perhaps I could provide a config plugin type which adds some buttons to control the toggling of alternative configurations.

Why wouldn’t that be an ordinary plugin?

As suggested above the desire would be to have two bundles of tiddlers (in a plugin or two) containing the same tiddlers but with a separate set of values. The value with plugins is is that we can revert to the shadow. One could then activate the values in one to replace the other. By using a bundle of tiddlers, less coding is required and in fact there is a way to record changes in a wiki and store them in a configuration so the creator of the config tiddler need not know the details of the tiddlers just work through the UI to set the prefered configuration, then save the changes in a config plugin.

We could also add a UI component to ease the activation of config plugins. 

I already have a project to enhance the management of $:/config and similar tiddlers, the addition of a UI to select values by default, and option to revert to the shadow value and automatically allow config tiddler containing one value to be change to another eg yes to no true to false, show to hide......

Regards

Tony

 

Best wishes

Jeremy

To unsubscribe from this group and stop receiving emails from it, send an email to tiddly...@googlegroups.com.