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


> 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 tiddlywikidev+unsubscr...@googlegroups.com 
> <mailto:tiddlywikidev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywikidev/3ce76d4e-d398-4866-a95b-b4abf610b77e%40googlegroups.com
> <https://groups.google.com/d/msgid/tiddlywikidev/3ce76d4e-d398-4866-a95b-b4abf610b77e%40googlegroups.com?utm_medium=email&utm_source=footer>.

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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to