Websocket implementation

[oparada1988]

Websock implementation is not present when installing it, not sure if it has been merged. Currently using obs-cli but would rather have it built into the manager

[zark0-UwU]

For this, i think a better approach would be a module system, thus not needing support from the official project, just independent plugins. But i could not agree more that some plugins should be there by default, like a web socket module (addons would be the same as a module but from 3rd party devs)

[zark0-UwU]

I have seen in other similar issues, the idea of implement a the same plugin system as the official windows streamdeck program uses, but i see some problems (from the perspective of someone not familiarized with that plugin system):

• those plugins will mostly not run on linux.
• Would need to get up to date with the official one, while needing to reverse engineer it (so it does not cause problems).

[nemec]

TL;DR: websocket can be done, but the app might need internal updates (e.g. statefulness) to unlock some of the really cool experiences.

There is no websocket support (yet) in this app. I've started working on a websocket proof of concept that supports the app in its current state (buttons identified by page/row/column coordinates) and can change page (#176), set icon (#99), and set the button text. It also sends a websocket message to all clients for each keyDown and keyUp event, so your apps can run code when someone presses a button on the device.

Demo here (watch to 18s for an example of setting text): https://twitter.com/djnemec/status/1482746465894154251 The demo is actually 3 components:

1. This streamdeck program, with websocket API
2. A websocket client on my PC that responds to a button press and plays music from my speakers
3. A websocket client on my Node Red server handling the icon/text change automation

I tried to model the WS API "similar" to the official SDK but there are significant fundamental differences between this application and the official one. Before moving too far forward on this, I'd love to hear the maintainers' vision for future extensibility and whether a websocket plugin fits (in its present or future state). One big thing we're missing now is statefulness: take a mic mute button, for example. The "keyDown" event only sends coordinates of the button pressed and nothing else, there's no indication of current state (muted or unmuted). Any statefulness would have to be managed by the websocket client, which also makes it more difficult to handle multiple clients interacting together (they'd have to share state out of band).

My current changes are committed to the websockets branch in my fork for now: https://github.com/nemec/streamdeck-ui/commit/10e6a556ad75a28e276e9f86c4d19245227208de

And here's a sample websocket client in Python. To use with OBS you'd have to write a Python program to receive websocket events from streamdeck_ui and reformat them to send to the OBS websocket. Left as an exercise for the reader 😉 https://gist.github.com/nemec/1508f74abef288200b8f341492d3259e

#142

[TheJebForge]

Hello, am currently actively developing an alternative software that is planning to solve/already solved many of the core issues with this project, including built-in support for websocket and general separation into separate clients and daemon service. If anyone's interested: https://github.com/TheJebForge/streamduck

[zark0-UwU]

Hello, am currently actively developing an alternative software that is planning to solve/already solved many of the core issues with this project, including built-in support for websocket and general separation into separate clients and daemon service. If anyone's interested: https://gitlab.com/TheJebForge/streamduck

I am really interested on helping with your new project, but im lacking the time to help, I think you went the right direccion, specially for me, I never liked languages like python, and always thought they are not suited for this kind of applications. I would like to go forward with streamduck. (btw I love the name XD)

[bdrung]

Looking at streamduck with my Debian packaging hat on: Written in Rust and LGPL is fine, but packaging the planned Electron UI will be complicated. Electron is not in Debian and getting it into Debian is a lot of work (see https://bugs.debian.org/842420).

[TheJebForge]

Looking at streamduck with my Debian packaging hat on: Written in Rust and LGPL is fine, but packaging the planned Electron UI will be complicated. Electron is not in Debian and getting it into Debian is a lot of work (see https://bugs.debian.org/842420).

Electron is just the last resort UI am planning, but the software itself is extendable enough that many different versions of the GUI can be made for it, since it's simply communicating to the service with sockets. I should probably point that out in the readme

[zark0-UwU]

Looking at streamduck with my Debian packaging hat on: Written in Rust and LGPL is fine, but packaging the planned Electron UI will be complicated. Electron is not in Debian and getting it into Debian is a lot of work (see https://bugs.debian.org/842420).

It should be a no problem if we use flatpack instead, I am not experience packaging projects, but i have heard of OBS ( Open Build Service), which i think it could do the trick?

[zark0-UwU]

Looking at streamduck with my Debian packaging hat on: Written in Rust and LGPL is fine, but packaging the planned Electron UI will be complicated. Electron is not in Debian and getting it into Debian is a lot of work (see https://bugs.debian.org/842420).

Electron is just the last resort UI am planning, but the software itself is extendable enough that many different versions of the GUI can be made for it, since it's simply communicating to the service with sockets. I should probably point that out in the readme

I think we should close this issue, and move it over ~~gitlab~~ streamduck's github, since this is getting more about the new project streamduck.

[dodgyrabbit]

The streamduck project looks neat! The more support we can create, the better. For what it's worth - some time ago I started working on a plugin system for this project (https://github.com/dodgyrabbit/streamdeck-ui/commits/ui-experiment). However, life got busy and never really got it done.

To be honest, my feeling about that has since changed. I had a look at the official streamdeck SDK and I think the best way to approach a plugin system is to effectively use theirs. It's a relatively simple JSON based API if I'm not mistaken, and it seemed quite feasible that we could allow you to run their official plugins. We would need to support the same interface. Definitely seems the most promising IMHO. However, a simple python approach for this project could work too.

[tristengrant]

Any progress on adding websocket support?

[coolapso]

hi, this project seems to be stale and a new fork as been made with the intention of replacing this one.

if this still an issue please reopen it at: https://github.com/streamdeck-linux-gui/streamdeck-linux-gui