Thank you to everyone for the thoughtful and interesting feedback. I have now posted a longer thread about v5.4.0, but do feel free to continue to post here.
1 Like
I may not be able to envisage the scope of your aspiration but as a single file TW user who is highly dependent on TW on my tablet, phone and laptop I very much appreciate the current role of the browser.
On my android phones I use Tiddloid and on my Unix laptop I use Tiddly desktop, I have a small keyboard for my tablet which means I can work when I am in transit. I use TW as my central knowledge base which is large and the product of hours of work every day for a number of years.
For me the browser is rarely a fundamental limitation and a lot of problems have a manual work around - what it delivers in return is that the browser is my access to TW on any device, its like a passport that means I float above the OS problems, all in return for very little inconvenience.
There are device issues for sure, for example on Android I need to access my TW on a device local server because of the way the Android security and filing system limits the ability of a browser to access locally stored videos and so on.
In terms of liberating people on different machines and platforms, in principle it might be a great thing, one of the reasons I am on Linux is because I could not tolerate Microsoft updating my machine when ever they felt like it - they always messed up my custom device drivers and thought they knew my needs better than I did and I have already mentioned a limitation of Android and of course there is Apple - the pinnacle of user tie in or coercion depending on your point of view. Against this viewpoint many users out there don’t want to understand their machine or software they just want something that works most of the time (Apple?) - as a linux user I sometimes forget all the fears about viruses and so on. I think a truly open system would have to come up with some new ideas about security balancing open-ness with safety - not an easy balance.
3 Likes
I think that is right.
Part of the issue is that back-end-geeks, informed users etc. can perfectly well understand the potential issues and address them.
Meanwhile the “let me only do anything safe but stop me otherwise” is the standard browsers’ norm.
There are good reasons both ways!
But, I do think a v. good case can be made to get round browser limits In Cases where the user needs interact with calls to the O/S.
A simple example would be “invoke a local search of all my docs mentioning ‘Ruston’ and build an external tiddler listing them.”
Implementations such as Tiddlydesktop, tiddlywiki-app do this by using a custom (Chrome) browser and do give you access to local resources. Also the antequated and limited hta method.
- Extending this to internet hosted wikis or through host side instalations (as used in Timimi) just requires the nessasary skills and a champion to make this posible.
- However we are already having trouble keeping Timimi operational after recent and pending browser changes.
1 Like
Wouldn’t it be great if instead of making custom browsers it were possible to configure regular ones to allow certain pages to interact with operating systems in the ways we want.
Could browser producers (roughly MS, Google and Mozilla) be convinced this would be good or can plugins achieve it including for mobile devices ?
1 Like
Chrome and Edge (desktop) did implement a native file-api lately. There even is a TW plugin which is a bit clunky to use for security reasons.
Safari and Mozilla did not implement it (probably) for security reasons. They are not even considering it atm.
I think none of the mobile browsers will ever implement it, since mobile phones do not really have a file-system. They have storage, which is heavily sandboxed, for obvious reasons.
-m
PS: I think we should give our TW browser-storage plugin a bit more love, since it works out of the box on all browsers.
1 Like
There actually is a proper filesystem on both iOS and Android, it’s just not exposed to users very often. That said, I’m also skeptical at this point that the File System Access API will move beyond Google Chrome Desktop.
Right. I use Chromebook. It’s whole thing/k is wooden.
To the point here: HOW, practically, can we legitimately get TW to act beyond The Standard Browser?
I keep meaning to comment here, but I’ve never had much to say. But I wanted to share what I just sent to a co-worker:
There is something very uplifting about being involved in a project—TiddlyWiki—which has recently started planning for its next major version release… in 2036. TW5 was released in 2011, with the tag line "a reboot of TiddlyWiki for the next 25 years. Since then, there have been three point releases with only minor backward incompatibilities. We’re about to release
5.3.7and are planning5.4.0now, but we’re also starting the6.0discussions, for when backward compatibility can be deemphasized.I don’t have a conceptual problem with Agile development (although corporate Agile is mostly an oxymoron), but it feels great to be thinking on such timescales.
Thank you @jeremyruston and everyone for a wonderful tool and an amazing community!
6 Likes
Oh but you’re wrong, Scott. You should apologize to your co-worker for that terrible mistake, forthwith.
Corporate Agile is an oxymoron.
There. I feel much better now. 
1 Like
You’re absolutely right. Apology sent.
I use something like this in the sidebar for editing, with a button to detach. Type or paste the tiddler title and the markup appears. A major time-saver for me, now I only use the regular editor for tags and fields. Very simple though—no toolbar & bypasses the “Draft of” state.
In a tiddler titled “Edit Tiddler” tagged $:/tags/SideBarSegment, positioned just below $:/core/ui/SideBarSegments/site-subtitle:
<style> .wide1 { width: 100%; } </style>
<details>
<summary>''Edit Tiddler''
<$button class="tc-btn-invisible">
<$action-sendmessage
$message="tm-open-window"
template="Edit Tiddler"
windowTitle="Edit Tiddler"
width="500"
height="645" />
<span>{{$:/core/images/open-window}}</span>
</$button>
</summary>
<p>''Tiddler Title''</p>
<p><$edit-text tiddler="Edit Tiddler" field="TiddlerTitle" size="35" /></p>
<p>''Tiddler Body''</p>
<p><$edit-text tiddler={{Edit Tiddler!!TiddlerTitle}} class="wide1" /></p>
</details>
But experimenting with the contenteditable attribute in TW was very cool, made me really wish I had the ability to edit directly as well.
3 Likes
oh that’s nice! I’ve tweaked it a little for my taste (made it a $:/tags/SideBar tab and removed the details/summary folding).
If I’d caught up this thread earlier, I may not have asked about the setting of height in the native edit field (though I’m glad I did, I learned a little more about the innards of things: Choosing the height of the text editor
1 Like
After half a year of studying PicoLisp, I came to the conclusion that there is a more interesting version of my proposal. PicoLisp is great, but I would not like to waste time arguing why, after all, it is not quite an ideal option, at least for me. Now the priorities have shifted to the Golang - Ryelang bundle … To summarize, I can say that I see the development of the project in the integration of Tiddlywiki - ASON - Go - Rye. I considered it necessary to declare this.
An interesting chat with Gemini happened by chance, read it, maybe you’ll even like something. I liked it. I apologize for the Russian, but it’s more convenient for me to think like that for now, and there are no problems with translation right now.https://aistudio.google.com/app/prompts/1fLNAQ0zjb7YxdotFW8DVmbtDRcti82oa
Not sure if it was mentioned before, but considering how vibe coding made coding accessible to many more people, I think it makes sense to enable writing functionality entirely in JS. Meaning it should be possible to construct a filter (not use a filter string with some function, but use JS code), define a view, etc. This works well for Obsidian, and will make enhancing TW less arcane (I don’t think vibe coding works well with TW’s unique filter syntax or procedures/macros/widgets). It will also allow to use tools developed for JS. E.g. right now, debugging a view template is impossible. Debugging JS is built into the browser.
1 Like
It is not impossible, but there is room for improvement 
We did discuss this problem quite some time ago at GitHub (Jan. 2022) and came up with some ideas to improve information, that can be used using default browser tools, without the need to debug JS code.
Jeremy gave his OK, that extended info has a chance to be merged into the core.
If you look at the core tiddlers with the prefix $:/core/modules/filters you will see all the JS based filter operators. I have sucessfuly given an LLM the code for one of these that resemble what I need and asked it to introduce a different operator with alternative functionality.
- This has been quite sucessful
It should be simple enough to document this process and teach people how to obtain the appropriate JS to use within tiddlywiki’s requirements.
- It is however importiant to note we now have the ability to define custom filter operators based on any existing filter operators (using
\functionwith a.in the name) - In this way we should only bother with a new JS operator if its functionality is missing or it introduces simpler or less verbose operators.
- I have raised the danger of reverting to JS solutions when either it is already possible in TiddlyWiki or it can be identified as a gap, and introduced to the core. We need this to assure continuose improvement and avoid the complexity of needing to install a plugin or override the core, when it can just be part of all tiddlywikis with little or no code.
1 Like