Post AvIZ58dMZerDLd2D1E by sun@shitposter.world
 (DIR) More posts by sun@shitposter.world
 (DIR) Post #AvITLyHhhrdKRpXz7I by fireborn@dragonscave.space
       2025-06-19T15:13:15Z
       
       3 likes, 4 repeats
       
       I didn’t plan to write about Wayland yet. But Xorg is dying — not eventually, but now. GNOME’s dropping X11 support. RHEL already removed it. Ubuntu and Fedora are next. And if you rely on accessibility, you don’t get to wait this one out.So here’s Post 4 of I Want to Love Linux. It Doesn’t Love Me Back.I’m using Wayland now. Primarily. Not because I love it. Because the fallback is disappearing, and I want to be there helping fix what comes next. GNOME with Orca actually works. KDE and COSMIC are making progress. I’ve talked to the people involved. They care.But a lot is broken.MATE — the desktop most blind users preferred — isn’t on Wayland.ocrdesktop doesn’t work. xdotool is gone.wlroots compositors still don’t reliably support Orca’s keybindings, especially on laptops.This isn’t GNOME’s fault. They’re the only reason accessibility on Wayland works at all.But the old excuses are gone. “Just use Xorg” isn’t going to be an option much longer.So yeah. I’m a Wayland shill now. Because I’m using it. Because I have to.And I want to make sure we’re not excluded from what comes next.https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-doesnt-love-me-back-post-4-wayland-is-growing-up-and-now-we-dont-have-a-choice/#Linux #Wayland #Accessibility #Orca #GNOME #KDE #COSMIC #FOSS #a11y #BlindTech #xorg
       
 (DIR) Post #AvITM61gvHZuSU7JGi by fireborn@dragonscave.space
       2025-06-19T15:22:36Z
       
       0 likes, 0 repeats
       
       I probably posted this at a bad time for circulation.
       
 (DIR) Post #AvITM6Fs4Yv9ASkdN2 by fireborn@dragonscave.space
       2025-06-19T15:47:58Z
       
       0 likes, 0 repeats
       
       I updated the post to be a lot more clear on the current state of Xorg.
       
 (DIR) Post #AvIX6zgibcnUH1MSLw by azonenberg@ioc.exchange
       2025-06-19T18:40:04Z
       
       1 likes, 0 repeats
       
       @fireborn Hopefully Debian + XFCE will keep X around for a while more.There's still a lot of core features in X (including but not limited to absolute window positioning) that simply do not exist in wayland, and for political reasons seem unlikely to be implemented any time in the future despite being technically achievable.
       
 (DIR) Post #AvIX70fKyFHpJ1irq4 by azonenberg@ioc.exchange
       2025-06-19T18:51:33Z
       
       1 likes, 0 repeats
       
       @fireborn so yes, if and when wayland achieves feature parity with X i might switch.But right now they seem to be explicitly saying "we will not implement these features". There are multiple tools I use that are either going to be impossible to port to wayland or will require major backend rewrites (e.g. getting multiple top level windows with docking working in Dear ImGui) due to lack of absolute positioning information.
       
 (DIR) Post #AvIX719p8tfmpZzDMG by ignaloidas@not.acu.lt
       2025-06-19T19:28:19.135Z
       
       0 likes, 0 repeats
       
       @azonenberg@ioc.exchange @fireborn@dragonscave.space does that really need absolute positioning?They don't want to "get stuck" to a single coordinate system - current way allows a lot of freedoms, like freely rotatable windows (admittedly a gimmick, but why not?), or e.g. VR Wayland compositors (trying to do that in X11 would lead to a lot of pain).
       
 (DIR) Post #AvIX74zgsVwajJHB7Q by azonenberg@ioc.exchange
       2025-06-19T18:55:29Z
       
       0 likes, 0 repeats
       
       @fireborn Debian trixie still has X available (not sure if default for new installs but if you upgrade from bookworm it's there) so I should have at least until 2028ish
       
 (DIR) Post #AvIX79NwYHikLgebTc by azonenberg@ioc.exchange
       2025-06-19T18:56:40Z
       
       0 likes, 0 repeats
       
       @fireborn (also gnome dropping X11 support sounds like a feature, I won't have to deal with gnome anymore)
       
 (DIR) Post #AvIYjmwk0pf00JuzPE by azonenberg@ioc.exchange
       2025-06-19T19:34:23Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn Relative positioning for groups of windows under the same application is probably good enough.But as of now, there's no way AFAIK to do things like* Determine the position of one application window relative to another* Restore a saved window layout* Spawn a new window at the cursor location* Drag an application-managed (not window manager controlled) toolbar etc. out of the application and spawn a new top level window* Drag a window-manager controlled window into the application and dock it as a toolbarxdg-toplevel-drag looks like it has potential for some but not all of these use cases.
       
 (DIR) Post #AvIYjo6hhHDvbVaSZc by ignaloidas@not.acu.lt
       2025-06-19T19:46:32.557Z
       
       0 likes, 0 repeats
       
       @azonenberg@ioc.exchange @fireborn@dragonscave.space Restore has a protocol, you ask compositor to remember the window config, and ask to restore it on startup. Spawning new top level windows from a drag is possible, my Firefox is running Wayland-native, and I can drag a tab out of the toolbar to spawn a new window, and can drag tabs between windows and drag all tabs from one window into another window to leave only one open.But I don't see much utility for determining the relative positions between windows (no good way to define it without baking in assumptions), or spawning a window at the cursor location.
       
 (DIR) Post #AvIYjruRYnnFOdsj1E by azonenberg@ioc.exchange
       2025-06-19T19:35:28Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn in general any kind of docking/splitting workflow is a nightmare to implement without a flat coordinate system for at least all of the application's windows
       
 (DIR) Post #AvIYjwNew7XXGPa772 by azonenberg@ioc.exchange
       2025-06-19T19:45:29Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn representative examples:* https://github.com/ocornut/imgui/issues/6281* https://github.com/ocornut/imgui/wiki/Multi-Viewports#issues* https://github.com/ocornut/imgui/issues/8609At best, if you are using a compositor supporting xdg-toplevel-drag (not all have this) a subset of these features may be possible to implement with a complete backend dragging rewrite.Some, like "I want to restore a saved lab setup with every window exactly where I left it" are still impossible.
       
 (DIR) Post #AvIYr6cvEvZ94K8ZXs by sun@shitposter.world
       2025-06-19T19:47:53.870342Z
       
       0 likes, 1 repeats
       
       @ignaloidas @azonenberg what about old mac style applications where there's multiple windows and you arrange them
       
 (DIR) Post #AvIYvcxqx2gCWK5F2m by ignaloidas@not.acu.lt
       2025-06-19T19:48:41.749Z
       
       0 likes, 0 repeats
       
       @sun@shitposter.world @azonenberg@ioc.exchange I mean, you can have multiple windows and arrange them in Wayland, so I'm not sure what exactly do you mean?
       
 (DIR) Post #AvIZ58dMZerDLd2D1E by sun@shitposter.world
       2025-06-19T19:50:26.067925Z
       
       0 likes, 1 repeats
       
       @ignaloidas @azonenberg do they keep their position after you restart the app, I'm just asking I don't know
       
 (DIR) Post #AvIZ7iP2YaTArXZ1uK by ignaloidas@not.acu.lt
       2025-06-19T19:50:52.998Z
       
       1 likes, 0 repeats
       
       @sun@shitposter.world @azonenberg@ioc.exchange there is a way apps can ask for that, yes, though finalized only fairly recently.
       
 (DIR) Post #AvIa1qsSEhklMW5ets by azonenberg@ioc.exchange
       2025-06-19T19:54:23Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn I'm talking about it being file specific.If I have five different lab setups, I want to be able to load any given setup and have it potentially spawn four different windows across different displays exactly as I had it before. It's not "restore the one set of windows I had the last time i ran ngscopeclient" it's "restore the windows I had last time I was working on PDUEfficiencyCharacterization.scopesession".WRT spawning new windows from a drag the thing you're talking about is xdg-toplevel-drag. Not all compositors implement this, if yours doesn't have it you're SOL. So you have to implement fallback or disable multi window setups (and then figure out how to handle e.g. a saved gui layout that depends on multi window if you load on a different compositor than the one it was created on).
       
 (DIR) Post #AvIa1rmSsSYYAEIOCe by ignaloidas@not.acu.lt
       2025-06-19T20:01:00.752Z
       
       1 likes, 0 repeats
       
       @azonenberg@ioc.exchange @fireborn@dragonscave.space File specific brings you into assumptions that Wayland doesn't want to take on. If e.g. you opened your file in a VR compositor and set up your windows in some way, how would you expect those to be arranged on a flat screen compositor, or vice versa? If you had your stuff with overlap on KDE, how would a fully-tiling compositor like Sway should act?Though FWIW you can have multiple separate restore sessions, and as such have a different restore session per-file on the same machine.WRT compositor support - sure, not everything supports everything - Wayland is in many ways focused on bringing more power to the compositor over the application for window management, for better and for worse.
       
 (DIR) Post #AvIa1viMFfeEMePAMC by azonenberg@ioc.exchange
       2025-06-19T19:57:46Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn More fundamentally, wayland seems to be deliberately breaking the way things have worked for decades and inventing massive amounts of new work for developers for very limited benefits.The long term trend I see this causing is "less people port applications to Linux because it's a lot more work than it used to be since window management is totally broken".I have nothing against replacing X11, it's a crufy pile of junk, but you need to replace it with *something that has feature parity*. I see a lot of Wayland's unnecessary restrictions as being just as ridiculous as "Oh let's replace X11 with something that doesn't have function key support because making people remember hotkeys is bad for UX".
       
 (DIR) Post #AvIdBMrsxpyj353My8 by azonenberg@ioc.exchange
       2025-06-19T20:04:46Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn and this is the problem I have, they're making 99% of applications do a huge amount of extra legwork to support edge cases like VR.I'm fine with having extra extensions to support VR that you can use on request, but when you break workflows for the ordinary desktop use case the end result is already overworked open source maintainers getting stretched even further.
       
 (DIR) Post #AvIdBO1UfbG4dAYYaG by azonenberg@ioc.exchange
       2025-06-19T20:05:37Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn For ngscopeclient for example it's already a nightmare to support Windows, Linux, and MacOS platform differences.Making window management completely different on Linux is only going to make things worse. We already have a lot of problems on Wayland that none of the devs have the time to address and it's only going to get worse as distros start dropping X.
       
 (DIR) Post #AvIdBOv9KfmHPmb0Km by azonenberg@ioc.exchange
       2025-06-19T20:09:33Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn Right now when people have problems we tell them just to go back to X. That won't be an option forever.Rather than focusing on fixing bugs and developing new features, in order to avoid major feature set regressions like multi-window support suddenly becoming unavailable, we're going to be forced to burn precious developer hours reimplementing things that weren't broken, adding significantly more platform specific code than we had before, and making testing even more of a pain.
       
 (DIR) Post #AvIdBPkuEFB60IoL0S by ignaloidas@not.acu.lt
       2025-06-19T20:36:19.317Z
       
       0 likes, 0 repeats
       
       @azonenberg@ioc.exchange @fireborn@dragonscave.space FWIW, if you have problems with wayland, just disable wayland by default - XWayland is still a thing, and it's the precisely to allow moving to Wayland gracefully, and without regressions. As commented around the Kicad wayland post: https://lobste.rs/s/i4cjur/kicad_wayland_support#c_bb2kobThe real problem here is that no users should be getting the native Wayland mode by default at this point if it’s broken! There should be no need to warn anyone, it should just be disabled by default. It looks like that is the case on at least Fedora and I think Gentoo, but possibly not all distros. So I think this is actually a distro packaging problem? Users shouldn’t even care if the backend is X11 or Wayland or have to think about it. This is how almost every other app/toolkit has handled the transition, only flipping the switch once the UX is good enough.I've been running on Wayland for past 6 years, and the only real problem I had with it was screen sharing from Firefox (which didn't always work), which was solved good 3 years ago - even though very few programs had any Wayland support 6 years ago, let alone 3 years ago. Just running them with XWayland works great, and lets the wayland parts be developed "in the background" until it works well enough to be enabled by default. XWayland continues to get updates, and most likely will continue to get updates longer than raw X11 will be usable.
       
 (DIR) Post #AvIdBTRCXRnDQLceqe by azonenberg@ioc.exchange
       2025-06-19T20:18:29Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn And generally, from the perspective of actually being able to get my work done using the tool, I would much rather be in the "doesn't work in VR with no easy path to fix" state (X11) than "doesn't work on desktop with no easy path to fix" state (Wayland).
       
 (DIR) Post #AvIfyuqVckHUWjACga by ignaloidas@not.acu.lt
       2025-06-19T21:07:43.632Z
       
       0 likes, 0 repeats
       
       @azonenberg@ioc.exchange @fireborn@dragonscave.space also, FWIW I think this is a bit of an XY problem? You're looking how to make the application do things with windows, while Wayland philosophy is to make the compositor do things with windows on request of applications. A bunch of applications tended to do "window manager-y" things with X11 and Windows API's, because window managers for those just couldn't properly do a bunch of those things. Wayland wants only one thing to do window manager things, and as such stuff you have to re-architect applications that want to manage windows to request that from wayland, and wayland compositors need to implement those behaviors, generally enough to match them.
       
 (DIR) Post #AvIiWtZV4Hh2KRXQYq by azonenberg@ioc.exchange
       2025-06-19T21:17:15Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn yeah but the end result is that you still have to implement all of that stuff for Mac and Windows versions of your application, then you have to also support the Wayland way instead of just having one bunch of coordinate math and calling X11 vs WinAPI functions to apply those coordinates to window handles.Also, generally speaking most GUI toolkits distinguish between widgets (application managed) and windows (window manager managed). Windows is a bit of an exception (with native Win32 common controls you have each widget be its own HWND, although I'm not sure e.g. GTK on Windows does this).So there's always going to be a need for application-layer management for anything that isn't window-y enough to be considered a window manager window, and when you start doing docking and MDI and tabbing there's often a need to transition from one to the other. It gets complicated fast and making the complexity vastly different on one platform vs others just adds to the pain.
       
 (DIR) Post #AvIiWurcGPmKKv1PRA by azonenberg@ioc.exchange
       2025-06-19T21:20:17Z
       
       0 likes, 0 repeats
       
       @ignaloidas @fireborn So it's an XY problem in that what I want is "one way to do docking and multi window management that works on Linux, Windows, and MacOS".The least common denominator there used to be absolutely positioned, OS-window-manager managed, top level windows that you drew stuff inside of and could create, delete, move, and reposition as needed. Wayland breaks this, and the least common denominator is now "windows that you may or may not have any level of control over", sometimes the OS forces you to do certain things yourself, other times it won't let you do them at all or you have to ask it to do them, and maintaining a consistent UX across all platforms is effectively impossible.
       
 (DIR) Post #AvIiWviR621syjjalc by ignaloidas@not.acu.lt
       2025-06-19T21:36:15.567Z
       
       0 likes, 0 repeats
       
       @azonenberg@ioc.exchange @fireborn@dragonscave.space Eh, I don't see why wayland should go and copy other window management protocols just so porting is easier - after all, those protocols at least somewhat copied X11, and many of it's flaws. Wayland was thought of as a clean-sheet design, and sure, there are pains associated with that, but there are also benefits in dropping a bunch of the built-in assumptions. If you really wanted to keep stuff mostly as is, just gain a bunch of security, you could just set up a separate x11 server for each program and have a compositor deal with outputs from all of the servers - which is what XWayland is, and if you need it, use it.