chore: update README and Cargo metadata

Author: jvatic

Cargo.toml

@@ -2,6 +2,11 @@
 edition = "2021"
 name = "tauri-ipc-macros"
 version = "0.1.2"
+description = "IPC bindings for using Tauri with a Rust Frontend (e.g. leptos)"
+license = "BSD-3-Clause"
+homepage = "https://github.com/jvatic/tauri-ipc-macros"
+repository = "https://github.com/jvatic/tauri-ipc-macros"
+authors = ["Jesse Stuart <[email protected]>"]
 
 [lib]
 proc-macro = true

README.md

@@ -1,12 +1,17 @@
 # tauri-ipc-macros
 
-![rust workflow](https://github.com/jvatic/tauri-bindgen-rs-macros/actions/workflows/rust.yml/badge.svg)
+![rust workflow](https://github.com/jvatic/tauri-ipc-macros/actions/workflows/rust.yml/badge.svg)
 
-This is an *experimental* crate to aid in generating Rust IPC bindings for [Tauri](https://tauri.app/) commands (for those of us who'd like to use Rust for the front-end). Please review the code before using it.
+IPC bindings for using [Tauri](https://v2.tauri.app/) with a Rust Frontend (e.g.
+[leptos](https://v2.tauri.app/start/frontend/leptos/)).
+
+**NOTE:** The API is currently unstable and may change.
 
 ## Why
 
-I couldn't find a comfortable way of defining commands that would maintain type safety with Tauri IPC bindings for a Rust frontend. So this is a crude attempt at solving this without changing too much about how the commands are defined.
+I couldn't find a comfortable way of defining commands that would maintain type
+safety with Tauri IPC bindings for a Rust Frontend. So this is a crude attempt
+at solving this without changing too much about how the commands are defined.
 
 ## Usage
 
@@ -41,9 +46,12 @@ I couldn't find a comfortable way of defining commands that would maintain type
     }
     ```
 
-    **NOTE:** If you have multiple enums deriving `Events`, these will need to be in separate modules since there's some common boilerplate types that are included currently (that will be moved into another crate at some point).
+    **NOTE:** If you have multiple enums deriving `Events`, these will need to
+    be in separate modules since there's some common boilerplate types that are
+    included currently (that will be moved into another crate at some point).
 
-    And if you're using a plugin on the frontend and want bindings generated for it, you can do so by defining a trait for it, e.g:
+    And if you're using a plugin on the frontend and want bindings generated for
+    it, you can do so by defining a trait for it, e.g:
 
     ```rust
     pub mod someplugin {
@@ -55,7 +63,16 @@ I couldn't find a comfortable way of defining commands that would maintain type
     }
     ```
 
-    **NOTE:** If you have multiple traits implementing `invoke_bindings` they'll each need to be in their own `mod` since an `invoke` WASM binding will be derived in scope of where the trait is defined (this will be moved into another crate at some point).
+    **NOTE:** You can find the `cmd_prefix` and plugin API by looking at the
+    [guest-js](https://github.com/tauri-apps/plugins-workspace/blob/v2/plugins/clipboard-manager/guest-js/index.ts)
+    bindings and [Rust
+    source](https://github.com/tauri-apps/plugins-workspace/blob/v2/plugins/clipboard-manager/src/commands.rs)
+    for the plugin(s) you're using.
+
+    **NOTE:** If you have multiple traits implementing `invoke_bindings` they'll
+    each need to be in their own `mod` since an `invoke` WASM binding will be
+    derived in scope of where the trait is defined (this will be moved into
+    another module at some point).
 
 2. Import the commands trait into your Tauri backend and wrap your command definitions in the `impl_trait` macro, e.g:
 
@@ -69,7 +86,18 @@ I couldn't find a comfortable way of defining commands that would maintain type
     });
     ```
 
-    This will define a shadow struct with an `impl Commands` block with all the functions passed into the macro minus any fn generics or arguments where the type starts with `tauri::`, and spits out the actual fns untouched. The Rust compiler will then emit helpful errors if the defined commands are different (after being processed) from those in the trait, yay!
+    This will define a new struct named `__ImplCommands` with an `impl Commands
+    for __ImplCommands` block with all the fns passed into the macro (minus any
+    fn generics or arguments where the type starts with `tauri::`), and spits
+    out the actual fns untouched. The Rust compiler will then emit helpful
+    errors if the defined commands are different (after being processed) from
+    those in the trait, yay!
+
+    **NOTE:** The crudeness here is due to `#[tauri::command]`s needing to be
+    top level fns and potentially having additional arguments in the siganture.
+    And while I can imagine a way of abstracting this out of the API (so this
+    could be a regular `impl` block), this was the easiest thing and works
+    without changing much about how the commands are defined.
 
 3. Import the event enum into your Tauri backend if you wish to emit events from there, e.g.: