Run this AppleScript from Script Editor.app and see if it doesn't make your housekeeping a little easier.
If you like it you can run from a Keyboard Maestro Execute an AppleScript action.
-Chris
------------------------------------------------------------
# Close Message Windows using a Pick-List.
------------------------------------------------------------
tell application "System Events"
if quit delay ≠ 0 then set quit delay to 0
tell application process "Mail"
set winList to windows
set messageWinNameList to {}
repeat with i in winList
if not (exists of button "Get Mail" of toolbar 1 of i) then
# set end of messageWinList to contents of i
set end of messageWinNameList to name of i
end if
end repeat
end tell
end tell
------------------------------------------------------------
tell application "Mail"
set closeWinList to choose from list messageWinNameList with title "MESSAGE WINDOWS" with prompt ¬
"Choose which windows to close:" default items {item 1 of messageWinNameList} ¬
with multiple selections allowed
try
repeat with i in closeWinList
close window i
end repeat
end try
end tell
------------------------------------------------------------
Thanks @ccstone - I’m perfectly happy with the solution of just bringing the back-most window forward.
by the time I have only 5 messages open, the built in Control-Tab feature of Keyboard Maestro is all that’s needed. Now that I can cycle from back to front, I doubt my too-many-windows issue will get as bad again.
I have struggled with restocking windows for many years, in QuicKeys, KM, AppleScript, and who knows what else. Here's what I believe:
A window's index can be set to 1
The window whose index is 1 is the front window (AppleScript's "front window")
Although no error occurs, nothing happens when you try to set a window's index to other than 1.
You may not get the results you expect: do you know what index your application returns for minimized windows as opposed to the front (or back) visible window?
Are you sure that an application that uses window tabs is not treating each one as a window (in addition to it's being a tab of another window)? (I think I have encountered this, but it does sound implausible.)
Screwing around with window indices is bad news anyway, because windows exist that are not normal visible application windows (palettes, etc.) that are not visible but ready to be made visible, depending on how applications implement that. (This may be an outdated belief, but if you ask for an application's WINDOWCOUNT(), you may very well be surprised by what you get.) Bind the following to a keystroke and try it in different applications under different circumstances:
Though you would think you could at least move a window to the back.
From what Peter's told me OSX does not support negative window indexing, so there's no way to send a window to the back except to re-stack all of them.
I'm not aware of a utility that could do this since OneClick on Mac OS 9.x.
On further thought an experimentation, I can see why setting the index of a window might not make sense (You would think that Apple would make index a read-only property; currently, if you try to set the index of a window you don’t get an error, but nothing happens.) Suppose you have 4 finder windows. The obvious AppleScript :
set the index of the first window to the index of the last window
wouldn’t make sense — what happens to the index of the last window when this is executed? You’d end up with two windows with index 4 and no index with index 1.
(On the other hand why does setting the index of a window to 1 work — what happens to the index of the front window when you do that? Apple must have put special code in for that case.)
Simply put, the only operation on windows is “bring a window to the front”.
Your example would work fine. If you start with windows 1,2,3,4, you’d end up with windows 2,3,4,1 (ie 2 becomes the front window). There is no confusion about what happens. But Apple does not support this.
So the index is read/write, but the only allowable write is “1”.
No, if you start with windows A, B, C, D and you set window B to be frontmost you would end up with windows B, A, C, D
Essentially the behaviour is the same as you get when you click on a non-front window - that window comes to the front, the previous front window is now second, and so on.
My point, and my example was that the mythical semantics of the non-functional AppleScript:
set the index of the first window to the index of the last window
has perfectly well defined behavioural semantics (A,B,C,D ➤ B,C,D,A) but does not in fact work, which I described, but which does not in fact work because the only valid set index is 1:
set the index of the third window to 1
Which also has perfectly well defined behaviour (A,B,C,D ➤ C,A,B,D) and the advantage that it does actually work.
I think it is confusing to provide such detail for things that don't work.
####So, let me see if I now have it straight about what CAN be done:
The only change in the stack of windows that can be made, is to make a selected window as frontmost.
You could do this by telling AppleScript to set the index of a window to 1
When you move a window to the front, all of the other windows remain in the order that they were.
####However, with a simple AppleScript, we CAN move the first window to the back
--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- MOVE FIRST WINDOW TO BACK
--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tell application "TextWrangler"
set winList to every window
set indexList to index of every window
set nameList to name of every window
log nameList
log indexList
--- It appears that the GET of every window always gets in
--- the current stack order
--- MOVE CURRENT WINDOW 1 TO BACK ---
-- Set each window index to 1 in reverse order
-- except for current window 1
repeat with oWin in (items 1 through -2 of reverse of winList)
log (name of oWin)
set index of oWin to 1
end repeat
end tell
On rereading this page I had a thought about moving windows to positions other than 1: the restriction is the same as for applications — you can make an application frontmost, but you can't rearrange the order of applications (that you would get by ⌘→. The concept both windows and applications are dealing with is simply whether or not they are frontmost — "index 1" for windows, "frontmost true" for applications.
I do wish that Apple provided a way to send a window, and even an application, to the back. In my experience I rarely gave any thought to arbitrary reordering, but I have often wanted to send a window to the back.
My recent experiments have shown the Bring to Front — whether with KM’s action or through AppleScript — is a no-op if the window is not in the current space/desktop.
Another experiment shows that bringing a window to the front by setting its index to 1 doesn’t give the window focus. The above GIF shows that. Note that the window made front seems to have focus briefly then loses it. Does anyone know how to give the front window the focus? I suppose I can just click on it, but I was hoping for something cleaner.
