I would like to set up a macro for Finder that when you switch to Finder;
if there are no finder windows open in the current space...
opens a new Finder window in the current space.
This is supposed to be the behaviour of Finder anyway when you have system settings set to not switch to another space when an application is activated, but it isn't reliable, or predictably repeatable.
I can use Finder Activates trigger to open the window to the desired directory easily enough, but the testing to only do it if there are no other windows in the space is the bit I don't know.
I saw this applescript:
is there a modification of this... something along the lines of:
if (exists of window 0) then
make new Finder window
I just tried this approach and it works for me (under MacOS Sonoma) but then again so does the default behaviour, so please let me know how you get on…
Here is one way to check if there are any Finder windows open and, if not, open one.
In direct terms, this is looking for the Cycle Through Windows menu command that would only be available if a window is already open, even if it is not in the foreground. If the specified menu command is enabled, nothing happens. Otherwise, File > New Finder Window is selected.
Oddly, automating the Finder is tricky. More challenging is the automation of Mission Control Desktop Spaces. When you put the two together, it gets really ugly!
I've found three non-ideal approaches with AppleScript to count the number of Finder windows in the current Desktop Space:
Option 1
( expand / collapse )
(*
This AppleScript will return the number of Finder windows visible and minimized from the current space with two caveats:
1. If the Finder is hidden, then windows from other spaces will be counted.
2. If Finder windows from other spaces are minimized, those windows will also be counted.
*)
tell application "System Events"
-- Since Monterey, one is able to Quit the Finder
if (name of processes) does not contain "Finder" then
return 0
else
tell application process "Finder"
return count of windows
end tell
end if
end tell
Option 2
( expand / collapse )
(*
This AppleScript will return the number of Finder windows visible and minimized from the current space with two caveats:
1. If the Finder is hidden, then windows from other spaces will be counted. To avoid these false this script returns 0 if the Finder is hidden.
2. If Finder windows from other spaces are minimized, those windows will also be counted.
*)
tell application "System Events"
-- Since Monterey, one is able to Quit the Finder
if (name of processes) does not contain "Finder" then
return 0
else if get visible of process "Finder" is false then
return 0
else
tell application process "Finder"
return count of windows
end tell
end if
end tell
Option 3
( expand / collapse )
(*
This AppleScript will return the number of Finder windows visible and minimized from the current space with two caveats:
1. If the Finder is hidden, then windows from other spaces will be counted. To avoid these false this script returns 0 if the Finder is hidden.
2. If Finder windows from other spaces are minimized, those windows will also be counted. To avoid these false positives, this script unminimizes all Finder windows in all spaces.
*)
tell application "System Events"
-- Since Monterey, one is able to Quit the Finder
if (name of processes) does not contain "Finder" then
return 0
else if get visible of process "Finder" is false then
return 0
else
tell application "System Events"
tell process "Finder"
repeat with w in windows
if value of attribute "AXMinimized" of w is true then
set value of attribute "AXMinimized" of w to false
end if
end repeat
end tell
end tell
delay 1
tell application process "Finder"
return count of windows
end tell
end if
end tell
If you want to test for yourself, here's a macro with the three options:
Thanks for all the suggestions folks, I'll look through them and see what works. What happens in Ventura is:
You have Mission Control set to NOT switch to a space with open windows when activating an application.
You click the Finder icon on the dock, Finder activates, but fails to spawn a file browser.
You click Finder again on the dock, and you get switched to another space where there is a Finder window open (because Finder doesn't respect the "don't switch spaces" setting).
To try to fix the lack of Finder window spawning, you go into system preferences, and toggle the appropriate switch back and forth, and it starts working again, for a while. Hence why I'm trying to build a replacement in KM.
I notice the use of selecting menus in Finder to spawn the new window. I don't appear to have that option in my version of KM (11) - I have "Select a menu by name" or "select or show a menu item".
Is there a reason to do this rather than what I was doing, using the "open" action targeting a directory, with Finder as the chosen application?
@kevinb Your suggestion worked the first time I used it, but afterwards didn't. What is FinderInsertionLocation doing? I tried it with an ANY conditional, for it being both empty and not empty, and then it worked all the time, but then it also triggered when there were other Finder windows open in the space I had active.
@NaOH The Cycle Through Windows menu exists across all spaces, so it's going to be returning true when windows are open in a different space.
@_jims How do I implement your solutions? Taking Option 1 as an example, I'm working within a framework of:
For the approach I gave above to work, any menu condition that changes between a space with open windows compared to a space without open windows will work. So maybe it's checking if File > Close Window is enabled, or some other Finder menu item.
Until I saw @_jims 's reply, I did not pick up on the importance of Spaces in all this (I never use it) so my reply was too simplistic... Also it was broken, as I explain below. Sorry!
The Wiki says: "The %FinderInsertionLocation% token returns insertion location in the Finder, which is usually the path of the front window".
So my thinking was that when there is no front window, the token should be empty. Testing today, I see that that is not correct. I must have been confused by something when I tested this approach before!
Today, a test macro shows that when there is no open window in the Finder, %FinderInsertionLocation% gives the path to the Desktop. Therefore the macro should have tested for that path, not an empty string.
In any case, since I did not even think to address the complexities of Spaces, I doubt that that will work either! I suppose you could try it but I am not optimistic.
No, it's just replicating the behaviour of how it's supposed to work - switching to Finder when there are no Finder windows open in that space is supposed to spawn a window opening to the location Finder defaults towards when you manually spawn a new window.
But it's not when switching to a space, it's when switching to Finder within the space I'm currently working.
The "edit" here is (obviously) correct. But multiple uses of If Then Else appears to work around this.
My Mac and OS are older, so testing on a faster machine may show it's necessary to add a short Pause between the first If Then Else and the second one.
Sorry, I've been otherwise occupied with things, but OMG thanks - that solved it. I'll really have to keep that in mind in future - testing for disabled menu options as a strategy.
There's a really interesting quirk for the second conditional - it doesn't work if there's:
already a Finder window open in the space,
that finder window didn't have focus when Finder was last used
Instead of using a hardcoded keyboard shortcut, you use the "select a menu by name" feature to select: Window > Cycle Through Windows
Interestingly enough, the final section to spawn the new window works fine with doing that for File > New Finder Window.
Is there any difference in speed or performance in using a keystroke directly, rather than the names of the menus?
I appreciate that solution, but it was probably a little outside my confidence level, in terms of loading in someone else's script library. But thanks all the same
I would guess selecting the menu item is faster—it didn't occur to me to use that when I posted that last macro—but I also don't know if the difference is perceptible.
In the second step of both macros, when Cycle Through Windows is selected, by following it with the keystroke Command-`, the result is that Cycle Through Windows is being selected twice, once by the menu item and once by the built-in keyboard shortcut. If one window is open, but not selected, then executing that menu command twice will select it then un-select it.
)
