feat(window-state): add filter callback for excluding windows from tracking

[thewh1teagle]

Add filter callback for excluding windows from tracking for window state plugin

Usage:

1. setup the plugin with

pub fn run() {
    /// in tauri.conf.json set window label to 'main' -> state saved -> change to 'main_deny' -> it won't be saved
    let plugin = tauri_plugin_window_state::Builder::new()
        .with_filter(|label| !label.ends_with("deny"))
        .build();
    ...

}

2. Check the state file in https://v2.tauri.app/reference/javascript/api/namespacepath/#configdir

Resolve

• fix [window-state] pattern based denylist #2329.

[github-actions]

Package Changes Through ae08144

There are 6 changes which include haptics with patch, haptics-js with patch, geolocation with patch, geolocation-js with patch, window-state with patch, window-state-js with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
api-example	2.0.14	2.0.15
geolocation	2.2.2	2.2.3
geolocation-js	2.2.2	2.2.3
haptics	2.2.2	2.2.3
haptics-js	2.2.2	2.2.3
window-state	2.2.0	2.2.1
window-state-js	2.2.0	2.2.1

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[amrbashir]

this is a breaking change, let's add the globbing into a different function or simply ignore the glob errors and store and match against it as is

[thewh1teagle]

this is a breaking change, let's add the globbing into a different function or simply ignore the glob errors and store and match against it as is

I'll change into

denylist_patterns.push(glob::Pattern::new(pattern).expect("Failed to parse glob pattern"));

Should I also change back the &mut [&str] denylist into &[&str]? (not sure how then sort it nicely)

[thewh1teagle]

Maybe

pub fn with_denylist(mut self, denylist: &[&str]) -> Self {
    let mut denylist = denylist.to_vec();
    denylist.sort();

    let mut denylist_patterns = Vec::new();
    for pattern in denylist {
        denylist_patterns.push(glob::Pattern::new(pattern).expect("Failed to parse glob pattern"));
    }
    self.denylist = denylist_patterns;
    self
}

[amrbashir]

Why do you need to sort?

Also please don't call .expect(), that's just a breaking change in disguise.

Instead, make two deny lists, one for globs and one for normal labels. if the pattern is built successfully then append to patterns list, otherwise append to normal list.

[thewh1teagle]

why do you need to sort?

In second thought, we don't need.

also please don't call .expect(), that's just a breaking change in disguise.

What do you suggest? If returning a Result isn't an option, I'm not sure what else to do.

[Legend-Master]

To be honest, I feel like if we're adding it in this way, a function might work better, the error handling here just feels wrong to me

[amrbashir]

why so?

[thewh1teagle]

To be honest, I feel like if we're adding it in this way, a function might work better, the error handling here just feels wrong to me

The denylist patterns will run during every reload of the app in development. The chances of the production build having an error with it are small.

[Legend-Master]

I was thinking they would re-use the same function but then I realized they can't as that will be a breaking change

If we're adding in another function just for the globs, I feel like it's enough reason to let the user provide a function instead, this will also allow some more advanced use cases like only skip for next window creation as well

Also in most cases, I believe a check like window_label.starts_with("some-name") would probably be enough

Another thing is I find functions returning results like this is quite confusing in general, I always wondered about why would this function ever fail? It's an extra mental burden

I'm not against this though, just find myself preferring a function more

tauri_plugin_window_state::Builder::new()
    .with_denylist_glob(&["window-*"])
    .unwrap()
    .build()

[thewh1teagle]

If we're adding in another function just for the globs, I feel like it's enough reason to let the user provide a function instead, this will also allow some more advanced use cases like only skip for next window creation as well

sounds better
How about

tauri_plugin_window_state::Builder::new()
    .with_filter(|label| true) // return true to save the state
    .build()

[Legend-Master]

Just a suggestion, instead of expending on the pattern, what about we allow an user provided function to customize this?

Maybe it's fine to just expand with glob patterns in this use case though

[amrbashir]

Just a suggestion, instead of expending on the pattern, what about we allow an user provided function to customize this?

We have a similar function map_label that is used when saving. But I think globs make sense here as well as it is similar to how you configure allowed/denied windows in the capability files.