[Feature, Linux] Add a basic DBus interface alongside the daemon

[orowith2os]

Acknowledgements

• I have searched the existing issues and this new issue is not a duplicate of any.
• I have written a concise and meaningful title.

Description

I've been using OTD since I got my drawing tablet, and it's been pretty solid so far. My only complaint is that there isn't a tray icon (or it doesn't like Tray Icons Reloaded on GNOME) and that can make switching presets on the fly a pain.

I know OTD already provides a daemon, but adding a DBus interface alongside that could be useful as some applications might want to talk to OTD to set some options, such as different presets or modes, and going through its own daemon might not be very app-friendly. Using DBus for these applications/use cases can make it an easier process.

Having a DBus interface would also allow for more integration into the system if some effort is put in by the end user/developers, as the desktop environments can add extensions to easily talk to OTD, such as a GNOME extension (why I'm making this feature request).

I'm not asking for a fully featured interface, but rather just something basic that can be expanded as time goes on. The features I'd request from an interface like this first would be querying and setting presets.

[X9VoiD]

Would improving the CLI not suffice? Platform-specific features (that are not related to input processing) are mostly not welcome here.

[wsippel]

D-Bus originated on Linux, but it runs on all POSIX operating systems, as well as Windows: https://github.com/freedesktop/dbus/blob/master/README.win
So if a multi-platform application wanted to talk to OTD directly, D-Bus should work on all platforms OTD runs on.

[X9VoiD]

I still don't believe it offers any real advantage over just improving and making use of the CLI. Adding D-Bus support as an official feature of OTD will just increase maintenance burden on top of being redundant. It would mean the daemon would now have to serve two different kinds of IPC. And that's a nightmare nobody would like to go through without any compelling argument of why it's a need to include D-Bus support.

[X9VoiD]

I'd argue that letting the daemon spit out either a pretty or json formatted output is a better place to put efforts in.

[wsippel]

I still don't believe it offers any real advantage over just improving and making use of the CLI. Adding D-Bus support as an official feature of OTD will just increase maintenance burden on top of being redundant. It would mean the daemon would now have to serve two different kinds of IPC. And that's a nightmare nobody would like to go through without any compelling argument of why it's a need to include D-Bus support.

Yeah, it would probably only really make sense as the only IPC. So remove whatever else you use, and only use D-Bus for everything. That might be a worthwhile change considering its flexibility and cross-platform nature, depending on how complicated the migration would be. But I totally get not wanting to support two different, independent IPC mechanisms. That sounds like a massive headache.

[X9VoiD]

So remove whatever else you use, and only use D-Bus for everything

No

[wsippel]

So remove whatever else you use, and only use D-Bus for everything

No

I mean, I don't personally have a horse in this race, but why? I don't get the feeling you actually worked with D-Bus, maybe it could make things easier in the long run? Not trying to be an ass or anything, but having to maintain an IPC mechanism is work, and here's one that's ready-to-use, that would work everywhere, and potentially open up new possibilities. Maybe that's worth looking into?

Again, don't get me wrong, I love OTD as is, but I do think a standard mechanism for other applications to interface with OTD could be kinda useful, and D-Bus might be the easiest way to do it, both for you and application developers, but I'm by no means an expert.

[X9VoiD]

The CLI already exists, and all supported platforms can use it in the exact same way without having to deal with D-Bus.

[wsippel]

I totally get that, but does that mean you use the CLI to handle communication between the GUI and the driver itself? I wouldn't have guessed, but I guess that's why you have to hit an "apply" button for changes to take effect? Hitting the button forms a command based on your settings that's then sent to the CLI?

[jamesbt365]

No? The cli is not the same as the daemon. The "apply" button is for confirming your settings. Stops them from changing on you every time you make a small change and only changes when you tell them to.

Windows for example isn't even packaged with the cli by default.

[X9VoiD]

The CLI and the GUI communicates with the daemon/driver via json-rpc 2.0.

[wsippel]

That makes a lot more sense, thank you. From your previous post, I thought you directly talked to the daemon using the CLI to change settings, as in, all settings are just application parameters, and hitting "apply" would simply restart the daemon with the new parameters. Doesn't really matter though. There's a json-rpc to D-Bus bridge (because of course there is), so a Gnome extension like what OP suggested could probably be implemented without any changes to OTD itself. I still think there might be value in a standardized, official, cross-platform IPC mechanism, but it would be a niche usecase, so probably not worth the effort.

[X9VoiD]

json-rpc is platform and transport-agnostic so it, by all definitions, is already a standardized, official, and cross-platform IPC mechanism of OTD.

[orowith2os]

How sandbox friendly is OTD/json-rpc? If there was a dbus interface available it would be fairly easy to get going in flatpak, not sure on json-rpc. I'm also fairly certain most apps prefer dbus for ipc over json (in the context of third parties).

[X9VoiD]

What I meant there is that JSON-RPC is transport-agnostic. JSON-RPC is not affected by sandboxing, the transport is.

[X9VoiD]

And there's already a CLI available that you can use and parse its output. What benefit does dbus provide over just using the CLI to get what you need? Sandboxing isn't an issue for OTD's IPC as long as the sandbox allows the use of named pipes, and you don't even have to use the IPC, just invoke the CLI.

Use of CLI also has the benefit of being scriptable, making it available to setups that use dmenu-like interfaces for example. The CLI allows one to do much more, especially in shell execution environments.

There's also the fact that OTD won't ever be packaged as a flatpak and have it work out-of-the-box since it requires access to devices that are normally only available to root.

[orowith2os]

Again, I'm not concerned about flatpakking OTD; only the flatpaks of apps that want to communicate with it, like osu! or Krita.

The issue with using the CLI is that it needs to be bundled inside of the application, it can't be interacted with via a generic dbus interface. Bundling the CLI can make the build process harder to work with, and be cross-arch.

It also turns out the Flatpak sandbox isn't really affected, as it has a share=ipc permission. But that still assumes the applications want to then depend on json-rpc for ipc, when they already use dbus for everything else.

[X9VoiD]

OTD is always distributed both with the daemon and the ui app, plus the cli for some platforms. They are built exactly the same way thanks to dotnet's tooling. Idk what you mean by "cross-arch" but it's just a single switch in dotnet to build it to that arch, we don't even need to do it because we're compiling it to IL, as long as the host has a dotnet runtime OTD will run there, no matter what architecture.

Also, both the apps you cited have no need to "communicate" with the daemon, what do you want to happen there? osu! has its own instance of OTD. Krita has no concern what your tablet configuration is. If any apps implement some sort of system-wide tablet reconfiguration by talking to the daemon then it's gonna make that part of the app itself redundant and prone to breakage, why not just use the official UI?

If you meant "flatpakk'ed apps cannot use the CLI because it only exists on the host, not flatpak's sandbox". Then you are right. However this goes outside your original intention of writing a gnome extension, I have never seen a gnome extension packaged as a flatpak. Again, nothing stops a gnome extension dev from just invoking cli commands to delegate the communication to the daemon. Plus the CLI is scriptable, much much easier to integrate with to the rest of a unix-principled system of using small tools to achieve something (for example, a shell script that does otd-cli, jq, dmenu to basically do what your gnome extension will do, but compatible to all environments)

[X9VoiD]

If we're ever gonna be adding dbus, it's most likely in the form of a plugin to offload that work to somebody else more interested in getting it in. May instead recycle this thread to talk about the eventual bus name and interface.