Specify where the Window State plugin's JSON file is stored

[zevnda]

Problem

Currently, the Window State plugin saves the .window-state.json file in a fixed location: ${dataDir}/${bundleIdentifier}/. This creates issues for applications that need to maintain full portable installations where all data stays in the app/binary directory.

Proposed Solution

Add a with_dir() method to the Builder that allows specifying a custom directory for the window state file, similar to how with_filename() allows custom filenames.

Suggested API:

pub fn with_dir<P: AsRef<std::path::Path>>(self, dir: P) -> Self

Example Usage:

// Relative path
tauri_plugin_window_state::Builder::new()
    .with_state_flags(StateFlags::SIZE | StateFlags::POSITION)
    .with_dir("./config")
    .with_filename("my-window-state.json")
    .build()

// Absolute path
tauri_plugin_window_state::Builder::new()
    .with_state_flags(StateFlags::SIZE | StateFlags::POSITION)
    .with_dir("C:\\Users\\Username\\AppData\\Local\\MyApp")
    .with_filename("my-window-state.json")
    .build()

[Legend-Master]

Not sure if it makes more sense to have a portable setting in the tauri builder/config which will make PathResolver to resolve app related directories (e.g. AppConfig, AppData) from the current executable directory

This seems to be a somewhat common use case now, also see https://github.com/tauri-apps/tauri/issues/3109

[zevnda]

My use case, and I'm sure many others, requires being able to release both portable and non-portable versions, ideally from the same codebase. A global portable setting would make this difficult, since the app could only operate in one mode at a time.

An additional method on the plugin's builder to specify the storage location at runtime would offer the flexibility needed, without being limited by a global setting.

[Legend-Master]

I mean, with an additional method on the builder, you'll still have the flexibility of setting it during runtime or compile time

For example:

let mut builder = tauri::Builder::default();
if is_portable() {
    builder = builder.use_portable_paths();
}
builder.run(tauri::generate_context!());

I imagine this is how you would use the directory setting for the window-state plugin as well

[zevnda]

The only caveat is that Tauri doesn’t officially support portable apps, as far as I know. Probably because it relies on the WebView2 runtime, which isn’t pre-installed on all versions of Windows. I believe it comes pre-installed in Win11, but only some eligible Win10 machines have it pre-installed, while anything before Win10 would need manual installation.

So while having a portable flag in the config would technically work, it’s less practical since Tauri doesn’t truly support backwards portability.

Just my two cents. I'll honestly be happy with either implementation.