[ Streams ] : future development

[fastfreddy]

I am almost embarrassed to ask, but I am having a problem play testing Streams from the SQPL on pre-release (does not seem tied to the library install, same issue if directly adding the plugin), and am wondering if I am doing something wrong. I seem to be causing an issue when deleting a Streams node.

Steps to reproduce:

1. using TiddlyDesktop, create a new TiddlyWiki - prerelease
2. drag’n-drop SQPL from SQ Plugin Library — TiddlyWiki plugins
3. through the settings->plugins->get more plugins->SQPL, install Streams, save and reload
4. create a test tiddler, add two nodes
5. delete the test tiddler

this error shows up:

The same steps in 5.1.23 do not result in the same problem.

Thanks in advance!

[saqimtiaz]

@fastfreddy You have found a core bug in the pre-release introduced by this PR:

Use event.event.view.confirm for confirmation messages in navigator.js and action-confirm.js

Good timing on the catch, I’ll submit a fix later today.

Edit: fix submitted.

[fastfreddy]

Hi again @JanJo; am getting ready to upgrade Streams-fusion to include a simple paragraph export. I was curious to know what is your preference in terms of hierarchy? Should we just flatten all levels of nodes into a \n\n(wikitext) or <p> (html) list then, or would you prefer a <p> hierarchy in raw html even if visually that is likely indistinguishable?

I have also managed a simple yet effective export to markdown capability using the turndown library; I have a feeling a lot of folks will be interested in that feature (quite possibly beyond streams-fusion; I may have to split that feature and release for non-stream users). There are still a few quirks to iron out that I may need help with, but early results are impressive.

My pipeline takes the HTML raw output to generate the markdown, so the wikitext is rendered first; maybe that will make the markdown conversion less interesting. Still…

first image is native wikitext in Streams; second is the fused markdown tiddler.

[TiddlyTweeter]

@saqimtiaz

First on my list of things to do is create a plugin library for Streams along with an associated optional plugin updates notification feature. With this in place, I will be able to make frequent smaller updates when I have the time, and users will find it easier to keep abreast of changes.

Right. IMO, simple point, updating for changes in the easiest way possible is very much on target. Hats off to you for caring!

TT

[JanJo]

Hi Freddy,
great to see you making progress. My version is a little asleep, and I told Saq to recommend only yours.
I am definitely in favor of a wikitext-solution.

best wishes Jan

[saqimtiaz]

Please note that there is now a dedicated thread related to Streams Fusion discussion:

Streams Fusion: export from Streams (including to Markdown)

ok @JanJo and everyone, 0.0.9-beta released which includes paragraph-based (but flat) fusion and introduces “fuse-to-markdown” features. Regular install is best through the SQPL Please test and report back. I note that for some reason, the inline <code> blocks don’t convert well to markdown. If you have ideas how I can fix that, please chime in. Otherwise, markdown conversion works pretty darn well and could become a big deal (plenty of credits to @saqimtiaz again for the Turndown integratio…

[arunnbabu81]

@saqimtiaz I think you should add back the double click editor to exit feature as a configurable option. I think it would be better to have that feature than not have it. One thing which went against double click editor to exit was that it may conflict with text selection using double click, but text selection can be done by Drag selection or keyboard shortcuts also. Also the number of times we may need double click to exit editing will be far more than number of times we may need double click to select text .

Swipe to indent/unindent could also be brought back to the plug in with visual feedback. I had shared my suggestion in github sometime back. If the swipe is of sufficient distance, indent or unindent is triggered. If the swipe is shorter, just like in WhatsApp for iOS , show options like context menu, indent/unindent etc. and select which ever is needed.

[saqimtiaz]

@arunnbabu81

@saqimtiaz I think you should add back the double click editor to exit feature as a configurable option. I think it would be better to have that feature than not have it. One thing which went against double click editor to exit was that it may conflict with text selection using double click, but text selection can be done by Drag selection or keyboard shortcuts also. Also the number of times we may need double click to exit editing will be far more than number of times we may need double click to select text .

I am afraid this will not be introduced. There were several usability concerns with it and having extra configurable options incurs an overhead in terms of code maintenance and performance.

@arunnbabu81

Swipe to indent/unindent could also be brought back to the plug in with visual feedback. I had shared my suggestion in github sometime back. If the swipe is of sufficient distance, indent or unindent is triggered. If the swipe is shorter, just like in WhatsApp for iOS , show options like context menu, indent/unindent etc. and select which ever is needed.

I will consider this if I find the time and motivation to work on new features for Streams, though my focus is unlikely to be on mobile UX.

[arunnbabu81]

Any possibility of monaco editor support for streams in the future

[saqimtiaz]

If support for any more editors is to be added, we would need to drop the features that involve knowing where the caret is in the editor.

For example:

• backspace at the beginning of a node to merge with the previous node
• splitting a node at the caret on enter, etc

None of the editors provide the necessary information for these features to work, and adding these features to them manually and maintaining that isn’t sustainable. Truth be told, I regret adding support for codemirror. It has made the codebase more brittle and harder to maintain.

[saqimtiaz]

I have moved speculative discussion on new ideas that I am exploring to a separate post, as the audience for that might be smaller than those interested in support and news of more concrete development:

Streams: exploring ideas for new features

I had a chance to revisit Streams development recently as it dovetailed nicely with other work. Here are some of the improvements that I am currently exploring: expand all / collapse all affordances for the children nodes of a stream further simplification of the templates and DOM structure improvements in performance and drag and drop behaviour the possibility to select node(s) with the mouse and copy and paste them between streams. the above will entail coming up with a string representa…

[linonetwo]

@saqimtiaz Is Streams plugin stable now? I’m planning creating an alternative layout to write down Principles that I’m agree to.

Principles in that book is organized in tree structure, and each could be linked from diary, and revisit by tidme plugin, so Streams plugin is suitable for it.

[saqimtiaz]

@linonetwo while there has not been active development for a while, the plugin itself is entirely stable and should be reliable for daily usage. I am committed to maintaining it with regards to bug fixes and compatibility with core changes.

[well-noted]

Can confirm, I use the streams plugin for nearly all my text entry and have for years now – I’ve found it incredibly versatile, resilient, and reliable.

[CodaCoder]

As your name suggests

[linonetwo]

Could you split the streams plugin to a library plugin that provides a outline widget, and a streams plugin same as current one for end user?

So plugin authors like me can embed the outline in our plugins, without showing nodes like this for people only install my plugin

I know $:/config/sq/streams/stream-enable-filter can be change from [!is[shadow]] to include and only include my layout plugins’s internal shadow tiddler, but this may cause problem on other users (not showing outline on my anternative layout, or not showing outline on every tiddler).

I already extract auto-complete-box plugin from command palette plugin, as an example Command palette plugin v1.0 , powerful context search bar, search under filter, etc - #47 by linonetwo . Simillarly, you could split the reuseable core feature to a new plugin, and keep things that works out-of-box (like $:/plugins/sq/streams/stream-view-template) in current plugin.

Anyway, I will use it for now, assuming my users don’t user streams plugin directly. My config on $:/config/sq/streams/new-node-title and $:/tags/streams/root-buttons will also affect them globally. I hope all config can be passed-in using widget or macro parameters too.

[linonetwo]

I can’t wait, so I do it here Streams outliner, now works as a procedure, use it as a library in your plugin , feel free to request a PR.

[saqimtiaz]

@linonetwo interesting use case! I will keep this in mind when I get the chance for a rewrite. Breaking out parts of plugins into separate plugins is appealing and something In have considered in the past, but the appeal as a developer needs to be balanced with the end user experience. Most TiddlyWiki users do not install plugins via plugin libraries from what I can tell, so dependencies are potentially problematic.