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
    I don't really have the feeling, that Wayland is developed for GNOME. I have been developing pure Wayland clients in C++ in the past (i.e. w/o toolkit) and the protocol seems pretty vendor neutral to me. Also, it's hosted at freedesktop.org and not at gnome.org. Just because GNOMEs Wayland implementation doesn't adhere to common standards, doesn't mean, Wayland is developed for GNOME.

    And once the HiDPI issue is worked out in sway, I will say goodbye to X11 for good.

    Comment


    • #22
      Originally posted by Britoid View Post

      I think you're severely over estimating how many people (ie normal desktop users) actually monkey patch their desktop.
      I'm currently reviving a tool I maintain named QuickTile which is a clone of a tool named WinSplit Revolution which monkey-patches the desktop to add intermediate window-tiling support to any WM. (More advanced than Aero Snap and its many clones, less advanced than a real tiling WM)

      Likewise, there are various popular Windows and Linux tools which implement things like input macros which are at odds with any security model which attempts to preclude keylogging.

      You don't have to be a programmer to want functionality that depends on monkey-patching under the hood.

      Comment


      • #23
        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


        • #24
          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


          • #25
            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; 01-04-2020, 10:43 AM.

            Comment


            • #26
              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; 01-04-2020, 11:28 AM.

              Comment


              • #27
                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


                • #28
                  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


                  • #29
                    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


                    • #30
                      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

                      Working...
                      X