i would also get a lot of value from this!
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)
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.
Let me just link a topic that I posted in October:
I have another wish, which should not be too difficult to accomplish:
Modals should also be set to close when clicking anywhere outside them.
Isnât it already availableâŚhttps://tiddlywiki.com/prerelease/#Modals
check the mask-closable option
Something else WANTED is fields with multiple lines as native implementation.
What do you mean ?
Being able to write a field with multiple lines without writing it manually in a text area ?
Or something else completely ?
I think he mean displaying textarea instead of input for editing a tiddler. This is already possible: https://tiddlywiki.com/#Customizing%20EditTemplate%20field%20rendering (demo)
Aliases have long been something I have wanted. The best I see is to create a tiddler with the âalternateâ name and link to the âmainâ one, but I would rather some seamless symlink-like experience.
You may already be aware, but I just wanted to note that while thereâs no core mechanism for aliases (yet?) we do have at least two plugins that tackle the issue in slightly different ways:
- @mklauberâs Aliases: uses normal link syntax; generates automatic disambiguation pages as needed
-
@pmarioâs uni-link: uses
[[alias|?]]
syntax; greater flexibility in terms of choosing the field displayed as an alias link; includes some additional filter operators for working with alias links; no disambiguation
Personally I canât live without some of the secondary features offered by uni-link, but the Aliases plugin may be closer to the sort of seamless integration youâre looking for.
I will give those a try, thanks!
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.
I want to have all fields possible to use with multiple lines.
The solution from @telumire should be available to all fields
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.
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.
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.
This is perhaps a bit niche, but Iâd love an easier way to set a particular tab configuration when navigating to a tiddler. I think it could be particularly useful when writing documentation/demos, as we currently see tab paths like this even in the official docs:
âYou can use an $action-setfield
widget to set the tab states to the appropriate values!â
Yes⌠but the <<tabs>>
macro stores its state in a <<qualified>>
system tiddler by default, so unless youâve set a custom state
parameter for each tabset you want to manipulate, you have to find the appropriate state tiddler before you can do anything with it â and thereâs no human-discernible pattern to the titles. I end up using custom state tiddlers for most of the tabsets I build myself, but itâs not practical to change $:/core tabs this way.
âYou could just link directly to the tiddler in questionâŚâ
Sometimes! The example above could indeed be simplified with a direct link to $:/core/ui/ControlPanel/Parsing. (Thank you, Link to Tabs! How I wish you were pre-installed on TW-com.)
But I use a lot of templates, and a lot of my tabs donât correspond to any extant tiddler; theyâre just a view template providing a particular view.
âIf you werenât overusing tabs so much, you wouldnât have this problemâŚâ
Possible â nay, likely. But I donât intend to stop.
You are welcome â Since Link-to-tabs and Trails do not need to restart they are easy to install from the browserâs âBookmarks Toolbarâ
My TW-com looks like this. I drag & drop import the plugins.
I did create an experimental PR which tried to make the existing ControlPanel tab-states more accessible. They main problem is âbackwards compatibilityâ.
To make it compatible it has to be complex. More complex than âallowedâ. Tabs qualified states need 3 different ways to evaluate them, which makes the needed filters complex.
Thanks for the PR link! I should have guessed that you would have considered this before. I thought it was quite a clever approach, though Jeremyâs observation
it only works for a single tabset within a tiddler.
does mean it probably wouldnât have covered all my needs. I suppose there isnât any neat solution, really.
Are you using bookmarklets there? I should really set some up⌠I find myself going to grab one of your plugins at least once or twice a week.