No announcement yet.

X.Org Server Development Hits A Nearly Two Decade Low

  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by brent View Post

    Sorry, I still can't figure that out. Until recently, GNOME w/ Wayland was so buggy, slow and feature-lacking that I can only imagine you must have seriously low expectations. I gave it a try for several Fedora versions and always had to revert to Xorg due to serious issues. For example, it wasn't that long ago that the clipboard was basically completely broken (no interop between X and Wayland apps), and mouse cursor stutters and freezes seriously impacted normal use (and that's not solved yet, it just got "good enough" in most cases).

    Even now with the latest GNOME patch release, I've experienced crashes on display hotplug, so stability isn't that great either. And if I enable fractional scaling (one of the features where Wayland actually has an advantage), I get reproducible crashes.

    And my hardware? It's just a standard Intel integrated GPU, so it should be well-supported.
    Yeah and the mouse stuttering will never get fixed an any DE. Wayland can only report where the mouse is, but has no means of synchronizing output on input. The protocol just doesn't do it. Its scope is too narrow.


    • #62
      Originally posted by betam4x View Post

      At any rate, Xorg could use quite a few improvements. Honestly, they should stop treating it like a dead platform and actually focus on evolving things. Many of the improvements in Wayland could be implemented evolutionary style in Xorg.
      I imagine we will end up with something like this. X11 will just use Wayland as the underlying implementation instead of the dark murky underlying Xorg implementation.

      In fact, since Wayland is not network aware (by design), this is pretty much guaranteed.
      Wayland honestly just feels like a backend refresh for Xorg. (Which I do appreciate!)

      For example, you could write an Xorg graphical program that doesn't use libx11 or libxcb; just the underlying primitives (and not over the network). Yes, it would be completely unportable and pointless. However this is kind of like what Wayland development is like now.
      Last edited by kpedersen; 01-05-2020, 08:10 AM.


      • #63
        Nowadays is deprecated but the majority of linux operating systems still stuck over this aged graphical apis.


        • #64
          Originally posted by set135 View Post

          I might be wrong, but I suspect what ssokolow is upset about, is that the means by which he creates some value-add software may be obsoleted, thus threatening his profit model. This is a valid reason to be unhappy, but not necessarily an argument against Wayland.
          QuickTile is open-source freeware that I wrote to scratch my own itch, always has been, and always will be. My only incentive to continue developing it is that I use it myself. I mentioned it because it just also happens to be the self-itch-scratch tool that grabbed the most interest from other people.

          Heck, I have so little incentive to keep working on it that I only finally found time to port it to Python 3.x and GTK+ 3.x (because Qt apparently has no libwnck equivalent) only a week ago, and that's still in "public alpha" state while I find time to go back and finish fixing some features I had to defer porting, such as automatically adapting to resolution changing.

          My issue with Wayland is ideological. The greatest strength of Unixy operating systems has always been their adaptability to change via developers hacking on experimental new features to scratch their own itches.

          (i.e. UNIX and then Linux beat out other OSes over the years because of "survival of the fittest", which Darwin really should have named "survival of the most adaptable" since it's "fitness for an unexpected new norm" that he was talking about.)

          If the X developers who became Wayland developers want to throw out the analogue to Firefox's legacy plugin non-API, they need to provide an equivalent to WebExtensions and engage in active and concerted shaming of any compositor which doesn't implement it. Otherwise, they endanger the long-term viability of the ecosystem itself.


          • #65
            Originally posted by betam4x View Post

            Input macros implemented properly shouldn't require monkey patching. Key-logging is only an issue on various systems due to the ability for an app to listen to keyboard events outside it's own scope. While one can argue that this may be useful in some scenarios, a secure system would not allow this. Just like a secure clipboard implementation would not allow applications to peak at the clipboard.
            What do you call intercepting keypresses destined for other applications and inserting new ones? Call it macros or keylogging and exfiltrating the data using the clipboard and running curl in the Run dialog, the security model can't tell the difference and that kind of event interception sure feels like monkey-patching to me.
            Last edited by ssokolow; 01-05-2020, 09:10 AM.


            • #66
              Originally posted by kpedersen View Post

              Not if you install via the CD that comes with Xfce.

              Basically it only comes with Gnome. If you install Gnome; you get Wayland. If you install anything else; you don't.
              The default desktop, of the default installer uses wayland by default


              • #67
                Bigon Confirmed.

                GNOME is default.
                Wayland is default.

                Like the Redhat distributions.


                • #68
                  ssokolow The NIHed compositors have been warned. You can’t stop them getting a rope and tie a noose..


                  • #69
                    Originally posted by 144Hz View Post
                    ssokolow The NIHed compositors have been warned. You can’t stop them getting a rope and tie a noose..
                    I just hope Redhad doesn't bring the whole ecosystem down by throwing all their eggs in the NIHed compositor's basket.

                    GNOME is a project founded on NIHing KDE. (Originally on Qt license zealotry, later mixing in anti-C++ zealotry based mostly in now-obsolete complaints about GCC's implementation of it, then on crashy-for-far-too-long reinventions of things like KIOSlaves (GnomeVFS) and retired attempts to replicate things like KParts.)

                    It's fundamentally a "haters desktop" (the link talks about the problems in TDE's approach to forking KDE 3.5. I'm reminded of previous Phoronix coverage of Devuan.) with all the associated downsides of duplicated work and a higher chance of being unwilling to cooperate in situations where it would benefit everyone.

                    I'm just glad that they agreed to retire their use of CORBA in favour of D-Bus (a cooperatively designed successor to KDE's DCOP) and managed to cook up something truly worthwhile in the GObject Introspection (GIR) system.

                    (I'll readily admit that GIR is something GNOME beat KDE to, which the Qt company should either use or NIH as long as they do something to catch up to GNOME on that front with the QWidget APIs.)
                    Last edited by ssokolow; 01-05-2020, 12:37 PM.


                    • #70
                      ssokolow Qt license problem exist today. CLA is a no-go. There’s no NIH just a sane approach to deal with license trolls.

                      Avoid, avoid, avoid.