As a recent Linux (and Wayland) switcher, I love this behavior. It has always felt insane to me that macOS will just let some random auto-updater steal focus and eat your keystrokes while trying to work on something.
Powerful permissions are needed for powerful apps.
I don't know about this particular issue, but for example, KiCAD has multiple issues with wayland being overly protective: [0]. For example KiCAD needs the ability to move cursor to provide good user experience. KiCAD needs the ability to move and place windows wherever it likes. KiCAD needs to control focus. KiCAD needs to prevent OpenGL throttling on inactive windows. These issues led KiCAD developers to reduce support for Wayland configurations to a bare minimum.
So it's a delicate balance for operating systems to both allow powerful apps to implement complicated UI and to prevent badly written apps to do inconvenient things.
As a user of KiCAD, I have not found any need for it to automatically move cursors or windows around (nor do I even remember such behaviour pre-wayland, so it can't have been important), but note that the cursor-warp protocol is coming to allow the former, and window tags are coming to allow things like window placement restoration, which should help where this may benefit UX.
Technical note, OpenGL is for rendering, which is unrelated to presentation. Window managers and display servers have no part in that process. It's the Window System Integration (WSI) if used, such as EGL or Vulkan WSI, and in the old days GLX, that talk to the display server.
Wayland only provides an optional suggestion for when it is a good time for a window to render for good frame pacing, latency and performance without the app having a full proper frame scheduling implementation itself. The issue that tends to crop up is that EGL, a WSI often used with OpenGL in apps not using a toolkit, when specifically told to block and wait for next frame, has been internally implemented to use the optional suggestion which is not provided for invisible windows.
Stuff is being done to solve this, and it doesn't affect applications that do not ask to block on updates (say, firefox), nor applications leaving this up to a toolkit (say, Gtk or Qt) or just a different window system integration than EGL (which is extremely limited on its own anyway).
Unfortunately the KiCAD messaging has been a bit messy. They list a spectrum of issues, some of which are very vague and also clearly issues with KiCAD (like "Application freezes and crashes: Instability issues specific to the Wayland environment" - unless the compositor is crashing I fail to see why you would assume KiCAD crashing is an issue with Wayland or your compositor.) On the other hand I don't really blame application developers for being frustrated in general, because a lot of us have been waiting a really long time to see Wayland issues get resolved, and the pace was so slow until recently that it basically felt like it would take an eternity for anything to get resolved. These days though, the pace is very fast, to the point where almost anything written about Wayland will be out of date in a couple of months, mostly for good reasons.
> KiCAD needs the ability to move cursor to provide good user experience.
Most applications are implementing pointer warping using pointer-constraints-unstable-v1. This lets you confine the pointer to a region, at which point you can use relative events to get movement, render the cursor yourself and do whatever you want. There is the locked_pointer_v1::set_cursor_position_hint function to allow one to set the location where the cursor should be released at when the constraint is lifted, which should make everything seamless.
And sure, it might actually be that pointer-constraints-unstable-v1 isn't enough for KiCAD's particular UX somehow, maybe they need pointer-warp-v1 or something even more advanced. However, applications generally don't need to set the mouse position to arbitrary locations on-screen at any time... That is a useful capability for something doing automation, but it should really not be needed for general application development.
> KiCAD needs the ability to move and place windows wherever it likes.
KiCAD isn't a window manager, it's a damn EDA tool. I do agree that Wayland needs to provide multi-window applications with better tools to hint to the compositor what to do with window placement and especially to save and restore window positions, but this doesn't translate to "applications need to be able to decide where exactly windows go." There is basically no behavior which literally requires this, and certainly no sane behavior that requires this.
Having every application perform its own sort of logic to decide where windows go is a mess everywhere it exists. It would be cleaner and better for users if we could just figure out what sorts of higher level tools applications need for good UX and try to build around that. In most cases merely being able to position windows relative to each-other is enough. (You can obviously do this in Wayland already to some extent, though I'm sure there are missing tools that are needed.)
On Wayland today, applications can't absolutely control window placement, or even know where they are on screen. There really isn't even a global window coordinate space to even leak to applications. It's a pretty radical departure from almost everything else, so yeah, application developers are obviously not thrilled about having to deal with it. But on the other hand, it's probably the right way to go. Just because ability to control absolute positions is convenient does not mean it is necessarily the right way to go, especially if you can provide higher level tools that encode intent better and let the user decide how your application's intent should be interpreted.
> KiCAD needs to control focus.
Honestly I have no clue what they're complaining about with focus. It's too vague.
If your application is in the foreground, you can grab an activation token and use it, so even with "extreme" focus protection, there should not be any issues with KiCAD being able to focus its own windows.
As for other software being able to focus itself from KiCAD, well, this article describes how you do it. It's pretty straight-forward and it's not obvious how you would misuse it. Pretty sure the same protocol exists in X11 as well.
They're also talking about modals, which might be related to their complaints. The xdg-dialog-v1 protocol (supported in KDE 6.4, GNOME 48, and used by Qt 6.8+) gives applications the ability to mark dialogs as modals. It is a bit crazy that it took as long as it did for this to become supported by everything, but it did cross the finish line. On Ubuntu 25.04, for example, you should get GNOME 48 and Qt 6.8.
> KiCAD needs to prevent OpenGL throttling on inactive windows
OpenGL isn't throttled, it is stalled if the window is entirely occluded. You can now resolve this issue with the fifo-v1 protocol and Mesa 25.0 or newer. For example, Ubuntu 25.04 ships Mesa 25.x and GNOME 48 which has fifo-v1. fifo-v1 is also available in KDE as of 6.4.
This should give applications the frame pacing behavior that they want. It is possible to work around the issue to some degree, it's just annoying.
If KiCAD developers don't want to support Wayland because it's effort they'd rather spend on other shit then fine, XWayland should mostly continue to work as-expected anyways. Best option for now is to force KiCAD to use X11, like Krita does. I'm sure that's not a 100% panacea but it should be good enough especially if KiCAD is so buggy on Wayland that it actively crashes.
They are free to create new protocols (or use existing ones) that allow these higher privileged functionality. Then the server implementation will hopefully figure out a decent way to request that permission and the app can then have it.
(Though this permission may be display server-dependent, as it may not make sense in case of each).
I have either approved or denied about a dozen things on my MacOS work laptop and have no idea what they were because I was in the middle of typing a sentence and happened to hit the spacebar when the dialog popped up. Hope none of them were too important!
Since it's usually Apple's own OS stuff usually to blame with their incessant "GIVE ME YOUR PASSWORD... something something updates" dialogs, I won't hold my breath.
If it does just let anything get the focus than it is still somewhat okay. The worst thing is you open a folder from some other app and nothing happens, the desktop did not switch to finder at all. And after you switched it manually. The whole ten windows opened at same time.
Seriously question about focus stealing: What is state of the art at the moment for desktop windowing systems? Is the "correct" action when a window wants to steal focus: Pop under the active window and give a non-focus stealing hint (UI balloon?) to the user that this window needs attention?
I can think of two real world examples: (1) debugger hits breakpoint and steals focus (this is sometimes configurable), (2) WiFi needs re-/auth.
I don't think there should be a "correct" way to steal focus. When I'm editing a document, I don't want _any_ application to steal focus. I don't want a window to show up and steal focus when something needs reauthentication. Maybe the developer of an application thought that his use case is of the very utmost urgency and requires immediate action. I don't agree. Just notify me over the standard way that the system provides and I will deal with it when I want to.
For the debugger use case: If the IDE has already focus, it can pass an activation token to the debugger and the debugger can use this to focus itself. If the IDE is not focused, I don't want the debugger to steal focus.
> It has always felt insane to me that macOS and Windows will both just let some random auto-updater steal focus and eat your keystrokes while trying to work on something.
Wait, what? Hasn't Windows prevented focus stealing for literally decades at this point?
It used to block focus stealing aggressively unless a program had foreground permission or was given it (AllowSetForegroundWindow), but the mechanism seems broken in current versions of Windows.
Yup. I used to use a Macbook Pro as my daily driver and played League of Legends on it... and the amount of forced-focus was infuriating. You just locked in and are messaging your friend on Discord about something? Well, there's 10 seconds left until the game starts and that's more important so you're focusing the League client now.
vbezhenar|6 months ago
I don't know about this particular issue, but for example, KiCAD has multiple issues with wayland being overly protective: [0]. For example KiCAD needs the ability to move cursor to provide good user experience. KiCAD needs the ability to move and place windows wherever it likes. KiCAD needs to control focus. KiCAD needs to prevent OpenGL throttling on inactive windows. These issues led KiCAD developers to reduce support for Wayland configurations to a bare minimum.
So it's a delicate balance for operating systems to both allow powerful apps to implement complicated UI and to prevent badly written apps to do inconvenient things.
[0]: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...
arghwhat|6 months ago
As a user of KiCAD, I have not found any need for it to automatically move cursors or windows around (nor do I even remember such behaviour pre-wayland, so it can't have been important), but note that the cursor-warp protocol is coming to allow the former, and window tags are coming to allow things like window placement restoration, which should help where this may benefit UX.
Technical note, OpenGL is for rendering, which is unrelated to presentation. Window managers and display servers have no part in that process. It's the Window System Integration (WSI) if used, such as EGL or Vulkan WSI, and in the old days GLX, that talk to the display server.
Wayland only provides an optional suggestion for when it is a good time for a window to render for good frame pacing, latency and performance without the app having a full proper frame scheduling implementation itself. The issue that tends to crop up is that EGL, a WSI often used with OpenGL in apps not using a toolkit, when specifically told to block and wait for next frame, has been internally implemented to use the optional suggestion which is not provided for invisible windows.
Stuff is being done to solve this, and it doesn't affect applications that do not ask to block on updates (say, firefox), nor applications leaving this up to a toolkit (say, Gtk or Qt) or just a different window system integration than EGL (which is extremely limited on its own anyway).
jchw|6 months ago
> KiCAD needs the ability to move cursor to provide good user experience.
Most applications are implementing pointer warping using pointer-constraints-unstable-v1. This lets you confine the pointer to a region, at which point you can use relative events to get movement, render the cursor yourself and do whatever you want. There is the locked_pointer_v1::set_cursor_position_hint function to allow one to set the location where the cursor should be released at when the constraint is lifted, which should make everything seamless.
And sure, it might actually be that pointer-constraints-unstable-v1 isn't enough for KiCAD's particular UX somehow, maybe they need pointer-warp-v1 or something even more advanced. However, applications generally don't need to set the mouse position to arbitrary locations on-screen at any time... That is a useful capability for something doing automation, but it should really not be needed for general application development.
> KiCAD needs the ability to move and place windows wherever it likes.
KiCAD isn't a window manager, it's a damn EDA tool. I do agree that Wayland needs to provide multi-window applications with better tools to hint to the compositor what to do with window placement and especially to save and restore window positions, but this doesn't translate to "applications need to be able to decide where exactly windows go." There is basically no behavior which literally requires this, and certainly no sane behavior that requires this.
Having every application perform its own sort of logic to decide where windows go is a mess everywhere it exists. It would be cleaner and better for users if we could just figure out what sorts of higher level tools applications need for good UX and try to build around that. In most cases merely being able to position windows relative to each-other is enough. (You can obviously do this in Wayland already to some extent, though I'm sure there are missing tools that are needed.)
On Wayland today, applications can't absolutely control window placement, or even know where they are on screen. There really isn't even a global window coordinate space to even leak to applications. It's a pretty radical departure from almost everything else, so yeah, application developers are obviously not thrilled about having to deal with it. But on the other hand, it's probably the right way to go. Just because ability to control absolute positions is convenient does not mean it is necessarily the right way to go, especially if you can provide higher level tools that encode intent better and let the user decide how your application's intent should be interpreted.
> KiCAD needs to control focus.
Honestly I have no clue what they're complaining about with focus. It's too vague.
If your application is in the foreground, you can grab an activation token and use it, so even with "extreme" focus protection, there should not be any issues with KiCAD being able to focus its own windows.
As for other software being able to focus itself from KiCAD, well, this article describes how you do it. It's pretty straight-forward and it's not obvious how you would misuse it. Pretty sure the same protocol exists in X11 as well.
They're also talking about modals, which might be related to their complaints. The xdg-dialog-v1 protocol (supported in KDE 6.4, GNOME 48, and used by Qt 6.8+) gives applications the ability to mark dialogs as modals. It is a bit crazy that it took as long as it did for this to become supported by everything, but it did cross the finish line. On Ubuntu 25.04, for example, you should get GNOME 48 and Qt 6.8.
> KiCAD needs to prevent OpenGL throttling on inactive windows
OpenGL isn't throttled, it is stalled if the window is entirely occluded. You can now resolve this issue with the fifo-v1 protocol and Mesa 25.0 or newer. For example, Ubuntu 25.04 ships Mesa 25.x and GNOME 48 which has fifo-v1. fifo-v1 is also available in KDE as of 6.4.
This should give applications the frame pacing behavior that they want. It is possible to work around the issue to some degree, it's just annoying.
If KiCAD developers don't want to support Wayland because it's effort they'd rather spend on other shit then fine, XWayland should mostly continue to work as-expected anyways. Best option for now is to force KiCAD to use X11, like Krita does. I'm sure that's not a 100% panacea but it should be good enough especially if KiCAD is so buggy on Wayland that it actively crashes.
nottorp|6 months ago
I don't know what KiCAD is, but it certainly does not need to control focus OS wide. Only between its own windows.
It's probably not KiCAD's fault that the windowing system doesn't work like that, but still...
gf000|6 months ago
(Though this permission may be display server-dependent, as it may not make sense in case of each).
bityard|6 months ago
yard2010|6 months ago
b2m9|6 months ago
mayoff|6 months ago
https://developer.apple.com/videos/play/wwdc2023/10054/?time...
xp84|6 months ago
mmis1000|6 months ago
throwaway2037|6 months ago
I can think of two real world examples: (1) debugger hits breakpoint and steals focus (this is sometimes configurable), (2) WiFi needs re-/auth.
jabiko|6 months ago
For the debugger use case: If the IDE has already focus, it can pass an activation token to the debugger and the debugger can use this to focus itself. If the IDE is not focused, I don't want the debugger to steal focus.
dataflow|6 months ago
Wait, what? Hasn't Windows prevented focus stealing for literally decades at this point?
https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19...
ack_complete|6 months ago
jenscow|6 months ago
dmart|6 months ago
Defletter|6 months ago
pmarreck|6 months ago