Investigate a possible cross-platform GUI implementation

[gesellix]

We started with a plain API/CLI implementation based on Golang and have good API coverage now. Until now, we foced on the aspects of a device's client. Other projects like https://github.com/deborahgu/soundcork focus on the remote Bose services to be replaced with an open source implementation. Another aspect is the SoundTouch App, which might be replaced by a HTML5 variant - see deborahgu/soundcork#125 and deborahgu/soundcork#123.

Given our personal experience with GioUI we might consider implementing a GUI on top of the CLI or the internal packages. That GUI would become an app replacement, given GioUI's broad support for all major or relevant platforms (Windows, Linux, macOS, Android, iOS, WASM).

Before simply running down the rabbit hole, we should consider joining forces with the Soundcorg devs. We should also check if GioUI's promises would also apply for features like device discovery on mobile devices and from a browser.

[oleggtro]

@gmuth reached out to me because of my lib here: https://github.com/oleggtro/libsoundtouch-ts

Id recommend implementing the app in react native and going mobile first because that's probably where most of the users are.

I personally don't have experience working with GioUI but I doubt it's able to create a nice mobile experience because as far as I can tell it's more focused on desktop

[gmuth]

Hi guys, great to see more people joining the soundtouch community!
Both proposals are valid and welcomed. While the native client support probably brings the best user experience I'd prefer a solution where no client deployment is needed.

Client html app that runs on your the local browser

No cloud or home server deployment would be required! Enabling developer mode due to CORS restrictions is totally valid for this project. ST10s support deploying the HTML and Javascript to the device - so no CORS issue there. ST20s currently need developer mode due to CORS issues.

@oleggtro , is it required for react apps to be deployed on a webserver or do the run locally with file:// support?

Every client would have to use the device api plus other apis to fully cover specific use cases. E.g. bmx search and navigate could be the API for searching radio stations. Just for reference I would like to name https://streamurl.link which is a UI only solution to search for radio stream URLs.

[oleggtro]

Depending on what features you want to use React requires a server, but it can also be "rendered" into a static site for a file based deployment.

But I was talking about "React Native" and/or Expo for creating a mobile app (for deployment via the app store).
You CAN also render a react native app into a web application and it works pretty okay, but I don't know whether you then can deliver in a "file only" deployment (don't think so...).

[gesellix]

For me there's no either ./. or, but we might implement both. I agree that a HTML/JS based client will be a good start and we might look how far we can go with that approach. I have no experience how good native support is regarding device discovery and such things in a web based implementation.

Full disclosure: I personally won't hesitate to get my hands on that native Golang variant. I'm not only trying to keep my SoundTouch working, but I see this project as playground to test WASM/GioUI. In times of AI the iterations are very quick.
I'm still willing to help the community on developing different aspects (Web App, Mobile App, testing on my device, ...).

For non-developers, we should try to create an easy-to-use app, @oleggtro already mentioned publishing to a play store as criteria. I don't see that as top priority, though. Automating the device setup with the USB stick can be automated/scripted to a certain extend, but I'm not sure if this would work from a Mobile or Web App.

As far as I'm aware, there are some building blocks required or nice to have:

• Device API clients (available: e.g. TypeScript, Golang, Rust, ...)
• Bose API Replacement (available/work in progress: Soundcork)
• Device migration to Soundcork (I see that as solved problem, e.g. like this: gesellix/Bose-SoundTouch-API@f57eb6f)
• Web App GUI (available ???)
• Mobile "native" Web App GUI (available ???)
• Mobile true native App GUI (available ???)
• Desktop App (required ??? ... this is optional)

[oleggtro]

I have reimplemented about half of the API through which we can control the device directly here: https://github.com/oleggtro/libsoundtouch-ts

Doing the other half wouldn't be that bad, I just ended up getting distracted. If we really need it it probably could be done in a few days.

[gmuth]

How about implementing a proof of concept for two user stories - for Ben the soundtouch owner:

Story "Set preset"

Ben would like to store radio stream https://dispatcher.rndfnk.com/br/br3/live/mp3/mid on preset 3.

Story "Show presets"

Ben wants to inspect stream urls assigned to the preset buttons.

Assumptions:

• LOCAL_INTERNET_RADIO source is functional (covered by soundcork)
• Ben knows the IP of the device

[gesellix]

So, I now merged a Soundtouch-Service based on Soundcork/Python, re-implemented in Golang (using AI). It already provides some features on top of Soundcork, especially a HTML based UI.
That UI is currently for device discovery/overview, initial setup (persistent remote_services, changing the XML to use different DNS, configure a mitm/proxy).
We might now start with the suggested use cases. If anything prevents a pure HTML5 app from directly communicating with the devices, the Soundtouch-Service in this repo might be extended with the required API (device discovery, ssh/telnet, oauth flow, etc).

... regarding the elephant in the room: I don't mean to simply steal the great work from the Soundcork repo (same applies to the Ueberboese-API), but we should keep in mind that anything being implemented in Golang is a candidate to be applied to the Python impl, too. I'm simply more confident with Golang (and reviewing AI generated Golang code) and the soundtouch-cli made total sense to have a sibling soundtouch-service. Also, the binary is much smaller 😅

[gmuth]

Ah, so you got infected as well by the keep-soundtouch-running virus :-)
Having more options is always good. However we need to have a focused look on components and their responsibilities. I understand you're more confident with your golang backend but until bose servers run there is actually no need for other backend testing alternatives when looking at the GUI component to configure the device! Both use cases from above can be implemented by using the soundtouch web api only!

By the way, I've started to integrate radio-browser.info: deborahgu/soundcork#150
This introduces source type RADIO_BROWSER to play radio stations using their uuid.
Enhancing existing clients for soundtouch support could save a lot of time.

[gesellix]

About the radio-browser: I'm going to include your Soundcork changes here: #65

[og-gh]

Did you see the GUI implementation from
https://github.com/[scheilch/opencloudtouch](https://github.com/scheilch/opencloudtouch)

[gesellix]

Yes, I'm aware of some other projects with overlapping implementations, including the one you mentioned. This is still something to be evaluated.

[gmuth]

Most GUIs look like they depend on a specific backend. However there are two dominant use cases that would be enough to start with: select a tunein station and play a custom url assuming the device is connected to a bmx compatible API.
I've prototyped a simple PWA for the custom url use case that can be added to the iOS home screen, so normal users can use it.

[gesellix]

In the best case we would find a way to re-use one of the more mature or polished web apps out there via an api compatibility layer. See also #120 (comment).