4 ms·

I honestly think this complaint is completely bogus. This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple

by DCKing 6y ago

I honestly think this complaint is completely bogus. This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations. The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] ! The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't. [1]: https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots

spion 6y ago
Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places). What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.
- alisonkisk 6y ago
  Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.
  - spion 6y ago
    No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.
    - cycloptic 6y ago
      The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.
      - spion 6y ago
        At least between-app DPI inconsistency was not a thing before this. Now its a thing, added to the stack of configuration problems.
        cycloptic 6y ago
        If you support multiple DPIs then that will always be an issue, regardless of what display server you're using.
        spion 6y ago
        Not if the protocol allows the exchange of desired DPI/scaling.
- DCKing 6y ago
  Right, I agree that differences of opinions between implementations is probably not productive. I was responding to the notion that this situation is somehow directly attributable to Wayland's design, which is bogus. The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.
  - spion 6y ago
    Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling" edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1 [1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_output https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

by DCKing 6y ago

spion 6y ago

Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places). What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.

alisonkisk 6y ago
Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.
- spion 6y ago
  No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.
  - cycloptic 6y ago
    The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.
    - spion 6y ago
      At least between-app DPI inconsistency was not a thing before this. Now its a thing, added to the stack of configuration problems.
      - cycloptic 6y ago
        If you support multiple DPIs then that will always be an issue, regardless of what display server you're using.
        spion 6y ago
        Not if the protocol allows the exchange of desired DPI/scaling.
DCKing 6y ago
Right, I agree that differences of opinions between implementations is probably not productive. I was responding to the notion that this situation is somehow directly attributable to Wayland's design, which is bogus. The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.
- spion 6y ago
  Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling" edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1 [1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_output https://wayland.freedesktop.org/docs/html/apa.html#protocol-...