[amrbashir]

ref: #965

[lucasfernog]

Do we reall need the without_handler variants? can't users just define an empty closure and then the global listener handles the event?

[amrbashir]

I am not happy with it either, the idea is to provide a method to register a shortcut without handler that is appealing to use, without using an empty closure, but a long method name is not good either, maybe just call it register2?

[lucasfernog]

maybe register_without_handler keeps its name register and the new API is named on_shortcut? so it's clear you intend on providing a callback there

that's even a non breaking change I believe

[amrbashir]

maybe register_without_handler keeps its name register and the new API is named on_shortcut? so it's clear you intend on providing a callback there

I am afraid that might confuse users because on_ methods throughout tauri, are used to register just the listener.

[amrbashir]

Changed to take an Option instead

[lucasfernog]

maybe register_without_handler keeps its name register and the new API is named on_shortcut? so it's clear you intend on providing a callback there

I am afraid that might confuse users because on_ methods throughout tauri, are used to register just the listener.

that's what the on_ here will do:

fn on_shortcut(&self, shortcut: &str, handler: impl Fn()) {}
fn register(&self, shortcut: &str) {}

[amrbashir]

maybe I am overthinking it, let's roll with that and see user feedback

[amrbashir]

that's what the on_ here will do:

fn on_shortcut(&self, shortcut: &str, handler: impl Fn()) {}
fn register(&self, shortcut: &str) {}

hmm if we go with that approach, there will be inconsistencies between the JS and Rust APIs

[lucasfernog]

it's already inconsistent though 😂 JS is just different.. right now i wish we had function overloading in rust :D

[amrbashir]

Alright, added that along with a few methods on the Builder that should make it more Rusty hopefully.