A concept for externalizing some current core features

[twMat]

In a post, Jeremy asked if the fold tiddler feature should stay or be externalized into a plugin. This was my reply there, but my post here is more about some follow up ideas that are more appropriate in this forum:

I basically never use the fold feature so would not mind it plugified. With that said though; who, except those that already know, would actively seek up such a plugin? It, along with much else, is probably a feature that you have to try out to realize that you want it. So how would users be exposed to such plugins so they can make an informed decision about it?

Would it be possible with a distro where several of these currentently native but smaller tidbits come as preinstalled plugins so the user can opt out/uninstall them!? "Fold+fold all" and several other buttons, most palettes, story views, ...

I have proposed similar ideas previously and the reply at that time was that it was administratively burdensome. But maybe something, e.g some infrastructure - github, TW plugin libraries - have changed in this regard since then? (More on this aspect further down.)

Vice versa; There may be features that are currently not in the core but that ought to come with the standard distro. The weighing about what is "universal enough" is possibly even trickier than we think since we don't have tools to measure the facts, so even a very convincing gut feeling may really be misleading.

Cases in point
By deafult, 3 out of 27 page toolbar buttons are activated and shown as buttons. One can argue they are also available for use under the sidebar Tools tab... but still... how many do you actually use? The editor toolbar buttons is another one; how many do you actually use?

As a plugin maker, I've also realized there is a category of plugins that are only "momentarily useful"; there is no reason to leave them in the wiki after using them. If I need the feature again, I just go get the plugin again.

The difficulty is to expose the users to the options so they easily can make informed decisions.

A big idea: "Local features libraries"
Imagine, next to some of the user interfaces, a "library button" to open library showing plugins specific for that particular UI part. For example, in the aforementioned editor toolbar; a button that lists plugins relevant for, only, the editor toolbar.

...the palette tab would show the palettes you actually care about but/and next to the "show editor" button, there's a "other palettes" button to the "palette library" (where the majority of the currently preinstalled palettes reside).

This would make TW much more configurable without having to hack it, and thus lowering the bar significantly for people. It is not trivial to, say, create a new editor toolbar button. The mere modularity of plugins could also offer a greater variety of items than what are currently available in, for example, the toolbars.

IMO this is very much in line with tiddler philosophy and I think TW would be uniquely suitable for this idea.

Administration
As noted above, when previously suggesting along similar lines I was informed that this was administratively burdensome. But does it have to be? Doesn't externalizing things into small plugins also mean they can be left alone assuming there is a well defined interface between the core and the plugins?

[pmario]

...the palette tab would show the palettes you actually care about but/and next to the "show editor" button, there's a "other palettes" button to the "palette library" (where the majority of the currently preinstalled palettes reside).

There is an open PR: add browser dark/light theme detection #7830 which allows us to make the ConfigPanel PaletteTab much simpler if they activate Dark/Light Mode Handling.

Only 2 palettes will be shown

• Light palette
• Dark palette

For a (Demo) open the link and go to ControlPanel -> Appearence -> Palette

The user can decide, what they want to see. ... Much simpler and IMO not confusing at all.
Even it the "show editor" button is clicked it stays simple

Problem @Jermolene does not want to enable it by default, so it has to look verbose and confusing.

[Jermolene]

Hi @pmario I think this is a bit off-topic for @twMat's original post, perhaps this is better moved to #7830

[pmario]

I think, it shows, that we do not need to externalize palettes, we only need to present them in a less confusing way.

At the beginning users can only make a decision between 2 palette types.

• Light
• Dark

If that's not enough, they will probably click the "palette icon". May be intuitively or if they read the intro text.

The "light dropdown" shows them all "light" palettes
The "dark dropdown" shows them all "dark" palettes

Selecting one in the dropdown will activate it. -- In my opinion, that's easy to use, and fun to play with.

IMO there is no need to externalize palettes.

[Jermolene]

I think, it shows, that we do not need to externalize palettes, we only need to present them in a less confusing way.

@twMat was using palettes as an example. Whether or not it turns out to be a good example does not undermine @twMat's central points, and those are what we should be addressing, not nitpicking his examples.

[twMat]

Thank you @Jermolene , I agree.
@pmario , I've posted some thoughts on your idea in the forum here :-)

[twMat]

Thanks @pmario , with your follow up post it makes the relevance clearer but I still think it makes more sense to take it in your thread or perhaps a new discussion thread. Interesting proposal btw :-)

---

Addition to the OP

If editions is to be a more prominent thing for tw.com (ref discussion), then the OP would be beneficial as such editions could be more streamlined; Obviously a, say, "public blog edition" has different needs from an "personal sql db interface edition" (just making a point, I'm not saying those are appropriate as editions ;-)