Announcement

Collapse
No announcement yet.

X.Org Server Development Hits A Nearly Two Decade Low

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

  • #21
    Originally posted by Britoid View Post
    Besides, both of these will be taken care of by the toolkits, so it's not as if application developers really have to care either way.
    Yeah. My understanding is that they're successfully pressuring SDL into providing support for a butt-ugly bare-minimum CSD implementation if the desktop doesn't offer SSD, and mpv just repurposed its OSD code (essentially a subtitle renderer with icon support that had already been pressed into service for an on-hover, overlay-based control UI) to draw minimal window decorations.

    Truly an applause-worthy success and a brilliant example of good engineering design.

    Comment


    • #22
      Originally posted by ssokolow View Post

      Yeah. My understanding is that they're successfully pressuring SDL into providing support for a butt-ugly bare-minimum CSD implementation if the desktop doesn't offer SSD, and mpv just repurposed its OSD code (essentially a subtitle renderer with icon support that had already been pressed into service for an on-hover, overlay-based control UI) to draw minimal window decorations.

      Truly an applause-worthy success and a brilliant example of good engineering design.
      SDL also uses the MacOS toolkit to provide window decorations on macOS, so it's not as if it's anything groundbreakingly new to use the host toolkit to provide window decorations.

      I personally think talking to a Wayland server directly is a bad idea for anything that's not a toolkit because toolkits abstract a lot away from application creators, including window decoration, hidpi support, input etc. But if an application really wants to talk to it directly, a comprimise like libdecoration is the solution.

      Is what GNOME wants different to X? Yes.
      But it's not "not common" when you compare it to other operating systems, including Android.

      Comment


      • #23
        Originally posted by Britoid View Post
        You've purposely forgot to mention that both are optional protocols.
        Which is a problem. Interoperability features being considered "optional". This effectively makes wayland-protocols useless. The result being fragmentation.

        Originally posted by Britoid View Post
        The former, GNOME supports the org.freedesktop.ScreenSaver API which works on both X and Wayland and is easier to bind to a permission system.
        It's significantly more complex than Xss and the idle-inhibit Wayland protocol. Starting with the need for dbus, a no-go for smaller environments and applications.

        Originally posted by Britoid View Post
        The latter would require large redesigns of Mutter for very little gain.
        I wouldn't call interoperability and consistency with non-Gnome applications "very little gain". If you're fully immersed into Gnome you won't care, but not even Gnome users use exclusively Gnome applications. Such lock-in used to be frowned upon, now there's people defending it.

        Originally posted by Britoid View Post
        Besides, both of these will be taken care of by the toolkits, so it's not as if application developers really have to care either way.
        Toolkits are overkill for certain applications.


        In X, there's XDG standards and things like EWMH which provide interoperability, so there's a diverse ecosystem of DEs and smaller window managers. You can mix and match window managers and panels and small applications to create your very own environment exactly the way you like it. Applications can opt into using DE-specific tools, but they can easily roll things themselves in a DE-independent manner and they'll generally fit into whatever environment the user has put together.

        Wayland though, requires fully immersing yourself into a big DE, using applications and tools from that DE and only those. If you want to configure something beyond what the DE's control panel exposes (the monkey-patching that was mentioned), if you want to things like use your own panel because the DE-provided one doesn't entirely fit with what you want, well, you can't, everything in the DE is completely tied together with private protocols. The mixing and matching of independent components that you can do in the X world is just plain not possible. And if you want to use small DE-independent applications, prepare yourself for a world of hurt from lack of consistency and interoperability between compositors.

        Wayland-protocols could be a solution here, but that would require everyone to play ball. Instead, you either have a big giant mess or Apple-style lock-in into a specific environment.
        Last edited by Gusar; 04 January 2020, 10:43 AM.

        Comment


        • #24
          Originally posted by Lycanthropist View Post
          I have been developing pure Wayland clients in C++ in the past (i.e. w/o toolkit)
          This is quite interesting. Do you have any links to your projects or documentation you have been following?

          Genuinely asking because my experience is that Wayland is all far to young and primitive at this stage. Everything is ad-hoc as hell!

          So far most people "pro Wayland" have either never developed in the underlying tech (such as libX11/xcb equivalents) or just dabble with Gtk / Gnome and very high level interfaces. You might be fairly rare in that regard!
          Last edited by kpedersen; 04 January 2020, 11:28 AM.

          Comment


          • #25
            Originally posted by 144Hz View Post
            I didn't learn anything from my ban.
            We know.

            Drive-by hacking, short term contractors and weekly blogs won’t cut it in the Age of Wayland.
            I'd take KDE over Gnome any day. I'm looking forward to the next ngraham blog.

            Comment


            • #26
              Originally posted by Britoid View Post
              SDL also uses the MacOS toolkit to provide window decorations on macOS, so it's not as if it's anything groundbreakingly new to use the host toolkit to provide window decorations.

              I personally think talking to a Wayland server directly is a bad idea for anything that's not a toolkit because toolkits abstract a lot away from application creators, including window decoration, hidpi support, input etc. But if an application really wants to talk to it directly, a comprimise like libdecoration is the solution.

              Is what GNOME wants different to X? Yes.
              But it's not "not common" when you compare it to other operating systems, including Android.
              Once libdecoration is suitably mature and stable and GNOME developers show a willingness to reciprocate by supporting Qt-based CSD on a Qt desktop without SSD, I'll agree with you. As-is, it's simply unreasonable to expect "Simple DirectMedia Layer" to pull all of GTK+ into a KDE desktop or vice-versa.

              Other platforms have a specific toolkit as part of their base, guaranteed plarform API, similar to how other platforms chose to make their syscall API unstable and require you to interface via a bundled wrapper library.

              Comment


              • #27
                Originally posted by CochainComplex View Post
                Mh....5 years ago I thought we will be already using Wayland by default in 2020. But somehow it seems that there will be an additional 5 years to wait.
                Fedora already uses Wayland protocol by default since its 25th release and recently Red Hat Enterprise 8 series and its derivative.

                Comment


                • #28
                  Originally posted by CochainComplex View Post
                  Mh....5 years ago I thought we will be already using Wayland by default in 2020. But somehow it seems that there will be an additional 5 years to wait.
                  I've been using Wayland on all of my physical Linux systems since about 2016. It's been solid.

                  As far as I can tell everyone who doesn't use Wayland is using Nvidia or has some strange edge case I would have never imagined needing.

                  Comment


                  • #29
                    Originally posted by Britoid View Post

                    The former, GNOME supports the org.freedesktop.ScreenSaver API which works on both X and Wayland and is easier to bind to a permission system. .
                    Remind me again, why don't mpv devs support org.freedesktop.ScreenSaver? I remember reading it was complicated, but I lost the point about it

                    Comment


                    • #30
                      Originally posted by ciupenhauer View Post
                      Remind me again, why don't mpv devs support org.freedesktop.ScreenSaver? I remember reading it was complicated, but I lost the point about it
                      It requires dbus, which by itself is a no-go for mpv devs, and it's a double no-go to be required to bring dbus into mpv just so that a *single* DE won't blank the screen while you're watching a video, when all other environments respond to Xss (the X screensaver extension) or the Wayland idle-inhibit protocol.
                      Last edited by Gusar; 04 January 2020, 02:31 PM.

                      Comment

                      Working...
                      X