Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active November 9, 2024 15:08
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.

The Wayland project seems to operate like they were starting a greenfield project, whereas at the same time they try to position Wayland as "the X11 successor", which would clearly require a lot of thought about not breaking, or at least providing a smooth upgrade path for, existing software.

In fact, 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.

Edit 08/2024: "Does Wayland becoming the defacto standard display server for Linux serve to marginalize BSD?" https://fossforce.com/2024/07/the-unintended-consequences-linuxs-wayland-adoption-will-have-on-bsd/

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

Update 6/2024: Looks like this will get unbroken thanks to xdg_toplevel_icon_manager_v1, so that QWindow::setIcon will work again. If, and that's a big if, all compositors will support it. At least KDE is on it.

Wayland breaks drag and drop

Wayland breaks ./windowmanager --replace

  • Many window managers have a --replace argument, but Wayland compositors break this convention.

Wayland breaks Xpra

Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.

  • Under Xpra a context menu cannot be used: it opens and closes automatically before you can even move the mouse on it. "It's not just GDK, it's the Wayland itself. They decided to break existing applications and expect them to change how they work." (Xpra-org/xpra#4246) ❌ broken since 2024-06-01

Xwayland breaks window resizing

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

@probonopd
Copy link
Author

probonopd commented Dec 28, 2023 •
edited
Loading

https://pointieststick.com/2023/12/26/does-wayland-really-break-everything/

Looks like has gotten the attention of @Pointedstick of KDE fame, whom I respect a lot.
And this is a good thing!

There’s a bit of chuckling and jeering over this in developer circles, but to regular people, the whole “Wayland breaks everything” charge might ring true, or at least seem like it contains a kernel of truth. Because from a certain perspective, he’s right: Wayland really does break everything that directly uses X11 functionality!

Chuckle or not, it's good if developers (and especially those responsible for the breaking changes) hear from those who have to suffer under their decisions.

Thing is, we (the people) (as in: application developers, end users, etc.) have not asked for anyone to come in and take away what has been working (more or less) for decades, and to replace it with something that a) has no feature parity, b) requires additional work from developers, and c) may require end users to change part of their software stack.

So, what we (the people) need is a smooth (as in: as few conceptual changes as possible) transition path. Wayland may have many benefits (I have never argued with that), but currently it is not an option for me (and many fellow users/developers) because it has no smooth transition path (feature-by feature).

So, if the https://github.com/probonopd/wayland-x11-compat-protocols/ seems to be getting some attention "in developer circles", and this is truly a great thing. Hopefully it will lead to some useful conclusions. Truth be told, the best outcome would be if upstream Wayland developers would finally acknowledge that there are application and desktop environment developers and end users out there who don't buy into this whole Portals-Flatpak-Systemd-Pipewire thing, and deliver feature parity with X11 on "pure" Wayland. If that happens, mission accomplished!

Linux isn’t a platform

Linux is a kernel. But "Desktop Linux" (for the lack of a better word) better gets their (our!) act together and provide a unified platform that can be taken for granted by application developers on all Linux distributions. I have given talks about this. (If you ask me, the "Year of the Linux Desktop" (tm) could have happened over a decade ago if everyone had embraced LSB Desktop.

https://gitlab.com/probono/platformissues - the Linux Foundation could possibly do something about it but seems to care more about non-Linux things these days.

Personally I have moved on to FreeBSD for that exact reason - I am fed up with there being different Linux distributions that agree on nothing.

The model of the monolithic window server that offers all functionality failed decades ago.

If it "failed decades ago", how come that I am typing these words on one?

The portal system

... comes from Red Hat's Flatpak, a system designed to ensure Red Hat's firm grip on all of "Desktop Linux" (essentially running containers on top of the operating system, so that the operating system doesn't have to provide a sane, binary-compatible platform). They even host things with "xdg" in its name on https://github.com/flatpak/, suggesting they can unilaterally decide how the desktop ought to work. Really don't know why KDE is buying into this, factually making KDE work conceptually like Gnome under the hood.

I think this is the platform: Portals-and-Wayland-and-PipeWire.

I think it is a platform, a platform that Red Hat wants to use, but it is not "the" platform. It has no official seal of the Linux Foundation, nor does it have universal buy-in from all desktop environment developers.

Clearly we need to come up with a better name.

How about "IBM Red Hat Fedora Gnome minus the GUI"?

porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past

That'd be painful but understandable. But even then, the very least thing Wayland must offer is, for each feature of X11, some migration path. Not being able to set random icons on windows, not being able to share the screen without additional nag screens. Wayland is just something that pushes pixels to the screens. Its designers should not mistake this for having carte blanche for designing (dictating) how the whole) desktop works. That job is better left to the actual developers of desktop environments.

I trust that KDE will find ways to make things work, but I'm not so optimistic for the "Desktop Linux" platform as a whole.

@Monsterovich
Copy link

Even with working graphics drivers on my new computer X.org is so slow.

System:
  Host: pc Kernel: 5.19.15-xanmod1 x86_64 bits: 64 Desktop: Xfce 4.18.1
    Distro: Linux Mint 21.2 Victoria
Machine:
  Type: Desktop Mobo: Gigabyte model: B550M S2H serial: <superuser required>
    UEFI: American Megatrends LLC. v: F15e date: 07/26/2022
CPU:
  Info: 6-core AMD Ryzen 5 5600X [MT MCP] speed (MHz): avg: 2910
    min/max: 2200/4650
Graphics:
  Device-1: NVIDIA GA104 [GeForce RTX 3060 Ti Lite Hash Rate] driver: nvidia
    v: 535.129.03
  Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: nvidia
    gpu: nvidia resolution: 1920x1080
  OpenGL: renderer: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2
    v: 4.6.0 NVIDIA 535.129.03
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
Drives:
  Local Storage: total: 1.36 TiB used: 671.86 GiB (48.1%)
Info:
  Processes: 340 Uptime: 8h 10m Memory: 31.26 GiB used: 4.34 GiB (13.9%)
  Shell: Bash inxi: 3.3.13

Xorg worked fine back in 2006, and it works fast now too. I don't know where you got that from. Don't use GNOME.

@kendofriendo
Copy link

I wish github had the opposite of a star so I could give it to this

@Pointedstick
Copy link

@probonopd It's a bit weird having a conversation here in the comments section of this document, but OK. :)

To start with, IMO it's neither fair nor accurate to say "Wayland broke this stuff". Wayland hasn't broken anything; it's just that software which hasn't been ported to run natively on Wayland in a Wayland session runs in an imperfect compatibility layer (XWayland); if anything, XWayland broke those apps.

But IMO even that pedantic clarification is still missing the forest for the trees. Now, I think it's totally fair to complain that Wayland isn't a 100% drop-in replacement for X11, and to be honest, sometimes I wish it was too. But it's not. Because it's not, and because the people who develop it don't want it to be one, we need to look at the situation from a different perspective: we need to see Wayland as a new platform with some intentional incompatibilities compared to X11. And we must expend effort to into the task of porting our software to work with Wayland natively, if we don't want the software to run in an imperfect compatibility layer and possibly not work as well.

I totally understand if you don't want to expend that effort. It's fair to wait. There are still some things that some apps can't do with Wayland that they can on X11, and the porting story evolves over time as new protocols are accepted and implemented in major compositors. So some of those omissions may be remedied in the future. And in the meantime, most distros are going to keep shipping X11 for years, so it's not like there's some super huge urgency here (unless you're on Fedora, but if you are, then this should be exciting to you, and if it's not, then you're using the wrong distro).

But, if you choose to wait, you need to be prepared to accept the consequence that users (and distros, and DEs) who do use Wayland might have a worse experience with your software if it does anything with X11 that XWayland can't provide.

If you're not fine with that, what are your options?

One is to try to change Wayland into being a drop-in replacement for X11. I'm not optimistic about the prospects for success here. You're certainly welcome to try, but I predict it will end up mostly a waste of your time and energy. And if I'm right, that's sad, because I think time and energy are our most precious resources.

Another option is to try porting now. In a lot of cases it's really not that hard. Nearly all KDE apps are ported and now run natively in Wayland, without impacting their support for X11 at all. This porting might mean doing things in a different way from what you're used to. For example, you might have to ship your software with a .desktop file that specifies an icon, rather than setting an icon on each individual window. If you want to open a popup under the cursor, you might have to create the pop-up as a sub-surface with relative positioning rather than a new top-level window with absolute positioning and a bunch of "don't show this in my taskbar/alt+tab/pager/etc" flags. And so on. A lot of this stuff is doable if you're willing to learn some new things and accept that new platforms have some differences from old platforms. And you can do it in a way that doesn't impact X11 support at all.

If you don't want to do that, and your effort to change Wayland to be a drop-in replacement for X11 fails, then allow me to propose a third way: come up with protocols to do things that apps want to do, but without completely replicating the X11 UX (which will get vetoed). Think of creative new ways to accomplish the underlying goals. Here are some examples I just thought of:

  • Most apps want to be able to do absolute window positioning so they can save and restore the locations of their windows at launch. So instead, why not create a xdg_restore_window_position_v1 protocol that addresses that need directly? Then apps that want to use absolute positioning for that can port to use that protocol instead, and apps that are currently misusing absolute positioning to open popups can use relative positioning instead.
  • No single-window app needs the ability to set a window icon, since the existing solution of setting an icon in the desktop file works fine. But multi-window apps can benefit from this to help the user disambiguate in abstract representations of windows (e.g. their taskbar or Alt+Tab switcher). So maybe we can create an xdg_window_badge_v1 protocol that lets apps opt into setting "badges" for their windows, with the stipulation that when only one is set, the badge is ignored and the app icon is used instead, but when more than one badged window is open, then the compositor must show either only the badge, or else the badge overlaid on top of the app icon.

These are just random ideas I thought up, but I think they're both likely to be better received in the Wayland developer community compared to proposals to bring back absolute window positioning or custom window icons verbatim.

@bodqhrohro
Copy link

@probonopd

Speed is nice to have

Said a bicycler mandating a ban on cars. Or a horse rider? Aw, yeah, horse poop everywhere. Let's fertilize the asphalt. Or should we perhaps remove the asphalt as well and grow crops on public roads?

act together and provide a unified platform
suggesting they can unilaterally decide how the desktop ought to work. Really don't know why KDE is buying into this, factually making KDE work conceptually like Gnome under the hood

Don't you see a contradiction here? You expect unification and blame KDE for not inventing a wheel and sharing standards with GNOME the same time.

@Monsterovich

Don't use GNOME.

I don't, how do you explain the performance difference then? :P Neither does @binex-dsk, they're i3/Sway fan.

@Pointedstick

And we must expend effort to into the task of porting our software to work with Wayland natively

Not a realistic task, there are lots of legacy software, some of which is proprietary. It's not like GNU/Linux is great with providing a backwards binary compatibility though.

Anyway, I had mentioned FLTK-based XS++ many times up the thread. The build from 2008 dynamically links with lots of libraries, and still all of them work on my modern system anyway, AFAIR, they are all even still available in repos and receive updates.

@bq:01:13:48:/tmp/dl$ ldd /opt/XS++/XS++\ v4.1 
        linux-vdso.so.1 (0x00007ffe64bfa000)
        libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007ff10dc00000)
        libfltk.so.1.1 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.1 (0x00007ff10deda000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff10d800000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff10db21000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff10deb6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff10d61e000)
        libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007ff10de9a000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007ff10de4f000)
        libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007ff10de4a000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff10d4da000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff10dfd0000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007ff10da56000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007ff10de3b000)
        libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x0000003bcea00000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff10de26000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff10d4b0000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff10d491000)
        libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007ff10d45b000)
        libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007ff10de17000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff10de12000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x0000003bccc00000)
        libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007ff10d438000)
        libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007ff10d422000)
        libmd.so.0 => /usr/lib/x86_64-linux-gnu/libmd.so.0 (0x00007ff10d413000)

I considered its sources lost, yet have found an SVN repo recently. It depends on some external libraries, including FLU which is rare and its website is dead long ago, yet I found it somewhere finally too. I attempted to build it, and the resulting build does not show any window at all. So until this problem is resolved I cannot even tell for sure if that's a full and relevant copy of sources and if that old build is not everything we have.

Luckily, it does not need to talk to other X clients and thus work under Xwayland well. There might be other legacy software which needs to though.

@lestcape
Copy link

@Pointedstick Look, I have read interesting messages written by you, but the truth is that this last one that you have written here, it's to leave without even read it.

There is only one thing that stands out, very, very clear. You are basing everything you say on the fact that the application developers are going to create a protocol or use a specific protocol for something. The truth is that just the fact that this has to happen is the real problem here. Wayland is selling us a functional, generic and transparent thing to make applications that work on Linux desktops, or it is selling us a huge mess? A huge mess, where some things are going to work, others are not, others are only going to work here and not in the other desktop, and so...

The answer is clear, Wayland is selling a huge mess that at this point makes no sense. It is separating the different implementations of Wayland, it is leaving spaces without solutions or with dissimilar solutions that were previously the same thing. That is, it is creating chaos and what it is solving is not clearly visible to application developers.

If GNOME and KDE did not exist and everyone used, for example, wlroots, then Wayland would make sense. But it doesn't, because no one in Linux ever wants to agree and everyone wants to do what they think is right. Wayland it simply leaves them the space for chaos to form. Just the last recently on LinuxMint Cinnamon Desktop:

linuxmint/wayland#25

Copy link

ghost commented Dec 29, 2023

...but it works.

No it doesn't. Wayland does.

@bodqhrohro
Copy link

@lestcape

Wayland is selling

It's FOSS, not some commercial product, please don't apply that terminology here.

a huge mess that at this point makes no sense

It makes sense for those who hack on it. That's enough. The opinion of the rest is not really valuable at all.

leaving spaces without solutions

If there are real problems affecting those who really can contribute, they get solved. At least in some of compositors. Same works for X.Org. I mentioned many times that X.Org works well enough for me, and there's nothing to fix really. I catched one sporadic bug though, but don't even have an idea how to reproduce it and it occurs rare enough. The stacktrace is not really informative, so that should be some memory corruption. Not that long ago, I investigated some sporadic (and frequent and annoying!) memory corruption in telegram-purple for months, and finally forfeited, which sounds alarming.

If GNOME and KDE did not exist and everyone used, for example, wlroots, then Wayland would make sense

If TWM, MotifWM and Enlightenment did not exist, then EWMH would make sense. Boycott EWMH!

(yeah, the analogy is not clear, as GNOME/KDE are far more popular than that, but there's nothing eternal under the Sun (pun intended))

@Monsterovich
Copy link

@Pointedstick

To start with, IMO it's neither fair nor accurate to say "Wayland broke this stuff". Wayland hasn't broken anything; it's just that software which hasn't been ported to run natively on Wayland in a Wayland session runs in an imperfect compatibility layer (XWayland); if anything, XWayland broke those apps.

Wayland not only breaks software, it breaks the proper paradigm in which applications function. As I've said a hundred times, we need a decent framework for DE and application development. This framework also should have a unified code base. All other options are not viable. Wayland is a true anti-pattern done in a "divide and conquer" style. This will create unimaginable fragmentation that will destroy GNU/Linux's desktop, making it uncompetitive. Wayland completely destroys the interchangeability that Xorg had.

On the background of all this, I don't care about Xwayland and how it will be integrated into Wayland's flawed architecture.

we need to see Wayland as a new platform with some intentional incompatibilities compared to X11

So it's all a farce to prove that "we're different" to the detriment of everything else. Is that what I'm getting at? Even Microsoft didn't think of doing such nonsense, MS Windows runs software from 20 years ago without any problems.

And we must expend effort to into the task of porting our software to work with Wayland natively, if we don't want the software to run in an imperfect compatibility layer and possibly not work as well.

There are two things to realize here:

  • If Wayland wasn't flawed, there would be 100% compatibility with Xorg (most likely).
  • Even if it was 90-95% compatible, everyone would agree on that, but if Wayland wasn't flawed.

Until Wayland has a unified library (and graphical server) and everything else, I don't see the point of even discussing anything.

@bodqhrohro
Copy link

@binex-dsk

No it doesn't. Wayland does.

It doesn't. C'mon, I cannot even switch layouts, that's an unusable piece of shit. There exists Tapper, but it's ported only for GNOME with the use of a shell extension which exposes its internal APIs at the moment. And even that might break with a minor update. That's why I dropped an idea of making a custom environment with lots of extensions based on GNOME or Cinnamon back in 2014, and went the pure X.Org way.

@bodqhrohro
Copy link

@Monsterovich

Even Microsoft didn't think of doing such nonsense

Windows Phone/WindowsRT moment here.

@Monsterovich
Copy link

@Monsterovich

Even Microsoft didn't think of doing such nonsense

Windows Phone/WindowsRT moment here.

Are we going to discuss marginalized garbage that no one remembers and that had no effect on anything?

@bodqhrohro
Copy link

bodqhrohro commented Dec 29, 2023 •
edited
Loading

marginalized garbage that no one remembers

Windows Mobile had quite a big market share.

They voluntarily dropped all its legacy and shoved totally incompatible and locked-out all the way Windows Phone instead. Market did not accept it, now we have neither. Morale?

And they attempted to do the same with the desktop branch (remember Windows 8?), but it was half-fetched and they listened to the market that time and cancelled that madness.

@bodqhrohro
Copy link

no one remembers

It's featured in the «}{0ТТ@БЬ)Ч» movie, by the way. As long as GNU/Linux, and defacing the Microsoft's website. How dare you don't know it!

@Monsterovich
Copy link

Monsterovich commented Dec 29, 2023 •
edited
Loading

@bodqhrohro

Windows Mobile had quite a big market share.

Look, it can't even compete with what Apple has in the phone market. A measly 7% in 2009. And it's a product of the corporation that made f*cking Windows! Well, it just made sense to let it die.

When it's obvious that a product is flawed and not selling, you have to let it die. Xorg has been (and still!) working for over 20 years and they want to destroy it, attributing to it flaws that either don't matter or are a rare use case.

Once again: killer-features made via a flawed architecture will NOT save Wayland.

@bodqhrohro
Copy link

Look, it can't even compete with what Apple has in the phone market

Do you compare the stupid iPhone crap with Windows Mobile PDAs for serious lol?

Well, it just made sense to let it die.

Yeah, but in reality, M$ killed both Symbian and Meego by buying Nokia, and left mobile GNU/Linux with no chances of overcompeting Android in time. Now it's too late, the ecosystem is mature already. Oh, and they killed their mobile Windows branch, for aforementioned reasons. Thus totally reformatting the market of high-end mobile devices, if you don't take Blackberry, that's another story (pretty relevant for US though, they barely know Symbian, and the Europe the same time barely knows Blackberry).

Xorg has been (and still!) working for over 20 years and they want to destroy it

But Android somehow uses its own SurfaceFlinger instead. While Meego did use X.Org. And SailfishOS uses Wayland for a long time already, with a proprietary compositor.

@lestcape
Copy link

@bodqhrohro

It makes sense for those who hack on it. That's enough. The opinion of the rest is not really valuable at all.

Yes that's just the point. Let those same people who created it use Wayland and don't expect other developers to migrate their applications (as is happening) to that mess they created for themselves. Don't ask users to accept the migration to that personal invention either and we will all be happy then.

@bodqhrohro
Copy link

Don't ask users

Yeah, users of popular distributions are not asked, that's the problem. They barely know what Wayland even is, and the fact how it is presented in GDM leads to a lot of misconceptions already discussed early in the thread. Like this.

@ssokolow
Copy link

ssokolow commented Dec 29, 2023 •
edited
Loading

@probonopd

The portal system

... comes from Red Hat's Flatpak, a system designed to ensure Red Hat's firm grip on all of "Desktop Linux" (essentially running containers on top of the operating system, so that the operating system doesn't have to provide a sane, binary-compatible platform). They even host things with "xdg" in its name on https://github.com/flatpak/, suggesting they can unilaterally decide how the desktop ought to work. Really don't know why KDE is buying into this, factually making KDE work conceptually like Gnome under the hood.

Correction: It's an artifact of history.

The XDG portal repos are under Flatpak because they began as "Flatpak Portals" and then got renamed to XDG Portals later. (I believe when Snaps started using them too.)

...however, going back further, Flatpak began as xdg-app and got renamed later, so it's a bit of a wash.

not being able to share the screen without additional nag screens. Wayland is just something that pushes pixels to the screens.

wlroots has the wlr screencopy protocol extension for portal-less screen-recording... other compositors just aren't interested in implementing it.

Overall, the problem is that the Wayland ecosystem brushed the original promise of "some APIs will only be available to privileged applications" (as in applications running under an analogue to Windows's "Run as Administrator") under the rug, so there's no agreed-upon, standard way to do something in the vein of chperm +screenrec /usr/bin/wayland-screenrecorder (like how macOS handles it) and then get on with your life.

@Pointedstick

Another option is to try porting now. In a lot of cases it's really not that hard.

Unfortunately, my most popular creation is a utility which uses libwnck and XGrabKey to runtime-monkeypatch keyboard-driven window tiling support into any X11 WM in a desktop-portable way.

Even if I weren't currently struggling to get back to a place where I can properly maintain my projects, it's antithetical to Wayland's security model.

(And, more generally, I'm going to need to look into whether the privileged protocols only available to kwin scripts are powerful enough to implement the "Window Rules, but must be almost turing complete" customizations I currently achieve through a "Fix Window Positions" launcher that calls a Python script full of wmctrl calls.)

No single-window app needs the ability to set a window icon, since the existing solution of setting an icon in the desktop file works fine.

It does not work fine for "no install" things like Appimages (probonopd is the Appimage guy) and running a development copy from a git checkout (my use-case).

Were you aware that I avoid Plasma's support for progress indicators in taskbar buttons because the Unity API you guys implemented it based on has this same testing-hostile design?

(I'm currently torn between following the Dolphin (emulator) and LibrePCB devs' lead and making my applications only accept XWayland or writing some kind of launcher proxy where the application generates and installs a temporary .desktop file and then re-launches itself as a child process so that, even if it crashes, the outer process can still cleanup the temporary... but that latter one doesn't adequately account for system rot induced by the last run of a to-be-uninstalled program having been ended by a power outage.)

Likewise, I added export WINEDLLOVERRIDES="winemenubuilder.exe=d" to my .xsessionrc years ago to keep Windows applications from taking their crayons to my launcher menu and I don't want to intermingle "These windows should have icons" with "these windows should be allowed to clutter up my launcher menu/search".

(Yeah. when Wine comes into the mix, suddenly "applications must not be allowed to move their windows because the user should have agency there" feels a bit philosophically at odds with "applications must have .desktop files to have icons". Am I not allowed to have "just works" agency over what's in my launcher menu?)

What about games in Steam/Lutris/PlayOnLinux/etc. or other launchers that you don't want cluttering up your main launcher? I don't think even implementing a nested compositor would help since this is about taskbar buttons as much as it is about window titlebars.

@bodqhrohro
Copy link

bodqhrohro commented Dec 29, 2023 •
edited
Loading

testing-hostile

Apps on Android need to be reinstalled completely on every change, and developers don't consider that "testing-hostile" somehow. And expect every platform now to follow that ideology of isolated app bundles. Like CLI utilities do even fit it adequately. Or daemons. Or dynamic linking (not a thing for Rust fans anymore).

I wonder how quickly do those reinstalls wear the flash memory out, BTW.

@ssokolow
Copy link

testing-hostile

Apps on Android need to be reinstalled completely on every change, and developers don't consider that "testing-hostile" somehow. And expect every platform now to follow that ideology of isolated app bundles. Like CLI utilities do even fit it adequately. Or daemons. Or dynamic linking (not a thing for Rust fans anymore).

I wonder how quickly do those reinstalls wear the flash memory out, BTW.

Android is stockholm syndrome made into a product and iOS is worse. The closest I get to writing mobile apps is writing web apps which I test on mobile. (Which has the added benefit of being able to support iOS without paying Apple's developer ransom and owning something that runs the Mac OS that can't be tweaked.)

@bodqhrohro
Copy link

bodqhrohro commented Dec 29, 2023 •
edited
Loading

Android is stockholm syndrome made into a product and iOS is worse

Sounds jealous.

which I test on mobile

You need to test it specifically on an iPhone, otherwise you have a high risk of running into issues specific for iOS Safari. And as long as Apple dropped the development of Safari for Windows long ago. So, as long as virtually everything but WebKitGTK+ has migrated to Blink already, you barely can test things for Safari reliably without an Apple system. Even WebKitGTK+ has significant differences from WebKit in Safari. And Safari on iOS is artificially limited in resource usage, to add up to all the specifics of WebKit being the most obscure among popular web browser engines nowadays, taking the baton from Trident and Presto. Ah, Presto is still relevant nowadays anyway, I hope you support Opera Mini? Do you? Don't upset feature phone users please.

Mac OS that can't be tweaked

Boring propaganda. There are lots of customization tools for macOS. And for iOS in Cydia. The problem is rather that they tend to break with every minor release, just like GNOME Shell extensions mentioned above.

@ssokolow
Copy link

ssokolow commented Dec 29, 2023 •
edited
Loading

Android is stockholm syndrome made into a product and iOS is worse

Sounds jealous.

...wut?

I'm having trouble even figuring out what misconception you might be holding about me.

You need to test it specifically on an iPhone, otherwise you have a high risk of running into issues specific for iOS Safari. And as long as Apple dropped the development of Safari for Windows long ago. So, as long as virtually everything but WebKitGTK+ has migrated to Blink already, you barely can test things for Safari reliably without an Apple system. Even WebKitGTK+ has significant differences from WebKit in Safari. And Safari on iOS is artificially limited in resource usage, to add up to all the specifics of WebKit being the most obscure among popular web browser engines nowadays, taking the baton from Trident and Presto.

I have a hand-me-down iPhone 8S that I test with. Otherwise, I wouldn't give a damn about supporting Safari since nobody is paying me to care.

I do also use it to hone my skills at finding ways to write single-file JavaScriptless "apps" since opening a local HTML file in the Files app imposes those additional constraints. (So far, my cleverest hack has been using fragment links and <details> to build a used bookstore want list that feels like a simple app, despite being a single HTML file. I've been planning to experiment with various CSS hacks to take it to the next level.)

Ah, Presto is still relevant nowadays anyway, I hope you support Opera Mini? Do you? Don't upset feature phone users please.

I don't have anything which runs it, so I don't give a damn about Opera Mini beyond my usual efforts to design things that rely on JavaScript only as a last resort and my habit of fine-tuning how they handle tiny screens, printing, and accessibility... I've slacked off on validation slip though. Definitely need to re-implement HTML and CSS validation and broken link detection when I get back to writing my next static site generator in Rust.

Mac OS that can't be tweaked

Boring propaganda. There are lots of customization tools for macOS. And for iOS in Cydia. The problem is rather that they tend to break with every minor release, just like GNOME Shell extensions mentioned above.

  1. That's what they call "can't be tweaked". Mac OS 9 had many stable APIs for customization while Mac OS X forced developers to "make their own unstable APIs", which Apple keeps breaking instead of acknowledging as market demand for stable APIs, to achieve the same aims. Very GNOME of them.
  2. That's one of many reasons I don't use GNOME.
  3. Why do you think I run an LTS distro despite not using GNOME, and then procrastinate into updating six months before support ends, rather than when the next LTS is out? (For non-infrastructural stuff, I use Flatpak and take advantage of its support for rolling back bad updates.)
  4. Firefox legacy/XUL extensions were the same way. Guess why I never wrote any of those.

@lukefromdc
Copy link

I've made a point of NOT supporting iOS. If some change in iOS interferes with playing the videos I upload, I point out that I choose not to pay Apple's prices so cannot test on their stuff.

@ssokolow
Copy link

ssokolow commented Dec 29, 2023 •
edited
Loading

I've made a point of NOT supporting iOS. If some change in iOS interferes with playing the videos I upload, I point out that I choose not to pay Apple's prices so cannot test on their stuff.

Supporting Mobile Safari saves me money because it means I can get use of the iPhone I paid nothing for when it would otherwise be sitting idle instead of buying some other piece of kit to serve those purposes.

@inikishev
Copy link

testing-hostile

Apps on Android need to be reinstalled completely on every change, and developers don't consider that "testing-hostile" somehow. And expect every platform now to follow that ideology of isolated app bundles. Like CLI utilities do even fit it adequately. Or daemons. Or dynamic linking (not a thing for Rust fans anymore).
I wonder how quickly do those reinstalls wear the flash memory out, BTW.

Android is stockholm syndrome made into a product and iOS is worse. The closest I get to writing mobile apps is writing web apps which I test on mobile. (Which has the added benefit of being able to support iOS without paying Apple's developer ransom and owning something that runs the Mac OS that can't be tweaked.)

you can't make that argument when android is so widespread. Clearly google immensely benefited from it. If there is something you would benefit from, why not make it? Also apps on Android don't need to be reinstalled completely on every change... Just use instant run

@bodqhrohro
Copy link

I'm having trouble even figuring out what misconception you might be holding about me.

Quiet, tsundere.

I've been planning to experiment with various CSS hacks to take it to the next level.

Is CSS Turing-complete already?

I don't have anything which runs it

Java is write once, run everywhere.

Very GNOME of them

Rather the opposite. The GNOME team clearly has a cargo cult of Apple.

Firefox legacy/XUL extensions were the same way

Not really, I had used many abandoned extensions for >4 years both in Firefox and Thunderbird.

@sevmonster
Copy link

I don't know how I got here and I am not reading the deluge above, but I wanted to bring up something in case no one paid particular attention to it: no one working on Xorg wants to continue working on Xorg. It's aged, kludgey, and has many bottlenecks that can't be reliably solved on the existing architecture without major reworks—which would cause just as much headache as switching to a new protocol would, i.e. Wayland. It works, yes, but that's only due to the virtue of it being the standard for decades. But just because something works and exists does not mean it is the most effective tool for a job. I welcome upset to the industry and ecosystem because it means we get new ideas. Wayland is not perfect but it's better than continuing to push along the shambling corpse of Xorg and pretending it's a good thing.

If you need Xorg, use it. No one is stopping you and for the time being Xorg is still vaguely maintenance mode Bugs probably won't be fixed but it is mature enough that it should be fine for most applications. If you are upset developers are abandoning Xorg (not just of corporate interest but also of personal/maintenance reasons mind you) then go support it yourself. Linux, GNU, and everything else is an open ecosystem, so getting upset that a bunch of developers are working on something they want to work on and taking it in a direction they want, without providing any work of your own (or complaining when that work isn't accepted instead of forking and continuing it in the path you prefer) is counterproductive. But the fact of the matter is not only are unpaid single developers moving to Wayland, so is everyone else. And because of that traction, Wayland will get better and bugs will get fixed.

I myself do not have issues with Wayland, other than automation tools being young. ydotool is nice and works great nowadays, but detecting state is largely unimplemented, which is both a blessing and a curse; it's good for security (this is important for application sandboxing) but bad for power user experience. Otherwise, everything I've personally needed has worked. Not saying the bugs do not exist and there are no features missing but not everyone's needs or experience are the same.

I fail to understand what this sort of "Wayland sucks and here's all the bugs!!!" positing accomplishes. Power users that use Wayland already know it has holes. People that implement Wayland already know it is a wholly different experience and have learned/will learn to adapt. Average users that use Wayland don't even know they use Wayland and wouldn't care if they did. None of that means it is somehow "broken by design", it simply does not fit the particular use case needed. It would be so so much more beneficial and productive to go support Xorg projects or try something else (Durden is a fun project) instead of listing a bunch of bugs, some of which are not as bad as implied and/or work under other user circumstances.

@ssokolow
Copy link

ssokolow commented Dec 29, 2023 •
edited
Loading

you can't make that argument when android is so widespread. Clearly google immensely benefited from it. If there is something you would benefit from, why not make it? Also apps on Android don't need to be reinstalled completely on every change... Just use instant run

Because I don't have the capital to develop, produce, and market a smartphone platform that's as open and well-supported by Linux kernel upstream as IBM PC compatibles are.

I'm having trouble even figuring out what misconception you might be holding about me.

Quiet, tsundere.

Whatever, man.

I've been planning to experiment with various CSS hacks to take it to the next level.

Is CSS Turing-complete already?

No, but you can do some impressively dynamic-feeling things using CSS selectors and things like the checkbox hack (Wrap a label element around anything to make it toggle a hidden checkbox at an arbitrary other location in the DOM and then use a CSS sibling or descendant selector to toggle properties based on the checked/unchecked state).

It takes a mix of managing your expectations as a developer and getting creative in how you use the tools you're given to achieve things that surprise the users... sort of like what it was like to achieve impressive stuff in the days of 8-bit microcomputers.

I don't have anything which runs it

Java is write once, run everywhere.

I mean I don't have anything where I lack a better option. Why would I bother supporting something as niche as Opera Mini for a self-itch-scratch project? My sense of perfectionism can only take me so far when I'm polishing up things that don't benefit me personally and, in the case of something like Opera Mini, it stops at "How does it run when I uMatrix away the JavaScript and use Firefox's responsive design view to play with the viewport dimensions?"

Very GNOME of them

Rather the opposite. The GNOME team clearly has a cargo cult of Apple.

No argument there. I could expound at length on the foolish, superficial decisions they've made since I started paying attention during the GNOME 2 era, where they copy the surface details of Apple's design while undermining the rationale which drove them.

Firefox legacy/XUL extensions were the same way

Not really, I had used many abandoned extensions for >4 years both in Firefox and Thunderbird.

You must have gotten into them after I did. I experimented with Firefox extensions back when they were so aware of "this isn't an API, it's a non-API" that your extension was required to have a maxVersion in its manifest and you couldn't upload an extension with a maxVersion higher than what was in their Subversion trunk.

@zDEFz
Copy link

zDEFz commented Dec 29, 2023 •
edited
Loading

I don't know how I got here and I am not reading the deluge above, but I wanted to bring up something in case no one paid particular attention to it: no one working on Xorg wants to continue working on Xorg.

TLDR;

X11/Xorg

  • Most compatible
  • Most hackable
  • Window Managers are comparably easy to implement
  • Less secure
  • Stable - tested thoroughly by lots of users
  • Unified base; Many tools can be re-used across Desktop Environment

Wayland

  • Far less compatible
  • Less hackable
  • Window managers no longer exist - we talk about compositors now, compositors are harder to implement and a lot of people just give up
  • More secure
  • Very much untested.
  • Less stable - e.g happens to trigger amdgpu resets in environments like sway on some gpus (but devs say doesn't cause them, its a amdgpu bug). Additionally, doesn't happen on all implementations of Wayland... not a sway bug!...
  • Fragmented base - each desktop environment needs to re-implement everything from ground-up

If this is wrong, please correct me. I'd like to learn.

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