Window Activation(blog.broulik.de)
blog.broulik.de
Window Activation
https://blog.broulik.de/2025/08/on-window-activation/
138 comments
If that's the topic you were looking for, you may like this "Dave's Garage" episode, where a retired Microsoft engineer talks about implementing... Windows Activation. https://www.youtube.com/watch?v=FpKNFCFABp0
They used to have whole conferences on window management!
"Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
My favorite chapters:
"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
My favorite chapters:
"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Don't feel bad -- the other frontpage story "ultra thin business card runs fluid simulation" I thought it said "...RUINS fluid simulation."
I'm worse than you - when I came across that article, I spent a while wondering whether "ulathrin" was the name of a company, or some new metal alloy. Your comment is what made me realize I misread it.
I made BOTH of those mistakes. I thought someone working at the company Ultrahin leaned over and dropped a business card into the particle accelerator and ruined a million dollar experiment.
I have found my people in this thread :D
Now I want to make ChatGPT write all these alternative universe articles.
Now I want to make ChatGPT write all these alternative universe articles.
I too was hoping for something like a deep dive into key management reverse engineering. lol
You may like this: https://sabah.forumotion.com/t333-all-you-need-to-know-about...
Yes, appending “in Wayland” would have 1000% clarified the topic for me.
Haha exactly why I am here too. I need glasses.
I have my glasses and still got here :(
Same.
I thought exactly the same thing
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.
[0]: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...
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...
s/KiCAD needs/KiCAD wants/
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).
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).
> As a user of KiCAD, I have not found any need for it to automatically move cursors
Well, the first thing you do with KiCAD is scrolling to zoom in and out, and KiCAD scroll works in a way to jump cursor to the center, so you basically can pan and scroll at the same time. That's default behaviour unless you changed it in the settings, and, obviously, it needs to warp cursor to the center of the window.
Well, the first thing you do with KiCAD is scrolling to zoom in and out, and KiCAD scroll works in a way to jump cursor to the center, so you basically can pan and scroll at the same time. That's default behaviour unless you changed it in the settings, and, obviously, it needs to warp cursor to the center of the window.
The way pan-and-scroll works in every other CAD program has been that zooming with the cursor off-center is a panning zoom (zoom centering on the cursor position), without the cursor warping anywhere, so that seems like a reasonable behavior. I do see that the described behaviour can be convenient, but definitely not a deal-breaker in the space.
Maybe I changed the config, can't remember and I must admit that it's been a little while since I had to fire it up.
Maybe I changed the config, can't remember and I must admit that it's been a little while since I had to fire it up.
I think, you can solve that with keyboard/mouse shortcuts without moving the cursor at all. What’s the reason why they don’t do that?
You cannot get the level of control out of keyboard shortcuts that you can with fine grained mouse movements. It'd be like trying to play a videogame while controlling camera movement with a controller DPAD/arrow keys.
I didn’t talk about using keyboard alone…
You didn't, but if we're introducing the mouse, we haven't dismissed the issues stemming from the lack of pointer warping.
Why would introducing a mouse interface necessitate pointer warping? There are several millions/billions of apps which utilize mouse and doesn’t need pointer warping.
So the second time, why is it needed in this case, and why it cannot be solved other ways?
So the second time, why is it needed in this case, and why it cannot be solved other ways?
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.
> 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.
As I understand it, a big issue for KiCAD is that it's old, so they went with WxWidgets as Qt wasn't a viable option[1].
It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.
[1]: https://forum.kicad.info/t/what-is-the-future-of-wxwidgets/2...
It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.
[1]: https://forum.kicad.info/t/what-is-the-future-of-wxwidgets/2...
I don't think it's absolutely necessary to move off of wxWidgets for Wayland support to be in decent shape in the long run. There is definitely a path forward that wxWidgets can improve its Wayland support, or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want. It might take time, but that's OK...
There's different ways to approach it that are equally pragmatic. Any of these approaches, possibly a combination of them, seem totally reasonable to me:
- Force X11, or at least prefer it when DISPLAY is non-empty. Probably also display a warning when loading on Wayland, since the experience is known to be sub-optimal. Let things sit for a while until Wayland looks mature and well-supported enough to basically rip off the bandage. This is a good option for most programs. Krita is doing this. Users understand this, other developers understand this, etc.
- Make specific efforts to support existing Wayland compositors even in spite of its limitations. Godot has been doing borderline heroic things to make Wayland first-class (check out how they're working around the lack of something like XEmbed - it's pretty intense.)
- Participate in the process of proposing Wayland protocols or new versions of existing protocols to fill in holes gradually. It's not a fun process anymore than any other standards process, but it's a way you can help the entire ecosystem out and impart some of your knowledge/experience into the protocol design in the process.
And ultimately, I don't really think there's anything wrong specifically with listing the problems that a program has when running under Wayland, it's very helpful to have a list that people can keep track of over time (like KDE's old "Wayland showstoppers"[1] page.) I do think that KiCAD's current list is overly opinionated on what the true root issue is even when it's subjective. I think it's better to frame things more in line with what doesn't work and a first-order "why" - i.e. "Pointer wrapping does not work because the current implementation in KiCAD relies on being able to set the absolute position of the cursor which is not available on Wayland." "There are currently stability issues on Wayland that don't occur on X11." etc. whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be.
I personally don't like wxWidgets very much, but it does have its advantages, and I'm sure a future can be built to be able to update wxWidgets applications to run smoothly on Wayland and maybe other future window systems, possibly by adding some new abstractions and tools.
> It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.
While that does complicate things, it's pretty tractable with some IPC. If you only need to change focus when `exec`ing (consider: this might be the case even when there's already a window open, if you're using something to do single-instancing) then it's even simpler as you can use the "standard" approach of passing the token via en environment variable on exec (then IPC'ing it to the instance in a single-instance situation.) I think this is what you want to do anyway on Linux right now, not just on Wayland.
[1]: https://community.kde.org/Plasma/Wayland_Known_Significant_I...
There's different ways to approach it that are equally pragmatic. Any of these approaches, possibly a combination of them, seem totally reasonable to me:
- Force X11, or at least prefer it when DISPLAY is non-empty. Probably also display a warning when loading on Wayland, since the experience is known to be sub-optimal. Let things sit for a while until Wayland looks mature and well-supported enough to basically rip off the bandage. This is a good option for most programs. Krita is doing this. Users understand this, other developers understand this, etc.
- Make specific efforts to support existing Wayland compositors even in spite of its limitations. Godot has been doing borderline heroic things to make Wayland first-class (check out how they're working around the lack of something like XEmbed - it's pretty intense.)
- Participate in the process of proposing Wayland protocols or new versions of existing protocols to fill in holes gradually. It's not a fun process anymore than any other standards process, but it's a way you can help the entire ecosystem out and impart some of your knowledge/experience into the protocol design in the process.
And ultimately, I don't really think there's anything wrong specifically with listing the problems that a program has when running under Wayland, it's very helpful to have a list that people can keep track of over time (like KDE's old "Wayland showstoppers"[1] page.) I do think that KiCAD's current list is overly opinionated on what the true root issue is even when it's subjective. I think it's better to frame things more in line with what doesn't work and a first-order "why" - i.e. "Pointer wrapping does not work because the current implementation in KiCAD relies on being able to set the absolute position of the cursor which is not available on Wayland." "There are currently stability issues on Wayland that don't occur on X11." etc. whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be.
I personally don't like wxWidgets very much, but it does have its advantages, and I'm sure a future can be built to be able to update wxWidgets applications to run smoothly on Wayland and maybe other future window systems, possibly by adding some new abstractions and tools.
> It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.
While that does complicate things, it's pretty tractable with some IPC. If you only need to change focus when `exec`ing (consider: this might be the case even when there's already a window open, if you're using something to do single-instancing) then it's even simpler as you can use the "standard" approach of passing the token via en environment variable on exec (then IPC'ing it to the instance in a single-instance situation.) I think this is what you want to do anyway on Linux right now, not just on Wayland.
[1]: https://community.kde.org/Plasma/Wayland_Known_Significant_I...
> There is definitely a path forward that wxWidgets can improve its Wayland support
Seems there's some willingness[1] to do just that.
> or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want
From what I gather the KiCAD devs are very much against that, as it would detract manpower from the core product, ie KiCAD itself, which is understandable.
> whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be
Then again, I can understand their frustration. Wayland makes Python 2 to Python 3 seem like a well-executed transition. Wayland is soon older than X11 was when Wayland got started, and it's still a mess.
Though as you say, it feels (as a user) like it's improving a lot more lately. So I think the strategy of the KiCAD devs to essentially ignore Wayland for a bit longer is a good one. In a few more years support all around is likely a lot better, and then it might make sense to spend a bit of time adding bespoke Wayland code to KiCAD.
[1]: https://gitlab.com/kicad/code/kicad/-/issues/7207#note_14094...
Seems there's some willingness[1] to do just that.
> or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want
From what I gather the KiCAD devs are very much against that, as it would detract manpower from the core product, ie KiCAD itself, which is understandable.
> whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be
Then again, I can understand their frustration. Wayland makes Python 2 to Python 3 seem like a well-executed transition. Wayland is soon older than X11 was when Wayland got started, and it's still a mess.
Though as you say, it feels (as a user) like it's improving a lot more lately. So I think the strategy of the KiCAD devs to essentially ignore Wayland for a bit longer is a good one. In a few more years support all around is likely a lot better, and then it might make sense to spend a bit of time adding bespoke Wayland code to KiCAD.
[1]: https://gitlab.com/kicad/code/kicad/-/issues/7207#note_14094...
> Wayland is soon older than X11 was when Wayland got started
Wayland was started in 2008, X11 in 1984 (according to Wikipedia). That makes X11 41 and Wayland 17 years old, respectively. X11 was 24 when Wayland was started.
That's without considering X11 was not a fresh start (it's 11th version of an existing protocol, so it did have some baggage), and that there was an explosion in complexity in hardware, software, security and networking for the past 30 or so years.
The functionality surface area that's "table stakes" for Wayland is a lot larger than it was for X11.
Wayland was started in 2008, X11 in 1984 (according to Wikipedia). That makes X11 41 and Wayland 17 years old, respectively. X11 was 24 when Wayland was started.
That's without considering X11 was not a fresh start (it's 11th version of an existing protocol, so it did have some baggage), and that there was an explosion in complexity in hardware, software, security and networking for the past 30 or so years.
The functionality surface area that's "table stakes" for Wayland is a lot larger than it was for X11.
I was considering X11 first release vs Wayland start. Sure not completely apples to apples. My primary point was more that Wayland is a very old project at this point, yet in many key areas it is quite immature. Primarily on the implementation side.
> Seems there's some willingness[1] to do just that.
I'm glad the wxWidgets developers are being helpful here.
> Wayland is soon older than X11 was when Wayland got started, and it's still a mess.
To me the Wayland transition is less about Wayland and more about finally breaking the dependency on X.org. It was a long, long, long time coming, and there were a lot of prerequisites to get there. KMS, DRM, EGL, GBM, dmabufs, libinput, etc.
I believe the immutable aspects of Wayland are perfectly serviceable and it should have a good shelf-life. I hope to see more advantage taken of the fact that Wayland is capabilities-based, more edge-cases of protocols nailed down, and I also hope the Newton accessibility bus sees more development as it seemed very promising.
I realize people are upset at how long things take. In my opinion, community-driven open source is pretty good at long-term things and bad at short-term things. The Wayland color-management MR took five years, but paging through the threads it's easy to appreciate the amount of thought that went into it and feel like it really lays a solid foundation for the future. With desktop systems evolving about as slowly as ever, I think this a tractable situation, and being a daily driver of Wayland on several devices I feel like it's been a long time since I felt the free software desktop was this close to parity with the competition in terms of features and to some extent, even productivity, dare I say. (I really like what KDE Plasma has done.) I honestly think the most major blocker for Wayland remains full parity for NVIDIA devices, and from that point forward the real main challenge for the Linux desktop will go back to being software and hardware support as it arguably once was.
I'm glad the wxWidgets developers are being helpful here.
> Wayland is soon older than X11 was when Wayland got started, and it's still a mess.
To me the Wayland transition is less about Wayland and more about finally breaking the dependency on X.org. It was a long, long, long time coming, and there were a lot of prerequisites to get there. KMS, DRM, EGL, GBM, dmabufs, libinput, etc.
I believe the immutable aspects of Wayland are perfectly serviceable and it should have a good shelf-life. I hope to see more advantage taken of the fact that Wayland is capabilities-based, more edge-cases of protocols nailed down, and I also hope the Newton accessibility bus sees more development as it seemed very promising.
I realize people are upset at how long things take. In my opinion, community-driven open source is pretty good at long-term things and bad at short-term things. The Wayland color-management MR took five years, but paging through the threads it's easy to appreciate the amount of thought that went into it and feel like it really lays a solid foundation for the future. With desktop systems evolving about as slowly as ever, I think this a tractable situation, and being a daily driver of Wayland on several devices I feel like it's been a long time since I felt the free software desktop was this close to parity with the competition in terms of features and to some extent, even productivity, dare I say. (I really like what KDE Plasma has done.) I honestly think the most major blocker for Wayland remains full parity for NVIDIA devices, and from that point forward the real main challenge for the Linux desktop will go back to being software and hardware support as it arguably once was.
> it should really not be needed for general application development.
That attitude is the problem, I think.
The functionality in question is irrelevant. What is relevant is that, presumably, Windows and Mac and X11 users of Kicad use this functionality.
The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.
That attitude is the problem, I think.
The functionality in question is irrelevant. What is relevant is that, presumably, Windows and Mac and X11 users of Kicad use this functionality.
The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.
> What is relevant is that, presumably, Windows and Mac and X11 users of Kicad use this functionality.
Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor. Windows and Mac and X11 users praise KiCAD for having a nice UX. You can definitely implement features like infinite panning in today's Wayland compositors, you just can't do it by absolutely setting the cursor position.
> The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.
This is a genuinely cancerous mentality. When you design a new API, "the old API had a function that does this" is not a valid justification. If you can't find another justification for why the function should exist, it means that it shouldn't. That's what designing from first principle looks like. I have actual reasons why the old functionality (getting/setting the absolute cursor position) is not an API that I want, too, but that's not even the point. API functionality should be able to stand on its own and justify itself. If you can't start on a completely clean slate, why even bother trying to design a new API in the first place?
It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum. It is a useful API primitive, because it can be used to implement other useful things, and a ubiquitous API primitive, but that doesn't mean it's a good API primitive. On the contrary, most of these desktop systems were designed a long time ago, and now modern OSes are actually having to come up with ways to carefully limit a lot of these sorts of very powerful legacy APIs because they can lead to security and privacy issues. As an end user and computer owner, I don't want random applications running on my desktop to be able to get or set the absolute cursor position on screen, especially when the window is not focused. And if I don't want that, then the next obvious question is, does something like KiCAD truly need that? Of course not. Applications need primitives that can implement the controls and UI that they want, but you don't just get to decide what those primitives are, as an application. As an application, you get to deal with the primitives that you're given, because by definition, that's literally the job of an application developer. And when those primitives prove insufficient to implement some UI, then we can discuss how to fix it, but the answer isn't "this old API just let me get/set the global cursor position so can I have that?" And if you don't like some system you don't have to support it. But Apple is a complete and utter dickhole to application developers, requiring all kinds of dumb signing bullshit and pushing users to huge proprietary APIs like Metal, and yet open source projects are happy to sink plenty of developer hours (and often money) into it anyways, even though its desktop marketshare is only somewhat more impressive than Linux anyway. So forgive me if I don't shed a tear because it required a bit more work to do something in Wayland than it did elsewhere.
And yes, I know: you can come up with an application that really truly actually does need this. There are a handful, like automation software, or a remote desktop server. Actually though, pretty much all of the modern Wayland desktops support being able to get or set the absolute cursor position for that use case, it's just that it will usually require a permission prompt, at least the first time you use it. (There are some exceptions. wlroots/SwayWM doesn't require a permission prompt for this, the functionality is exposed as long as applications are not sandboxed.)
Application developers have developed this sense of ownership over the desktop that has become very annoying. No. I want my desktop environment to act as the owner of my desktop, the same way I want my window manager to control the management and positioning of my windows. Your applications just get to live in that world, the way that web pages get to live in a web browser.
Love it or don't, Wayland exposing higher level APIs for things that used to be implemented by application developers using lower level APIs is a step in the right direction for higher quality desktops and for user's control over their own desktops.
Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor. Windows and Mac and X11 users praise KiCAD for having a nice UX. You can definitely implement features like infinite panning in today's Wayland compositors, you just can't do it by absolutely setting the cursor position.
> The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.
This is a genuinely cancerous mentality. When you design a new API, "the old API had a function that does this" is not a valid justification. If you can't find another justification for why the function should exist, it means that it shouldn't. That's what designing from first principle looks like. I have actual reasons why the old functionality (getting/setting the absolute cursor position) is not an API that I want, too, but that's not even the point. API functionality should be able to stand on its own and justify itself. If you can't start on a completely clean slate, why even bother trying to design a new API in the first place?
It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum. It is a useful API primitive, because it can be used to implement other useful things, and a ubiquitous API primitive, but that doesn't mean it's a good API primitive. On the contrary, most of these desktop systems were designed a long time ago, and now modern OSes are actually having to come up with ways to carefully limit a lot of these sorts of very powerful legacy APIs because they can lead to security and privacy issues. As an end user and computer owner, I don't want random applications running on my desktop to be able to get or set the absolute cursor position on screen, especially when the window is not focused. And if I don't want that, then the next obvious question is, does something like KiCAD truly need that? Of course not. Applications need primitives that can implement the controls and UI that they want, but you don't just get to decide what those primitives are, as an application. As an application, you get to deal with the primitives that you're given, because by definition, that's literally the job of an application developer. And when those primitives prove insufficient to implement some UI, then we can discuss how to fix it, but the answer isn't "this old API just let me get/set the global cursor position so can I have that?" And if you don't like some system you don't have to support it. But Apple is a complete and utter dickhole to application developers, requiring all kinds of dumb signing bullshit and pushing users to huge proprietary APIs like Metal, and yet open source projects are happy to sink plenty of developer hours (and often money) into it anyways, even though its desktop marketshare is only somewhat more impressive than Linux anyway. So forgive me if I don't shed a tear because it required a bit more work to do something in Wayland than it did elsewhere.
And yes, I know: you can come up with an application that really truly actually does need this. There are a handful, like automation software, or a remote desktop server. Actually though, pretty much all of the modern Wayland desktops support being able to get or set the absolute cursor position for that use case, it's just that it will usually require a permission prompt, at least the first time you use it. (There are some exceptions. wlroots/SwayWM doesn't require a permission prompt for this, the functionality is exposed as long as applications are not sandboxed.)
Application developers have developed this sense of ownership over the desktop that has become very annoying. No. I want my desktop environment to act as the owner of my desktop, the same way I want my window manager to control the management and positioning of my windows. Your applications just get to live in that world, the way that web pages get to live in a web browser.
Love it or don't, Wayland exposing higher level APIs for things that used to be implemented by application developers using lower level APIs is a step in the right direction for higher quality desktops and for user's control over their own desktops.
> Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor.
What does praising have to do with it? After all, I use my television remote mainly to control the volume, but I have never praised the ability to control the volume.
> When you design a new API, "the old API had a function that does this" is not a valid justification.
That is not the justification I, and others, gave; it's essentially a strawman that pops up in every single Wayland conversation.
The justification is "Windows, Mac and X11 allow this feature."
At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.
> It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum.
Well ... yes? What's wrong with that? What's wrong with the argument "All the competitors provide this"?
What does praising have to do with it? After all, I use my television remote mainly to control the volume, but I have never praised the ability to control the volume.
> When you design a new API, "the old API had a function that does this" is not a valid justification.
That is not the justification I, and others, gave; it's essentially a strawman that pops up in every single Wayland conversation.
The justification is "Windows, Mac and X11 allow this feature."
At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.
> It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum.
Well ... yes? What's wrong with that? What's wrong with the argument "All the competitors provide this"?
> At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.
You actually haven't come up with any good reason to justify this, you've just repeated it as fact for some reason. And what's weird is, there's no point in doing this. Like, I can understand doing this maybe earlier, when there was possibly a question if Wayland would succeed; at that point, the proponents, designeds and developers of Wayland and Wayland software had something to prove.
But guess what? It's over. There's no more fight for Wayland to prove itself. Wayland is, for now, here to stay. We are done with that part of things. Nothing will literally stop someone from using X.Org, anymore than you are stopped from doing anything with your own computer, but the Linux world is largely moving on. Application developers are largely moving on. Toolkit developers are largely moving on. Desktop environments are largely moving on. Distributions are largely moving on. And nobody in this process is losing immense sleep over wxWidgets or KiCAD not having complete parity because it's not a big deal. We genuinely have more important things to worry about.
So framing this fight with whatever basis you personally feel appropriate is a waste of my time and a waste of your time. If your best justification is 'everyone else was doing it in 1999', you can pipe it to /dev/null and save us all some time. We don't care.
So no, the onus is absolutely on you to justify this. You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.
All modern desktop systems supported silently querying and setting the absolute position of the cursor... Before Wayland. Wayland became a modern desktop system that doesn't, so now not all modern desktop systems support that. And if a commercial vendor ever decides to design a new desktop system from scratch, you can bet all of the hairs on your ass it will have nearly the exact same limitations.
You actually haven't come up with any good reason to justify this, you've just repeated it as fact for some reason. And what's weird is, there's no point in doing this. Like, I can understand doing this maybe earlier, when there was possibly a question if Wayland would succeed; at that point, the proponents, designeds and developers of Wayland and Wayland software had something to prove.
But guess what? It's over. There's no more fight for Wayland to prove itself. Wayland is, for now, here to stay. We are done with that part of things. Nothing will literally stop someone from using X.Org, anymore than you are stopped from doing anything with your own computer, but the Linux world is largely moving on. Application developers are largely moving on. Toolkit developers are largely moving on. Desktop environments are largely moving on. Distributions are largely moving on. And nobody in this process is losing immense sleep over wxWidgets or KiCAD not having complete parity because it's not a big deal. We genuinely have more important things to worry about.
So framing this fight with whatever basis you personally feel appropriate is a waste of my time and a waste of your time. If your best justification is 'everyone else was doing it in 1999', you can pipe it to /dev/null and save us all some time. We don't care.
So no, the onus is absolutely on you to justify this. You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.
All modern desktop systems supported silently querying and setting the absolute position of the cursor... Before Wayland. Wayland became a modern desktop system that doesn't, so now not all modern desktop systems support that. And if a commercial vendor ever decides to design a new desktop system from scratch, you can bet all of the hairs on your ass it will have nearly the exact same limitations.
> You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.
TBH, "need" doesn't come into it. It can't. There's no justification for not maintaining feature parity with current competitors.
Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.
There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.
You want security on your desktop? You get it. I want KiCAD on mine? I get it.
What, specifically, is the reason that you feel so strongly that only one option must be enforced?
I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?
TBH, "need" doesn't come into it. It can't. There's no justification for not maintaining feature parity with current competitors.
Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.
There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.
You want security on your desktop? You get it. I want KiCAD on mine? I get it.
What, specifically, is the reason that you feel so strongly that only one option must be enforced?
I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?
> TBH, "need" doesn't come into it. It can't. There's no justification for not maintaining feature parity with current competitors.
Firstly, again, choosing your own premise here isn't going to do you or me any good. I'm happy to waste my time because for some fucked up reason I actually enjoy participating in threads like these, but unless you also do, I have to warn you that this is simply a waste of time as I'm not interested in this premise and it won't do any good to convince any Wayland proponents. To put it bluntly, your opinion on where this argument starts is really not material because nobody really asked.
Secondly, this premise is terrible anyways. First, it starts with the assumption that there's no justification for why not to provide the ability to position the cursor directly, which isn't true, and you seem to recognize that when you mention "security" later on (though that is certainly not the only reason.) And anyway, this premise pushes the idea that you have to justify not introducing features when designing an API, which is just silly. Wayland started with a completely clean slate, and there are plenty of things that X11 and Win32 can do that Wayland can't do, but I don't see anyone complaining about the lack of X11 colormaps or the ability to run without compositing. This idea applies much better when it comes to removing features: you would need justification to remove a feature that already exists. Wayland doesn't have this feature (absolutely positioning the pointer), so it has the opposite: it would need to justify adding the feature. But when Wayland developers get a feature request, they don't just blindly add the feature. They dig deeper into what applications really want and try to figure out the best primitive that allows the desktop and application to work together. Just letting applications position the cursor absolutely is pretty inelastic; you can develop primitives that are maybe a bit less powerful for applications, but are much more powerful for the desktop as a whole.
The reason I haven't been talking about justifications for why there isn't an explicit API to set the cursor position is because I think that would mislead someone into thinking that's a worthwhile thing to debate about when in reality it's not. If anyone thinks this is actually a good idea for an API in Wayland they can try to add it, you don't have to be anyone special to do it. In practice though I really strongly believe that if someone made an earnest effort to do so they would wind up changing their mind anyways after actually understanding the entire scope of what it entails in the frame of how Wayland works.
> Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.
> There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.
> You want security on your desktop? You get it. I want KiCAD on mine? I get it.
> What, specifically, is the reason that you feel so strongly that only one option must be enforced?
> I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?
I've been very carefully to be specific in hopefully every post I've made so far: what Wayland lacks is the ability to absolutely position the mouse cursor. It does not lack the ability to do mouse wrapping, for example, or constrain the pointer, or any of that stuff, it just can't be done the way KiCAD currently does it for existing desktop systems. These things work in existing Wayland software. That's actually the point of my first post in this thread a few levels up where I point out that KiCAD developers have made the messaging confusing, making it sound like these problems are inherent to Wayland when they're usually not. I stand by this.
I also claim that I don't really find it surprising that KiCAD developers are not excited to have to deal with Wayland things that basically don't exist in other desktops. I personally think they should prefer XWayland for now and continue leaning on wxWidgets to improve Wayland support over time. I fully believe wxWidgets can evolve to add higher level abstractions where lower level ones fail on Wayland, basically solving the problem for more than just KiCAD. GTK and Qt themselves have largely done this already.
And also, I don't feel that only one option should be enforced. In fact I don't even care if people only use Wayland, I'd be happy to see Arcan succeed, or people using Wayback, or even X11Libre, whatever. Moreover if someone wants to propose a Wayland protocol that allows querying and setting the pointer position, they can do that. I am actually not overall a fan of how monolithic the Linux/free software desktop has become. Even though I prefer systemd, for example, I generally dislike the way it took over and how everything now has very systemd-specific logic all over it. That's part of why I like Wayland, everyone sees it as being hugely opinionated, but actually it's not, it's basically a very minimal protocol that can be extended infinitely to do whatever you want, and each compositor gets to make it's own choices. As an application developer, this does cause you some headaches especially during the transition as you have to cope with some fragmentation especially if you do a lot of lower-level (in terms of desktop) stuff. This does not imply though, that applications should do a bunch of Wayland specific things, instead, I believe they should push features like pointer wrapping to a higher level to the point where the implementation can be done the old-school way or using Wayland protocols. (Some applications were basically already here and just needed an implementation.)
The thing is though, even though all of the Wayland compositors are totally free to implement whatever functionality they see fit, and they absolutely do, btw, they still don't implement an exact match for the API that X11 has here. I think all of them actually agree that the old API isn't particularly good. Even if they wanted to implement it such that applications like KiCAD could just ignore all of this, they literally can't: the old X11 APIs (i.e. XWarpPointer) are not designed for multiple seat, multiple cursor systems, even though X11 was extended to support many cursors a long time ago. The Wayland API is just simply going to require more work to implement versus systems that have legacy APIs that operate on a single global cursor. And simply treating an arbitrary choice for which seat/cursor to use is just not a very compelling decision.
FWIW, KiCAD does run on Wayland natively, but until it runs with full parity, it's probably going to be better ran under XWayland instead. And unless you desperately want something Wayland offers that X11 doesn't ("perfect" frames, more seamless high DPI rendering, better handling of VFR, color management) it just doesn't make sense to sweat over some applications still needing to fall back. As far as I'm concerned the XWayland fallback should continue to exist long into the future, ideally until it's so old that the applications that still need it are better ran under an emulation environment. (I'm not sure if that's even in my lifetime though.)
If a commercial vendor went out and tried to make a next-generation desktop system, without the baggage of any existing systems, I would be willing to bet a fortune they would come to agree on Wayland's limitations for unprivileged applications. Maybe they, together, marginally improve desktop security and privacy, but most importantly, I think that the Wayland way leads to better software, that makes less assumptions and needs less heuristics. This isn't about ideological purity, at the end of the day. It's about trying to improve the status quo. Improving the status quo is fucking hard.
Firstly, again, choosing your own premise here isn't going to do you or me any good. I'm happy to waste my time because for some fucked up reason I actually enjoy participating in threads like these, but unless you also do, I have to warn you that this is simply a waste of time as I'm not interested in this premise and it won't do any good to convince any Wayland proponents. To put it bluntly, your opinion on where this argument starts is really not material because nobody really asked.
Secondly, this premise is terrible anyways. First, it starts with the assumption that there's no justification for why not to provide the ability to position the cursor directly, which isn't true, and you seem to recognize that when you mention "security" later on (though that is certainly not the only reason.) And anyway, this premise pushes the idea that you have to justify not introducing features when designing an API, which is just silly. Wayland started with a completely clean slate, and there are plenty of things that X11 and Win32 can do that Wayland can't do, but I don't see anyone complaining about the lack of X11 colormaps or the ability to run without compositing. This idea applies much better when it comes to removing features: you would need justification to remove a feature that already exists. Wayland doesn't have this feature (absolutely positioning the pointer), so it has the opposite: it would need to justify adding the feature. But when Wayland developers get a feature request, they don't just blindly add the feature. They dig deeper into what applications really want and try to figure out the best primitive that allows the desktop and application to work together. Just letting applications position the cursor absolutely is pretty inelastic; you can develop primitives that are maybe a bit less powerful for applications, but are much more powerful for the desktop as a whole.
The reason I haven't been talking about justifications for why there isn't an explicit API to set the cursor position is because I think that would mislead someone into thinking that's a worthwhile thing to debate about when in reality it's not. If anyone thinks this is actually a good idea for an API in Wayland they can try to add it, you don't have to be anyone special to do it. In practice though I really strongly believe that if someone made an earnest effort to do so they would wind up changing their mind anyways after actually understanding the entire scope of what it entails in the frame of how Wayland works.
> Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.
> There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.
> You want security on your desktop? You get it. I want KiCAD on mine? I get it.
> What, specifically, is the reason that you feel so strongly that only one option must be enforced?
> I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?
I've been very carefully to be specific in hopefully every post I've made so far: what Wayland lacks is the ability to absolutely position the mouse cursor. It does not lack the ability to do mouse wrapping, for example, or constrain the pointer, or any of that stuff, it just can't be done the way KiCAD currently does it for existing desktop systems. These things work in existing Wayland software. That's actually the point of my first post in this thread a few levels up where I point out that KiCAD developers have made the messaging confusing, making it sound like these problems are inherent to Wayland when they're usually not. I stand by this.
I also claim that I don't really find it surprising that KiCAD developers are not excited to have to deal with Wayland things that basically don't exist in other desktops. I personally think they should prefer XWayland for now and continue leaning on wxWidgets to improve Wayland support over time. I fully believe wxWidgets can evolve to add higher level abstractions where lower level ones fail on Wayland, basically solving the problem for more than just KiCAD. GTK and Qt themselves have largely done this already.
And also, I don't feel that only one option should be enforced. In fact I don't even care if people only use Wayland, I'd be happy to see Arcan succeed, or people using Wayback, or even X11Libre, whatever. Moreover if someone wants to propose a Wayland protocol that allows querying and setting the pointer position, they can do that. I am actually not overall a fan of how monolithic the Linux/free software desktop has become. Even though I prefer systemd, for example, I generally dislike the way it took over and how everything now has very systemd-specific logic all over it. That's part of why I like Wayland, everyone sees it as being hugely opinionated, but actually it's not, it's basically a very minimal protocol that can be extended infinitely to do whatever you want, and each compositor gets to make it's own choices. As an application developer, this does cause you some headaches especially during the transition as you have to cope with some fragmentation especially if you do a lot of lower-level (in terms of desktop) stuff. This does not imply though, that applications should do a bunch of Wayland specific things, instead, I believe they should push features like pointer wrapping to a higher level to the point where the implementation can be done the old-school way or using Wayland protocols. (Some applications were basically already here and just needed an implementation.)
The thing is though, even though all of the Wayland compositors are totally free to implement whatever functionality they see fit, and they absolutely do, btw, they still don't implement an exact match for the API that X11 has here. I think all of them actually agree that the old API isn't particularly good. Even if they wanted to implement it such that applications like KiCAD could just ignore all of this, they literally can't: the old X11 APIs (i.e. XWarpPointer) are not designed for multiple seat, multiple cursor systems, even though X11 was extended to support many cursors a long time ago. The Wayland API is just simply going to require more work to implement versus systems that have legacy APIs that operate on a single global cursor. And simply treating an arbitrary choice for which seat/cursor to use is just not a very compelling decision.
FWIW, KiCAD does run on Wayland natively, but until it runs with full parity, it's probably going to be better ran under XWayland instead. And unless you desperately want something Wayland offers that X11 doesn't ("perfect" frames, more seamless high DPI rendering, better handling of VFR, color management) it just doesn't make sense to sweat over some applications still needing to fall back. As far as I'm concerned the XWayland fallback should continue to exist long into the future, ideally until it's so old that the applications that still need it are better ran under an emulation environment. (I'm not sure if that's even in my lifetime though.)
If a commercial vendor went out and tried to make a next-generation desktop system, without the baggage of any existing systems, I would be willing to bet a fortune they would come to agree on Wayland's limitations for unprivileged applications. Maybe they, together, marginally improve desktop security and privacy, but most importantly, I think that the Wayland way leads to better software, that makes less assumptions and needs less heuristics. This isn't about ideological purity, at the end of the day. It's about trying to improve the status quo. Improving the status quo is fucking hard.
> "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.
That can be done using relative window placement. It's not about pixel-perfect placement, but absolute vs relative.
> KiCAD needs to control focus.
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...
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...
The page states:
> Unpredictable window focus behavior that can interrupt workflows
Which isn't exactly the same issue, so indeed it doesn't need to control focus.
> Unpredictable window focus behavior that can interrupt workflows
Which isn't exactly the same issue, so indeed it doesn't need to control focus.
That sounds like my problem with focus being stolen by random apps while i work :)
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).
(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!
Supposedly this was improved in macOS 14 (Sonoma, late 2023) with "cooperative app activation". It's discussed in this WWDC 2023 video:
https://developer.apple.com/videos/play/wwdc2023/10054/?time...
https://developer.apple.com/videos/play/wwdc2023/10054/?time...
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 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.
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?
https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19...
Wait, what? Hasn't Windows prevented focus stealing for literally decades at this point?
https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19...
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.
Do you have a link to more details or something? I haven't seen or heard of what you describe.
Afraid not. The documentation for AllowSetForegroundWindow() and the associated mechanism still exists, of course:
https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
But the last time I tried to test code using this to properly hand off foreground permission from one process to another, I had a hard time testing it because I couldn't get it to fail. When this mechanism was first introduced in Windows 98 and 2000, it was pretty aggressive -- if you were past the input timeout and foreground permission hadn't been forwarded or already shared, the target application would fail to come to the front and its taskbar button would light up instead. I haven't seen this happen in a long time on current Windows, programs steal focus all the time.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
But the last time I tried to test code using this to properly hand off foreground permission from one process to another, I had a hard time testing it because I couldn't get it to fail. When this mechanism was first introduced in Windows 98 and 2000, it was pretty aggressive -- if you were past the input timeout and foreground permission hadn't been forwarded or already shared, the target application would fail to come to the front and its taskbar button would light up instead. I haven't seen this happen in a long time on current Windows, programs steal focus all the time.
Haven't used windows in a decade, but there is (was?) a registry setting that would disable focus stealing prevention. Some egregious tools "helpfully" changed that setting for you when you installed them, because they couldn't get focus management to work properly. Maybe it's that?
Interference from some program is a possibility, but the relevant foreground lock registry keys seem default on all my systems.
I'm pretty sure something weird is going on in your case because I recently had to fight a case of this that had seemingly gotten more aggressive in Windows 11, not less. The focus stealing prevention has always been there and is still there as far as I've observed.
An app can still steal focus with `uiAccess=true` in the app manifest's execution level (and the app is signed).
Ah, that may be the case - I’ll edit my comment. I was primarily using macOS before this so I may have misremembered the Windows behavior.
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.
Windows was worse at this than the Mac was.
This mechanism sounds worth it.
So many times on X11 do I type some chat message, and then some popup from another program comes up, which I accidentally confirm by my typing containing a space which presses the confirmation button, and I don't even know what the popup was.
Or my password being typed in a popup.
I once patched some code into i3 to prevent this for myself, but it wasn't a clean solution.
So many times on X11 do I type some chat message, and then some popup from another program comes up, which I accidentally confirm by my typing containing a space which presses the confirmation button, and I don't even know what the popup was.
Or my password being typed in a popup.
I once patched some code into i3 to prevent this for myself, but it wasn't a clean solution.
KDE: Settings → Window Management → Window Behavior → Focus → Focus stealing prevention
Even on "Low" (the options are None, Low, Medium, High, Extreme) I'm not seeing this behavior. Might be an i3 problem.
Even on "Low" (the options are None, Low, Medium, High, Extreme) I'm not seeing this behavior. Might be an i3 problem.
Not sure I understand. You acknowledge that I use i3 as window manager, yet suggest settings for another (KWin != i3).
You categorised it as an X11 issue. I showed you another desktop session ("KDE:") has a specific setting for this. Therefore, it is clearly not an unsolvable X11 problem, and likely an i3 problem.
You said "mechanism seems worth it". While there seems to be some work on extending it, this is not a new mechanism. A hypothetical i3 port to Wayland might very well have the same behaviour you dislike. (I wouldn't categorise sway as a port, rewrite seems more like it.)
You said "mechanism seems worth it". While there seems to be some work on extending it, this is not a new mechanism. A hypothetical i3 port to Wayland might very well have the same behaviour you dislike. (I wouldn't categorise sway as a port, rewrite seems more like it.)
Huh I'm also on i3 but I never run into this problem. If any program would start stealing focus I'd just uninstall it and yell at the author/vendor.
Try
The popup of the other program should appear and capture your input.
As far as I know, i3 has no prevention for that.
(In this example I'm spawning a program delayed to demonstrate that, but the same can happen to e.g. the gpg-agent password prompt popping up when an SSH connection that uses it reconnects, a chat window from an IM program, and so on. I think the idea of Wayland window activation / focus stealing prevention is that you can still have those windows pop up, but without them taking your input.)
sleep 2 && zenity --entry --text="Enter text:"
The popup of the other program should appear and capture your input.
As far as I know, i3 has no prevention for that.
(In this example I'm spawning a program delayed to demonstrate that, but the same can happen to e.g. the gpg-agent password prompt popping up when an SSH connection that uses it reconnects, a chat window from an IM program, and so on. I think the idea of Wayland window activation / focus stealing prevention is that you can still have those windows pop up, but without them taking your input.)
I don't understand who historically has thought it's a good idea to allow applications to steal focus in the first place. It should be the window manager's decision, and the window manager should only switch focus if the user decides that.
Well, sometimes the user expects the focus to shift, like the example mentioned when you click a link in one application and your browser in the background should come into focus when it opens a new tab.
Some applications just decide to steal focus when the user does not expect it, and that is the problem.
I am not sure, as a convert to the church of "focus follows mouse" I sort of want well... my focus to follow the mouse and the mouse to follow me.
Now there may be a legitimate case to steal focus, but I am unable to think of one at the moments and your click link example fails to convince me.
I also sort of hate modal dialogs/windows. I think modals are in general an indicator of lazy/bad design. That being said, there are legitimate cases for modals. but "stop the world and handle me" should be a last resort not the first.
Now there may be a legitimate case to steal focus, but I am unable to think of one at the moments and your click link example fails to convince me.
I also sort of hate modal dialogs/windows. I think modals are in general an indicator of lazy/bad design. That being said, there are legitimate cases for modals. but "stop the world and handle me" should be a last resort not the first.
The legitimate use-cases for stealing focus are situations where an immediate response is required and timing is limited. For example: after you queue up for a ranked League of Legends game, there's a timed confirmation popup that appears when 10 players are found and which all players are required to accept before the game moves on to the draft.
In purely software spaces there's usually nothing that urgent happening. If something is really urgent it's usually going to be because it carries significant real-world consequences. Emergency alerts on smartphones are a good example of taking immediate priority over all other activities, especially if it's something like a warning of incoming missiles.
In purely software spaces there's usually nothing that urgent happening. If something is really urgent it's usually going to be because it carries significant real-world consequences. Emergency alerts on smartphones are a good example of taking immediate priority over all other activities, especially if it's something like a warning of incoming missiles.
At the very least you need the ability to show the browser when you send a link to it. And if that overlaps the window you were clicking the link in, then it'll now be under the mouse. Are you happy with that indirect focus steal? If not, I don't think there's a way to align your preferences with the average user.
That's a situation where the focus doesn't need stolen at all, the focus could be delegated by the active window itself.
> delegated
Yes that's being included under "stolen" in this conversation, at least how I'm interpreting it. Done without explicit user action.
Yes that's being included under "stolen" in this conversation, at least how I'm interpreting it. Done without explicit user action.
I'm of the cult of "focus follows mouse" as well but I think the same conversation exists regardless, just not for the specific case you already had your browser window positioned elsewhere from the window your mouse is currently over.
If you click a link in one application, surely it should pass focus to the browser, why should the browser be initiating that process?
Only the invoked app knows whether it needs the focus in the first place. Maybe the link you clicked is supposed to initiate some background processing that does not demand your focus at all.
Sure, so the previous app can give the option to take focus to the browser which can take it or not as it wishes.
Yes but there's no way for the OS to know if the focus request is legitimate, is there?
Can't even say "browsers are allowed to grab focus" because they'll grab it for a stupid window telling you to update the browser or what new features no one cares about they introduced.
I'd prefer to have to switch focus to the browser manually than have the stupid ubuntu update manager steal focus when i'm typing in the terminal...
Can't even say "browsers are allowed to grab focus" because they'll grab it for a stupid window telling you to update the browser or what new features no one cares about they introduced.
I'd prefer to have to switch focus to the browser manually than have the stupid ubuntu update manager steal focus when i'm typing in the terminal...
The article is about a mechanism for the OS to validate focus requests. The application with the link requests a focus token, and passes it to the browser along with the open-link request, and the browser can then request focus.
It isn't perfect, because there's no way to know that the browser isn't using the token to request focus for something else, but maintaining and validating chain of custody for focus across applications is exactly the problem it looks like they are working on solving.
It isn't perfect, because there's no way to know that the browser isn't using the token to request focus for something else, but maintaining and validating chain of custody for focus across applications is exactly the problem it looks like they are working on solving.
That was exactly the example given in the article, but somehow this isn't what I expected would happen if I click a link in say, my email client or chat program.
I imagined it more like: User clicks link in email program. Email program tells OS: "Here, open https://..." -- OS checks URL scheme registry and selects Firefox, OS brings Firefox to the front and throws the URL at it and says "Open this."
I guess perhaps my naïve way could falls down if the OS accepts URLs from apps that aren't in the foreground, so a random background process could activate any app it wants to steal focus.
I imagined it more like: User clicks link in email program. Email program tells OS: "Here, open https://..." -- OS checks URL scheme registry and selects Firefox, OS brings Firefox to the front and throws the URL at it and says "Open this."
I guess perhaps my naïve way could falls down if the OS accepts URLs from apps that aren't in the foreground, so a random background process could activate any app it wants to steal focus.
Yep. With the solution discussed, as I understand it, the e-mail program just needs to be modified to request a focus token and send it along with the URL request to the browser or the OS browser dispatch service to keep the expected behavior.
This could be abstracted by libraries (e.g. a method in Qt to open a URL in the system browser automatically gets the token) so each application doesn't need to be updated separately, or possibly even OS services.
This could be abstracted by libraries (e.g. a method in Qt to open a URL in the system browser automatically gets the token) so each application doesn't need to be updated separately, or possibly even OS services.
> Yes but there's no way for the OS to know if the focus request is legitimate, is there? Can't even say "browsers are allowed to grab focus" because [...]
To my understanding, the approach described in the article is that the currently active program requests a token and then passes that along to the program that it wants to take focus. Compositor can also check what triggered the request (mouse click? global keybind?) to decide if the request is legitimate.
That seems reasonable to me, opposed to requiring the user to switch over to a new window every time they `right click -> show in file browser` a file in their IDE, or after they press a hotkey to open a screenshot tool, or so on.
To my understanding, the approach described in the article is that the currently active program requests a token and then passes that along to the program that it wants to take focus. Compositor can also check what triggered the request (mouse click? global keybind?) to decide if the request is legitimate.
That seems reasonable to me, opposed to requiring the user to switch over to a new window every time they `right click -> show in file browser` a file in their IDE, or after they press a hotkey to open a screenshot tool, or so on.
> Compositor can also check what triggered the request (mouse click? global keybind?) to decide if the request is legitimate.
That's what I'm dubious about. But I haven't look at the details ofc.
That's what I'm dubious about. But I haven't look at the details ofc.
You think that's bad, back in the day when I was in an office where everyone used X terminals off of a common unix server, you could open a window on someone else's screen by just changing your DISPLAY environment variable. Fun pranks were fairly common.
KDE has KWin settings controlling this. I have no idea if this is some kind of a fixup after the fact or whether the window manager always controls this, but at least it does on a KDE X11 session.
Earlier discussion with comments from devs https://news.ycombinator.com/item?id=44784312
> In essence, an application cannot take focus, it can only receive focus. In the example above, your chat app would request an XDG Activation token from the compositor
To be fair, the same is mostly true on Windows, but through some different APIs.
Applications being able to put themselves in front unconditionally was for a long time a huge source of pain for the user, due to abusive/malicious software, and probably a reason Windows was malware platform #1.
This is honestly a reasonable design.
To be fair, the same is mostly true on Windows, but through some different APIs.
Applications being able to put themselves in front unconditionally was for a long time a huge source of pain for the user, due to abusive/malicious software, and probably a reason Windows was malware platform #1.
This is honestly a reasonable design.
Stealing focus is possible in X11, but the window manager needs to implement it. For instance, my dwm build does not refocus for any reason other than the user moving the mouse or pressing a key
On my my glorified gaming console (Windows desktop PC) it drives me absolutely nuts when I'm in the middle of some competitive game and a random auto-updater pops up, minimizing my current current fullscreen application. Bonus points if it happens again 30 seconds later because it launches the application after updating it (Why? I didn't even have it open before!)
In some cases this had to get past QA at two billion-dollar companies, and neither did something about it.
But that's far from the only way we've regressed in software quality. Really not worth mentioning. A drop of piss in an ocean of sewage.
I'm glad that at least on my actual computer I get to focus on work distraction free - likely because most of the software running on there is designed by its users and survived by merit, rather than being the brainfart of some corporate committee more concerned with other things.
In some cases this had to get past QA at two billion-dollar companies, and neither did something about it.
But that's far from the only way we've regressed in software quality. Really not worth mentioning. A drop of piss in an ocean of sewage.
I'm glad that at least on my actual computer I get to focus on work distraction free - likely because most of the software running on there is designed by its users and survived by merit, rather than being the brainfart of some corporate committee more concerned with other things.
Great idea, but pretty painful at the moment. I guess not everything uses this protocol yet, so I often can't find (for example) my password pops under other windows. Hoping this gets a bit better over time, it's one of the last remaining Wayland pains.
I can only barely appreciate or fathom the endless masochistic self-abuse of maintaining functional, useful semi-headless UI automation testing for various Linux distros.
If you did have UI automation, you probably would do it at the DE level, and not swap things like X11 for Wayland. If you don't update (or use something like XFCE), it would probably remain functional for decades
It's not just windows that I love popping up in my face actively! interrupting what I'm doing, but also ones that have autofocus elements, doubly stealing my attention and not having a debounce for ignoring actions, as others here have mentioned.
Type-type-type...HEY THIS APPLICATION HAS SOME UPDATES HERES A CHANGEL-keypress closes window
I wanted to read that, damn it!
Type-type-type...HEY THIS APPLICATION HAS SOME UPDATES HERES A CHANGEL-keypress closes window
I wanted to read that, damn it!
The power of a system does not lie within its mechanisms, systems, and strategies.
The power of a system allows one -near infinite- ability to create and manipulate those mechanisms, systems, and strategies.
The most powerful systems have few safeguards or rails, and user beware.
The most restrictive systems we hand to grandma and grandpa, knowing there is little they can actually do with them.
The power of a system allows one -near infinite- ability to create and manipulate those mechanisms, systems, and strategies.
The most powerful systems have few safeguards or rails, and user beware.
The most restrictive systems we hand to grandma and grandpa, knowing there is little they can actually do with them.
Wait, hold on. Is this actually an issue that needs a solution? It feels like Wayland is doing something very stupid here. Why not let apps control their windows? I cannot remember when an app stole focus last time. The only time this makes sense is while entering a password. But that is a very specific case that can be solved by having the password dialog on a protected desktop (ie. one with only that single window.)
> I cannot remember when an app stole focus last time.
You must not use Windows where every application comes with its own auto-updater, often stealing focus and minimizing your game once when the updater pops up, and then again when it restarts the main application it just updated.
Devs can't be trusted to not turn their users homicidal. Someone has to stop them for their own good.
You must not use Windows where every application comes with its own auto-updater, often stealing focus and minimizing your game once when the updater pops up, and then again when it restarts the main application it just updated.
Devs can't be trusted to not turn their users homicidal. Someone has to stop them for their own good.
> Well, you probably know by now that Wayland, unlike X, doesn’t let one application force its idiot wishes on everyone else.
…I thought {not allowing,managing} this on X11 is the window manager's job? (kwin certainly doesn't allow it on my X11 session…)
Or is this arguing about "uncooperative"/"hostile" applications?
…I thought {not allowing,managing} this on X11 is the window manager's job? (kwin certainly doesn't allow it on my X11 session…)
Or is this arguing about "uncooperative"/"hostile" applications?
Umm.. thanks to this logic I had to write an extension just so I could open firefox using a keystroke, because otherwise the browser did not receive focus..
I just checked and assigning the shortcut in "System Settings>Keyboard>Shortcuts" will open Firefox and put it in focus.
For me in GNOME on Fedora this only works for chromium, for firefox I had to make an extension - I don't know why.
Trade-offs abound, but this sounds amazing to me. I already have hotkeys to instantly switch between browser/terminal/Emacs/etc., so it's not an issue for me. What is an issue is some other application stealing focus while I'm typing elsewhere and (as another commenter mentioned) accidentally pressing space or some other key that performs an action in whatever pop-up or application stole the focus.
You should have focused more! /s /pun intended
But yeah, it has happened to me too, too often for it to be a problem. Especially the press the space bit.
I am not sure this is the right solution, however, but I cannot think of any solution right now.
Someone (in the comments) who has claimed to patch i3 may shed some light on what he did.
But yeah, it has happened to me too, too often for it to be a problem. Especially the press the space bit.
I am not sure this is the right solution, however, but I cannot think of any solution right now.
Someone (in the comments) who has claimed to patch i3 may shed some light on what he did.
the pragmatic thing to do is just let the Free Market decide. as far as i understand, windows just lets apps grab whatever window they want, whatever input they want, right? and everything Just Works(tm). app writers are discouraged to make things too clever by virtue of users having the choice of not using the app in question.
why cant linux guys just... copy windows?
android-ifying this space with permissions, channels, protocols etc, and pretending that apps are insecure is adding friction that benefits nobody imo.
why cant linux guys just... copy windows?
android-ifying this space with permissions, channels, protocols etc, and pretending that apps are insecure is adding friction that benefits nobody imo.
Sometimes I type a password into one window, only to have another window pop up partway through and eat the rest of my input. This is why we need to prevent unintentional window activation.
It is relatively easy to replicate if you open 2 apps and start typing in the first one which opened, both on macOS and Windows (I don't use Linux enough to notice this issue).
A proper solution is probably faster startup times, but overall it pretty much never happens? Idk maybe I'm lucky or just conditioned to ignore it.
A proper solution is probably faster startup times, but overall it pretty much never happens? Idk maybe I'm lucky or just conditioned to ignore it.
This happens so rarely, that it makes the UX impact to the every day user not worth it in my opinion.
Fellow macOS users: is this rare for you as well?
Maybe an auto-updater will do this, and if it happened with any frequency I might disable those autoupdates and try a macro-based (e.g. Keyboard Maestro) solution.
Maybe an auto-updater will do this, and if it happened with any frequency I might disable those autoupdates and try a macro-based (e.g. Keyboard Maestro) solution.
Windows stealing focus happens to me multiple times a day on Windows when I'm working.
It's infuriating.
It's infuriating.
> windows just lets apps grab whatever window they want [...] and everything Just Works
Not really, as proven by the amount of searches with "Windows 11 disable focus stealing" (and ensuing frustration after seeing that it's not a simple toggle somewhere in the Settings) that I've done over time, and confirmed with so many coworkers over the years that we'd like to disable it.
Windows in particular and computers in general, work as they do, and people just adapt to it and sigh in frustration, assuming that things must be that way and there's nothing that can be done to change it. It's difficult to measure "Just Works" if there are no satisfaction surveys for each feature (also would be impractical). Focus stealing in particular is so ingrained in people's minds that I doubt many are even aware that it could work differently.
Not really, as proven by the amount of searches with "Windows 11 disable focus stealing" (and ensuing frustration after seeing that it's not a simple toggle somewhere in the Settings) that I've done over time, and confirmed with so many coworkers over the years that we'd like to disable it.
Windows in particular and computers in general, work as they do, and people just adapt to it and sigh in frustration, assuming that things must be that way and there's nothing that can be done to change it. It's difficult to measure "Just Works" if there are no satisfaction surveys for each feature (also would be impractical). Focus stealing in particular is so ingrained in people's minds that I doubt many are even aware that it could work differently.
It already works that way on X11.
Linux is already set up to handle this better than Windows actually since most apps are open source and abusive window management is likely to result in PRs.
Linux is already set up to handle this better than Windows actually since most apps are open source and abusive window management is likely to result in PRs.
Someone has to actually accept and merge them.
Not necessarily. The fork could get packaged instead if the users prefer it.
As history has proven multiple times, most forks fail, after those that made them in first place lose interest keeping up with upstream, while others appreciate the fork as long as they aren't the ones actually doing the work.
You're right, but it's not unusual for distro maintainers to carry patches for one or two removing an obnoxious behaviors for a long time.
This title seems click-baity, as the term is most frequently used for registering Windows. That was my curiosity when I clicked through. I somehow doubt it would have gotten as many clicks had it been “Window Focus”.
It's called window activation in the standard protocol the blog is about, so it's technically correct terminology.
I don't think Linux users, much less Linux desktop developers, are thinking about Windows license activation.
There is no indication in the title that this is about Linux.
[flagged]
We detached this subthread from https://news.ycombinator.com/item?id=44836873 and marked it off topic.
…if that was the reason, why would the operating systems give other applications the right to steal focus and record keystrokes? They control the kernel, they don’t need that.
Wait, you can do that in X11 too... Is X11 spyware??? I know there is xeyes.. Is it..
In the past, I would've said no. It absolutely had severe vulnerabilities, no question about it. Anything in userland monitoring keystrokes, mouse input, and display of anything else is userland is genuinely concerning; that said, these were byproducts of architectural decisions made long ago in open source software - not quite the same as deliberately writing code explicitly and specifically to take away privacy and control from your users the way Microsoft and Apple do.
These days however, the negligence of the current custodian, Red Hat, does seem to border on malicious, especially when forks like XLibre are continuing to patch vulnerabilities while Red Hat refuses to merge patches into the "official" X11, as part of a coercive strategy of trying to force all users onto Wayland by allowing X11 to become even worse through active refusal and neglect to merge good PR's with security patches, despite being the official project owner and custodian.
As a final note, I did not say that Windows and Mac OS were spyware, I said they were functionally spyware. There's a meaningful and nuanced difference between those two claims that I'm not sure you are discerning in accordance with my intent.
These days however, the negligence of the current custodian, Red Hat, does seem to border on malicious, especially when forks like XLibre are continuing to patch vulnerabilities while Red Hat refuses to merge patches into the "official" X11, as part of a coercive strategy of trying to force all users onto Wayland by allowing X11 to become even worse through active refusal and neglect to merge good PR's with security patches, despite being the official project owner and custodian.
As a final note, I did not say that Windows and Mac OS were spyware, I said they were functionally spyware. There's a meaningful and nuanced difference between those two claims that I'm not sure you are discerning in accordance with my intent.
[flagged]
The first words in the guidelines are "Be kind", and we always expect people to try to do that, no matter what they're replying to.
Can you be more specific about what parts of my perspective appear crazy, or fan-fic to you? There is heaps of well-documented evidence from reputable sources to support all of my claims that I would be eager to offer. What specific claims do you find dubious?
Exercise left for the reader.
Is the snark really necessary here? These companies (Microsoft, Apple) have genuinely concerning practices regarding user ownership/control, data privacy, and there are legitimate concerns regarding the stewardship practices of Red Hat. I'm trying to engage in good faith, I've demonstrated a willingness to take your criticism seriously, and I'm willing to substantiate my claims, I don't understand why you're being so rude.
If you don't care enough to keep the conversation going, that's fine, but why do the whole catty "mean girl" / light bullying / social ostracization routine along with it? There's no reason for that.
@ dang @ tomhow
If you don't care enough to keep the conversation going, that's fine, but why do the whole catty "mean girl" / light bullying / social ostracization routine along with it? There's no reason for that.
@ dang @ tomhow
We always want people to comment without snark, and I've replied to that commenter reminding them of that.
Your comments in the subthread are quite inflammatory, starting with:
> Windows and Mac OS are already functionally spyware posing as operating systems, as Microsoft and Apple are functionally intelligence agency partners posing as private corporations.
I totally understand that it's a valid fear given what we know about the NSA, which has been heavily discussed here over the years. But when you blithely assert this kind of conspiracy theory as an accepted fact, it is inevitable that it will set off the kind of flamewar that has developed here.
The guidelines ask us all to eschew flamebait and generic tangents.
Your comments in the subthread are quite inflammatory, starting with:
> Windows and Mac OS are already functionally spyware posing as operating systems, as Microsoft and Apple are functionally intelligence agency partners posing as private corporations.
I totally understand that it's a valid fear given what we know about the NSA, which has been heavily discussed here over the years. But when you blithely assert this kind of conspiracy theory as an accepted fact, it is inevitable that it will set off the kind of flamewar that has developed here.
The guidelines ask us all to eschew flamebait and generic tangents.
OpenBSD has Xenocara and it does better than XLibre.
Read the first paragraph and it was really confusing. Still the same after reading it again.
Until I looked at the title. Oh, window activation is what we are actually talking about.