Separate build of gtk frontend and daemon

[Aleksanaa]

Maybe it's a good idea to separate this project into a gtk frontend and daemon backend, and make the backend depend on as less GNOME stuffs as possible. In this way we can develop kdeconnect clients for such as TUI, command line, deepin desktop, enlightment and xfce, and make these clients fit in their use cases well.
For example, I'm using hyprland (a simple wayland tiling wm) and waybar, what I want is a simple and suckless command which I can wrap around it with a shell script and make it as a waybar custom module, or a simple indicator with a gtk drop-down menu.

[bbinet]

That would actually be great! I would also like to have a command line tool so that it can be easily used in shell scripts.

[andyholmes]

Thanks for the idea!

I've actually spent some time thinking about this very thing, but it's difficult to separate GTK (and libadwaita) from the service process; much more so that situations like a torrent application. It may be possible to separate the dependency on GTK/libadwaita from libvalent into a sublibrary and I've been investigating that, but Valent the application will always depend on GTK/libadwaita because that's the toolkit that was chosen to provide third-party plugins an interface for preferences and so on.

It is possible, however, for a third party to use libvalent to build a KDE Connect application that is TUI-based or uses another toolkit. The catch is that because plugins have to implement their own UI (plugin preferences, SMS messaging window, etc), in some cases you will have to rewrite plugins you want to use a different UI.

The good news is that (as a rule) the default plugins in Valent will detect if GTK has not been initialized and either fallback to some headless behaviour or just do nothing. Most functionality is also exported as GAction and GMenu, both internally and on D-Bus, so it's possible for someone to write an alternate UI in a couple of different ways.

So the short story is you can write TUI clients and use other toolkits, but Valent will always depend on GTK/libadwaita. Since I don't have a use case for another type of client myself, anyone interested in writing one might want to get in touch before the API is finalized (no ETA) in case there are some unforseen changes required to make that possible.