Bottles Next KDE client

[Akselmo]

Hi, I was thinking since Bottles Next would be client/server/agent architecture, I would be interested trying my hand making a KDE client application for it. I think the idea of separating the client from server makes sense.

This way we KDE Plasma users could get an app that fits our systems and follows our HIG, which Plasma users expect.

Is there some documentation I should delve in, is Bottles Next architecture done yet for this, or is it still being planned out?

I am not 100 sure if this is the right place for this conversation (if theres Bottles Next repo or something), but anyway.. I would gladly give it a try and I am very interested working on the KDE client of Bottles Next. :)

I will not promise that I can get it all done just like that, it will likely take time because Life:tm: but just so you know there's at least one interested in creating and maintaining a KDE client.

Edit: Also if there is already someone working on this, I wouldn't mind helping out!

Edit2: To add, I would not expect Bottles devs to maintain this! This client would be maintained by the KDE folk like me. And if theres bugs and such in server I will gladly help with reporting/testing.

[edfloreshz]

Hi, thanks for your interest, we’re still planning and testing things out, there’s progress being made but we’re still in early stages.

I’ll do my best to document the API to the best of my ability during development, but if you’d prefer waiting until the stable release to start working on this, that’s okay too.

We’re not currently working on the client, that’ll come later.

[Akselmo]

Alrighty, i am willing to wait for the API to stabilize, but when theres some documentation for the API out, i wouldnt mind starting experimenting! :) thanks for the quick reply!

[mirkobrombin]

This reminds me we'll have to document both classic and next modes, so as a client can decide which one to support.

[Qronikarz]

If you want to start experimenting then theoretically it should be already possible for the current Bottles.

If I remember correctly there were some commits that focused on separation of backend and frontend of Bottles to allow different frontends, but I can't find the discussion for it.

Here the decoupled backend PR: #2628

And here some info from the old Rust issue:

Today the frontend is already 100% disconnected from the backend, there's a signal/event system that makes the communication between the two when necessary. It is theoretically already possible to write another frontend fro Bottles.

I think the approach with PyO3 is the better one in our case, switching to a daemon approach would be quite the work without much benefits imo

The signal/event system would be exactly the same if using the backend as a daemon, the one added part would be having a reciever/sender function to communicate with the daemon.

using pyo3 would make us rely on an external system that can break and require us to rewrite parts if pyo3 updates with breaking changes (which apparently already is the case based on the issue linked in the first issue message by oro)

#3007 (comment)

Though I would wait for Bottles Next before starting a new frontend for Bottles.

[Akselmo]

Ah interesting, thanks! I will likely wait for more progress, but I will look into it nevertheless!