Announcement

Collapse
No announcement yet.

GNOME Shell 3.35.3 Released With NVIDIA Driver Offloading, Fixes To Shell + Mutter

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Gusar View Post
    I never said Mutter "breaks" the protocol. It doesn't. Neither does Weston. But they are missing features, features that are described in wayland-protocols, and the lack of those features causes additional work for application developers.

    You see not following wayland-protocols as not a big deal, because it's "optional". But that exactly *is* the big deal, that interoperability is considered optional. It shouldn't be. Just like EWMH isn't optional in the X world, so shouldn't wayland-protocols be optional.

    And if it isn't possible to add SSD to Mutter due to design decisions, that's crappy design then. A consequence of the devs not willing to see that there is a world beyond Gnome out there.
    Not many developers are going to be affected. If you use Qt, GTK or WxWidgets the toolkit already has you covered and that covers the vast majority of Linux applications.

    Anything else? libdecoration or XWayland.

    Comment


    • #22
      As I already wrote on another discussion, libdecoration is a back-burner project that may or may not ever get done. And interfacing with that is still extra work and it's still just to placate one environment (few people use Weston as a daily driver). And presenting Xwayland as a "solution" when the goal is to move away from X to something allegedly better and more modern is... weird to say the least.

      Besides, the issue isn't just window decorations. There's also idle-inhibit. Then there's cursor handling - configure a cursor in Gnome, but that's not what an application calling wl_cursor_theme_load will get, because Gnome has its own way of applying the cursor theme. This one isn't completely Gnome's fault though because there's no protocol for cursor handling, not even in wayland-protocols. Then there's the inability to use your own panel for example, you're stuck with the one the compositor ships with. There are one or two standalone Wayland panels out there, but they only work with wlroots-based compositors, presumably because a private protocol that's not part of wayland-protocols is used. Then, what about keyboard settings, is there an equivalent of xmodmap in Wayland, that would allow manipulating with the keymap in a DE-independent way, or are you stuck with whatever the DE's control panel exposes. Then there's display output configuration. There are a few xrandr-like commandline utilities out there, but they too only work with wlroots, while elsewhere you're probably again limited by what the DE's control panel exposes. Then... well, you get the idea already, though I could find more examples of were Wayland is just plain and simple limited, compared to what's possible in X. There's much greater flexibility in the X world, and interoperability remains because things are well defined at lower levels. Whereas in Wayland, even things that are already well defined are "optional", so you have to write compositor-specific code in your app. Or you're limited in your configuration options by what a compositor-specific control panel exposes.

      Comment


      • #23
        Originally posted by Gusar View Post
        As I already wrote on another discussion, libdecoration is a back-burner project that may or may not ever get done. And interfacing with that is still extra work and it's still just to placate one environment (few people use Weston as a daily driver). And presenting Xwayland as a "solution" when the goal is to move away from X to something allegedly better and more modern is... weird to say the least.

        Besides, the issue isn't just window decorations. There's also idle-inhibit. Then there's cursor handling - configure a cursor in Gnome, but that's not what an application calling wl_cursor_theme_load will get, because Gnome has its own way of applying the cursor theme. This one isn't completely Gnome's fault though because there's no protocol for cursor handling, not even in wayland-protocols. Then there's the inability to use your own panel for example, you're stuck with the one the compositor ships with. There are one or two standalone Wayland panels out there, but they only work with wlroots-based compositors, presumably because a private protocol that's not part of wayland-protocols is used. Then, what about keyboard settings, is there an equivalent of xmodmap in Wayland, that would allow manipulating with the keymap in a DE-independent way, or are you stuck with whatever the DE's control panel exposes. Then there's display output configuration. There are a few xrandr-like commandline utilities out there, but they too only work with wlroots, while elsewhere you're probably again limited by what the DE's control panel exposes. Then... well, you get the idea already, though I could find more examples of were Wayland is just plain and simple limited, compared to what's possible in X. There's much greater flexibility in the X world, and interoperability remains because things are well defined at lower levels. Whereas in Wayland, even things that are already well defined are "optional", so you have to write compositor-specific code in your app. Or you're limited in your configuration options by what a compositor-specific control panel exposes.
        One reason here is that a big part the Wayland community does not want it to be a X11 drop in replacement. That's the point of not calling it X12. They want to make changes such as moving responsibilities to other parts of the stack. There are other ways to do things, such as using dbus, xdg-portals, moving stuff to toolkits etc. So arguably many these protocols and features can be considered bloat. And having them supported in X11 a mistake, retrospectively.

        I know that the wl_roots camp is more in favour of "let's invite another Wayland protocol!" and "what is dbus?". We'll see how far it gets them.

        Comment


        • #24
          Originally posted by Hibbelharry View Post

          Thats utter nonsense.

          Archsway. I still really miss Devuanwindowmaker. Or Lindowstwm. Or Suseyawm. Can't be too long.
          debianxf- ...

          Comment

          Working...
          X