Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add property inspector types #15

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

carlosmn
Copy link
Contributor

@carlosmn carlosmn commented Oct 4, 2023

These are the messages that go back and forth between the software and the plugin's property inspector.


I don't know how much you care about these types given that the property inspector has to be in HTML, but these have been useful to me.

These are the messages that go back and forth between the software and the
plugin's property inspector.
@mdonoughe
Copy link
Owner

I've actually got these in https://github.com/mdonoughe/sbzdeck/blob/2ab5c605811b259e7c7f7c2a01f8719b5eb76415/inspector/src/message.rs because sbzdeck has an inspector based on Yew. It seems like a separate concern. Maybe the plugin process code and the inspector code could be optional features so your property inspector doesn't have dependencies on tokio but the crates can still have some commonality, or maybe it should be separate crates, possibly core crate for the common stuff.

@carlosmn
Copy link
Contributor Author

It's a bit of a different concern in a way, but given that you can use Rust and compile to wasm, to me it makes sense that this is all together. Depending on tokio for your wasm is not great. If you're writing the inspector in Rust I would expect the plugin to also be in Rust, though I guess that's not technically necessary.

As far as options and dependencies, I think it makes the most sense to split things such that you can opt into just having the message types, which would cover an inspector but also if for some reason you're using something different to talk to the streamdeck, you wouldn't have to worry about also having tokio (this might get awkward with tungstenite and parsing though, I'm not sure).

I'm mostly using this to talk to plugins so for me it's all part of the same thing, but I understand that's not what you envisioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants