Some thoughts on plugins

[Diego Mesa]

All,

The general attitude/perspective to new/additional functionality in TW tends to be: "Keep the core small and backward compatible", leaving many interesting additions to plugins. In order for this to be a viable thing to do, I think we need to think critically about:

1. How do (particularly new) users find out about new/existing plugins?
• The "resources" information on tw.com. There is something unsatisfying/unclear about this. New users are bombarded with 30 ways to save, let alone a collection of links to other pages, many of which are dead, no longer supported and/or do not work with the current version of TW.
• The "Get more plugins" button on a fresh TW install - this links to the official TW plugin library, which lists 54 "official" plugins. I actually like this, and its how I first found out about plugins. 
• The most complete answer to this seems to be: google group threads. This requires new users A. find out about our google groups and actually go it - B. Subscribe/read/search for new plugins/additional functionality.
• A great option would be a "web store"/"app store" equivalent like chrome/firefox/smartphones have. Also, other tools have "package managers"/communities that make this easy. For example, sublime text has package control, vim has vim awesome, etc. which tell you what versions this plugin supports, always points to the latest versions, offers comments underneath plugins, tells you what plugins are popular, most installed etc.
2. How do users install plugins?
• The drag-n-drop method (and additional files-based-method on node) is actually a very user-friendly and easy to understand method. 
3. How do users update (and find out about updates) to plugins? 
• Many plugins get updated to fix bugs, keep up with TW, and add new features. Many other plugins just get out of date/abandoned/unsupported. 
• To find out about updates you have to: A. go to authors website which is hopefully (but rarely) listed on readme and reinstall or B. Stay subscribed to google groups
• As an example, I recently went through and updated my plugins - I had to go to many different websites (searching google groups for some), and check version numbers, and update accordingly. 
• I think some centralized method for "check for and install updates" would be a fantastic addition to the community. 

With a centralized repository of plugins, we could also enforce certain plugin structure, as Joe recently recommended in another thread. Things like:

• author name
• email
• website
• license
• supported TW version: an optional field which could force a plugin to only work on select versions of TW, which a person could override.

So, some solutions/ideas are:

1. A centralized repository of plugins, very much like package control for sublime text
2. An "update" method
• Your TW could check installed plugin versions with that on our centralized repo, letting you know if you need to update.
  
• As I understand, it still couldn't actually "fetch" the updated plugin tiddler from github - you need to do this manually - is this correct?

What are others thoughts on this topic?

Best,

Diego

[TonyM]

Diego,

I support what you are asking we do. One side note is if you edit a plugin there are additional fields. The Source field should point to the source of the latest version of the tiddler (and only sometime does)  Personally I built my own repository of plugins to get around this and to allow be to "register" each, adding my own notes without editing the original plugin to combat the limitations of the current model.

If there was a well documented method for plugins to be submitted to and accessed from both GitHub and a community plugin library we would be a long way to solving this. There would be less dependance on multiple sources.

I would love to see more work done on this.

Thanks for sharing.

Tony

[Jed Carty]

I have a working plugin library through Bob that can either have the library updated by pulling from GitHub or by the author pushing a new plugin version.

One of the half finished features is a check for updates button that pulls a list of the current version of each plugin and checks it against installed plugins with a note if there are any updates available.

The hope was that people would be interested in using this, but I got almost no response so I haven't worked on polishing it.

Ooktech.xyz is currently having certificate problems, but when it is available the library is public.

With this it doesn't need to be a centralised repo, we could have multiple federated servers that can serve different plugins and each server could have a listing of other known plugin servers so if someone has access to one server they can find the others. A developer could either have their own server that is listed on other servers or they could register with an existing server to get credentials to push updates to their plugin(s) to that server.

[TonyM]

Jed,

I built my own plugin repository on top of Bob, and was keen to migrate it into the library Bob provides and those features, making it available to all its children etc.... Like everything about bob I love the work your doing and think you select great targets for innovation.  However I always stumble trying to actually use its advanced features, or implement them. With all due respect and also as someone who is aware of the challenges you face, your documentation is always quite brief, has jargon, assumptions,  and it is necessary to read between the lines, that is have prior detailed knowledge of Bobs technology before I can follow the instructions, and gain the detailed knowledge. Bit of a catch 22.

I have and continue to offer help developing documentation further for the naive like me, however unfortunately I have being unable to develop the deeper understanding I need to start on this. I am aware Josiah has made progress on this but have lost track of where it is published.

It is understandable that your domain is the deep technical reaches of TiddlyWiki but few of us have your understanding, and we can't expect you to easily comprehend our nativity, but we must breach this gap.

I treasure your brilliance and value your contributions greatly, but are struggling to jump in the "deep end". I think all that is needed is a little more hand holding and less assumptions of prior knowledge in the documentation.

Yours Sincerely

Tony

  

[Mohammad]

Hello Diego,

 I totally support your idea. For start, at least we can have some conventions!

--Mohammad

[PMario]

On Monday, February 11, 2019 at 11:31:20 PM UTC+1, Diego Mesa wrote:

So, some solutions/ideas are:

1. A centralized repository of plugins, very much like package control for sublime text
2. An "update" method
• Your TW could check installed plugin versions with that on our centralized repo, letting you know if you need to update.
  

Nope. If I open a file-tiddlywiki, in NO-WAY I want it to ping any 3rd-party server!

For me this action MUST be manual

• As I understand, it still couldn't actually "fetch" the updated plugin tiddler from github - you need to do this manually - is this correct?

Automatic plugin-update is extreamly dangerous. With TW users have the possibility to modify plugin tiddlers. Which is a valid action! If plugins try to update in the "background", they will blow up in your face! I'm 100% sure!

Manual actions are OK for me, because it's a user-decision.

-mario

[Diego Mesa]

I dont think they should be automatically updating - but surely they can be automatically notifying you that an update was issued... let you decide if you want to proceed... 

[@TiddlyTweeter]

PMario

I think you make great points.

From my point of view there are three things I'd like to say ...

1 -- Whilst its natural that users here in this group incline to the "latest & greatest" plugin mod I'm not convinced most of the time end-users need to be interested at all if what they have is working. Why ever update if what you have works?

2 -- I do think its useful that plugins indicate the lowest TW version number they will work with. And a stable address reference in the plugin itself to check out mods if you want to.

3 -- I think at base the issue is "informational"--its about finding things you need. I 'd say that comes first. 

I think the "Plugin Library" on sites like the main one and Jed's are great. Because they are curated (I trust). Update calls in the wild--no thanks.

Best wishes

Josiah

[talha131]

Diego Mesa you hit the nail right on the head.

After using TW for last couple of months, I have realized what makes it unique and powerful is the ability to customize almost each and every aspect of it. This is something missing from established products like EverNote and OneNote. New products like Notable have planned feature for plugin support but I doubt it will be as permissive as TW.

Problem is for a beginner TW has a bland UI and very little features. To customize you need to use plugins and scripts. A central repository for searching and installing plugins would be nice.

I like how Browser Addons Stylus and GreaseMonkey do it. The browser addons let user install customized soles and JS scripts for different sites.

1. They let you search from the addon UI, without having to visit some external site.
2. They also let you update the scripts and style if an update is released.
3. Most of the styles and scripts are hosted on Github. So you can Github to view the code and suggest updates if necessary.
4. Finally if you have the addons installed and visit a user css or user script they detect it and offer to install it for you. Try installing Stylus and visit this https://stylishthemes.github.io/GitHub-Dark/github-dark.user.css to see what I mean.

A similar mechanism for TW would be very useful.

​

[talha131]

Mohammad you are already hosting your plugin and script directory on Github. What if we do this,

1. Break down the html into individual tiddlers and host in Github repository
2. Use Travis to build these tids into html file using tiddlywiki command. For example tiddlywiki ~/Dropbox/TiddlyNotes --verbose --build index
   *. If we use GitLab then using an external integration tool will not be necessary.
3. Host the generated index.html via Gitub pages

And finally use this repo as the official plugin repository.

Advantage of breaking down into individual tid files is

1. All tids are just text files
2. Easier to view the code and suggest changes
3. Use Github as the CMS for plugins
4. We can enforce contributors to use some standard fields in their tids like author name, url, contact email etc
5. Use Git for versioning
6. Contributors can use Github online IDE to make changes or add new tid. All their contributions will be received as PR, which maintainers can review before merging
7. Git already is being used for distributed development. TW community can certainly take advantage of it.
8. Use git tags and releases user will know which plugin has been upgraded and then they can upgrade it manually

I guess bottom line of my suggestion is to use Github/GitLab repository as a official CMS for TW plugins and scripts.

​

[Mohammad]

Hi Talha,

 I agree! I will manage to do that. I absolutely believe in collaboration.

Thank you

Mohammad

[bimlas]

Diego,

I agree with the idea, searching for and discovering plugins is a complicated process at the moment. However, instead of finding a new interface, why not use the existing ones? I don't know the Javascript / NPM world enough, but I have the feeling that we could use NPM to distribute Tiddly plugins. If all plugin makers would follow the same schema and register (?) his/her plugin to the NPM registry, it would be easy to update, search, and filter the plugins. The downside of this is that it only works with directory based wiki, not with single HTML.

In order to achieve uniformity, I am working on a plugin edition where all the necessary files are available to create a new plugin, all you have to do is change the appropriate fields (this could be automated later). At the moment, it is not yet working, don't use anyone, but the idea I hope is understandable.

https://gitlab.com/bimlas/tw5-plugin-template/