Only slightly less irksome is that the undo history spans all open documents commingled.
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.
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.
Focus stealing happens quite a lot on macOS.
It's even more infuriating when I want the focus but because it's on a different space MacOS bugs out and refuses to switch. Not to mention when I have an app set to all spaces and reboot and it's stuck on a single space. Nobody at Apple uses MacOS.
Oh, and all these times where a running program doesn't want to be focused. I run my shortcut to focus it, nothing. I type its name in spotlight, nothing. I click its icon in the dock, magic, it gets into focus!
Or when the dock doesn't hide away as it should but just stays there for unknown reasons.
Then in Apple's infinite wisdom, doesn't let you manually set a window to be always on top - one of my most missed features from Gnome, KDE, and even Windows has it with PowerToys.
I love my macbook's hardware, but macOS has to be one of the most frustrating operating systems I've ever used.
(i run it when I have an image in the clipboard and it shows an always-on-top window with that image. i can drag it around but it doesn't take focus. it's so on my single monitor setup (aka laptop on the couch) I can take a snapshot of something and then easily reference it in a maximized/semi-fullscreen application). I honestly mostly wrote it to see how fiddly winapi stuff from rust is but I actually end up using it a bunch)
I see where Wayland is coming from but I've come around to preferring the chaos of every app getting to do whatever it wants over hoping that various compositors are willing to support some obscure special case some app or other might want. Like, it sucks if apps are misbehaving but it sucks more if you can't reasonably fix an app to behave like you want it at all.
Right click the titlebar (or left-click the icon at the left corner thereof) -> M_ore Actions -> uncheck "Keep A_bove Others".
Personally I activate it quite frequently, e.g. to keep a small text editor or terminal open in front of a maximized browser window for reference.
So, anything breaking these very mature mechanisms is a red flag, and is taken seriously.
I don't get the reasoning behind the zero-window cmd-tab interaction, but if it is there I guess that there's a reason behind it?
The current behavior is such a terrible user experience.
I don't know how a company as big as apple can leave everyday things in such a terrible state.
1) If you had a single Finder window open, then closed it, focus would get stolen by whatever other application happened to have a window open.
2) There would be no way to use the keyboard to interact with an item on the desktop without first closing or hiding every running application.
- 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".
Honestly even this is questionable. If a running app gets focus between me asking for the new app to launch and that app actually launching, I probably want the existing app that has focus to keep focus until I actively click on the window of the new app.
Once you do that, too fucking late application. Should've been faster, now you don't get focus until I actively do something.
That being said, I've only ever really noticed focus stealing issues happening on Windows or OS X, never Linux.
One-size-fits-all woes I guess.
That doesn't change the fact that very many apps are in fact that slow that it does matter.
The network is always down, the disk is always slow, and the OS never schedules your threads. Keep those in mind and your code might be good
Applications should take about 1s to launch (median for Apple's native apps), including under moderate load, so this problem should never be perceptible. But the fallback behavior you describe is perfectly reasonable.
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.
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!"
This is why there are protocols like sd_notify [1] or readinessProbe [2] to determine the actual state of the launched service/process/application.
[1] https://www.freedesktop.org/software/systemd/man/254/sd_noti...
[2] https://kubernetes.io/docs/concepts/configuration/liveness-r...
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.
"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.
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.
It’s fairly normal to treat context menus as modals within their parent window. Not universal, but my feeling (which I don’t trust here) is that it has been generally preferred for quite some time. I think this has also become a stronger custom as popovers have become more common, and pure context menus have become less common. It then makes sense to formalise on that pattern. And then applying the modal-closing behaviour across all windows makes sense, even if it’s not the only reasonable option and you’d prefer not.
This happens on any GTK apps on KDE as well, so it seems to be a toolkit bug instead of compositor bug.
Apparently this happens only when you have a mouse that have those additional buttons that are exposed as a "keyboard" to the system :)
I like KDE a lot, but this part of it needs work.
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.
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-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:
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!
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.
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.
>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!
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.
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.
It was infuriating. Had to reboot and it does it on every filament sync now.