Investigate tauri.app for building an alternative desktop/server GUI

[Jermolene]

I've started investigating using tauri.app for a future TiddlyWiki desktop/server app. The attraction is that it is a modern, complete toolchain that includes support for cross-platform builds via GitHub Actions and has an integrated updater. It is more performance oriented than Electron, and generally seems very promising.

I've made a test "HelloWorld" app here:

https://github.com/Jermolene/tauri-test

It includes a GitHub Actions workflow to do the cross-platform builds, which you can download here:

https://github.com/Jermolene/tauri-test/releases

I'd welcome thoughts and questions. If all goes well, my thinking is to integrate the desktop app functionality much more deeply into TiddlyWiki than TiddlyDesktop was, making the Tauri build the standard way to install TiddlyWiki locally. (Like npm, Tauri includes a mechanism for registering CLI applications). Installation via npm would still be possible for developers, but we'd expect most end users to use the desktop installer. We could go further, and get the app into the desktop app stores.

[Jermolene]

Another couple of salient points about Tauri:

• By default, for most platforms Tauri uses the browser installed with the users operating system, meaning that the download size is tiny – the download for the test app is 1.89MB on Windows, 2.08MB on macOS, 3.3MB on Debian, and 68MB as an AppImage for other *nix platforms that includes an integrated browser
• Tauri have just launched an alpha for mobile support so there is a good chance that this path would let us ship the full Node.js power of TiddlyWiki as an iOS app and Android app

[saqimtiaz]

One of the other possibilities that Tauri offers that I have previously considered, is running in a near headless mode where the UI is just a configurations panel and the node.js (or a WebDAV) server exposed on localhost, allowing end users to utilize the browser of their choice if they have multiple available.

I am curious what the size file would be after bundling node.js and TiddlyWiki as a sidecar.

[Jermolene]

One of the other possibilities that Tauri offers that I have previously considered, is running in a near headless mode where the UI is just a configurations panel and the node.js (or a WebDAV) server exposed on localhost, allowing end users to utilize the browser of their choice if they have multiple available.

Exactly that. As part of this, we need to extend the Node.js configuration to host multiple independent subwikis. The present root wiki would become the admininistation interface, which we could optionally present with Tauri's webview.

I am curious what the size file would be after bundling node.js and TiddlyWiki as a sidecar.

Interesting. I hadn't seen https://github.com/vercel/pkg which is itself very useful.

[pmario]

That's a very interesting project. From the first view it seems to be even simpler to use than Electron and it has a very fine-grained control over local access rights. .. I'll have a closer look.

[linonetwo]

I can say I'm familiar in writing tauri app, I'm responsible for writing a tauri app for AFFiNE recently, and I have written https://github.com/linonetwo/DarkDayArch

It can serve static HTML wiki properly I think, but is not easy to run a nodejs wiki, that is why I haven't use tauri in https://github.com/tiddly-gittly/TidGi-Desktop

And its preload script is simpler than electron, so it might difficult to achieve things like trigger wiki operations from electron

I may not write a tauri tw app myself, because I use nodejs wiki. But if you need help in rust or tauri commands, feel free to ask me in talk forum DM or @ me in github. I suggest using vite+ts+tauri setup.

[Jermolene]

Thanks @linonetwo that's really helpful.

The lack of Node.js support is a shame, but the tantalising thing is that the Node.js configuration of TiddlyWiki will of course run in a browser if it is provided with the right APIs. All we'd need would be a few additional Rust proxies (eg for HTTP serving).

One question: is it possible in Tauri to assign different permissions to different windows? All the examples I've seen scope the allowlist to the app, not an individual window.

[linonetwo]

What kind of permissions? If you mean providing different sets of tauri command to different window, that is currently not possible, (which can be done in electron using preload script).

If you just want to apply different global variable to different window. You can remove the window setting in tauri.conf.json, and create window programmatically in rust code:

let preload = include_str!("../../dist/preload/index.js");
  tauri::Builder::default()
    .manage(AppState(Mutex::new(
      state::AppStateRaw::new().await.unwrap(),
    )))
    // manually create window here, instead of in the tauri.conf.json, to add `initialization_script` here
    .setup(move |app| {
      let _window =
        tauri::WindowBuilder::new(app, "label", tauri::WindowUrl::App("index.html".into()))
          .title("XXX")
          .inner_size(1000.0, 800.0)
          .title_bar_style(TitleBarStyle::Overlay)
          .hidden_title(true)
          .initialization_script(&preload)
          .build()?;
      Ok(())
    })
    .invoke_handler(commands::invoke_handler())
    .run(tauri::generate_context!())
    .expect("error while running tauri application");

And in preload script

function setEnvironmentVariables() {
  window.CLIENT_APP = true;
}

setEnvironmentVariables();

Different from electron, the ipc methods are injected by .invoke_handler(commands::invoke_handler()), so each window will receive same ipc methods. But in electron, ipc methods can be loaded by preload script, which is per-windowed.

[Jermolene]

Thanks @linonetwo that makes sense. It would seem to be a dead end for TiddlyDesktop. I'd like to be able to load the user wiki into a window that doesn't have any special permissions, and inject saver functions that use window.postMessage to save changes via another window that has privileged permissions. It doesn't sound like that is possible.

[linonetwo]

Why post to another window to save? Normally renderer windowss are connect to main process via ipc command, instead of connect to another window.

[Jermolene]

Why post to another window to save? Normally renderer windowss are connect to main process via ipc command, instead of connect to another window.

The idea is that the privileged window can verify the save request, perform backups etc. Ideally we would avoid giving any privileges to the user wiki. There are risks to the way that TW encourages users to install random JS plugins, but the risks are usually mitigated by the fact that TW runs in a sandbox when in the browser. Removing the sandbox would be a retrograde step.

[linonetwo]

Maybe you can add a save() ipc method that can only pass a HTML content to it, and not receive the path as a parameter. The path is got from the main process, which is read from a setting JSON that can only be modified from a setting window.

Like

#[tauri::command]
pub async fn save_html<'s>(
  state: tauri::State<'s, AppState>,
  workspace_id: String,
  html_content: String,
) -> Result<bool, String> {
  let configs = &state.0.lock().await.configs;
  let store_path = configs[workspace_id].store_path

So in window that contains TW, it can only call this safe save method. And workspace_id can be injected into the window via a preload script.