2 ms·
I'm not sure if there's any point in arguing this but I am not suggesting the Linux ecosystem should just drop DBus. I can kind of see why it may read like I'm
by jchw 4y ago
I'm not sure if there's any point in arguing this but I am not suggesting the Linux ecosystem should just drop DBus. I can kind of see why it may read like I'm suggesting that, but it wasn't really my intent. Instead, I'm actually saying something much simpler; I think that not all users of Wayland will want DBus, and in those cases, the Wayland protocols is a very reasonable place to put functionality related to the display server. I understand that in the view of some folks, certain things do or do not belong in the Wayland protocol. However, I think that's moot. It's mostly philosophical where Wayland begins and ends. The truth is, idle inhibition is adjacent to the compositor, and thus reasonable to support. To their credit, GNOME does the much more reasonable thing in the Mutter side by supporting the idle inhibit protocol as a proxy for the equivalent desktop portals interface. This is a win-win-win, as it's not terribly difficult to do, it allows GNOME to still keep things organized mostly the way they want, it supports clients that don't want to use DBus for this, etc. It seems the GTK maintainers would be willing to merge support in GTK too, but it's not currently happening. This is a shame. I'd be willing to help make it happen, by either writing code or helping fund someone else to, though for the latter I have no idea where to begin. (except maybe bountysource or something, but I am uncertain of the effectiveness of that model.)
Now for something like syncing the cursor size, that belongs in Wayland. Duh. The Wayland compositor handles displays, their scale factors, and the hardware cursor. It's just common sense.
Wayland as a protocol is probably not good enough to replace DBus, but it is significantly simpler and lacks some DBus pitfalls. I think for things that could reasonably be handled by the compositor, it should be.
(I have other concerns about DBus, too, especially now that desktop stuff is moving to systemd user services. Aren't systemd user instances per user and not per session? How can you deal with DBus in that context?)
- QUrprUd1nCeicw 4y ago>This is a shame. I'd be willing to help make it happen, by either writing code or helping fund someone else to You might consider joining the IRC/Matrix channel and making an offer to one of the maintainers. >Now for something like syncing the cursor size, that belongs in Wayland. Duh. The Wayland compositor handles displays, their scale factors, and the hardware cursor. It's just common sense. No, unfortunately it doesn't and it isn't. You're describing something that isn't Wayland. I've seen upstream Wayland developers following the rule of "it should only be a Wayland protocol if it requires access to Wayland object ids" and idle-inhibit does follow that rule (you can inhibit on a window id). Anything to do with mouse settings doesn't follow that rule. There was a conscious decision to keep settings handling out of Wayland protocols because, among other reasons, Wayland is designed for a specific thing (windowing) and is bad at being a settings database. It doesn't really even have a way to identify hardware devices, those are all abstracted away under "outputs" and "seats" which don't actually need to correspond to any physical device. >Aren't systemd user instances per user and not per session? How can you deal with DBus in that context? You only have one session bus per user and it's the one used by systemd. I mean, you can start more buses but why would you need to when none of the services you want will be using that?