9 ms·

KDE Plasma prepares crackdown on focus-stealing window behavior under Wayland

153 points by bundie 1y ago

margalabargala 1y ago
My ideal state of this feature is probably one that mostly behaves as "normal", but lets me mark individual badly behaving, user-hostile applications like Zoom as unable to steal focus when they abuse it.
- robhlt 1y ago
  This is already supported! KDE has a really powerful "window rules" feature that lets you configure all kinds of properties on specific windows/apps, and focus stealing prevention is one of them. Just right click the app's title bar and under "more actions" you'll see "Configure Special Window/Application Settings...". The rule configuration window isn't the easiest to use, but "Add Property" is how you can set properties on windows that match the new rule.
  - prmph 1y ago
    This windows rules feature seems to be bug ridden. Yesterday I struggled with it all day. Rules were not being followed properly, were erased mysteriously, etc. I like KDE a lot, but this part of it needs work.
    - dmonitor 1y ago
      I suspect a lot of that comes from the "how to detect whether window x is window x" settings
    - o11c 1y ago
      Don't confuse "window rules" with "application rules". When configuring rules, you normally want the latter unless you know you want the former. Also don't forget that rules can interact with other rules. For example, window size interacts with all of: "fullscreen", "maximized", and the "geometry" options (commonly set to more than 1 pixel for terminals). That said, I am really not a fan of the recent UI-pessimization of the settings screen to require you to type out the setting you want rather than have tabs listing all the various options in a discoverable manner.
pseudocomposer 1y ago
Interesting reading, and it’s nice to see how they’ve implemented it and tweaked the KDE app suite to manage focus better as a result. Does anyone know whether there are (or have been) analogous issues on macOS/Windows? And what about GNOME or maybe XFCE?
- sho_hn 1y ago
  It's all more or less the same between Plasma/Gnome/XFCE. On X11 all window managers had to employ roughly similar heuristics-based tactics. That does however mean there might be behavior differences based on the specific WM's implementation. The token-based activation protocol for Wayland is a shared development that has been adopted across different toolkits, and I imagine will probably also result in more consistent default behavior across environments, although of course in theory a given compositor could decide or be configured to whatever flavor of stealing prevention is wanted. I can't comment much on macOS/Windows technically, except that my standard user experience on Windows installs is that at least once per week, some OEM background thing decides to update something that for some reason requires running a cmd.exe terminal window that reliably steals focus from whatever I'm doing. This kind of thing hasn't really been an issue on Linux DEs for decades.
- ghusto 1y ago
  It's the same everywhere, and it's unbelievable that it's been allowed for so long.
rollcat 1y ago
IMHO every desktop environment (yes, looking at you, macOS) should aggressively block focus stealing. The only conditions under which focus should change: - I've just launched the application - I've clicked on a window - I've clicked the window's icon in the dock - I've cmd-tabbed (or equivalent) to this window - The currently focused window has produced a modal dialog, that prevents all input events from going into the original window. (Whether and when modal dialogs are OK is debatable.) Matthew 5:37, "anything more comes from evil".
- phkahler 1y ago
  I would add "I've just opened this file" which is close to "just launched the app". That requires a bit of plumbing though since it's user interaction with another app which then tells the system to open the file (and hence launch the app for it). It sounds like that's what KDE is doing here, passing the user permission (granted by double click) on to whatever opens the file. In general I agree that most system access should only be allowed if its an actual user intent through the GUI or whatever. Obviously certain things might be granted exceptions, but the norm should be more restrictive.
- ghusto 1y ago
  > I've just launched the application I'd even have a special sub-criterion under this: The application may only take focus once it is _ready to actually use_. Slack is a prime example of how apps steal focus multiple times during startup: I start the app, cmd+tab to something else whilst I'm waiting, and it steals focus again at least 3 times before it's actually loaded and usable. You can have focus once I can actually do something, not to show me "HEY LOOK I'VE LOADED YET ANOTHER BLOATED COMPONENT!"
  - zuminator 1y ago
    Determining when an app is fully ready to actually use sounds like it might have Halting Problem issues?
    - eliaspro 1y ago
whalesalad 1y ago
Oddly enough I find this to be annoying. 99.99% of the time when I want an app to take focus (ie, clicking a hyperlink from within a shell window), it won't and simply illuminates that app in the task bar (orange). Classic example is when you push a fresh branch to Github and they conveniently provide the "click here to make a PR" in the push response. I just set my window stealing behavior setting to "None" to see if that improves things. I have never had an app (on Linux/KDE) steal my attention inappropriately. I only experience the opposite - frustration that something I expect to become the new focus, front-and-center window, is not.
ghusto 1y ago
I'm so happy someone's doing something about this. I've had to resort to using my iPad with a keyboard for when I can't stand distractions. DnD on iPad/iPhone actually does what it says on the tin, because applications can't bypass it with direct access to the screen like they can on a desktop.
- hollerith 1y ago
  "DnD" == "Do Not Disturb"
Shank 1y ago
This is, quite unironically, the type of development I wish Apple would pursue for macOS. It's 2025 and focus stealing is still a topic we can have a serious conversation about. Why? "I want to use my computer without random popups accidentally eating my keyboard commands and doing things without my consent" is not /that/ unreasonable of an ask.
- seemaze 1y ago
  Oh man, I loathe when I close a Microsoft Excel window on macos and my whole desktop virtual space jumps to some other virtual space that happens to still have an Excel window open. Only slightly less irksome is that the undo history spans all open documents commingled.
  - emchammer 1y ago
    Where has macOS focus stealing let you down other than Microsoft applications?
    - troyvit 1y ago
      Hilariously LibreOffice steals this "functionality", at least in KDE.
    - nottorp 1y ago
      I think about everything that's not made by Apple focus steals. And Apple allows them. I suppose that's why they developer liquid glass, if they make the screen unreadable it won't matter that the wrong application is focused.
    - lynndotpy 1y ago
      This happens to me regularly on computers running MacOS, including with system prompts that appear too quick while I'm typing for me to tell you what I even hit enter/space on.
    - pxc 1y ago
      I like to have a new Emacs frame pop up for Org capture, but when the frame closes, focus is then given to Emacs instead of being restored to whatever I was using before I used the global hotkey to summon the new frame for the Org-capture buffer. I have the same problem for opening any text file in a text editor from a separate terminal emulator. If I have any other editor windows open, if I save and close that file, focus is not restored to my terminal application. It should be noted that this isn't true focus stealing, which is when a new window (that you didn't ask for) pops up and suddenly grabs focus from what you're doing. This is just macOS' app-based rather than window-based GUI task switching behavior sucking like it has always sucked.
jm4 1y ago
Is focus stealing a real problem? I am a longtime Linux user and I happen to use KDE on Wayland. I wasn’t even aware this was a thing. Which desktops and apps is this happening with?
- DonHopkins 1y ago
  Not only focus stealing, but focus hostage taking, when one application steals the focus and won't give it back! Sun's notorious XBugTool stole both my input focus AND mouse motion, and held me hostage when I tried to file a bug against its XView buddy cmdtool. Here is the bug report I filed against the X11/NeWS server as a desperate cry for help while I was trapped in xbugtool's grabby clutches: https://www.donhopkins.com/home/catalog/unix-haters/x-windows/xbugtool.html https://www.donhopkins.com/home/catalog/unix-haters/x-window... Date: Mon, 20 May 91 22:45:46 PDT Bug Id: 1059974 Category: x11news Subcategory: server Bug/Rfe: bug Synopsis: I have no mouse motion and my input focus is stuck in xbugtool!!! Keywords: I have no mouth and I must scream [Harlan Ellison] Severity: 1 Priority: 1 Description: This is my worst nightmare! None of my TNT or XView applications are getting any mouse motion events, just clicks. And my input focus is stuck in xbugtool, of all places!!! When I click in cmdtool, it gets sucked back into xbugtool when I release the button! And I'm not using click-to-type! I can make selections from menus (tnt, olwm, and xview) if I click them up instead of dragging, but nobody's receiving any mouse motion! I just started up a fresh server, ran two jets and a cmdtool, fired up a bugtool from one of the jets (so input focus must have been working then), and after xbugtool had throbbed and grunted around for a while and finally put up its big dumb busy window, I first noticed something was wrong when I could not drag windows around! Lucky thing my input focus ended up stuck in xbugtool! The scrollbar does not warp my cursor either... I can switch the input focus to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh! There, yes! Aaaaah! What a relief! It stopped! I can move my mouse again!! Hurray!!! It started working when I opened a "jet" window, found I could type into it, so I moved the mouse around, the cursor disappeared, I typed, there were a couple of beeps, I still couldn't find the cursor, so I hit the "Open" key, the jet closed to an icon, and I could type to xbugtool again! And lo and behold now I can type into the cmdtool, too! Just by moving my cursor into it! What a technological wonder! Now I can start filing bug reports against cmdtool, which was the only reason I had the damn thing on my screen in the first place!!! I am amazed at the way the window system seems to read my mind and predict my every move, seeming to carry out elaborate practical jokes to prevent me from filing bugs against it. I had no idea the Open Windows desktop had such sophisticated and well integrated interclient communication!
nottorp 1y ago
Can't you just not allow applications to request focus from themselves, and allow focus changes only from the window manager based on user actions?
eviks 1y ago
> The file manager then launches your PDF viewer and hands it the token. The PDF viewer, upon starting, shows this token to the compositor and asks to be activated. The compositor checks if the token is legit and, if so, gives the PDF viewer focus. >If the token is missing, old, or otherwise invalid, the compositor says no. Doesn't seem to go far enough. If this is a long operation and you switch to another app to read a page in a browser, will the opened PDF steal focus from your reading or allow you to switch to PDF at your own leisure? > The viewer window will not get focus, and instead, its icon in the taskbar will start flashing to grab your attention. This is just a common awful alternative. There is nothing important about this activity to flash, charging the style once would be just fine. But at least it's not jumping up like the UI geniuses at Apple have done. But otherwise, great initiative, focus stealing is a serious UI crime!
bjoli 1y ago
Gnome should follow suit. I still have problems with context menus stealing focus and locking it to the window where they are opened. When I right click in nautilus I have to close that menu before I can click anything not-nautilus. It happens in every gnome application with 2 out of 3 mouse devices and it drives me nuts. I still can't drag and drop if I alt-tab to a different window. All of these were introduced after 3.0, but have not been considered severe enough to fix.
- IlikeKitties 1y ago
  > Whats the use-case of focusing windows? > Ticket closed This is what gnome will do.
  - lannisterstark 1y ago
    Yep, been there. It's baffling just how strange Gnome devs' priorities are, not to mention how they interact with the community. Rest of the DEs seem to be more "Okay, community said this, let's try this with x or y." Gnome is more "We know best, no we're not listening to you" from all the interactions I've had with gnome devs. "Can you tell me a use case for this?" for a feature for example present in every other DE. I forgot what the exact context was or I'd pull up the ticket. Something to do with the sorting of files from the header of the sort display or some such.
- chrismorgan 1y ago
  Focus stealing is when a window unexpectedly acquires focus. You’re describing something different, a window not relinquishing focus because of a chosen and consistent (not universally appreciated, but justifiable) behaviour for modals.
  - bjoli 1y ago
    Not a modal dialog. A right click menu. I have had so many focus issues on gnome that what I meant is that they should do a new take on the whole thing. The problem has gotten worse, not better, over the years.
SubiculumCode 1y ago
Oh you are typing a password? Let's change the focus to some random insecure window.
rpgbr 1y ago
macOS Sequoia (or Sonoma) changed behavior when you right click a link on Safari having its window in background. The context menu shows up and previous foreground app loses focus, but Safari doesn't get it/stays in background, so you basically have no window on focus.
lannisterstark 1y ago
Hah. Just yesterday Bambu studio did this shenanigan when the application crashed. 10 focus changes within a 1 second, repeat indefinitely. It was infuriating. Had to reboot and it does it on every filament sync now.
cadamsdotcom 1y ago
Nice. Open source lends itself well to folks refining tiny but crucial details until they are really nice - or at least really configurable.
t_mann 1y ago
This is a perfect example of how FLOSS is nowadays a truly different type of experience from commercial software: thanks to A/B-tests, software has become so good at manipulating our behavior that it's now often more profitable to optimize software not to be the best at what it's supposed to do but at stealing your time and attention. Ads and (extremely clickbaity) 'news' plastered all over W11 are a prime example, and the exact opposite of what the KDE team are doing here.
wkat4242 1y ago
I'm glad this can be turned off. Choice is why I use KDE. I use many older pieces of software which will probably never implement this. And I never have issues with focus stealing with the stuff I use.
Klaster_1 1y ago
It's infuriating that browser vendors still haven't dealt with extensions stealing focus. Every time I turn my seldomly-used laptop, one of extensions decides it's extremely important to show me a change log or something. I don't even remember what extensions I have as long as these function as expected.
vrighter 1y ago
Great. It's really annoying to be typing my password to unlock my password manager, immediately after logging in, only for discord to pop up and steal focus, because it takes long to load. Switch back, try entering the password again and now steam launches and steals the focus again.

153 points by bundie 1y ago

My ideal state of this feature is probably one that mostly behaves as "normal", but lets me mark individual badly behaving, user-hostile applications like Zoom as unable to steal focus when they abuse it.

robhlt 1y ago
This is already supported! KDE has a really powerful "window rules" feature that lets you configure all kinds of properties on specific windows/apps, and focus stealing prevention is one of them. Just right click the app's title bar and under "more actions" you'll see "Configure Special Window/Application Settings...". The rule configuration window isn't the easiest to use, but "Add Property" is how you can set properties on windows that match the new rule.
- prmph 1y ago
  This windows rules feature seems to be bug ridden. Yesterday I struggled with it all day. Rules were not being followed properly, were erased mysteriously, etc. I like KDE a lot, but this part of it needs work.
  - dmonitor 1y ago
    I suspect a lot of that comes from the "how to detect whether window x is window x" settings
  - o11c 1y ago
    Don't confuse "window rules" with "application rules". When configuring rules, you normally want the latter unless you know you want the former. Also don't forget that rules can interact with other rules. For example, window size interacts with all of: "fullscreen", "maximized", and the "geometry" options (commonly set to more than 1 pixel for terminals). That said, I am really not a fan of the recent UI-pessimization of the settings screen to require you to type out the setting you want rather than have tabs listing all the various options in a discoverable manner.

pseudocomposer 1y ago

Interesting reading, and it’s nice to see how they’ve implemented it and tweaked the KDE app suite to manage focus better as a result. Does anyone know whether there are (or have been) analogous issues on macOS/Windows? And what about GNOME or maybe XFCE?

sho_hn 1y ago
It's all more or less the same between Plasma/Gnome/XFCE. On X11 all window managers had to employ roughly similar heuristics-based tactics. That does however mean there might be behavior differences based on the specific WM's implementation. The token-based activation protocol for Wayland is a shared development that has been adopted across different toolkits, and I imagine will probably also result in more consistent default behavior across environments, although of course in theory a given compositor could decide or be configured to whatever flavor of stealing prevention is wanted. I can't comment much on macOS/Windows technically, except that my standard user experience on Windows installs is that at least once per week, some OEM background thing decides to update something that for some reason requires running a cmd.exe terminal window that reliably steals focus from whatever I'm doing. This kind of thing hasn't really been an issue on Linux DEs for decades.
ghusto 1y ago
It's the same everywhere, and it's unbelievable that it's been allowed for so long.

rollcat 1y ago

IMHO every desktop environment (yes, looking at you, macOS) should aggressively block focus stealing. The only conditions under which focus should change: - I've just launched the application - I've clicked on a window - I've clicked the window's icon in the dock - I've cmd-tabbed (or equivalent) to this window - The currently focused window has produced a modal dialog, that prevents all input events from going into the original window. (Whether and when modal dialogs are OK is debatable.) Matthew 5:37, "anything more comes from evil".

phkahler 1y ago
I would add "I've just opened this file" which is close to "just launched the app". That requires a bit of plumbing though since it's user interaction with another app which then tells the system to open the file (and hence launch the app for it). It sounds like that's what KDE is doing here, passing the user permission (granted by double click) on to whatever opens the file. In general I agree that most system access should only be allowed if its an actual user intent through the GUI or whatever. Obviously certain things might be granted exceptions, but the norm should be more restrictive.
ghusto 1y ago
> I've just launched the application I'd even have a special sub-criterion under this: The application may only take focus once it is _ready to actually use_. Slack is a prime example of how apps steal focus multiple times during startup: I start the app, cmd+tab to something else whilst I'm waiting, and it steals focus again at least 3 times before it's actually loaded and usable. You can have focus once I can actually do something, not to show me "HEY LOOK I'VE LOADED YET ANOTHER BLOATED COMPONENT!"
- zuminator 1y ago
  Determining when an app is fully ready to actually use sounds like it might have Halting Problem issues?
  - eliaspro 1y ago

whalesalad 1y ago

Oddly enough I find this to be annoying. 99.99% of the time when I want an app to take focus (ie, clicking a hyperlink from within a shell window), it won't and simply illuminates that app in the task bar (orange). Classic example is when you push a fresh branch to Github and they conveniently provide the "click here to make a PR" in the push response. I just set my window stealing behavior setting to "None" to see if that improves things. I have never had an app (on Linux/KDE) steal my attention inappropriately. I only experience the opposite - frustration that something I expect to become the new focus, front-and-center window, is not.

ghusto 1y ago

I'm so happy someone's doing something about this. I've had to resort to using my iPad with a keyboard for when I can't stand distractions. DnD on iPad/iPhone actually does what it says on the tin, because applications can't bypass it with direct access to the screen like they can on a desktop.

hollerith 1y ago
"DnD" == "Do Not Disturb"

Shank 1y ago

This is, quite unironically, the type of development I wish Apple would pursue for macOS. It's 2025 and focus stealing is still a topic we can have a serious conversation about. Why? "I want to use my computer without random popups accidentally eating my keyboard commands and doing things without my consent" is not /that/ unreasonable of an ask.

seemaze 1y ago
Oh man, I loathe when I close a Microsoft Excel window on macos and my whole desktop virtual space jumps to some other virtual space that happens to still have an Excel window open. Only slightly less irksome is that the undo history spans all open documents commingled.
- emchammer 1y ago
  Where has macOS focus stealing let you down other than Microsoft applications?
  - troyvit 1y ago
    Hilariously LibreOffice steals this "functionality", at least in KDE.
  - nottorp 1y ago
    I think about everything that's not made by Apple focus steals. And Apple allows them. I suppose that's why they developer liquid glass, if they make the screen unreadable it won't matter that the wrong application is focused.
  - lynndotpy 1y ago
    This happens to me regularly on computers running MacOS, including with system prompts that appear too quick while I'm typing for me to tell you what I even hit enter/space on.
  - pxc 1y ago
    I like to have a new Emacs frame pop up for Org capture, but when the frame closes, focus is then given to Emacs instead of being restored to whatever I was using before I used the global hotkey to summon the new frame for the Org-capture buffer. I have the same problem for opening any text file in a text editor from a separate terminal emulator. If I have any other editor windows open, if I save and close that file, focus is not restored to my terminal application. It should be noted that this isn't true focus stealing, which is when a new window (that you didn't ask for) pops up and suddenly grabs focus from what you're doing. This is just macOS' app-based rather than window-based GUI task switching behavior sucking like it has always sucked.

jm4 1y ago

Is focus stealing a real problem? I am a longtime Linux user and I happen to use KDE on Wayland. I wasn’t even aware this was a thing. Which desktops and apps is this happening with?

DonHopkins 1y ago
Not only focus stealing, but focus hostage taking, when one application steals the focus and won't give it back! Sun's notorious XBugTool stole both my input focus AND mouse motion, and held me hostage when I tried to file a bug against its XView buddy cmdtool. Here is the bug report I filed against the X11/NeWS server as a desperate cry for help while I was trapped in xbugtool's grabby clutches: https://www.donhopkins.com/home/catalog/unix-haters/x-windows/xbugtool.html https://www.donhopkins.com/home/catalog/unix-haters/x-window... Date: Mon, 20 May 91 22:45:46 PDT Bug Id: 1059974 Category: x11news Subcategory: server Bug/Rfe: bug Synopsis: I have no mouse motion and my input focus is stuck in xbugtool!!! Keywords: I have no mouth and I must scream [Harlan Ellison] Severity: 1 Priority: 1 Description: This is my worst nightmare! None of my TNT or XView applications are getting any mouse motion events, just clicks. And my input focus is stuck in xbugtool, of all places!!! When I click in cmdtool, it gets sucked back into xbugtool when I release the button! And I'm not using click-to-type! I can make selections from menus (tnt, olwm, and xview) if I click them up instead of dragging, but nobody's receiving any mouse motion! I just started up a fresh server, ran two jets and a cmdtool, fired up a bugtool from one of the jets (so input focus must have been working then), and after xbugtool had throbbed and grunted around for a while and finally put up its big dumb busy window, I first noticed something was wrong when I could not drag windows around! Lucky thing my input focus ended up stuck in xbugtool! The scrollbar does not warp my cursor either... I can switch the input focus to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh! There, yes! Aaaaah! What a relief! It stopped! I can move my mouse again!! Hurray!!! It started working when I opened a "jet" window, found I could type into it, so I moved the mouse around, the cursor disappeared, I typed, there were a couple of beeps, I still couldn't find the cursor, so I hit the "Open" key, the jet closed to an icon, and I could type to xbugtool again! And lo and behold now I can type into the cmdtool, too! Just by moving my cursor into it! What a technological wonder! Now I can start filing bug reports against cmdtool, which was the only reason I had the damn thing on my screen in the first place!!! I am amazed at the way the window system seems to read my mind and predict my every move, seeming to carry out elaborate practical jokes to prevent me from filing bugs against it. I had no idea the Open Windows desktop had such sophisticated and well integrated interclient communication!

nottorp 1y ago

Can't you just not allow applications to request focus from themselves, and allow focus changes only from the window manager based on user actions?

eviks 1y ago

> The file manager then launches your PDF viewer and hands it the token. The PDF viewer, upon starting, shows this token to the compositor and asks to be activated. The compositor checks if the token is legit and, if so, gives the PDF viewer focus. >If the token is missing, old, or otherwise invalid, the compositor says no. Doesn't seem to go far enough. If this is a long operation and you switch to another app to read a page in a browser, will the opened PDF steal focus from your reading or allow you to switch to PDF at your own leisure? > The viewer window will not get focus, and instead, its icon in the taskbar will start flashing to grab your attention. This is just a common awful alternative. There is nothing important about this activity to flash, charging the style once would be just fine. But at least it's not jumping up like the UI geniuses at Apple have done. But otherwise, great initiative, focus stealing is a serious UI crime!

bjoli 1y ago

Gnome should follow suit. I still have problems with context menus stealing focus and locking it to the window where they are opened. When I right click in nautilus I have to close that menu before I can click anything not-nautilus. It happens in every gnome application with 2 out of 3 mouse devices and it drives me nuts. I still can't drag and drop if I alt-tab to a different window. All of these were introduced after 3.0, but have not been considered severe enough to fix.

IlikeKitties 1y ago
> Whats the use-case of focusing windows? > Ticket closed This is what gnome will do.
- lannisterstark 1y ago
  Yep, been there. It's baffling just how strange Gnome devs' priorities are, not to mention how they interact with the community. Rest of the DEs seem to be more "Okay, community said this, let's try this with x or y." Gnome is more "We know best, no we're not listening to you" from all the interactions I've had with gnome devs. "Can you tell me a use case for this?" for a feature for example present in every other DE. I forgot what the exact context was or I'd pull up the ticket. Something to do with the sorting of files from the header of the sort display or some such.
chrismorgan 1y ago
Focus stealing is when a window unexpectedly acquires focus. You’re describing something different, a window not relinquishing focus because of a chosen and consistent (not universally appreciated, but justifiable) behaviour for modals.
- bjoli 1y ago
  Not a modal dialog. A right click menu. I have had so many focus issues on gnome that what I meant is that they should do a new take on the whole thing. The problem has gotten worse, not better, over the years.

SubiculumCode 1y ago

Oh you are typing a password? Let's change the focus to some random insecure window.

rpgbr 1y ago

macOS Sequoia (or Sonoma) changed behavior when you right click a link on Safari having its window in background. The context menu shows up and previous foreground app loses focus, but Safari doesn't get it/stays in background, so you basically have no window on focus.

lannisterstark 1y ago

Hah. Just yesterday Bambu studio did this shenanigan when the application crashed. 10 focus changes within a 1 second, repeat indefinitely. It was infuriating. Had to reboot and it does it on every filament sync now.

cadamsdotcom 1y ago

Nice. Open source lends itself well to folks refining tiny but crucial details until they are really nice - or at least really configurable.

t_mann 1y ago

This is a perfect example of how FLOSS is nowadays a truly different type of experience from commercial software: thanks to A/B-tests, software has become so good at manipulating our behavior that it's now often more profitable to optimize software not to be the best at what it's supposed to do but at stealing your time and attention. Ads and (extremely clickbaity) 'news' plastered all over W11 are a prime example, and the exact opposite of what the KDE team are doing here.

wkat4242 1y ago

I'm glad this can be turned off. Choice is why I use KDE. I use many older pieces of software which will probably never implement this. And I never have issues with focus stealing with the stuff I use.

Klaster_1 1y ago

It's infuriating that browser vendors still haven't dealt with extensions stealing focus. Every time I turn my seldomly-used laptop, one of extensions decides it's extremely important to show me a change log or something. I don't even remember what extensions I have as long as these function as expected.

vrighter 1y ago

Great. It's really annoying to be typing my password to unlock my password manager, immediately after logging in, only for discord to pop up and steal focus, because it takes long to load. Switch back, try entering the password again and now steam launches and steals the focus again.