Plugin mechanism steps + relevance for twCards List?

[Mat]

[Doh! Title should read: "Plugin library mechanism steps + relevance for twCards List?" ]

For importing plugins, one should;

1) Click the big blue button "Get More Plugins" to get a modal

2) ..and then click the green button "Open Plugin Library". This opens first empty tabs (plugins, themes, languages)  but quickly they fill with lists of available plugins.

3) ...then click "Install" to fetch the plugin.

Questions:

a) Why two buttons to reach it? Couldn't the modal just open with the contents of the green button already open?

b) In step 2 the loading duration indicates that it is an iframe loading ... but on the other hand, if it is an iframe then one shouldn't be able to download from inside it? What am I misunderstanding?

c) If the list is actually a local display, does this mean it is only updated when one does a full upgrade of the core?

The main reason for asking is because for the TWederation, Jed and I are planning on having a central public twCards List. A twCard is a tiddler with the "contact info" to a source TW where you can fetch tiddlers (including messages to you). The twCards list is thus a central hub where people can publish their public(!) twCards - e.g for blogs - so everyone else knows where to find them. 

My hope is that people can download such twCards without leaving their own TW, similar to how the plugin library lets you filter and fetch(?) plugins that you fancy.

Any thoughts on this are welcome.

<:-)

[Jed Carty]

The information is obtained using postMessage in the same way as in twederation. The difference is that the plugin library pulls static content (in the sense that you can only get predefined things from the remote site instead of being able to request a custom set of tiddlers), this makes it less flexible but also a bit simpler and probably a bit safer.

a) The answer here is mainly 'because that how Jeremy made it'. You could make it so that opening the modal also opened the unopened libraries but then there wouldn't be an explicit user action for opening up a new connection which goes against some of the design principles tiddlywiki has adopted.
b) It is getting information from within the iframe using the same process as twederation. Well, that is I copied how this works to make twederation work. The twederation connections just pass more information and have some more sophisticated communication but it is the same thing happening.
c) Yes, that is one of the problems that has kept me from updating the plugin libarary I made right after Jeremy introduced it. There isn't any way to properly close an iframe and clean things up afterward in the core. I have a sloppy version working for twederation but nothing is implemented for the plugin library yet. It hasn't been a problem because the only libraries are the core one, the one I made and haven't been using and now Tobias has his library. Hopefully since he is using it too there will be some updates to the core to make it all work better.

We may have to do a hangout devoted to just going over the inner workings of the wiki communication we are using

[Mat]

HA! Your reply here and in a private email gave the missing piece in my puzzle of confusion; The plugin "Install" button is not in any iframe after all!

I'm sure some are rolling their eyes now because the whole process has already been explained several times, in hangouts by Jeremy. So let me explain why I never got it, in case anyone tries to explain it for people who might be as slow as I have been - such as in potential documentation on the matter:

It is the visual appearance of the plugin library and my perception of what an iframe is, that misled me;

Jeremy has (patiently) explained that the plugin library uses a hidden iframe and also a postMessage. Now, all use cases of iframes that I've seen are a visual representations of remote websites. So, the "deep digging" to reach the plugin list and the loading delay really tricked me into assuming that this involved the iframe, temporarily visible... or perhaps, somehow, not visible but still loading. I now understand that an iframe is not at all involved before you click the Install button and that an iframe is not necessarily a visual thing at all. Instead the click sets some parameter and it is only after this that the iframe - a separate matter (and styled to not display) - becomes active, and uses this parameter value.

So, NOW I think I finally got it (...but please do shout if I somehow still didn't...).

Big thanks!

<:-)

[Mat]

Regarding 

 

> If the plugin list is actually a local display, does this mean it is only updated when one does a full upgrade of the core?

 

Yes, that is one of the problems that has kept me from updating the plugin libarary I made right after Jeremy introduced it.

But... that's trivial, no? - Have one plugin be "special"... it is actually the plugin list itself. The button is named "Update plugin list" instead of "Install"...?

For TWederation, we can least we can do this with the twCards list, if we think it is suitable with a local list. Could be a dictionary instead of the actual twCards.

<:-)

[Jeremy Ruston]

Hi Jed, Mat,

> If the plugin list is actually a local display, does this mean it is only updated when one does a full upgrade of the core?

The plugin list displayed by the plugin manager is obtained dynamically from the plugin library. The current implementation of the core plugin library is only updated when a new release of the core is released, but that’s not a restriction placed on third party plugin libraries.

Anyhow, a future version of the core plugin library could be more dynamically updated, but right now I want to focus on getting good support for third party plugin libraries.

Yes, that is one of the problems that has kept me from updating the plugin libarary I made right after Jeremy introduced it.

I’m not sure which problem you’re referring to here Jed?

But... that's trivial, no? - Have one plugin be "special"... it is actually the plugin list itself. The button is named "Update plugin list" instead of "Install"…?

As I say, the mechanism to pass the plugin list from the plugin library to the host wiki already exists.

Best wishes

Jeremy.

For TWederation, we can least we can do this with the twCards list, if we think it is suitable with a local list. Could be a dictionary instead of the actual twCards.

<:-)

--
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/3466b655-ef55-4191-a5be-0077cc123a38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jed Carty]

Jeremy,

The local information about available plugins didn't update when there were updates in the library. Since I am so inconsistent about when I update things this is a problem. I had looked into a way to solve this a while ago and made an attempt to create something that closes and re-opens a library to refresh it but I didn't know how any of it worked so I stopped. This was a few months ago, now that I have a better idea of how things work I maybe able to make something but I am attempting to limit myself to only a few projects at a time (currently the simple TWederation work, the SnapSVG tool and the resume edition). Hopefully since Tobias is being much more active with the plugin libraries than I ever was he will create clean ways to reload a library and take care of the problems I had.

[Jeremy Ruston]

Hi Jed

The local information about available plugins didn't update when there were updates in the library.

Do you mean that you made updates to the library and that they didn’t automatically show up in the browser? I think it’d be a hard problem to make it make it do that without some kind of explicit reload (either of the page, or within the plugin library UI itself).

Since I am so inconsistent about when I update things this is a problem. I had looked into a way to solve this a while ago and made an attempt to create something that closes and re-opens a library to refresh it but I didn't know how any of it worked so I stopped. This was a few months ago, now that I have a better idea of how things work I maybe able to make something but I am attempting to limit myself to only a few projects at a time (currently the simple TWederation work, the SnapSVG tool and the resume edition). Hopefully since Tobias is being much more active with the plugin libraries than I ever was he will create clean ways to reload a library and take care of the problems I had.

For plugin libraries, I think it’s not a huge problem for end users to have to reload their TW in order to see updates made to a library. I can see it’s an issue in development for plugin library maintainers, but for end users I’m not sure that updates to plugin libraries are frequent enough for it to be a problem.

For me, it’s only when we look at TWederation that we need to fix the problem by providing a means to reload an embedded server (which is what we might call the contents of an iframe in TWederation; it’s not necessarily a TiddlyWiki, as the plugin library shows). I think it’s a critical part of the mechanisms that we need to introduce to implement TWederation. To be clear, when we’re done, the existing plugin library will be a thin layer over the top of a generic federation layer. In other words, we need to refactor the existing plugin library code for the ultimate implementation of federation. That’s not something we need to worry too much about now, it’s more important to speed up the experiments you’re doing on the UI around federation.

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/a1fecdbd-67c8-4c9c-8c2d-1eab56ec9eb7%40googlegroups.com.