Thank you!
This is an addon to @linonetwo’ streams?
It would be great to have this as a clean, renamed standalone. It already was the problem with fusion that it was a plugin for a plugin.
If I was to give a name, I would call it treenote because the notes can be organized in branches.
Stream Outliner is a library, @linonetwo intends it to be incorporated into other people’s plugins, is my understanding.
I suppose the cost/benefits of a “plugin of a plugin” is in the eye of the beholder.
I’m not opposed to releasing it as an independent plugin.
Some of the benefits of having multiple compatible plugins working in an ecosystem:
- Each part can be updated independently, but with respect to one another
- Different usecases may call for different tools in the same wiki
- credit for the work is more evenly distributed since each plugin represents the work of one party
- Modular design is more flexible
- Smaller parts means easier to identify and fix problems
I personally would like to get this Streams-compatible so I can use it right away in wikis that already have streams. And while many of my longer tiddlers I would want to render with the <<stream-ouliner>>
call, for some types of tiddlers I think I would prefer the default stream-list.
As I said, I designed this as a demo, but if I can make it compatible I will likely begin using it in hopes that it becomes core to Streams later, because I think it is especially useful for tiddlers that call for sections that would eventually be “excised” into independent tiddlers (technically, they are independent tiddlers as soon as you add the first node, with this system).
I am calling it States, and I think that is a flexible name that reflects exactly what I am trying to communicate about the power of Streams within the context of Tiddlywiki, through this plugin:
-
Nodes are only a single “state” in which one can observe a stream.
-
Like particles/waves, the way that someone is interacting/measuring the stream determines the way it appears
-
Independent observations of the same phenomena reveal different aspects of the same phenomena, allowing us to choose our method of interaction based on our desired result
As I said on the other post, I also believe that, rather than just transcluding nodes to other tiddlers, it would also be ideal to develop an Entanglement system for States, which would
-
allow nodes to exist in multiple instances at the same time, and
-
maintain independent relationships with the nodes around them
TreeNote does not fully encompass all of these relationships in my mind, certainly not as well as States…
Besides that, I have a personal fetish for naming Streams-add-on’s with single-syllable S words – So far I have developed Stacks and now States
I actually, upon testing, can see this is a more fundamental problem with Streams-outliner’s compatibility with Streams.
I whole heartedly agree. It also encourages extensible and customizable plugin design and allows plugin writes to collaborate in a loosely coupled manner, rather than placing the entire onus on one person.
Could you summarize the areas where you find the current version of Streams is limiting your integration?
It’s not compatible with the streams outliner, they both use the same nomenclature and try to access the dom the same way.
Might need to add some guard flags, change the nomenclature, and/or add a handler to make them work together. @linonetwo may have more insight
I am familiar with and extremely pleased by linonetwo’s work on the outliner. I am curious as to what precise aspects of his refactoring you are finding crucial for your work that current versions of Streams are falling short in. I am still thinking about the direction an eventual rewrite will take and such explorations are extremely helpful and informative, thank you.
That was what I thought you might mean, I’ll write up my thoughts when I’m at my desk
I would be happy about this compability with the original plugin because I ran into incompatibility issues when I tried the streams-outliner.
I liked @linonetwo’s more WYSIWYG approach without borders around the editingfields and the possibilty to use it as a macro and the configuration options
But I did not switch because I could not get a viewtemplate to work and my streams-sidebar would have needed changes.
Since the sidebar and the viewtemplate are what I use most changing was no option.
PS:
@well-noted Importing your Plugin into Lin’s Demo I also have problems getting it to work - e.g. the famous checkboxes - so for me streams is much more reliable.
And @saqimtiaz for the WYSIWYG thing I am a little cured. It is good to see where I am editing.
A glance at the console revealed that the problem was the redundant draggable JS – after disabling it, both plugins run side-by-side.
Yes, I think it could work quite well considering it’s received about a week’s worth of work, but it’s definitely still a demo and would need development
A quick test shows that my stream-row-template strategy as described elsewhere does succesfully work in the stream-outliner row-body-template:
Here is the updated version that is compatible with Streams:
$__plugins_NoteStreams_streams-states (3).json (44.3 KB)
Note: by compatible, I mean that both Streams and Stream-Outliner can, with this third plugin installed, exist side by side. It will also handle the fusing part of States, but the unfuse function requires the outliner to achieve.
One may want, at any time to be able to interact with text either as a node-list or as editable text blocks:
Additionally,
A major mental roadblock for me, using streams, has always been the creation of “Functional” tiddlers, which only serve the purpose of being a headline:
Now these headlines represent an actual tiddler that does not have the additional baggage of being in relation to the rest of the stream-list.
___________________________________________________________________________
Going forward, if we are talking about expanding viewtemplates for the Stream-row-body, we could have additional parameters such as <<stream-outliner "TODO" 2/2/2025>>
that would alter the behavior of the new node button to add additional conditions, such as rendering each item of the stream-list through a specific view-template like TODO:
These are just a few sketch-thoughts while field-testing the States plugin with Outliner and Streams – will continue to write up thoughts as I have them and they mature.
Thank you!
What is the unfuse function?
Is it the magical section-like switching?
Will it present the template dropdown in the original streams-plugin?
I would prefer to only have one plugin that avoids such load and confusion.
???
Yes, I thought this was likely a somewhat heady concept… let me try to explain
If I am writing a stream-list and I come across an original idea, I can tag it plap as Idea, and it will take on all the associate characteristics – however, by the very fact that it is part of a Stream, the Idea tiddler has some limitations:
-
its parent value is immediately used, so it can’t be used in relation to anything else that uses a parent value (admittedly this could be worked around, it’s just not intellectually satisfying to me that Streams is causing this, at least in part because
-
it can’t be used in any other stream-lists, which is very limiting for a tiddler like an Idea that should be representable in multiple spaces.
a) Technically, you can have the same item in multiple stream-lists, but
b) currently, having the same item appear in multiple stream-lists messes up the indentation/unindent process
You can do this, although you’ll need to use outliner and, as you pointed out, Streams proper has lots of things going for it.
Actually, the most recent updates will probably make streams-outliner not work unless you also have Streams installed – I could probably add some workarounds for that.
I wont try very hard to talk you out of it, but the plugins don’t actually take too much space. It’s not particularly confusing – once they’re installed, they will work as if they were one app. The only thing you’d need to make sure of is, unless it’s disabled, the fuse button will appear in the original streams node-list, and if you fuse it by mistake, it has the potential to overwrite all the outliner macros within it.
Yes.
This demo has nothing to do with todo items, I’m afraid My point of bringing it up was to demonstrate one thing about this method that I like and suggest to @saqimtiaz one of the possibilities that having streams as a callable widget has – specifically, if expanding streams viewtemplates is an area of interest, having additional pragma in the macro call to specify the viewtemplate for nodes would be VeryCool™
But since I’ve been teasing you with it so long, @JanJo, I will try and make time to create that example wiki for you to check out, about how to create your own.
$__plugins_NoteStreams_streams-states 0.0.27.tid (42.0 KB)
New version adds caption
parameter, as in, <<stream-outliner currentTiddler:"MyTiddler" caption:"Hello this is a test">>
What I have done is a refactor to streams plugin, so it is better to PR to original repo, I keep the same procedural naming because I still don’t think it is a new plugin, but rather a preview for PR. Or instead of PR, Sq can reference it and make changes to Streams to meet our need.
Only when @saqimtiaz really don’t want to update streams plugin anymore, I will change the procedural naming, then it won’t confilct with original streams plugin.
@JanJo WYSIWYG editor’s outline feature is for outline inside single tiddler, streams is for multiple tiddler, I use both of them in my wiki. It is possible to use WYSIWYG to edit a tiddler in streams, then it will feels much cleaner. I haven’t tried that, because I’m waiting for WYSIWYG related PRs to the core to be reviewed, then update WYSIWYG editor, then do those integrations.
I really appreciate your work on it @linonetwo. The plan is to explore adopting your changes as part of a complete rewrite once I find the time. The very first versions of Streams were heavily macro based but changed to transcluding tiddlers instead because of drastic performance differeneces. Since then I believe we have mitigated most of the performance differences but some testing will be needed to make sure that we have no regression in this regards if we switch to using procedures. I am also holding off on a Streams rewrite until some things land in the core, like better localization support and improved palettes.
I have experimented with this and use it in one of my wikis, and it also entails changes to streams to remove the distinction to some extent between editing and view modes. This is another area that I want to address in the Streams rewrite.
The Streams rewrite is planned to be entirely backwards compatible for end users, but not for plugin writers or advanced users that have customized the plugin. Therefore, the plan is to one such breaking change with a complete rewrite rather than piecemeal. Once I find the time, I will make a post with the issues that I am tracking that I want to explore or address in a Streams rewrite.
For reference here is how you can use the original Streams as a widget or procedure though without the ability to pass parameters to replace config tiddlers:
\procedure streams(id:"tiddler-to-hold-stream-list")
<$tiddler tiddler=<<id>> >
<$transclude $tiddler="$:/plugins/sq/streams/nodes-list-template"/>
</$tiddler>
\end streams
This should also make it possible to embed more than one Stream in a single tiddler, though I would approach that differently. Namely, a Stream where the first level was customized to just appear like a regular paragraph (rather than a list item) with the children nodes visible as a stream.
Allowing easier customization of the appearance of the nodes (list vs paragraphy etc) is a part of what I want to explore in the rewrite.
Edit: corrected syntax typo
Interesting, I will need to experiment with this some, but it sounds like it might be applicable to my desire to have multiple sets of relationships for the same streamlist (entanglement), perhaps with some tinkering.
As in, same tiddler but different ID (if I understand your usage) representing different states, allowing the same node to be represented in multiple lists with multiple relationship sets.
If this is the direction you’re interested in taking the plugin, with sections, etc, I would gladly PR it. I did not do so because 1) I meant as a demo, hence not being in the plugin section, 2) I originally began with the “Entanglement” project that seemed a bit of of scope.
I suppose another reason I didn’t PR it is because I have mostly worked on modifying @fastfreddys plugin, and have modified the stream outliner only a little.
EDIT
Realize after waking up some that I did not understand your usage – not a path forward for my idea.
This does not seem to work straight out of the box for me, perhaps user error.
There was a typo, now corrected.
I haven’t yet had the chance to explore your customizations so don’t quite have a feel for what your requirements are. If you need to customize and pass configuration options as variables, it wont help. If you want to view multiple streams inside the same tiddler, then this is one way to achieve that.
Create a tiddler at Streams — on TiddlyWiki 5.2.2 called Test
and paste the following in it:
\define streams(id)
<$tiddler tiddler=<<__id__>> >
<$transclude tiddler="$:/plugins/sq/streams/nodes-list-template"/>
</$tiddler>
\end
!!UX Tweaks
Some text about UX tweaks.
<<streams "Streams 0.2 improvements/20201219205647810">>
!! Filters
Some text about filters.
<<streams "Streams 0.2 improvements/Filters">>
I suspect it will need more finessing in terms of state tiddlers but that is one way to approach it.
Yes, that works, I expect that it would be able to achieve the same functional role as Stream-outliner in the demo I have set out – some further tests down the line.