Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active June 9, 2024 02:52
Show Gist options
  • Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Download ZIP
Think twice about Wayland. It breaks everything!
Raw
Wayland.md

Think twice before abandoning Xorg. Wayland breaks everything!

Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.

Wayland proponents make it seem like Wayland is "the successor" of Xorg, when in fact it is not. It is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incomprehensible words like "xdg_toplevel" instead).

DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Please add more examples to the list.

Wayland seems to be made by people who do not care for existing software. They assume everyone is happy to either rewrite everything or to just use Gnome on Linux (rather than, say, twm with ROX Filer on NetBSD).

Edit: When I wrote the above, I didn't really realize what Wayland even was, I just noticed that some distributions (like Fedora) started pushing it onto me and things didn't work properly there. Today I realize that you can't "install Wayland", because unlike Xorg, there is not one "Wayland display server" but actually every desktop envrironment has its own. And maybe "the Wayland folks" don't "only care about Gnome", but then, any fix that is done in Gnome's Wayland implementation isn't automatically going to benefit all users of Wayland-based software, and possibly isn't even the implementation "the Wayland folks" would necessarily recommend.

Edit 12/2023: If something wants to replace X11 for desktop computers (such as professional Unix workstations), then it better support all needed features (and key concepts, like windows) for that use case. That people also have displays on their fridge doesn't matter the least bit in that context of discussion. Let's propose the missing Wayland protocols for full X11 feature parity.

Wayland is broken by design

  • A crash in the window manager takes down all running applications
  • You cannot run applications as root
  • You cannot do a lot of things that you can do in Xorg by design
  • There is not one /usr/bin/wayland display server application that is desktop environment agnostic and is used by everyone (unlike with Xorg)
  • It offloads a lot of work to each and every window manager. As a result, the same basic features get implemented differently in different window managers, with different behaviors and bugs - so what works on desktop environment A does not necessarily work in desktop environment B (e.g., often you hear that something "works in Wayland", even though it only really works on Gnome and KDE, not in all Wayland implementations). This summarizes it very well: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Apparently the Wayland project doesn't even want to be "X.org 2.0", and doesn't want to provide a commonly used implementation of a compositor that could be used by everyone: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233. Yet this would imho be required if they want to make it into a worthwile "successor" that would have any chance of ever fixing the many Wayland issues at the core.

Wayland breaks screen recording applications

  • MaartenBaert/ssr#431 ❌ broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
  • https://github.com/mhsabbagh/green-recorder ❌ ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
  • vkohaupt/vokoscreenNG#51 ❌ broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
  • obsproject/obs-studio#2471 ❌ broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
  • There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)
  • phw/peek#1191 ❌ broken since 14 Jan 2023. Peek, a screen recording tool, has been abandoned by its developerdue to a number of technical challenges, mostly with Gtk and Wayland ("Many of these have to do with how Wayland changed the way applications are being handled")

As of February 2024, screen recording is still broken utterly on Wayland with the vast majority of tools. Proof

Workaround: Find a Wayland compositor that supports the wlr-screencopy-unstable-v1 protocol and use wf-recorder -a. The default compositor in Raspberry Pi OS (Wayfire) does, but the default compositor in Ubuntu doesn't. (That's the worst part of Wayland: Unlike with Xorg, it always depends on the particular Wayand compositor what works and what is broken. Is there even one that supports everything?)

Wayland breaks screen sharing applications

  • jitsi/jitsi-meet#2350 ❌ broken since 3 Jan 2018
  • jitsi/jitsi-meet#6389 ❌ broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted.

NOTE: As of November 2023, screen sharing in Chromium using Jitsi Meet is still utterly broken, both in Raspberry Pi OS Desktop, and in a KDE Plasma installation, albeit with different behavior. Note that Pipewire, Portals and whatnot are installed, and even with them it does not work.

Wayland breaks automation software

sudo pkg install py37-autokey

This is an X11 application, and as such will not function 100% on 
distributions that default to using Wayland instead of Xorg.

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

Wayland broke global menus with KDE platformplugin

Good news: According to this report global menus now work with KDE platformplugin as of 4/2022

Wayland breaks global menus with non-KDE Qt platformplugins

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

  • https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ ❌ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

Update 2023: Some Wayland compositors (such as Wayfire) now support wlr_gamma_control_unstable_v1, see https://github.com/WayfireWM/wayfire/wiki/Tutorial#configuring-wayfire and jonls/redshift#663. Does it work in all Wayland compositors though?

Wayland breaks global hotkeys

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

Apparently Wayland relies on nouveau drivers for NVidia hardware. The nouveau driver has been giving unsatisfactory performance since its inception. Even clicking on the application starter icon in Gnome results in a stuttery animation. Only the proprietary NVidia driver results in full performance.

See below.

Update 2024: The situation might slowly be improving. It remains to be seen whether this will work well also for all existing old Nvidia hardware (that works well in Xorg).

Wayland does not work properly on Intel hardware

Wayland prevents GUI applications from running as root

  • https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)

Suggested solution

Wayland is biased toward Linux and breaks BSD

  • https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."

Wayland complicates server-side window decorations

  • https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ ❌ FUD since at least 27 January 2018 ("I heard that GNOME is currently trying to lobby for all applications implementing client-side decorations. One of the arguments seems to be that CSD is a must on Wayland. " ... "I’m burnt from it and are not interested in it any more.") Server-side window decorations are what make the title bar and buttons of all windows on a system consistent. They are a must have_ for a consistent system, so that applications written e.g., Gtk will not look entirely alien on e.g., a Qt based desktop, and to enforce that developers cannot place random controls into window titles where they do not belong. Client-side decorations, on the other hand, are destroying uniformity and consistency, put additional burden on application and toolkit developers, and allow e.g., GNOME developers to put random controls (that do not belong there) into window titles (like buttons), hence making it more difficult to achieve a uniform look and feel for all applications regardless of the toolkit being used.

Red Hat employee Matthias Clasen ("I work at the Red Hat Desktop team... I am actually a manager there... the people who do the actual work work for me") expicitly stated "Client-side everything" as a principle, even though the protocol doesn't enforce it: "Fonts, Rendering, Nested Windows, Decorations. "It also gives the design more freedom to use the titlebar space, which is something our designers appreciate" (sic). Source

Wayland breaks windows rasing/activating themselves

Wayland breaks RescueTime

Wayland breaks window managers

Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.

Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like functionality

  • Screen recording and casting
  • Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool, wmctrl)
  • Global shortcuts
  • System tray
  • Input Method support/editor (IME)
  • Graphical settings management (i.e. tools like xranrd)
  • Fast user switching/multiple graphical sessions
  • Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
  • HDR/deep color support
  • VRR (variable refresh rate)
  • Disabling input devices (xinput alternative)

As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You do not expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.

Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol

  • https://github.comelectron/electron#33226 ("skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland." Workarounds are only available for some desktops including GNOME and KDE Plasma.) ❌ broken since March 10, 2022

Wayland breaks NoMachine NX

Wayland breaks xclip

xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections ("the clipboard"). Apparently Wayland isn't compatible to the X11 clipboard either.

This is another example that the Wayland requires everyone to change components and take on additional work just because Wayland is incompatible to what we had working for all those years.

Wayland breaks SUDO_ASKPASS

Wayland breaks X11 atoms

X11 atoms can be used to store information on windows. For example, a file manager might store the path that the window represents in an X11 atom, so that it (and other applications) can know for which paths there are open file manager windows. Wayland is not compatible to X11 atoms, resulting in all software that relies on them to be broken until specifically ported to Wayland (which, in the case of legacy software, may well be never).

Possible workaround (to be verified): Use the (Qt proprietary?) Extended Surface Wayland protocol casually mentioned in https://blog.broulik.de/2016/10/global-menus-returning/ "which allows you to set (and read?) arbitrary properties on a window". Is it the set_generic_property from https://github.com/qt/qtwayland/blob/dev/src/extensions/surface-extension.xml?

Wayland breaks games

Games are developed for X11. And if you run a game on Wayland, performance is subpar due to things like forced vsync. Only recently, some Wayland implementations (like KDE KWin) let you disable that.

Wayland breaks xdotool

(Details to be added; apparently no 1:1 drop-in replacement available?)

Wayland breaks xkill

xkill (which I use on a regular basis) does not work with Wayland applications.

What is the equivalent for Wayland applications?

Wayland breaks screensavers

Is it true that Wayland also breaks screensavers? https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/

Wayland breaks setting the window position

Other platforms (Windows, Mac, other destop environments) can set the window position on the screen, so all cross-platform toolkits and applications expect to do the same on Wayland, but Wayland can't (doesn't want to) do it.

  • PCSX2/pcsx2#10179 PCX2 (Playstation 2 Emulator) ❌ broken since 2023-10-25 ("Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.")

Wayland breaks color mangement

Apparently color management as of 2023 (well over a decade of Wayland development) is still in the early "thinking" stage, all the while Wayland is already being pushed on people as if it was a "X11 successor".

https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md

Wayland breaks DRM leasing

According to Valve, "DRM leasing is the process which allows SteamVR to take control of your VR headset's display in order to present low-latency VR content".

Wayland breaks In-home Streaming

Wayland breaks NetWM

Extended Window Manager Hints, a.k.a. NetWM, is an X Window System standard for the communication between window managers and applications

Wayland breaks window icons

Wayland breaks drag and drop

Workarounds

  • Users: Refuse to use Wayland sessions. Uninstall desktop environments/Linux distributions that only ship Wayland sessions. Avoid Wayland-only applications (such as PreSonus Studio One) (potential workaround: run in https://github.com/cage-kiosk/cage)
  • Application developers: Enforce running applications on X11/XWayland (like LibrePCB does as of 11/2023)

Examples of Wayland being forced on users

This is exactly the kind of behavior this gist seeks to prevent.

History

  • 2008: Wayland was started by krh (while at Red Hat)
  • End of 2012: Wayland 1.0
  • Early 2013: GNOME begins Wayland porting

Source: "Where's Wayland?" by Matthias Clasen - Flock 2014

A decade later... Red Hat wants to force Wayland upon everyone, removing support for Xorg

References

@ctrlcctrlv
Copy link

Good catch, I forgot to attach util.py, but you'll be glad to know it does:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

# getgist utilities

import os
import sys
import warnings
from pathlib import Path

def eprint(*args, **kwargs):
    print(*args, file=sys.stderr, **kwargs)

def get_github_token_from_env_file_if_exists():
    env_file = Path('.env')
    if env_file.exists():
        with env_file.open() as f:
            for line in f:
                key, value = line.strip().split('=', 1)
                if key == 'GITHUB_TOKEN':
                    os.environ['GITHUB_TOKEN'] = value
                else:
                    warnings.warn('Unknown key in .env file: {}'.format(key))
    return None

@fredvs
Copy link

fredvs commented May 17, 2024 •
edited

Okay, okay, got it, Wayland matters and we widget developers need to adapt.
From our side, a "pure Wayland with wlroots" target is on the way, but moving from Form X11 to Wayland is not "out of the box" and will take time.

So, one of our solutions to become "pure Wayland" would be to use SDL (we already have this target working):
https://jan.newmarch.name/Wayland/SDL/

What do you think about SDL-Wayland, does it work well and can it be called a “pure Wayland” application?

@ctrlcctrlv
Copy link

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.

Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

@binex-dsk
Copy link

Come on, you have to know what's inferior by now :p Why are you typing that from W11 and not W10 LTSC?

Why would you not use Spectre if you're using Windows?

@dm17
Copy link

dm17 commented May 19, 2024

Nice job @ctrlcctrlv! Would you mind asking it what it thinks a reasonable amount of years to catch up would be? Or if there should be a cut off or due date before another option is considered?

@guiodic
Copy link

guiodic commented May 20, 2024

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.

Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

today Xorg uses a generic driver called "modesetting" that works in a similar way to Wayland, using kms/drm kernel infrastructure. So it is unlikely that in the foreseeable future there will be any boards that do not work at all on Xorg. However, it is possible that in the very distant future some proprietary drivers will be discontinued (Nvidia)

@anoraktrend
Copy link

2024-05-19T13:48:11,890734833-07:00
a fun screenshot for people to see something fun.

@anoraktrend
Copy link

probono doesn't update the OP so this is just an image i think is pretty good, I can do this again with a freebsd desktop in a couple years (because freebsd doesn't have good modesetting support for dg2).

@AndreiSva
Copy link

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.

Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

I think a bigger problem for you at that point is going to be finding X11 windows managers that are still maintained and that work on modern linux.

@probonopd
Copy link
Author

probonopd commented May 30, 2024 •
edited

As long as Linus Torvalds manages Linux, "modern Linux" shall not break userland (source). So existing userland software should continue to run on newer versions of the Linux kernel pretty much indefinitely. Many X11 window managers are mature by now, can be used as-is and are pretty much maintenance-free (read: ideal) nowadays. No need to fix what is not broken.

@bodqhrohro
Copy link

https://www.linux.org.ru/news/opensource/17630584?cid=17633042

TL;DR: IPv6 is like Wayland, just 15 years older. It's 30 years old soon, and half of the planet still ignores it.

@bodqhrohro
Copy link

I think a bigger problem for you at that point is going to be finding X11 windows managers that are still maintained and that work on modern linux.

Compiz is long abandoned, yet I'm still using it somehow. How?

Things don't magically break if you don't touch them.

@bodqhrohro
Copy link

today Xorg uses a generic driver called "modesetting" that works in a similar way to Wayland, using kms/drm kernel infrastructure. So it is unlikely that in the foreseeable future there will be any boards that do not work at all on Xorg. However, it is possible that in the very distant future some proprietary drivers will be discontinued (Nvidia)

Then why the Macbook video driver in Asahi Linux only supports Wayland?

@hendrack
Copy link

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.
Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

I think a bigger problem for you at that point is going to be finding X11 windows managers that are still maintained and that work on modern linux.

Like IceWM, for example?

@zDEFz
Copy link

zDEFz commented May 31, 2024

today Xorg uses a generic driver called "modesetting" that works in a similar way to Wayland, using kms/drm kernel infrastructure. So it is unlikely that in the foreseeable future there will be any boards that do not work at all on Xorg. However, it is possible that in the very distant future some proprietary drivers will be discontinued (Nvidia)

Then why the Macbook video driver in Asahi Linux only supports Wayland?

The Software Rendering was faster on Asahi running xorg.
With the GPU driver, they went to use Wayland and found that faster.

@birdie-github
Copy link

Has this been posted in this thread? Sorry, it if has been:

123

@Monsterovich
Copy link

Has this been posted in this thread? Sorry, it if has been:

@birdie-github I already posted it, but thanks for saving the picture because the author on reddit deleted it.

@Consolatis
Copy link

Missing clipboard API over dbus. What is that nonsense?

@AndreiSva
Copy link

As long as Linus Torvalds manages Linux, "modern Linux" shall not break userland (source). So existing userland software should continue to run on newer versions of the Linux kernel pretty much indefinitely. Many X11 window managers are mature by now, can be used as-is and are pretty much maintenance-free (read: ideal) nowadays. No need to fix what is not broken.

Yes, however glibc does not keep that promise. In fact it changes its ABI fairly often.

@fredvs
Copy link

fredvs commented May 31, 2024

Yes, however glibc does not keep that promise. In fact it changes its ABI fairly often.

No, it is because some devs use glibc the wrong way. If you use the great feature of symbol versioning for each method called, the compatibility is maintained, even if your code uses the old GLIBC_2.2.5 symbol table.

@dm17
Copy link

dm17 commented May 31, 2024

And just like Wayland, it's technically better in every way, and it is steadily gaining adoption

Not a fair comparison at all. You'd have to find equivalent criticisms of ipv6. I don't see anything technically wrong with it. The fact that it wasn't so quickly and completely replacing ipv4 is not due to issues with ipv6. However, the primary reason Wayland hasn't wiped the floor with xorg is that it isn't so great technically. It is inferior in ways and not superior enough where it counts. We've been over this ad nasueum in this thread, but I wanted to point out the apples to oranges comparison.

@fredvs
Copy link

fredvs commented May 31, 2024 •
edited

Maybe if all the developers here who are crying about Wayland's problems (I'm one of them) decided NOW to target X12 (of course backward compatible with X11), X12 would work before all of Wayland's problems are fixed.
And given the remarkable work of XWayland, I'm sure it would be possible to create a "new X11" with the absolutely necessary new features of Wayland (if there are any).

@Consolatis
Copy link

Consolatis commented Jun 1, 2024 •
edited

That sounds like a great idea. Suggest opening a MR over at https://gitlab.freedesktop.org/xorg/proto/xorgproto and https://gitlab.freedesktop.org/xorg/xserver. Also maybe for GTK, Qt, SDL and other GUI frameworks. Should not take longer than a week to get everything designed, written and merged.

@bodqhrohro
Copy link

I don't see anything technically wrong with it

Wayland inventors don't see anything technically wrong with it too. The problem is with adapting it to reality rather than to isolated fantasies of idealists.

From the same thread: https://apenwarr.ca/log/20170810

@fredvs
Copy link

fredvs commented Jun 1, 2024 •
edited

That sounds like a great idea. Suggest opening a MR over at https://gitlab.freedesktop.org/xorg/proto/xorgproto and https://gitlab.freedesktop.org/xorg/xserver. Also maybe for GTK, Qt, SDL and other GUI frameworks. Should not take longer than a week to get everything designed, written and merged.

If you are talking about X12 (with the few absolutely necessary new features of Wayland), the adaptation for GUI widgetsets X11 compatible will be a funny game. Of course if the spirit of X11 is maintained (like atoms, ... etc).

And it would also be good, before asking something from the X11 developers, to discuss here what would be absolutely necessary to add in the new X12 version.

And a fantastic project like wine, which managed to create a Windows emulator that works even better than all official Windows versions (thanks to X11), could retain this status (which it lost with the wayland-wine version).
The same for XQuartz for Mac.

@hendrack
Copy link

hendrack commented Jun 1, 2024

You know, there is still Arcan. I bet they would appreciate some manpower and resources.

@fredvs
Copy link

fredvs commented Jun 1, 2024 •
edited

You know, there is still Arcan. I bet they would appreciate some manpower and resources.

Does Arcan have an out of the box solution for GUI widget sets containing code for X11 or do they all need to be rewritten like when using Wayland?
The huge advantage of an X12 version compatible with X11 is that the immense stock of application code using X11 would not be lost.

@binex-dsk
Copy link

And a fantastic project like wine, which managed to create a Windows emulator that works even better than all official Windows versions (thanks to X11), could retain this status (which it lost with the wayland-wine version).

Wine can run ~40% of windows applications I've tried on Wayland. Wine can run the exact same amount of Windows applications, if not a bit less, on X11.

@fredvs
Copy link

fredvs commented Jun 1, 2024 •
edited

Wine can run ~40% of windows applications I've tried on Wayland. Wine can run the exact same amount of Windows applications, if not a bit less, on X11.

By default, Wine runs on Wayland through Xwayland, are you sure you used the native wine-Wayland driver?

And about your ~40%, maybe, but here on X11 100% of the Windows apps that I need are working (an only 10% with wine-Wayland driver) .

@binex-dsk
Copy link

Yes, I was running wine-wayland

@fredvs
Copy link

fredvs commented Jun 1, 2024

Now that Wayland is on multiple distributions and tested, what Wayland features should definitely be added for a possible X12?
It might be interesting if we shared our hopes here.

@alfredon996
Copy link

alfredon996 commented Jun 1, 2024 •
edited

Has this been posted in this thread? Sorry, it if has been:

123

This image makes no sense. Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box? Furthermore, XWayland is only needed for X11 compatibility, if it is present in the Wayland diagram, equivalently something for Wayland compatibility should be present in Xorg

@Sivecano
Copy link

Sivecano commented Jun 2, 2024

This image makes no sense. Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box? Furthermore, XWayland is only needed for X11 compatibility, if it is present in the Wayland diagram, equivalently something for Wayland compatibility should be present in Xorg

I also think it's strange that compositors and window managers are not properly distinguished. these are often split and different.
(X11 compositors are also a god-damn terrible thing since they can break rendering in ways which (unlike with wayland where expectations are clear) are not properly communicated (if anyone disagrees then I'd be happy if you could help me set a wallpaper in a way that makes picom render it correctly))

@fredvs
Copy link

fredvs commented Jun 2, 2024 •
edited

This image makes no sense. Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box? Furthermore, XWayland is only needed for X11 compatibility, if it is present in the Wayland diagram, equivalently something for Wayland compatibility should be present in Xorg

I also think it's strange that compositors and window managers are not properly distinguished. these are often split and different. (X11 compositors are also a god-damn terrible thing since they can break rendering in ways which (unlike with wayland where expectations are clear) are not properly communicated (if anyone disagrees then I'd be happy if you could help me set a wallpaper in a way that makes picom render it correctly))

I admit that all this is still obscure.

If you are creating an X11 GUI application, after compilation you need to link to 'libX11.so.6' and maybe the most used dependencies 'libXft.so', 'libXrender.so', ...
And your application will work regardless of which compositor/window manager you use.

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

That's what I understood.

@probonopd
Copy link
Author

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

The way I understand it:

You can write a GUI application for Wayland and it should run on all Wayland compositors, but since not all compositors support all features, functionality may be broken in different ways on each of them.

@fredvs
Copy link

fredvs commented Jun 2, 2024 •
edited

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

The way I understand it:

You can write a GUI application for Wayland and it should run on all Wayland compositors, but since not all compositors support all features, functionality may be broken in different ways on each of them.

So, I haven't yet figured out how to create a compositor-agnostic Wayland GUI app.

@alfredon996
Copy link

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

The way I understand it:
You can write a GUI application for Wayland and it should run on all Wayland compositors, but since not all compositors support all features, functionality may be broken in different ways on each of them.

So, I haven't yet figured out how to create a compositor-agnostic Wayland GUI app.

If you are using only stable protocols, it should work in all compositors

@bodqhrohro
Copy link

@alfredon996

Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box?

Because an X11 window manager is totally optional software (as I demonstrated above by writing a simple X11 client which is capable of changing its window geometry itself with no running WM).

With Wayland it's totally not the case, you cannot run some ordinary "Wayland" software (if you don't consider Weston as such). You have to run some compositor, and all compositors provide significantly different flavours of "Wayland".

@bodqhrohro
Copy link

If you are using only stable protocols, it should work in all compositors

Useless suggestion. In case of tachycardia, cut the heart out and use only stable organs?

@bodqhrohro
Copy link

Oh, and I didn't even start the topic of incompatible blood types. How do I write generic blood which works for all blood types and Rh factors, and for minor cases of angitens incompatibility as well, like Kell, Kidd, Duffy, MNSs, etc.?

@binex-dsk
Copy link

binex-dsk commented Jun 3, 2024 •
edited

With Wayland it's totally not the case, you cannot run some ordinary "Wayland" software (if you don't consider Weston as such). You have to run some compositor, and all compositors provide significantly different flavours of "Wayland".

You can run ordinary "wayland" software. The window can composite itself over DRM with minimal LOC.

@birdie-github
Copy link

You can run ordinary "wayland" software. The window can composite itself over DRM with minimal LOC.

You seriously believe a single Wayland app will ever do that? Why? LMAO, what a joke.

@binex-dsk
Copy link

binex-dsk commented Jun 4, 2024 •
edited

I don't recall any widespread apps designed to work like that but is so low-overhead that you could probably slap it onto any application you wanted.

I don't recall any X11 apps that were meant to run without a window manager either. In the end, you actually end up with less overhead on Wayland thanks to everything talking client->compositor->DRM, not client->compositor(optional) -> WM -> server -> DRM

Though, this is perhaps an unfair comparison since an X11 compositor and a Wayland compositor are fundamentally dissimilar concepts.

@fredvs
Copy link

fredvs commented Jun 4, 2024 •
edited

I don't recall any X11 apps that were meant to run without a window manager either. In the end, you actually end up with less overhead on Wayland thanks to everything talking client->compositor->DRM, not client->compositor(optional) -> WM -> server -> DRM

The point is that when developing an X11 application, you don't have to worry about which window manager will be used.
But yes, the X11 application will of course work with a window manager (if installed).

To summarize, Wayland certainly has many qualities but, instead of doing everything to attract developers, everything seems to be done to discourage them, obsolete docs and demos, war of compositors, ...

And like it or not, the end developers of the applications that will run on Wayland are the key to Wayland's possible success.

Or perhaps Wayland's policy is "only for applications made by tenors, who of course do not forget to give alms".

@Consolatis
Copy link

Lets face it though, if you use GTK or Qt your application just magically works fine on wayland. Unless you used X11 specific functions manually instead of via the toolkit wrapper. Also, frameworks have a bunch of X11 WM workarounds in place. Just because you don't see them when writing your application doesn't mean that all WMs behave the same way.

@fredvs
Copy link

fredvs commented Jun 4, 2024

Lets face it though, if you use GTK or Qt your application just magically works fine on wayland.

Yes, thank you, I know that.
The problem is that I don't want to use GTK or QT, all my apps use another widgetset that don't have the tons of bugs of those big Tenors.
And making that other widgetset Wayland-compatible is just boring, tedious, unappealing and ultimately only focused on Linux (while destroying its philosophy).

@Consolatis
Copy link

Consolatis commented Jun 4, 2024 •
edited

Why is it only focused on Linux? FreeBSD for example works fine (at least for wlroots based compositors). And the philosophy of X11 protos vs wayland protos is really the same. Both have a required core and lots of optional extensions.

@Monsterovich
Copy link

Monsterovich commented Jun 4, 2024 •
edited

@Consolatis

And the philosophy of X11 protos vs wayland protos is really the same. Both have a required core and lots of optional extensions.

No. Wayland doesn't have any "core" because there is no unified server. Nobody cares that there is some "core" specification. This core specification without implementation is nothing. Moreover, this core specification is obviously insufficient.

Wayland's philosophy is very simple - “we'll write an incompatible server for our DE from scratch, now do the same to compete with us, let's see if you have the enough resources”. The architecture based on this philosophy is inherently flawed.

If you want to stay sane, don't play this game.

The Wayland inventors don't care that users and the entire ecosystem will suffer. All for the sake of Wayland cargo cult.

@fredvs
Copy link

fredvs commented Jun 4, 2024

Why is it only focused on Linux? FreeBSD for example works fine (at least for wlroots based compositors). And the philosophy of X11 protos vs wayland protos is really the same. Both have a required core and lots of optional extensions.

OK, so I'm going to ask you again because you're a connoisseur of Wayland.
Could you please show the code for a simple, fully functional demo using a wlroots compositor, out-of-the-box, ready to use and not obsolete?

Tip: If you can't find one, here are the working codes for all chapters in the Wayland-book: https://wayland-book.com/

Original C++ code (updated and fixed):
https://github.com/fredvs/wayland-pascal/tree/main/src/c

Translated Pascal code:
https://github.com/fredvs/wayland-pascal/tree/main/src

Like in the Wayland-book, the last chapter is how to use the compositor and is on the "TODO" world.

Many thanks.

@binex-dsk
Copy link

The problem is that I don't want to use GTK or QT, all my apps use another widgetset that don't have the tons of bugs of those big Tenors.

The "bugs" you're facing are caused more so by your incompetence, because I've never seen any show-stopping bugs that don't get fixed by a single extra LOC.

@fredvs
Copy link

fredvs commented Jun 4, 2024

The problem is that I don't want to use GTK or QT, all my apps use another widgetset that don't have the tons of bugs of those big Tenors.

The "bugs" you're facing are caused more so by your incompetence

Thanks for the interesting tip.

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

But that's another story, let's talk about Wayland and its open doors.

@Consolatis
Copy link

Consolatis commented Jun 4, 2024 •
edited

Could you please show the code for a simple, fully functional demo using a wlroots compositor, out-of-the-box, ready to use and not obsolete?

https://github.com/emersion/hello-wayland could be an example. Took me like 2 minutes to find, compile and test.

Wayland doesn't have any "core" because there is no unified server. Nobody cares that there is some "core" specification. This core specification without implementation is nothing.

Some parts of the core (e.g. what is defined in libwayland via wayland.xml) + xdg-shell (from wayland-protocols) should be enough for a basic application (also used by ^). For sane compositors (e.g. basically everything other than gnome) I would also add the decoration protocol so you have some proper server side decorations.

@binex-dsk
Copy link

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

@zarlo
Copy link

zarlo commented Jun 5, 2024

@Monsterovich

No. Wayland doesn't have any "core" because there is no unified server.

that's like saying there is no core of http as there is no unified server.

@fredvs
Copy link

fredvs commented Jun 5, 2024 •
edited

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

Yes, you already said it, it's because of my incompetence.
And it's because of this that some of my old applications written for Qt4 (what a bad idea I had) force users to tinker with their system because the qt4/libqt4-* dependencies are removed in last distros.
Of course you will tell me that with 4 lines in the console, forcing the user to add the PPA repository, it will work.

With my "other widgetset" this won't happen.

In fact, my view of open source and out-of-the-box applications is inconsistent with the Wayland philosophy.

So, I apologize for the noise and good luck in your closed world of Wayland and friends.

@zDEFz
Copy link

zDEFz commented Jun 5, 2024

So, I apologize for the noise and good luck in your closed world of Wayland and friends.

I don't like Wayland either. But either way, it seems to be a accumulated issue...

@Monsterovich
Copy link

@zarlo

@Monsterovich

No. Wayland doesn't have any "core" because there is no unified server.

that's like saying there is no core of http as there is no unified server.

These are incomparable things. A graphical server is many times more complicated than any web server. Isn't that obvious?
Even more so, applications depend on the approach to implementing things in that server.

@binex-dsk
Copy link

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

Yes, you already said it, it's because of my incompetence. And it's because of this that some of my old applications written for Qt4 (what a bad idea I had) force users to tinker with their system because the qt4/libqt4-* dependencies are removed in last distros. Of course you will tell me that with 4 lines in the console, forcing the user to add the PPA repository, it will work.

With my "other widgetset" this won't happen.

In fact, my view of open source and out-of-the-box applications is inconsistent with the Wayland philosophy.

So, I apologize for the noise and good luck in your closed world of Wayland and friends.

Again, you can port a Qt 4 app to Qt 5 with minimal effort, and don't have to rely on some library that 4 other people use and you have to add 4 PPAs or compile 13 6000-file dependencies from the AUR or GURU.

@fredvs
Copy link

fredvs commented Jun 5, 2024 •
edited

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

Yes, you already said it, it's because of my incompetence. And it's because of this that some of my old applications written for Qt4 (what a bad idea I had) force users to tinker with their system because the qt4/libqt4-* dependencies are removed in last distros. Of course you will tell me that with 4 lines in the console, forcing the user to add the PPA repository, it will work.
With my "other widgetset" this won't happen.
In fact, my view of open source and out-of-the-box applications is inconsistent with the Wayland philosophy.
So, I apologize for the noise and good luck in your closed world of Wayland and friends.

Again, you can port a Qt 4 app to Qt 5 with minimal effort, and don't have to rely on some library that 4 other people use and you have to add 4 PPAs or compile 13 6000-file dependencies from the AUR or GURU.

Maybe you didn't understand it.
Once an application is "published", only the application binary is made public.
And if this application, when compiled, was linked to some qt4 libraries, these libraries are necessary to run the release binary.

Of course I can port the application to Qt x, but then I have to provide 2 different binary versions.

To get in the "Linux" mood, Qt and GTK should take a look at how glibc did with its signed symbol table for each method.
This way only one libc.so is used with multiple symbol tables to always ensure backward compatibilities.

@Consolatis
Copy link

Once an application is "published", only the application binary is made public.

I seriously hope you are complying with the respective licences of those libraries.

@fredvs
Copy link

fredvs commented Jun 5, 2024 •
edited

Once an application is "published", only the application binary is made public.

I seriously hope you are complying with the respective licences of those libraries.

Yes, of course, there is always a readme.txt and a license.txt and for open source projects there is a link to the source and contributors in the reame.txt and brush my teeth every morning.

But now that I'm using another widgetset with root code that only needs to link libx11.so, I'm no longer bothered by forgetting to add a license and being afraid of possible incompatibilities/outdated dependencies on the end-user system.

@binex-dsk
Copy link

...until that widgetset gets an update that introduces incompatibilities. Software evolves. If you don't want to worry about widgetset incompatibilities, you're free to use GTK1 and Qt 1.45. This is a completely invalid complaint, because supporting Qt 5 and Qt 6 at the same time is minimal effort--4 LOC and a flag in your make system.

Maybe you didn't understand it.
Once an application is "published", only the application binary is made public.
And if this application, when compiled, was linked to some qt4 libraries, these libraries are necessary to run the release binary.

Then update it to support Qt 5 or 6. Unless you're releasing proprietary crapware, in which case we have no room to continue this discussion. Distros don't even offer Qt 4 anymore, so forcing users to find some outdated Qt 4 overlay or PPA is anti-user. What's even worse is forcing them to install a widget library that likely doesn't even exist in GURU, honestly.

@fredvs
Copy link

fredvs commented Jun 6, 2024 •
edited

...until that widgetset gets an update that introduces incompatibilities.

That widgetset dont need dependencies (apart libx11.so) because his code is compiled with the application.
And one of his priority is to always be compatible with previous version.

f you don't want to worry about widgetset incompatibilities, you're free to use GTK1 and Qt 1.45. This is a completely invalid complaint, because supporting Qt 5 and Qt 6 at the same time is minimal effort--4 LOC and a flag in your make system.
Then update it to support Qt 5 or 6.
Distros don't even offer Qt 4 anymore

I think I've already explained that I don't use GTK or Qt for several reasons, why do you insist that I use them?

Either way, my choice is made for now. I will stop the conversion of the widgetset to Wayland. And continue to use the X11 version which works wonderfully with XWayland (obviously, its only dependency is libx11.so).

And maybe when Wayland has enslaved the planet and killed XWayland, I'll dive again.

By the way, I just tried Gimp, Inkspace and Audacity on Wayland.
Unfortunately, there is no working Wayland version of these essential applications yet.
It is on the todo list with not lot of enthusiasm.
And with XWayland the result is not perfect.
In their forum the advice is: go back to x11.

@fredvs
Copy link

fredvs commented Jun 6, 2024 •
edited

And about XWayland.

OK it works more or less but the solution to completely install an X ​​server is from Jurassic IT.

If they were serious, they would create an API compatible Xlib and XCB library that speaks the Wayland protocol underneath rather than X11.
Look at wine, they have done it for Windows to X11.

I'm disappointed, I was hoping for lots of wow in exploring Wayland.
But ultimately I get a lot of meh instead.

@zarlo
Copy link

zarlo commented Jun 6, 2024

@zarlo

@Monsterovich

No. Wayland doesn't have any "core" because there is no unified server.

that's like saying there is no core of http as there is no unified server.

These are incomparable things. A graphical server is many times more complicated than any web server. Isn't that obvious? Even more so, applications depend on the approach to implementing things in that server.

my point was by your definition no spec has a core

there are no unified:

  • js runtime
  • tls
  • smtp
  • bgp
  • sql

@probonopd
Copy link
Author

probonopd commented Jun 6, 2024 •
edited

Again, you can port a Qt 4 app to Qt 5 with minimal effort

Not all applications are still being developed, but need to continue to work.

Then update it to support Qt 5 or 6. Unless you're releasing proprietary crapware, in which case we have no room to continue this discussion.

This mindset is what imho holds back "the year of the Linux desktop". The fact is, there is software out there that needs to continue to run. Not everyone wants to or can afford to invest into updating everything all the time.

@zarlo
Copy link

zarlo commented Jun 6, 2024

@probonopd

Not all applications are still being developed, but need to continue to work.

yes but there has a limit, you cant have backwards compatibility with every thing for ever.
i would say there is a point that its on people who are still using it to make it work

This mindset is what imho holds back "the year of the Linux desktop". The fact is, there is software out there that needs to continue to run. Not everyone wants to or can afford to invest into updating everything all the time.

Not everyone wants to or can afford to invest into backwards compatibility everything all the time. this goes 2 ways.

@probonopd
Copy link
Author

probonopd commented Jun 6, 2024 •
edited

you cant have backwards compatibility with every thing for ever.

Well, on Xorg I can still happily run the Mosaic web browser... (have even created an AppImage of it)

Not everyone wants to or can afford to invest into backwards compatibility everything all the time. this goes 2 ways.

Yes, but companies like IBM Red Hat who are pushing Wayland have way more resources than random joe hobby developer working on a little app in his spare time out of passion. And, unlike the developers of some applications, they are still around.

@zarlo
Copy link

zarlo commented Jun 6, 2024 •
edited

And, unlike the developers of some applications, they are still around.

okay at that point its on the user to make it work or move on

Yes, but companies like IBM Red Hat who are pushing Wayland have way more resources than random joe hobby developer working on a little app in his spare time out of passion.

and? in this case there is a good change it will work under xwayland

okay so i have been a i3-wm user since 2012 is x11 only some of the scripts i have made depend on x11 and i use fedora.

have i been whining since i found out they will be dropping x11 at some point no i have looked at my options and have just need dropping x11 only things right now the only thing left is i3 its self i just pick 1 thing every few week tryed out the x11/wayland options it was not hard to do nor did it take a long time

and you are always free to use a distribution that supports x11 i doubt arch would drop it any time soon

@probonopd
Copy link
Author

Think of things like GNUstep. Developed a long time ago, few active developers (not much development needed anymore, stable and feature complete since a long time). No resources to cater for work created by external changes in the underlying platform.

@zarlo
Copy link

zarlo commented Jun 6, 2024

Think of things like GNUstep. Developed a long time ago, few active developers (not much development needed anymore, stable and feature complete since a long time). No resources to cater for work created by external changes in the underlying platform.

then either

  • it works in xwayland
  • someone updates it
  • you say on x11
  • you stop using it

@binex-dsk
Copy link

Not all applications are still being developed, but need to continue to work.

Updating it so that it's actually usable for people who don't have access to 20-year old abandoned ebuilds is much closer to basic maintenance than development.

That widgetset dont need dependencies (apart libx11.so) because his code is compiled with the application.
And one of his priority is to always be compatible with previous version.

This is a good mindset to have, but ultimately there is going to be some kind of incompatibility someday. It's simply not possible to make 100% of everything 100% backwards compatible. Even Windows, lauded for its backward compatibility, struggles to have applications work on both Windows 7 and 11--though Qt does an excellent job making this happen.

Also, only depending on libX11 is great in theory, but what if you want to support Windows?

@probonopd
Copy link
Author

probonopd commented Jun 6, 2024 •
edited

@zarlo

it works in xwayland

Wayland proponents keep telling me that XWayland is not "proper" and somehow only a temporary "workaround".

someone updates it

I don't think so, no developers are interested in that. No GNUstep developers have asked for Wayland to exist nor to create additional work for them.

you stay on x11

Exactly my point, hence I urge everyone to be careful and not abandon X11 anytime soon.
IBM Red Hat (surprise) has already stated their intent to do the exact opposite, though.

you stop using it

No. Not because someone at IBM Red Hat decided to shove Wayland upon us.

The proper solution imho would be: XWayland becomes an integral first-class citizen and the default way for applications to use Wayland without having to rewrite or even recompile them.

Unfortunately, it's unlikely that the Wayland proponents will ever see it this way. They think the world revolves around them and everyone is keen to rewrite everything to please their moving-target and still feature incomplete protocols.

@binex-dsk
Copy link

Unfortunately, it's unlikely that the Wayland proponents will ever see it this way.

Please don't try to act high and mighty as if you aren't doing the same thing in a different font.

@fredvs
Copy link

fredvs commented Jun 6, 2024

Also, only depending on libX11 is great in theory, but what if you want to support Windows?

Of course libX11 is mainly for Unix systems.
For Windows the widgetset links to the root gui gdi32.dll.
https://github.com/mse-org/mseide-msegui

And luckily, the world isn't just ruled by C and Java.
This widgetset + ide is in Pascal and uses the Free Pascal Compiler.
https://www.freepascal.org/

@fredvs
Copy link

fredvs commented Jun 6, 2024 •
edited

but ultimately there is going to be some kind of incompatibility someday.

Maybe not. If the application correctly uses libx11.so and libc.so and its signed symbol table, there is no reason to have an incompatibility.
libx11.so.6 is static now, it won't change anymore and using the libc.so signed symbol table ensures compatibility.

I have applications compiled on the latest version of XUbuntu that work perfectly on the first version of Ubuntu.
And the same applications compiled on the first version of Ubuntu which work perfectly on the latest version of XUbuntu.

And this using the same code and the same compiler.

@AndreiSva
Copy link

AndreiSva commented Jun 6, 2024 •
edited

@probonopd

@zarlo

it works in xwayland

Wayland proponents keep telling me that XWayland is not "proper" and somehow only a temporary "workaround".

someone updates it

I don't think so, no developers are interested in that. No GNUstep developers have asked for Wayland to exist nor to create additional work for them.

you stay on x11

Exactly my point, hence I urge everyone to be careful and not abandon X11 anytime soon. IBM Red Hat (surprise) has already stated their intent to do the exact opposite, though.

you stop using it

No. Not because someone at IBM Red Hat decided to shove Wayland upon us.

The proper solution imho would be: XWayland becomes an integral first-class citizen and the default way for applications to use Wayland without having to rewrite or even recompile them.

Unfortunately, it's unlikely that the Wayland proponents will ever see it this way. They think the world revolves around them and everyone is keen to rewrite everything to please their moving-target and still feature incomplete protocols.

Do you really want to live in a world where nothing, ever breaks backwards compatibility? If that were the case we would still be using unencrypted HTTP, broken and duct-taped init systems like SysVinit, slow and insecure BIOS boot, the list is huge.

You need to understand that we have to do this in order to progress our technology. Real fundamental improvement usually only come with real fundamental changes, which break compatibility. This will have to be done at some point, and it only gets worse the more we put it off.

In 10 years, do you really want to use a 50 year old windowing system? I don't think you understand the implications of what you're calling for here.

@fredvs
Copy link

fredvs commented Jun 6, 2024 •
edited

Real fundamental improvement usually only come with real fundamental changes, which break compatibility.

Yes I would accept for fundamental improvement but Wayland is not the case.

Do you really want to live in a world where nothing, ever breaks backwards compatibility?

Yes, I would prefer.

In 10 years, do you really want to use a 50 year old windowing system?

And why not if old interesting apps can run on it and if the new windowing system of 24 year old cannot do what the 50 year old can do?

@Consolatis
Copy link

Do you really want to live in a world where nothing, ever breaks backwards compatibility?

Yes, I would prefer.

The obvious solution for old applications is to open source them. If they are valuable enough for enough people you'll find people making them work on current software eco systems. There is a reason that Doom for example is still around.

@fredvs
Copy link

fredvs commented Jun 6, 2024

Do you really want to live in a world where nothing, ever breaks backwards compatibility?

Yes, I would prefer.

The obvious solution for old applications is to open source them. If they are valuable enough for enough people you'll find people making them work on current software eco systems. There is a reason that Doom for example is still around.

Of course, with the source you can do it. But this requires some expertise and if the root-developer cares about backwards compatibility (and it's possible with x11) it's not even necessary.

@probonopd
Copy link
Author

probonopd commented Jun 6, 2024 •
edited

Yes, I'd prefer to use Windows 2000, Mac OS X 10.4 and Linux with KDE 3 without hesitation over what we have today - if it ran on modern hardware and if "the web" would still work on it. To me it seems like the desktop computing user experience has steadily declined since then. (Everything dumbed down, constant flow of notifications, not designed for offline usage, constant updates for no real reason, n-th reshuffling of the settings, advertising tricking you into subscriptions, mobile UI paradigms bleeding into the desktop, "Secure Boot", lockdown, etc.)

In fact, if I could have the desktop experience from System 7 from 30+ years ago on today's Linux I'd be super happy.

What we are lacking is an appreciation of when a product is mature. At that point, it should best be left alone. I consider a mature product a good thing. No longer a moving target.

Remember when iOS apps were ~3 MB? Today everything seems to require hundreds of megabytes because people mistake JavaScript for "app development". Those 3 MB apps were better than what we have today.

And don't even get me started on things like Windows Recall (which is constantly spying on the user and saving its findings so that malware can easily steal them).

The obvious solution for old applications is to open source them.

That doesn't mean that there are any developers willing to work on them for no reason other than to chase a moving target, Point in case: GNUstep.

@mattatobin
Copy link

Well.. I think a distro highlighting mature Linux software would be a good thing.

@lukefromdc
Copy link

lukefromdc commented Jun 7, 2024 •
edited

This in fact is a broader indictment of current society AS A WHOLE. People don't seen when something has been developed to the "just right" point and they must keep moving. On my systems and in my life, I try to roll back changes I see as negative and keep those I see as positive. Systems should change as users and needs change, not for sake of a "refresh."

In my own usage, I use custom GTK and icon themes whose purpose is to roll back most of the visual changes to the GNOME 2 UI since when I first set up an UbuntuStudio machine in 2008 and customized the theme a bit. Thus I have MATE on wayfire looking and acting much like GNOME 2 with Compiz did for me over a decade ago. I added one more customization: the first few versions of GNOME shell used a tranparent black "shell theme" I thought was gorgeous, so I retrofitted it via my GTK theme and some widget naming to mate-panel and applet menus. The origjnal 2008-era UbuntuStudio theme had tried to do something similar with panel menus but could only do a few of them due to GTK2 theming limitations.

My goal with all this is an unchanging or minimally changing front end fitted to the backend of the day over the hardware of the day. I only replace hardware now if it is destroyed, as we have long ago reached the point that most machines can handle editiong 1080p video, which is usually my most demanding task.

Yes, I'd prefer to use Windows 2000, Mac OS X 10.4 and Linux with KDE 3 without hesitation over what we have today - if it ran on modern hardware and if "the web" would still work on it. To me it seems like the desktop computing user experience has steadily declined since then. (Everything dumbed down, constant flow of notifications, not designed for offline usage, constant updates for no real reason, n-th reshuffling of the settings, advertising tricking you into subscriptions, mobile UI paradigms bleeding into the desktop, "Secure Boot", lockdown, etc.)

In fact, if I could have the desktop experience from System 7 from 30+ years ago on today's Linux I'd be super happy.

What we are lacking is an appreciation of when a product is mature. At that point, it should best be left alone. I consider a mature product a good thing. No longer a moving target.

Remember when iOS apps were ~3 MB? Today everything seems to require hundreds of megabytes because people mistake JavaScript for "app development". Those 3 MB apps were better than what we have today.

And don't even get me started on things like Windows Recall (which is constantly spying on the user and saving its findings so that malware can easily steal them).

The obvious solution for old applications is to open source them.

That doesn't mean that there are any developers willing to work on them for no reason other than to chase a moving target, Point in case: GNUstep.

@zarlo
Copy link

zarlo commented Jun 7, 2024

@probonopd

it works in xwayland

Wayland proponents keep telling me that XWayland is not "proper" and somehow only a temporary "workaround".

i would just tell them to fuck off as they must not know what they are talking about as there are not such things as "temporary" workaround only workarounds that become features. but i think i get why they are saying this they dont want new work to rely on xwayland to work on wayland

The proper solution imho would be: XWayland becomes an integral first-class citizen and the default way for applications to use Wayland without having to rewrite or even recompile them.

im 100% with you on this as it would fix most of the issues but you would have issues as i doubt it would be a 100% comparable x11 api ever

@zDEFz
Copy link

zDEFz commented Jun 8, 2024

It would be outrageous to see games and software only running on Wayland, but not on X.

@mattatobin
Copy link

mattatobin commented Jun 8, 2024 •
edited

Well some time ago I was here on a misguided mission against my better judgement to correct some what I was TOLD were misconceptions despite knowing otherwise implicitly. That's over. So is a lot of things if you look me up. Linux and the BSDs are out there for anyone to create a system from.

People should bake their own bread and the like. Not necessarily mill the flour but baking the loaf.. Anyone can do that and if we don't watch out and don't take advantage of the digital raw materials around they will eventually vanish or be mutated beyond whatever it was intended to do in the first place with CLOOOOOOUUUUUUDDDD and AAAAAAAAAAYYYYYY-EEEEEEYYYYYEEEEE.

@mattatobin
Copy link

mattatobin commented Jun 8, 2024 •
edited

Also, did someone inject some JS into this? Was it that BomberFish? I had to use devtools to get rid of the BSOD overlay..

EDIT: Yeah @BomberFish is abusing some math js thing.. A 9x BSOD would have been far better imo. I am reporting it to our overlords.

EDIT2: Went to the profile.. big ol tiled trollface.jpg for a background. Cool as hell but now he may have to do it all over again with another account.

EDIT3: It's all been resolved by apparently being resolved rolls eyes.. Luckily I had screenshots when I made the reports so in the event he reverted it himself they will still be aware of it.

@BomberFish
Copy link

Also, did someone inject some JS into this? Was it that BomberFish? I had to use devtools to get rid of the BSOD overlay..

EDIT: Yeah @BomberFish is abusing some math js thing.. A 9x BSOD would have been far better imo. I am reporting it to our overlords.

EDIT2: Went to the profile.. big ol tiled trollface.jpg for a background. Cool as hell but now he may have to do it all over again with another account.

Haha, you got me. Looks like they patched it completely by now... it was fun nonetheless.

@mattatobin
Copy link

@BomberFish Surprised they didn't ban you outright. It is Microsoft.

@mattatobin
Copy link

mattatobin commented Jun 9, 2024 •
edited

Anyway, what was I on about before blue screens of troll? Oh yeah, do these FUCKS (not you BomberFish) not understand you need a stable, working, and predictable surrounding system to properly test and create new stuff that also becomes stable, working, and predictable?

I mean I just got called psychotic by a Linux-from-Scratch user in their IRC channel for not wanting systemd (despite the fact that LFS continues to produce their SysVInit instructions) and not just systemd but systemd-boot instead of my distro-independent grub configuration not managed by anyone but me, manually. Also for keeping my kernel not in /boot or that I put files on my computer in a file structure I want my files to be in.

And accused (when I was disconnected from one client) of never having used systemd and wayland. Thing is, when I started doing my servers I was on a systemd distro because at the time I didn't really mess with much except start stop and do a couple of those ini-like unit files. But the moment I wanted to do more advanced and specific management of my systems it became me fighting the system for who would comply with what. At this point I am good enough with bash scripting to manage in a SysVInit environment which does only the things I tell it to.

As for wayland, I have had my fill since October last year and previous short previews as well as researching into what Wayland is and isn't. It also doesn't work properly on my system regardless of what card I use from graphical glitches to crazy ass infinite mirror effects to complete stalling out. Basically doing everything people bitch about X11 for without any of the advantages of X11 like actually working properly (or at least as expected and advertised).

I seriously do not fully understand why any of this is happening though. Why any of it was needed in the way it has unfolded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment