LiddlyDesktop, a tiny Tauri-based TiddlyDesktop Alternative for Windows

Hello Tiddlers,

Extending TiddlyStow, and wrapping it with Tauri, I’ve created a standalone, portable windows binary that can be used to access and save Local TiddlyWiki HTMLs that clocks in at 7.83 MBs.

This seems more in line with TiddlyWIki’s design principals that the ‘official’ TiddlyDesktop app imo.

It’s mostly a proof of concept but I’d like to create releases for other platforms as well if there is interest.

There is also not currently a way in the UI to ‘return’ back to the launcher screen after loading a wiki so you will have to close and re-open the application; I’m open to suggestions and feedback if this is an appropriate workflow as-is or if I should add some way to do this.

Anyway, I’d appreciate it if you’d check it out and let me know your thoughts.

https://github.com/Xyvir/LiddlyDesktop/releases

-Xyvir

3 Likes

Edit: Removed suggestion for the link, which has now been corrected.

If I have a windows sandbox set up at home, I’ll try it this evening. (I’m not allowed to run arbitrary executables on my day job) and I’m cautious enough not to run them in my main instance at home without knowing more about them.

1 Like

Thanks for the correction, in my haste I mangled the link. Should be corrected now.

I had a go at this and really like it! Importantly, it supports standard Ctrl+F searches which TiddlyDesktop does not. It is also noticeably higher-performance than TiddlyDesktop on Windows 10. I’m quite excited about this and can easily see it replacing TiddlyDesktop with a little more work.

There are a few observations I have to share:

Improvements I’d like

In rank order:

  1. I would prefer to open external links with my system’s web browser instead of the WebView.
  2. A Linux edition. I’m not sure how Tauri works, but it would be great if there was a version of LiddlyDesktop configured for Wayland only (not an X/Wayland mix), unlike TiddlyDesktop in its standard distribution.
  3. A warning prompt before closing LiddlyDesktop if there are unsaved changes.
  4. Be able to set a wiki to be opened by default - and I appreciate TiddlyDesktop doesn’t support this either. This could probably be addressed as part of your idea of how to return to the main screen.
  5. It seems the size of the window is hardcoded. The operating system normally remembers the window size (and I prefer TW maximised), but LiddlyDesktop always goes back to a smaller size when I launch it. I would prefer that that LiddlyDesktop respects the standard OS behaviour in this regard.
  6. This might be a bit ‘above and beyond’, but given that search works in a more conventional way, I can see this replacing Tiddloid on Android for me. But I appreciate an Android port would probably be much harder.

Bugs

  • I successfully opened and saved an existing wiki with LiddlyDesktop. On my second launch though, I had to give filesystem permissions again twice (on the main screen and inside my wiki). The save failed initially and I got an error. However, hitting ‘save changes’ again it did work.
  • Opening a tiddler in a new window works, but when I tried to close the window, LiddlyDesktop became unresponsive for a while the first time around. It didn’t freeze again, for what that’s worth.
  • LiddlyDesktop shows “about:blank” in the address bar when a tiddler has been opened in a new window.

Other notes

  • ‘Sideload’ seems like an odd term to use for loading an existing wiki - I’m not sure what you are getting at with that?
  • There are permissions prompts for the filesystem API which surprised me a little; I thought it would ‘just work’ without needing the prompts. I wonder if this is configurable so to require less prompts.
  • It would be nice to know where the data for LiddlyDesktop (right now, just the list of recent files/URLs) is stored. Perhaps it could be stored in the same folder, which would let you take it on a USB drive as well.
1 Like

Thank you for sharing this.
I have not tested it yet, but I have two main questions:

  1. What are the requirements (dependencies)?
  2. Is it truly portable, or does it need to read/write from the user’s AppData, Local, Temp folder on Windows? (I am referring to the application itself, not tiddlywiki.)
1 Like

Dependencies
Edge WebView2 Runtime: Required.
This is pre-installed on Windows 11 and fully updated Windows 10 machines.

Portability:
Not “True” Portable: While it runs from a single .exe, Tauri apps default to writing cache and data to the host machine’s C:\Users<User>\AppData\Local\ folder. It leaves (small) traces on the host.

Recent Files:
Because these are saved in the host’s AppData (via localStorage), your list of recent wikis will not persist if you move the app to a different computer.

If you are interested it would be fairly easy to create a version that doesn’t leave a trace on the host device.

1 Like

Hi Yan,
Thanks for the detailed feedback! It is great to hear you are seeing performance gains over TiddlyDesktop.

To address your points and explain what is happening under the hood:

The “Bugs” & Permission Prompts

You hit on the exact reason I am planning a backend update. Right now, Liddly is essentially the “pure HTML” version of TiddlyStow running inside a browser window (WebView2).
Why the prompts? Those permission requests are actually coming from the browser engine, not the app itself. The browser is designed to be paranoid and ask you to re-confirm file access on every restart for security.

The Fix: I am writing a small Rust backend to replace the browser’s file access. Once that is done, the app will have “native” ownership of file operations, meaning zero permission prompts after you open a wiki, and full compatibility with other operating systems (fixing the Chrome-only limitation).

Specific Features
Window Size & Memory: I can probably add a state-manager plugin that remembers your window dimensions and maximization state between launches, though this isn’t high on my list.

Close Warning: This is doable and an important feature. I’m surprised this didn’t carry over through Tuari. I can hook into the close-request event to check for “dirty” states before closing.

Linux/Wayland:
Since this is built on Tauri, a Linux build is definitely possible (it uses WebKitGTK). I can look
into a specific config for Wayland environments.

External Links:
I have added this to the list, though it is currently a lower priority for me than getting the file system backend working smoothly.

Android:
Surprisingly, this is feasible! The framework I am using (Tauri v2) recently added mobile support, so an Android version is a realistic long-term goal.

Portability & Data
Config Location: Currently, it defaults to the standard Windows AppData folder.

True Portability: I like your suggestion of a recent.txt or config file sitting next to the executable. I am looking into having it check for a local recents.txt first, which would make the app fully portable on a USB stick. I would just need a button that can “export ‘recent.txt’” to implicitly switch from default behavior to portable mode.

TiddlyDesktop is geat if you have ONE place with EXACT ADDRESSING to TWs under it. It is not portable.

I’d look at alternatives, such as yours, IF TW addressing could be RELATIVE such that PORTABILITY was easy.

A query, TT

2 Likes