Most Wanted 2025

, ,
#22

I would like to see a well documented path for other open source projects to bring their tools into tiddlywiki as a platform to both demonstrate, use and prototype.

Many projects are designed to integrate with website, html and/or JavaScript environments. For good reason they need to behave with TiddlyWiki especialy when interacting with TiddlyWiki in the scope of a tiddler or across tiddlers. This work is done time and time again bringing in different tools and libraries of features, some of which have become part of or near the core such as Codemirror, fonts and a lot more.

  • With appropriate documentation to allow intergration without needing to be a TiddlyWiki core wizzard many different projects may see TiddlyWiki as a flexible front end or platform for their project and be motivated to put in the work for their own benifit and to extend the posibilities with TiddlyWiki.
  • Lessons need to be learned and documented so newer versions can be introduced and updated in line with each projects own development time line, with minimal intervention.
  • This could result in some tooling in the TiddlyWiki core to facilitate this reducing redundancy and bloat (Eg introducing almost identical libraries for say date handling)
3 Likes
#23

This one:

If merged, this will allow us to make plugins translatable. I would like to make TiddlyDesktop translatable after it was merged.

And this one:

Which improves tiddlywiki’s dark mode switching.

5 Likes
#24

Let me just link a topic that I posted in October:

1 Like
#25

2 posts were split to a new topic: Clicking Outside a Modal Closes It (Most Wanted 2025)

#27

4 posts were split to a new topic: Make Editing MultiLine Fields Easy (Most Wanted 2025)

#30

3 posts were split to a new topic: Aliases (Most Wanted 2025)

#34

Another one occurred to me - it would be nice to be able to take a block of dynamic wikitext (with widgets, macros, etc.) and replace it with a static version. So <$list ..></$list> would be come Tiddler1 Tiddler2 ...

My main use case is that there are times where I built up something from a dynamic view and want to snapshot it and I don’t want the snapshot to keep updating. It would also save on computation cost by “downgrading” when the dynamicisim is no longer needed.

How to disable all lists update on every click to make Tiddlywiki work fast with 10000+ tiddlers?
#36

Chopping of dynamic lists would mean amputating the legs to loose weight. The list widget is one of tw’s superpowers, and for me dynamic organization saves weight.
If a developper wanted to do, he sould he should try to add wings and add an entire featherwiki export tool to shrink the wikistrucure to 58kbit.

I do not know a usecase where a wiki has to be that small. TW easily fits into an email. The only limit I could think of is the size of a qr…which is much smaller.
But perhaps this size would be the chunk that could be used to hide critical information in a steganographic way. But again here you’d need an unwrapper on the other side to do the work.

#37

I think one of my dearest wishes would be three xtra feature’s for the whiteboard plugin - or anything that brings us closer to a canvass.
Since there is much talk about obsidian - obsidian’s whiteboard would be the only thing that makes me look enviously to the dark side.
So far the ability to really work with Tiddler-Content is too limited in the whiteboard. @linonetwo -if you find the time:
Could you please add

  • an Add Tiddler Button that opens a searchfield to choose a tiddler to add or to write the title of a new Tidddler if nothing is found in the search.
  • The ability to open a tiddler as a modal above the Board in order to edit the content, best together with the ability to change the style.
  • The ability to switch between Titleview and Bodyview (or perhaps even a customizable viewtemplate for each tiddler - with the Titleview being able to show the content as a modal on click.
  • The ability to zoom to a tiddler by clicking.
    I think this could transform the whiteboart into the absolute TiddlyWiki Supertool.
WhiteBoard plugin
#39

I’d love for the Zoom Story View bug to be fixed. I tried looking into it a while ago but I couldn’t determine why it wouldn’t zoom to the top of a new tiddler.

It seems to occur if you’ve scrolled down on the current tiddler, then click on a link to a new one, and the new one appears scrolled down midway instead of loading with the title at the top of the storyriver.

2 Likes
#40

4 posts were split to a new topic: Make Nested Tabs Easy to Navigate (Most Wanted 2025)

#44

Its not broken, its the way it works, and its not always nice. The title will be at the top if the tiddler is longer than the screen. It does not scroll all the way to allow visibility of what comes before it.

There are a few ways to change this, the simplest being extra white space in a tiddler tagged below story.

#45

8 posts were split to a new topic: Prune TW Core Functions in a Reversable Way (Most Wanted 2025)

#52

I think this one is worth to be implemented. This would replace the awkward way of using the wikify widget to pass indirect parameters to macros in filters.

1 Like
#54

Personally, I wish for some added filter operators to handle JSON array manipulation (like push and pop, for instance)…

(An idea proposed in GitHub issue #7840…)

3 Likes
#56

2 posts were split to a new topic: Encrypt Single Tiddlers (Most Wanted 2025)

#58

5 posts were split to a new topic: Spreadsheet Like Functionality for TW (Most Wanted 2025)

#59

Database functionality

@Scott_Sauyet provided in this post Multi level depending tags? a solution of simple database functions.

It would be a great idea to develop it further and to integrate it as plugin or native function.

1 Like
#64

15 posts were split to a new topic: MindMap Functionality for TW (Most Wanted 2025)

#79

In addition to making modules more decoupled from each other like @Mohammad said, making each module a common js library that can be used by all js software developers. Also want tiddlywiki to be front-end headless software. Only provide api on the browser side. no involvement in interface design.

Except ui stripped out. I also hope that the data storage side is also stripped out.

BTW, a question. Why is the data storage format [] and why not {}? Is it because of performance reasons?