Mat, I understand where you are coming from yet when you write a plugin or macro which changes something tiddlywiki already does, in this case the way it lists plugins, it is best to use a low impact "tag of a system tiddler", if that is available, in my example I have moved this into the viewtemplate tag. Alternatively if it looks like a common occurrence we can ask that the core hackability be enhanced by providing a system tag for this purpose. Eg a tag that indicates the "template" to use when listing plugins. However as long as you are replacing a User Interface component, you will I believe, always face this issue. We can either see the default or the new view not both.
One strategy is to not replace something tiddlywiki does, but add to it. That is let it continue to display plugin tiddlers as it does but also display the extra information you intended in the plugin, Although in this case it may still demand a new system tag. Perhaps create an alternative control panel tab "MatsPluginview" so the existing behaviour remains and yours has being added. Another strategy is to override the default behavior as per my earlier suggestion, but also add a sideBar tab that lets the user enable or disable your override. This keeps the fact a system tiddler was modified visible. Speculation - I wonder if there were a way to code into you plugin a method for it to detect if the tiddlers you "override", and their shadow tiddlers change, then your plugin could advise there is an underlying change that has occured?. - Perhaps the upgrade process itself could list the tiddlers that have being updated yet continue to be overridden by another tiddler or plugin. So people get to choose at upgrade time. Regards Tony On Monday, July 8, 2019 at 11:23:59 PM UTC+10, Mat wrote: > > TonyM wrote: >> >> ... that removes the $:/tags/ViewTemplate tag from >> $:/core/ui/ViewTemplate/plugin and adds it to >> $:/mats/plugin-info/ViewTemplate and visa versa. This will toggle your >> change in and out. > > > While better than manipulating the very content of the core tid, it still > modifies the core tid potentially causing issues when updating. > > In contrast, the implemented mechanism Jeremy describes is that e.g the > core sidebar tid lists all sidebar segments i.e just any tiddler tagged > with the right tag. The user can insert whatever he wants and updates are > no issue. > > My question is specifically how I can insert something in the plugin > display in a comparable way. While the "list everything tagged" technique > is general, it is not *applied* everywhere (that'd be impossible) so my > general question is how a user should approach this. I.e now that I'm > creating a plugin, hopefully soon to be unleashed unto the the crowds, how > do I avoid having to include a modified core tid? > > <:-) > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/bbad6743-8b26-46d7-8420-9fefebe475f9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
