Hey,
I searched the forum and found a lot of discussion, but every script I found seemed to be for sending a specific programs frontmost window to the back.
I am trying to script so that whatever window is active gets sent to the back, can anyone help?
While there's a "bring window to front" that KM can use, the OS doesn't provide a "send window to back". So you'll have to spoof it by bringing every window except the frontmost window to the front, in turn.
You may have to play with the pause time so it suits every app on your computer, but try this:
Thanks for the reply!
Unfortunately when I try this script nothing happens at all. Both when using the "try action" cmd and using the designated hotkey.
Similar problem I was having with other solutions I saw on the forum from the past. I assumed those didn't work or were broken with time. Does this script work for you?
Yes, it works for me. Try with a bunch of windows open in TextEdit.
By default, KM imports macros in a "disabled" state. Do make sure you've enabled the macro -- "Try action" will still work when a macro is disabled, but it may be you only have one Editor window open.
If enabling the macro doesn't help, this is a short enough one that you can simply reproduce it yourself in KM. Try that -- does it work?
Okay interesting...
So it works with TextEdit. But it isn't working with my windows that I need it to, (preview, Brave, Word, OneNote, etc.).
Also it seems to only be working within that one app.
So for instance if I have 5 TextEdit windows open on top of a Brave window the script will shuffle around those 5 TextEdit windows, but they will all remain on top of the brave window.
Works fine for me in Preview.
Yes, it will only work within an app. Each app has its own window stacking order, so manipulating windows in this way won't let you send eg a Preview window to the back and reveal the Brave window that was behind it. Even minimising the frontmost window won't do that -- it activates that app's next window.
AFAIK, what I now think you want -- for "interleaved" application windows, send the frontmost window to the back and set focus to the next window even though it belongs to a different app -- can't be done (at least, not reliably in every situation).
Damn that is unfortunate. You are correct that is what I was asking for, sorry for the confusion. I appreciate the help.
I have been trying to do this too, although I don't really care that the front application's window goes all the way to the back, I just don't want it in the front and would be happy to just bring the second application forward.
So far, what I've been trying is to get details of the front app's window: app, filename, size, position, then close that window. That seems to be the only way to actually get that app out of the way so that I can find out what the second app is. When it is close, then I get details of whatever the new frontmost window is for the second app. I reopen the window I just closed in the first app and then bring the second app's window to the front.
I've been trying to do the whole thing in AppleScript so that it runs a little faster, but so far I haven't been able to figure out how to reopen the original front window in the same position it had been in, I have to open it and then move it. As fast as AppleScript can do that, it still shows the window in a different location from where it "belongs".
I've asked about how to do this step in a different thread:
The most recent info that I have on that thread is a tutorial by @CJK on Ask Different that shows how to open a new QuickTime window at the desired size and position.
From the way CJK is able to achieve this, it looks like the front app, the one I want to restore after finding out what the second app is, must be AppleScript-able.
It also looks like this solution (part of: save front window propreties, close front window, identify second window, restore front window, activate second window to put it on top) may be app-specific since it seems to depend on finding a property of the new app that changes between when the app window exists and when it's completely visible. The QuickTime property he uses isn't going to exist for a Finder window, for instance. Since the method of avoiding moving and resizing the window varies from app to app, it's not a general-purpose solution and I may be limited to activate-and-move in the general case.
In their OP, @name3 points out that all solutions they had found were for specific apps, and this approach is no different there, at least as far as being able to avoid the "open first, then move" flash of the app window in the wrong place, but it does work to get the front window behind a window of a different app, rather than behind other windows of the same app, which still stay at the front of everything else.
