My plugin needs a modified core tid - how?

[Mat]

So I'm working on a plugin that, among other things, will give plugin update alerts. (never mind how)

I want to show this alert in the regular plugin list, ideally in the $:/core/ui/Components/plugin-info tiddler which is the one showing each separate plugin as a "row" in the plugin list.

How should one approach manipulating core components? It is one matter for personal tweaking but not so good when making public plugins. ...besides, whose shadow tiddler wins? Once my overwrite is in a plugin it is no longer an overwrite but a shadow, so which one should the system choose?

Jeremy has mentioned putting in hooks which I interpret to mean things for these sort of matters... so should I just "request a hook" and specify exactly where? Or maybe I'm using the term "hook" in a faul way.

<:-)

[PMario]

Hi Mat,

Your plugins are activated after the core. So your stuff should win if your plugin just contains core ui tiddlers. ..

If you overwrite core javascript modules, there is a way to define the startup order. BUT overwriting modules is really hardcore and should only happen, if you exactly know what you do.

Overwriting eg: UI-Elements is standard for plugins.

-mario

[PMario]

So what should your "hook" do?

-m

[PMario]

Do you have an MTC where we can see your changes. ... You need to tell, what you changed.

We can see, if a hook is possible ...

-m

[Jeremy Ruston]

Hi Mat

There are a few different kinds of “hook”.

Often, I’ll be referring to JavaScript hooks. They’re a low level mechanism for JavaScript functions to be invoked as certain actions are performed (e.g. renaming a tiddler), allowing those actions to be customised.

We do also use the word more loosely in a wikitext context. The most important wikitext hook is the system tag mechanism that allows additional elements to be folded into TiddlyWiki’s user interface.

I want to show this alert in the regular plugin list, ideally in the $:/core/ui/Components/plugin-info tiddler which is the one showing each separate plugin as a "row" in the plugin list.

So, we could extend $:/core/ui/Components/plugin-info to use a system tag in the same way.

How should one approach manipulating core components? It is one matter for personal tweaking but not so good when making public plugins. ...besides, whose shadow tiddler wins? Once my overwrite is in a plugin it is no longer an overwrite but a shadow, so which one should the system choose?

Plugin writers should avoid overwriting core tiddlers in almost all cases. Otherwise it’s difficult for plugins to co-exist reliably.

Best wishes

Jeremy

Jeremy has mentioned putting in hooks which I interpret to mean things for these sort of matters... so should I just "request a hook" and specify exactly where? Or maybe I'm using the term "hook" in a faul way.

<:-)

--
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/bcbb2e82-f950-4461-9d41-037869be8fdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

PMario thanks for reply

Do you have an MTC where we can see your changes. ... You need to tell, what you changed.

http://plugin-info-hook.tiddlyspot.com/

I don't know if the macro call is put in the optimal place.

<:-) 

[Mat]

Jeremy, thanks for reply.

What would you call the thing I did in the MTC mentioned in previous post? I.e i inserted a <<macrocall>> in the middle of a core tid. Is that a hook? 

If not, what it the correct term for something that would achieve the same or similar result?

Thanks

<:-)

[PMario]

Hi Mat,

I did create a slightly similar PR some time ago: https://github.com/Jermolene/TiddlyWiki5/pull/2764

Also with the intention to make it easier to read.

So imo this should be fixed in the core.

-m

[Mat]

PMario wrote:

I did create a slightly similar PR some time ago: https://github.com/Jermolene/TiddlyWiki5/pull/2764

Also with the intention to make it easier to read.

Wait, my question is not in any way about making things easier to read. It is about inserting content more freely. I put ni a <<macrocall>>. I intend to have a download button there to directly download an updated version of the plugin. 

The even wider question is how we generally can insert content into, or otherwise modify, shadow tids without overwriting them. 

BTW, your proposal 

<:-)

[Jeremy Ruston]

Hi Mat

On 6 Jul 2019, at 21:13, Mat <matia...@gmail.com> wrote:

The even wider question is how we generally can insert content into, or otherwise modify, shadow tids without overwriting them. 

I tried to answer that earlier: we transclude components by their tag so that new components can be interleaved by creating a new tiddler with that tag. You see this mechanism in the page template, sidebar, view template, edit template etc. etc. It’s the universal mechanism TW5 uses for extensibility.

Best wishes

Jeremy

[Mat]

Jeremy Ruston wrote:

I tried to answer that earlier: we transclude components by their tag so that new components can be interleaved by creating a new tiddler with that tag.

I didn't realize that this was as universally appropriate everywhere. So... the right thing for me to do now is then to request that a listwidget is inserted in the template for those "plugin cards" listing everything tagged with, say, the plugin title? Or the plugin title and a specific tag like "plugin card" - or how would only the "plugin cards" be targeted?

<:-)

[TonyM]

Mat,

So I understand you want to modify $:/core/ui/Components/plugin-info?

Perhaps I am missing something but Plugins are displayed as such when they have the plugin-type=plugin  and uses $:/core/ui/ViewTemplate/plugin which itself transcludes the tiddler you want to edit. The fact is, that the plugin info view comes to us as a result of the $:/core/ui/ViewTemplate/plugin having the $:/tags/ViewTemplate tag.

• Why not create you own alternative $:/core/ui/ViewTemplate/plugin tiddler eg: $:/mats/plugin-info/ViewTemplate  having the $:/tags/ViewTemplate   tag 
• Which instead transcludes your own version of $:/core/ui/Components/plugin-info lets call that $:/mats/plugin-info/custom.
• Now add a checkbox to your $:/mats/plugin-info/ViewTemplate 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.
• Now if it is a plugin you created, add to your readme or a config tab,  \in the plugin definition, the checkbox toggle to alternate between the core or your plugin info view. If it is only a macro place and document this in $:/mats/plugin-info

Using this method your change is simple to reverse, documented in the plugin and driven by an existing tag. If removed and the tag is not restored to $:/core/ui/ViewTemplate/plugin it will show this is an overridden tiddler, and deleting it will restore the tiddler and tag.

The only thing that can be updated that will cause a possible problem is $:/core/ui/Components/plugin-info if you never get to see its change. But your change will most likely keep working.

Regards

Tony

[Mat]

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?

<:-)

[TonyM]

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

[Ed Dixon]

Hi all. 

Been a long time since I have done anything with TW5 or anything else for that matter, still recovering from brain surgery where damage was definitely done but I have been lurking both forums all along (for years now without a word!) and regretfully find trying to use even the most basic functionality of TW a challenge due to its already built-in amazing flexibility and functionality. So I may be way off on this and want to say up front, first and foremost, I mean absolutely no disrespect to anyone involved here. However, as I am understanding this, I simply can not stand to watch this thread continue much longer. I can picture Jeremy right now trying to figure out how to allow an end user turn his fine-tuned jet airplane into a space station at the cost of other useful functionality he may be trying to add, He has proven to work very diligently on feature requests (usually very successfully) to provide needs that also meet the applications goals but this one is simply too much to ask IMHO and I do hope Jeremy seriously gives that consideration. I made a similar request years ago to meet a specific need that I no longer have, and couldn't implement now even if he gave me supervised directions complete with pictures on how to do so. Despite all that he probably did add that functionality (I can't even remember what it was at this point) and hope it didn't cost him too much time or if so it did turn out to be of use to the project as a whole. 

That said, My first instinct to a thread suggesting a core change would be to fork it and go for it yourself (which is what I wish I had done while I still had the chops to try to do so) I am a little surprised this hasn't already been suggested. He can always implement those changes back into the core if it meets his requirements without the cost of a lot of his own time (GOD bless GIT). But be prepared to meet all the needs of his overall goals with TW5 and ALL the complexities that imply. Such as the Internal mechanisms that other core mechanisms may rely on that are based on the one you intend to change, the responsiveness of the application, clarity, and functionality for the typical and advanced end-user, testing to make sure changes have not broken any other functionality, any and all security implications involved, and everything else that Jeremy so diligently provides us with this amazing tool.

I can understand a need to add special functionality a specific project might require at the cost of some of this (as I think was my case, my memory is shot) but given that the core has been built with the ability to transclude even itself providing what I feel is as much flexibility as one could expect and should allow almost anything within reason to be possible,. perhaps at this point, TW5 has reached a point of maximum returns in regards to adding new plugin programming features (especially if they are for specific needs and not the project as a whole)? (again all IMHO and yes I admit I am a total fanboy, his work on this is and was totally mind-blowing at least for me anyway LOL!). 

Thanks for taking the time to read all this if you made it this far I tend to rant on and on at this point... 

[Mat]

Ed, good to see you here and thanks for your thoughts - but I don't understand you point.

First, my question is how should a user insert something in "items" that are seen in the pluging list. Don't you think this is a fair question? Jeremy kindly answered, referring to a technique that is simply not applicable here because the individual items there are not built up by a listwidget. (The plugin list itself is, but the display of the individual items is not).

My wider question is HOW a user should request "hooks" and what are the conditions around it? I have not done any request. I'm asking because I want to know HOW to request something like this, if at all reasonable. The background here is that Jeremy has previously explicitly stated an ambition to have "hooks" in the code. As should be clear in my original post, I'm uncertain what exactly constitutes a "hook" but think that what I asking about would be one. (Is it?)

I'm an advanced user who pushes some of the limits in TW. My handicap is also my strength, namely that I don't know javascript so I need to solve everything within TW itself. This exposes limitations in TW in a way that people who solve it via non-TW means probably don't see as limitations in the same way. Obviusly, the more sophisticated TW gets the more "fringy" requests are made - the basic functionality is there and works well - but what TW can do is there thanks to Jeremys incredible work in combination with input from the community both in therms of code and mere ideas and expressed needs.

<:-)

[Jeremy Ruston]

Hi Ed, Mat,

Good to see you back, and good luck with your recovery. Your concerns echo some of my mine over the years, but happily I don’t think they apply to most of the conversation here.

The context is that we use system tags as a common extensibility mechanism throughout the core user interface, and it has proven to work successfully. From Mat’s question arises the proposal of bringing that same extensibility mechanism to the way that plugin information panels are displayed.

I’ll respond to Mat’s specific questions momentarily.

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/2183b04d-fdea-4e0e-a990-38dc8411cf0d%40googlegroups.com.

[Jeremy Ruston]

Hi Mat

My wider question is HOW a user should request "hooks" and what are the conditions around it? I have not done any request. I'm asking because I want to know HOW to request something like this, if at all reasonable. The background here is that Jeremy has previously explicitly stated an ambition to have "hooks" in the code. As should be clear in my original post, I'm uncertain what exactly constitutes a "hook" but think that what I asking about would be one. (Is it?)

Discussions on the group are a great way to explore solutions to problems, and sometimes specific proposals for core changes will drop out of those. Once there’s a concrete proposal GitHub is often the right place to work on it.

I'm an advanced user who pushes some of the limits in TW. My handicap is also my strength, namely that I don't know javascript so I need to solve everything within TW itself. This exposes limitations in TW in a way that people who solve it via non-TW means probably don't see as limitations in the same way. Obviusly, the more sophisticated TW gets the more "fringy" requests are made - the basic functionality is there and works well - but what TW can do is there thanks to Jeremys incredible work in combination with input from the community both in therms of code and mere ideas and expressed needs.

Yes indeed. I’ve long lost count of the number of TW5 enhancements that would never have happened had not somebody asked the right question at the right time.

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/e0b88d8b-cd14-4946-af0b-6e3e659a5040%40googlegroups.com.

[TonyM]

Mat,

Did you consider my suggestion to build a parallelle "list plugins" and use the view template? Placing a list-before or list after to position it? The same view template could include the checkbox to switch between the default and your own. The only and common thing is to tag with the view template system tag. And the only core change is the addition or removal of this tag. You could even build into your checkbox to restore the shadow tiddler. Ie your change is always reversible and announces itself when in use. 

To me this is more than adequate.

I can provide more details if you want.

Regards

Tony