4 ms·

>This is all assuming you want to use DBus. Why? Wayland is already the thing that you speak to talk to the display server. Why use another protocol for basic f

>This is all assuming you want to use DBus. Why? Wayland is already the thing that you speak to talk to the display server. Why use another protocol for basic functions like this? You have this completely backwards. Dbus was already standard on nearly every X11 desktop and was spoken by a lot of X11 window managers, before Wayland even existed. It was adopted during the X11 days because X11 is a poor IPC for anything outside of window management. It's notably bad at syncing settings where you commonly have an external process storing a settings database that sends notifications to interested applications. X11 is a poor fit for that, but dbus is great at handling that case with its signaling mechanism. Mouse cursor size being a good example of that type of setting. >If DBus is so great, why do we even need the Wayland protocols in the first place? Because they're two different protocols with different goals. Dbus is a general-purpose IPC that can be used for a lot of desktop tasks, like syncing settings. It's designed for many-to-many communication between every program on the system. Wayland is designed mainly for high performance between only one application (the window server) and its clients. >Dbus is not great. Dbus is the worst option except for all the others. I've seen a lot of dbus hate over the years but still no one has ever been able to propose a replacement. No, putting everything into Wayland protocols is not a suitable replacement.

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?

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?