Why are we deprecating X11?
Why are we deprecating X11?
Posted Feb 5, 2025 12:13 UTC (Wed) by ebassi (subscriber, #54855)In reply to: Why are we deprecating X11? by dskoll
Parent article: What’s new in GTK, winter 2025 edition
"Supporting" doesn't always mean "it works on somebody's computer"; for a library, it also means: "are the features exposed through the API available on this platform or not?". In this particular case, we're already not implementing features available on Wayland because they are missing entirely from X11; things that people use, like:
- graphics offloading, for zero-copy playback
- dmabuf object passing
- Vulkan support
On top of that, without a proper way to ensure that we don't break some random functionality only used by X11 outside of what we employ in our CI and test suites, we cannot reliably affect changes to how the backend is implemented, or keep it up to date with internal refactoring; this is mainly due to:
1. nobody in the GTK team is actively using X11
2. nobody that cares about X11 is willing to pick up the backend and implement features, fix bugs, or refactor the code to fit in
> This smacks of "move fast and break things" which is a really dumb approach to anything.
It's adorable to see what people that have zero experience or insight in GUI toolkit maintenance and development think about other projects.
Posted Feb 5, 2025 19:04 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link] (2 responses)
Posted Feb 5, 2025 19:36 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link]
Posted Feb 5, 2025 21:52 UTC (Wed)
by ebassi (subscriber, #54855)
[Link]
Performance. Feature coverage is another big one.
In general, we have no idea if the X11 drivers actually work with X11, or if they work within an acceptable performance envelope. Bug reports indicate that the nvidia driver, for instance, is about 3x slower when initialising Vulkan on X11 compared to Wayland.
Considering the amount of GTK developers actively using X11, there is simply no way for us to ensure a consistent experience on it.
Posted Feb 5, 2025 20:31 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link] (67 responses)
Merging https://gitlab.freedesktop.org/wayland/wayland-protocols/... would be a good place to start.
Posted Feb 5, 2025 21:46 UTC (Wed)
by ebassi (subscriber, #54855)
[Link] (66 responses)
These niche applications can go and use other toolkits—something they likely already are—instead of using GTK4, which already does not provide an API to global screen positioning.
The ext-zones protocol is a bad protocol, written for the wrong reasons; it has already been NACK'ed by multiple Wayland compositors, which is why it's in the "ext" namespace. GTK developers have zero interest in implementing client-side support for it, and re-introducing a whole lot of API to make it work only conditionally on some Wayland compositors. It's a waste of limited resources.
Posted Feb 5, 2025 22:21 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link] (3 responses)
Posted Feb 5, 2025 22:46 UTC (Wed)
by ebassi (subscriber, #54855)
[Link] (2 responses)
I'd also point out that most scientific applications are generally not designed by anybody, and are mostly thrown together to the undergrads that do the work, and then either turned in black boxes that get rewritten wholesale, or ossified by tenured professors. In either case, they rarely get iterated over by people who actually studied UI/UX principles.
The ext-zones protocol is just a way to keep stuff on life support for the sake of some random contract, in an environment that is so conservative about "how things are supposed to be done" that only death, or an emeritus position, are agents of change.
Posted Feb 5, 2025 23:43 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
I have never used Wayland, but I'm surprised to hear that applications cannot position top-level windows, or at least ask them to be positioned. Is that really the case?
It also seems that Wayland developers respond with "You shouldn't do that..." when it's a fairly reasonable request, but something they don't want to implement. And that's one of the reasons I will stick with X11 until it becomes completely infeasible.
Posted Feb 5, 2025 23:52 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link]
Posted Feb 5, 2025 22:25 UTC (Wed)
by TomH (subscriber, #56149)
[Link] (61 responses)
It's not just "niche applications" though, it's ordinary desktop users trying to do perfectly ordinary things.
There's no doubt that wayland is a vast improvement in many ways but it does drive me add that after ten or more years I still have to place all my windows manually everytime I restart my desktop because --geometry still doesn't work!
Posted Feb 5, 2025 22:51 UTC (Wed)
by ebassi (subscriber, #54855)
[Link] (60 responses)
Programmatically positioning random windows on the screen, or querying the screen position of a window to do something with it, is not "ordinary". I have no idea when that has become a thing, but it looks like any other shibboleth invented to have a horse in this front of the culture war. "Look at what THEY have taken from you", only with a stipple pattern instead of a Roman marble statue.
> There's no doubt that wayland is a vast improvement in many ways but it does drive me add that after ten or more years I still have to place all my windows manually everytime I restart my desktop because --geometry still doesn't work!
You're lucky, then, because there's a session management protocol, and it's getting implemented by all compositors and toolkits: https://gitlab.freedesktop.org/wayland/wayland-protocols/...
But user positioning has absolutely **nothing** to do with programmatic access to global screen coordinates.
Posted Feb 5, 2025 23:59 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link] (57 responses)
If the result is that some applications lose their Linux ports, that’s a net loss.
Alternatively, toolkits can implement ext-zones, SDL3, Qt6, and compositors can add support for it, and application authors can declare that compositors that do not support ext-zones are not supported. Users who are stuck with such a compositor can use a nested compositor that does have the needed support.
If I were writing an application that needed to manage its own windows, I would take the latter route.
Posted Feb 6, 2025 23:16 UTC (Thu)
by intgr (subscriber, #39733)
[Link] (56 responses)
Which was a huge mistake made during the browser wars of the 90s. Did it ever have a use case outside of annoying popup ads?
Posted Feb 7, 2025 12:44 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (55 responses)
It's a right royal pain that apps apparently can't pass a request to the window manager - why does xosview always start up - TWICE - in the middle of my screen when I want it tucked out of the way in a corner - but no I DON'T want apps able to plonk themselves wherever they want. If I'm actively working in a window, that window should be PINNED, IN FOCUS, and nothing else should be able to shove it out the way. Yes, let an app pop up somewhere else. Yes, let an app make the system tray flash saying "I want attention". Etc etc. But don't screw the user over in the middle of their work!
Cheers,
Posted Feb 7, 2025 13:06 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (54 responses)
How is windows being positioned programatically a security hole? I'd go nuts without that ability. I have four monitors and I use devilspie2 to position windows for certain applications more intelligently than the defaults. The lack of this ability would make Wayland completely unusable for me.
I'd be willing to live with only being able to programatically position a window once, when it is first made visible and never again thereafter. I don't have a use-case for programatically moving windows around once they've been positioned initially.
Posted Feb 7, 2025 14:22 UTC (Fri)
by daroc (editor, #160859)
[Link]
Unfortunately, it's hard to allow a user to programmatically customize their environment without also opening the door to problems like that.
For my part, I use sway configured such that I can move things around with swaymsg, but there's no way to steal focus without moving the mouse or using a built-in keybinding, and focus is visually obvious from the window decoration so I would notice any applications pulling shenanigans like that.
Posted Feb 7, 2025 14:37 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
Have a window grab focus just as you're about to type a password ... ? Yup, I know that's not quite "being positioned programmatically", but it's pretty much seen as the same thing ...
I'm not sure it was quite that scenario, but I got confused as to which window had focus and typed my password into a chat channel ... OOPS!
I'm sure some bad hat can find a way to exploit that. As I say, I regularly have grief with windows grabbing focus away from the window I'm working in, and it really does not make for a pleasant working environment ...
Cheers,
Posted Feb 7, 2025 16:22 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (1 responses)
Positioning a window and stealing focus are two different things. I'd be fine (for example) with programatically-positioned windows automatically being put at the bottom of the stack so they can't move themselves over another window maliciously.
Posted Feb 7, 2025 17:22 UTC (Fri)
by paulj (subscriber, #341)
[Link]
E.g., when I have to enter a PGP key on my desktop a GUI window pops up. It takes focus and NOTHING else can get focus from it. Anything I type can only go to that window and nothing else.
I assume the window is from seahorse, and I assume this is thanks to the X11 Security extension. I can't easily check the process as I can't mouse over to a terminal, cause of the focus lock. Not even the X server "change to console" key combo works at this point. The X11 Security extension allows applications to be "untrusted", but I don't know exactly how this is setup to make it so this password window is trusted and everything else is not. ??
Posted Feb 7, 2025 14:46 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (41 responses)
For instance, there are compositors such as Niri (infinite scrollable workspace) that do not have a concept of a coordinate space — at all. Or perhaps there are/could be compositors for VR environments that would be incompatible with a _2D_ coordinate space. Then, there is a choice of per-output coordinate space vs. global coordinate space.
If you choose some specific sort of a coordinate space and enshrine it in a protocol, this would lead to one of two things: either restrict Wayland from ever outgrowing that particular kind of coordinate space, or create an unfixable split between apps that use this protocol and compositors that are fundamentally incompatible with this kind of coordinate space.
Posted Feb 7, 2025 16:25 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (40 responses)
Wayland tries very hard not to paint itself into a corner by adopting concepts that would be insufficiently generic.
There's a huge risk of over-engineering then. And also, wasn't that a big criticism of X11? That it tried to be too generic and didn't impose much in the way of policy?
It's no good making your code adapt to all kinds of possible weird scenarios if it can't do what existing code does and what people want it to do now.
Posted Feb 7, 2025 19:43 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (39 responses)
Exactly. That's why there is no protocol for top-level positioning *at all* instead of someone making an "everything-and-a-kitchen-sink" protocol that would include N-way coordinate spaces, non-Cartesian geometries, arbitrary relative positioning against any existing objects or origins, provisions for independent sub-spaces, and whatever else one would need to cover at least the things I outlined above.
> And also, wasn't that a big criticism of X11? That it tried to be too generic and didn't impose much in the way of policy?
No. The big criticism of X11 is that everything that should've been a policy was a mechanism, and everything that should've been a mechanism was a policy. In other words, X11 operates in terms of abstractions so outdated that there was no way to reconcile them with contemporary applications and hardware without turning X11 into a glorified slow and crappy IPC bus (which is precisely what it degenerated into).
> It's no good making your code adapt to all kinds of possible weird scenarios if it can't do what existing code does and what people want it to do now.
One can philosophize all day long, but it still does not resolve the very practical concern I outlined: there *already* are several extant or immediate-future applications of Wayland where there is *no* concept of a coordinate space that would've satisfied legacy applications and users of such.
Posted Feb 7, 2025 20:08 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (38 responses)
In that case, Wayland is probably going to fail. If it can't have at least feature-parity with what it's supposed to replace, then it's not worth switching to it. And honestly, N-way and non-Cartesian coordinate systems for a windowing system that's supposed to manage a 2D desktop seems absurd. I just don't get it. Ultimately, no matter what, a window is going to boil down to a bunch of pixels on the screen, typically in a rectangular region parallel to the coordinate axes.
I remember all the fancy X window managers that made use of compositing to show you all your windows on a rotating cube or whatever... they were fun for about a minute and then just got irritating. Desktop paradigms consisting of rectangular windows, buttons, etc. have been around for 30+ years and people are used to them. Nobody's asking for radically-new paradigms.
Posted Feb 7, 2025 20:13 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (29 responses)
Yeah, right.
> And honestly, N-way and non-Cartesian coordinate systems for a windowing system that's supposed to manage a 2D desktop seems absurd. I just don't get it.
It seems so, given that I've said several times that Wayland is "supposed" (designed) to do things *beyond* managing a 2D desktop. If you ignore essential parts of my reasoning, then of course you wouldn't get it.
Posted Feb 7, 2025 20:27 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (28 responses)
But we don't want anything beyond a 2D desktop. That's mission creep.
Posted Feb 7, 2025 20:31 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (27 responses)
I thought that Wayland was supposed to have more users than just the LWN subscriber "dskoll". I might be wrong, of course.
Posted Feb 7, 2025 20:36 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (26 responses)
"We" is more than dskoll. It is, I'd wager, the vast majority of computer desktop users. Who especially are uninterested in experimental things when basic existing things don't work.
Posted Feb 7, 2025 20:42 UTC (Fri)
by pizza (subscriber, #46)
[Link]
The vast, vast majority of "computer desktop users" are using MS Windows and couldn't give two craps what this "Leenux" thing is.
The vast majority of the remaining folks are using MacOS, and similarly couldn't care less.
Posted Feb 7, 2025 20:42 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (24 responses)
Posted Feb 7, 2025 20:48 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (23 responses)
I'm speaking on behalf of everyone I know who uses a desktop. You claim top-level window positioning is "niche". Do you have data to back that up? If it's so niche, why is it the case that every single desktop environment supports it? Did they misread how "niche" it was?
Posted Feb 7, 2025 20:53 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (2 responses)
So far, I have seen no indication that "we" is anything more than a rhetorical device. Thus, I will continue to treat it accordingly.
Posted Feb 7, 2025 21:08 UTC (Fri)
by daroc (editor, #160859)
[Link] (1 responses)
Posted Feb 7, 2025 21:09 UTC (Fri)
by intelfx (subscriber, #130118)
[Link]
Posted Feb 7, 2025 20:55 UTC (Fri)
by pizza (subscriber, #46)
[Link] (19 responses)
Once upon a time, "every single desktop environment" had full root priveleges and any application could freely access the state of any other application.
That doesn't mean that either "feature" was a good idea.
Posted Feb 10, 2025 9:42 UTC (Mon)
by paulj (subscriber, #341)
[Link] (18 responses)
Least, I can not use xev to snoop on keyboard entry into other windows.
Posted Feb 10, 2025 13:00 UTC (Mon)
by pizza (subscriber, #46)
[Link] (8 responses)
xev only cares about events relating to its own window (or the root window). It doesn't report global keypresses or mouse events. However, this global input state is still clearly accessible, as xeyes continues to follow every cursor movement even as xev reports nothing happening.
(Reproduced just now on Fedora 41's GNOME Xorg session)
Posted Feb 10, 2025 13:28 UTC (Mon)
by paulj (subscriber, #341)
[Link] (7 responses)
I'm just curious what mechanism is stopping xev from watching keyboard events on other windows? Did Xorg fix the X11 keyboard snooping issue? Is the "Security" extension? Is it something else? What are the limitations?
Additionally, I'd love to know what mechanism Seahorse is using. Is it X Security and seahorse is a trusted application somehow (where is that specified?)? Or is it just doing a normal X11 GrabKeyboard call, like any app can do? (E.g. the venerable "xterm" has a "Secure Keyboard" option in its ctrl-<left click> popup menu, which does a GrabKeyboard and enables reverse video so long as it holds - so you can be reasonable sure other X clients can not snoop.
Posted Feb 10, 2025 13:36 UTC (Mon)
by paulj (subscriber, #341)
[Link] (6 responses)
Setting other issues with the X code-base aside (lot of it due to its age?), the keyboard issue surely did not need a "empty the bathtub" approach of itself. Only a few applications need such a capability, and a mechanism to label a trusted set of such securely for the X server surely would have been possible, in terms of protocol.
Posted Feb 11, 2025 17:33 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Maybe? But all the X maintainers moved to developing Wayland rather than doing so (and no one has stepped up to continue X maintenance in the interim).
Posted Feb 11, 2025 18:00 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
And once you're going as far as removing large chunks of core protocol because they're no longer relevant, resetting extension behaviour to a sane shared state etc, you end up with effectively Wayland. You could have called it X12, but the X11 developers who created Wayland felt that it was sufficiently far from what X11 had become that it would be clearer to give it a whole new name, rather than calling it X Window System version 12.
Posted Feb 11, 2025 18:21 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
It wasn't that it was sufficiently far enough from X11, it was that there had already been an abortive X12 rewrite, and for whatever reason they didn't fancy X13 ...
Cheers,
Posted Feb 11, 2025 19:51 UTC (Tue)
by jem (subscriber, #24231)
[Link]
Using the name X12 or X13 would probably have provoked a lot of protests, since Wayland is *not* X. There is not direct lineage from X11 code to Wayland code (Wayland isn't even an implementation, just a specification), Wayland is totally lacking the core of X11, and the X11 and Wayland protocols are totally different, and have different roles. Calling Wayland X12 or X13 is simply wrong, since it is totally incompatible with Core X11.
Posted Feb 11, 2025 18:21 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
The problem with X has always been the server itself. It's a huge chunk of code written in an ancient C style, that shares the state across all applications. It also does complicated drawing operations, text rendering, etc.
There is simply no realistic way to make that mess secure. Adding ACLs on top of it is just like adding locks for a knee-high fence. Sun tried that with Solaris Trusted X-Windows thingie ( https://www.filibeto.org/sun/lib/solaris10-docs/trusted-e... ), but nobody really trusted it.
Posted Feb 11, 2025 19:09 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
And note that XACE tried to add the hooks needed to secure X11, but actually writing policies around those hooks to prevent malicious clients causing trouble, while not blocking off legitimate clients, is a tall order that nobody actually bothered to do; in many respects, being able to run multiple XWayland instances is a simpler solution to get to the same place.
Posted Feb 10, 2025 13:19 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (8 responses)
X11 has never sent all keyboard events to all clients; the thing that's broken in the X11 model is that I can get the window IDs for all clients, and snoop on any window given that I know its ID.
Posted Feb 10, 2025 13:40 UTC (Mon)
by paulj (subscriber, #341)
[Link] (7 responses)
However, the Xinput2 extension does seem to expose this hole.
Posted Feb 10, 2025 13:50 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
It's probably the fact that the Xorg server no longer runs as root.
Cheers,
Posted Feb 12, 2025 2:14 UTC (Wed)
by whot (subscriber, #50317)
[Link]
Or as an analogy: running grep as root doesn't change how grep's regular expressions work.
Posted Feb 10, 2025 14:06 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (4 responses)
Monitoring all input is thus a bit of a pain - you have to track all window IDs and monitor the "right" ones.
Posted Feb 10, 2025 14:15 UTC (Mon)
by paulj (subscriber, #341)
[Link] (3 responses)
- xev /does/ receive all MotionNotify events as I move my mouse over the target xterm
- xev does /not/ receive any keyboard events as I type into the target xterm
What method are you using?
Posted Feb 10, 2025 14:55 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
I then choose the child window of the named window, 0x3a00021, which I happen to know from past experience is the one that's actually receiving keypresses after I click inside the xterm window. Then, with xterm focused by a mouse click, I can type into the xterm and see:
Note that I have to take a bit of care here to make sure that I'm looking at the right window in the stack belonging to xterm, and that the exact window that gets input will change depending on how I've focused xterm. A "real" malware would track all windows on the system (same way as xwininfo -root -tree does) and get events for all of them.
Posted Feb 10, 2025 15:13 UTC (Mon)
by paulj (subscriber, #341)
[Link] (1 responses)
Thanks.
Posted Feb 10, 2025 15:19 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Posted Feb 8, 2025 10:22 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (7 responses)
Wayland intends that to be entirely a compositor decision at protocol level; in X11 the application says "I want to be top-most window on the right-hand display, 3 pixels from top-left and 2000 pixels square", with the API saying that this is a requirement that the compositor is expected meet, even if two applications want to be top-most window, and practical compositors ignoring this and overriding the application's request. Instead, your compositor is supposed to provide the user (and only the user) with tools to set where windows go; applications get positioned and sized where the compositor chooses to place them.
Nothing stops a compositor offering a CLI tool to set window positions; it's just not something that Wayland is going to define for apps to use, but something that Sway/KDE/GNOME/whatever else you choose to use has to provide. Separately to this, there's an ongoing discussion about providing MDI apps with a way to position their windows relative to each other, but it's slow-going because Wayland is trying to avoid the issue where two apps can make conflicting demands of the compositor, and require heuristics to decide which one wins.
Posted Feb 8, 2025 13:29 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
Which is obviously a massive booboo if the screen just happens to be 480 x 640 pixels...
Again, the number of times I lose windows on Windows, because when they re-open my screen estate has changed, and they position themselves somewhere that no longer exists :-)
Cheers .
Posted Feb 10, 2025 9:50 UTC (Mon)
by paulj (subscriber, #341)
[Link]
One of the most frustrating things when you're forced to use MS Windows as the WM on a corp laptop. (At least WSL gives me a proper Linux environment - though unfortunately, with a default display server [wayland] whose clipboard integration still sucks a bit; At least compared to VcXsrv, which I still prefer for that feature, but unfortunately it requires display to go over TCP/IP from WSL apps to the VcXsrv in the windows session, and that will get reset everytime you suspend resume - so you need another layer of indirection, via xpra, to get around that, if it matters).
Posted Feb 8, 2025 16:25 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (4 responses)
This is a feature that your compositor is supposed to provide, not your application.
Yes... is that not how it works in X11? The application or a command-line tool can request a certain geometry for a window, but it's up to the window manager to make it happen (or not, as it sees fit.)
If Wayland compositors offer a command-line tool to request window positions and geometries, then that's fine... that's all I'm asking for. It might be nice to standardize how such requests are made to the compositor, though that may be out of scope for the Wayland spec.
Right now, I use XFCE4 on X11. The XFCE people are apparently working on Wayland support, so once that's deemed ready, I might give Wayland a try.
Posted Feb 8, 2025 16:39 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Seeing as the application could easily be on one system, and the windowing system on another, surely it would make sense for Wayland to say "this is how you do it"? "Compositors ignore requests they don't know how to handle" is a perfectly reasonable part of the spec, surely?
Take a leaf out of WordPerfect's book, from 1994 for $deity sake ... which is why my ancient copy of WP6 could round-trip a document written using WP2003 *without* *losing* *features*. WordPerfect defined a "well formed format instruction", and - from WP6/1994 on - everything used these. The important thing was that they were defined as "if you don't recognise it, you ignore and preserve it".
So if somebody defines a bunch of 3D instructions, which somehow get passed to a 2D compositor, it will ignore them. But if the 2D compositor can call a 3D compositor, and these are part of the stream that get passed on, the 3D compositor is guaranteed to receive them.
If Wayland doesn't do this already, I'd be surprised. Or could this be like remote windowing, which took ages to be implemented because "Wayland permits it, but nobody's stepped up to write it"? I gather Wayland can do it now, but when I was asking about it's absence years ago, that was the standard response - "nobody's written it yet".
Cheers,
Posted Feb 8, 2025 16:57 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (2 responses)
This is obviously absurd, but is how the X11 spec was written, since it massively predates badly behaved GUI applications.
XFCE can provide you such a tool that works on XFCE but not on GNOME or KDE, but there's no intent to standardise how such requests are made, in large part because evidence from every platform that's standardised such requests is that some applications will falsely claim to be asking you to set their position and stacking order (and focus, if they can) because the human asked them to, when in fact you did not. It's considered better to let badly behaved software have to implement the bad behaviour for every environment differently, rather than to standardise a way to misbehave.
Posted Feb 8, 2025 19:32 UTC (Sat)
by kleptog (subscriber, #1183)
[Link] (1 responses)
The spec may have said that, but many window managers routinely ignored such requests, especially tiling WMs. So your concerns, while real, don't seem to have caused any meaningful problems the last few decades, so I don't really understand why they would occur under Wayland.
Posted Feb 8, 2025 19:36 UTC (Sat)
by farnz (subscriber, #17727)
[Link]
This is a really annoying misfeature, because I've often arranged them to not overlap, but they don't bother checking for that - just Z-order. And it tends not to be an issue unless you're running proprietary apps that are required to do a job, because FOSS apps tend not to have this sort of user-hostile behaviour.
Posted Feb 7, 2025 17:28 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (7 responses)
AFAIK, at least the more configurable compositors (e.g., river) have this support. KWin had it with X11 back in late-00's (almost certainly earlier too), so I would imagine it may have gotten a port as well.
But I agree with Wayland here…move-on-startup is up to the compositor to perform, not the application itself. As a tiling window user, applications can, at best, request an aspect ratio. Beyond that, I have rules in place to allow dialog (and similar) windows to start floating rather than tiled. Positioning and scaling beyond such a request is completely up to XMonad though.
Posted Feb 7, 2025 18:56 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (6 responses)
But I agree with Wayland here…move-on-startup is up to the compositor to perform, not the application itself. I am not that familiar with Wayland, so I'm assuming "compositor" is roughly equivalent to "window manager". And that's how it works in X11: An application can request a certain geometry (size and position) for a top-level window, but it's up to the window manager to accommodate the request. As long as Wayland compositors can do something similar, and let me run the equivalent of devilspie2, I'd be satisfied.
Posted Feb 7, 2025 21:21 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
Cheers,
Posted Feb 7, 2025 21:22 UTC (Fri)
by dskoll (subscriber, #1630)
[Link]
Wol, you don't count because you're niche.
Posted Feb 8, 2025 23:28 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 8, 2025 23:37 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
The control is somewhat backwards here. *Applications* should not request anything about positioning. *You* request it via configuration of your compositor. For example, I tell XMonad[1] to "center float" new dialog windows. Without that rule, they end up tiled like everything else regardless of what "position" they request (size is far more application-specific; XMonad usually at least grants the aspect ratio, but without doing whatever `mpv` does to *react* to the size it actually gets, layouts can get busted). Similarly, river (a Wayland compositor) does this with "rules"[2] upon window creation.
> As long as Wayland compositors can do something similar, and let me run the equivalent of devilspie2, I'd be satisfied.
It's really down to the compositor you choose. The "upon close" part may be harder to find, but the "upon open" actions are certainly around (with varying available actions between compositors). But it's not going to be a separate tool but rather the compositor itself conducting things (either performing the actions itself or delegating to some external tool over an IPC mechanism).
[1] X11, but it is more comparable since it is far more in the bucket of not giving two hoots about application positioning requests.
Posted Feb 10, 2025 9:30 UTC (Mon)
by geert (subscriber, #98403)
[Link] (1 responses)
OK, applications should not request it, the user launching the application does. I don't care whether this goes through the application (i.e. the old X11 "--geometry" command line hint that lots of applications still have), or through a third party (e.g. the compositor).
> For example, I tell XMonad[1] to "center float" new dialog windows.
How do I ask the compositor to position a specific window?
Thanks!
Posted Feb 10, 2025 11:32 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Depends on your compositor. GNOME is probably not going to support your use case, but you could get `river` to do it.
> My use case is a script that launches a zillion of terminal emulator windows, some running a specific application (e.g. screen /dev/serial/by-id/... or ssh), carefully laid-out on my multi-monitor setup.
First, I would use `tmux` and its layout controls (still running `screen` because, yes, it is very good at talking to serial devices). If you need to multiplex commands, there is the `synchronize-panes` option to send input to all panes in a window. But if you want to have top-level windows, here's how I would do it in XMonad:
- set the layout for the workspace to Grid (or anything that is suitable for you)
With `river`, I would do it largely the same (though s/workspace/tag/). However, I'll note that I am still in the process of migrating to river, so this is just based on my limited understanding of its capabilities, not from experience.
Posted Feb 6, 2025 7:18 UTC (Thu)
by TomH (subscriber, #56149)
[Link] (1 responses)
Well that's certainly interesting though I thought Gnome had deemed session management unworkable about 20 years ago and given up on it, long before the wayland era.
Which is why for years I had a script that I ran to launch all my terminals, which positioned them with --geometry (though even X would let me put them on the right virtual desktop) and I still run that today just now I have to move each window to the right place manually.
Posted Feb 6, 2025 10:10 UTC (Thu)
by ebassi (subscriber, #54855)
[Link]
That was mostly the result of XSMP being broken and unimplementable as a protocol, with every single implementation being subtly (or not subtly) different. We've been trying to fix session management for at least 15 years, but it's a hard topic and not many people are willing, or have the social capital, to drag everyone on board. It's exhausting, and there are so, so many other fires to extinguish before dealing with re-positioning windows at login.
Why is X11 incompatible with Vulkan?
Why is X11 incompatible with Vulkan?
Why is X11 incompatible with Vulkan?
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
Linux lacks the market share to make applications conform to Wayland
There are things that do not work on Wayland yet
>
> The ext-zones protocol is a bad protocol, written for the wrong reasons; it has already been NACK'ed by multiple Wayland compositors, which is why it's in the "ext" namespace. GTK developers have zero interest in implementing client-side support for it, and re-introducing a whole lot of API to make it work only conditionally on some Wayland compositors. It's a waste of limited resources.
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
Wol
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
Wol
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
It's not just the keyboard issue - the underlying driver for Wayland is that about 90% of the X11 core protocol is not used any more, and there's a large number of interacting extensions that have evolved over time and don't play as nicely with each other as you'd like in the areas where they overlap (MIT-SHM with DRI2 and DRI3, Xinerama with RandR, Composite and Damage with core) because people have evolved them independently. The consequence is that you have to "just know" that you must ask DRI3 to do something, not MIT-SHM, or that you should trust Damage over core protocol, because Damage is more precise.
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
Wol
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There's a side problem that even if you rewrote the codebase in modern C++, Haskell, Rust, or something else, you'd be writing a lot of new code to handle cases that basically don't happen any more, but are required by X11's core protocol (which, after all, is from the 1980s). You'd have to handle 2D acceleration as done in the 1980s (not accelerated by modern GPUs), palette-based colour modes as well as truecolour modes, monochrome pointers, an assumption that sound is a bell controlled by the graphics terminal, pre-Unicode keyboard mapping and more.
There are things that do not work on Wayland yet
xev only snoops on one window at a time - by default, its own window. To snoop on another window, you need to use xev -id $WINDOW_ID, or xev -root to snoop on the root window. Something like xwininfo -tree -root can be used to find all the windows on the system so that you can target your snooping.
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
Wol
There are things that do not work on Wayland yet
It absolutely does on my setup as long as I use the right window ID - note that xev does not change the requested event mask on windows belong to applications, so you can't just choose a window ID at random, but must choose one that's requested input.
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
I run xterm, and find its details from xwininfo:
There are things that do not work on Wayland yet
$ xwininfo -tree
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x3a00012 "user@host:~"
Root window id: 0x34b (the root window) (has no name)
Parent window id: 0x20002d (has no name)
1 child:
0x3a00021 (has no name): () 499x316+0+0 +3174+913
1 child:
0x3a00026 (has no name): () 14x316+-1+-1 +3173+912
KeyPress event, serial 21, synthetic NO, window 0x3a00021,
root 0x34b, subw 0x0, time 43084264, (281,284), root:(3455,1197),
state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XmbLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyRelease event, serial 21, synthetic NO, window 0x3a00021,
root 0x34b, subw 0x0, time 43084309, (281,284), root:(3455,1197),
state 0x10, keycode 25 (keysym 0x77, w), same_screen YES,
XLookupString gives 1 bytes: (77) "w"
XFilterEvent returns: False
There are things that do not work on Wayland yet
Knowing that it's a child window takes some experience of how xterm (unlike more modern applications) works; most applications just have a single window for their entire drawable area, and ask for all the interesting events, handling everything client-side, but xterm is old enough to have been optimized for doing everything over a 10BASE-2 LAN, and thus tries not to get keypress events if it's just going to ignore them.
There are things that do not work on Wayland yet
This is a feature that your compositor is supposed to provide, not your application. That's the fundamental argument going on here; in X11 and older versions of Windows and macOS (but not current ones), applications are supposed to be able to set window stacking order and positioning in terms of absolute screen coordinates, along with knowing precisely which pixel positions correspond to which displays.
Top-level window positioning decisions
Top-level window positioning decisions
Wol
Top-level window positioning decisions
Top-level window positioning decisions
Top-level window positioning decisions
Wol
No; in X11, the application sets its location and stacking order, and the compositor/window manager can then change that after the fact. A window manager is supposed to respect the demands of the applications, and per the letter of the spec, if two applications both want to be top-most, they're supposed to both be on top of each other, and which one wins is based on whose requests arrive last at the X server. Further, applications get notified when their windows are moved or restacked, and can then tell the X server to change it; all a window manager can do is continuously tell the X server to restack and move windows, and if the application insists on undoing that, it all falls to pieces.
Top-level window positioning decisions
Top-level window positioning decisions
I've had more than one X11 app from a vendor run at 100% CPU if I have a second app from the same vendor running - both apps demand to be on top, and when they get told they're not, they tell the X server to restack windows. The result is that both apps spend a lot of time restacking each other, until I quit one.
Top-level window positioning decisions
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
Wol
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
There are things that do not work on Wayland yet
[2] https://wiki.archlinux.org/title/River#Window_rules
There are things that do not work on Wayland yet
My use case is a script that launches a zillion of terminal emulator windows, some running a specific application (e.g. screen /dev/serial/by-id/... or ssh), carefully laid-out on my multi-monitor setup.
There are things that do not work on Wayland yet
- launch all the windows while it is active (or have rules that put them on that workspace)
There are things that do not work on Wayland yet
>
> But user positioning has absolutely **nothing** to do with programmatic access to global screen coordinates.
There are things that do not work on Wayland yet
Well that's certainly interesting though I thought Gnome had deemed session management unworkable about 20 years ago and given up on it, long before the wayland era.