I’ve been using totalFinder for quite some time, its great, but I came across something I think might be a bug, and was wondering if anyone else have had the same issues.
I develop OS tools for graphic softwares, and one of my tools allow users to open multiple folders in the OS browser.
This works on OSX when totalFinder is not running (so just the regular finder)
The problem is that when opening a directory by running python commands ( with subprocess.Popen), total finder will only open the 3 first folders that the python code is telling the OS to open. It always stops on 3 folders for some reason.
The reason I think it’s a bug is as mention above: if I quit totalFinder and run the regular finder - the problems does NOT happen.
Have anyone had the same issues, or is there any totalFinder Developers in here that might be able to give me some info on this issue?
from the graphic software I’m running a module that has subprocess.Popen() built in, but running the code directly in for example Sublime or equal program also results in the same problem:
Most of the time it opens the 3 first paths in the list, some times it opens 4 of the paths.
import subprocess, os, sys
osName = sys.platform
a = '/Users/username/Desktop/otherFolder'
b = '/Users/username/Movies'
c ='/Users/username/Desktop/icons'
d = '/Users/username/Music/AlbumsArt'
e = '/Users/username/pics'
f = '/Users/username/Desktop/Resume'
list = [a,b,c, d, e, f]
print 'running on OSX:', osName
for i in list:
if (osName == 'darwin'):
print "now opening path: '%s'" % i
subprocess.Popen(['open', i])
You have discovered a nasty bug in TotalFinder. Applescript subsystem is creating windows so fast that some totalfinder hooks get re-entered. This was never expected. Have to redesign my code to be more safe.
A workaround:
put time.sleep(0.5) after Popen call
I did more tests and the problem affects Finder too. I have tested with 10 paths and Finder also does not open all of them on my machine.
Under the hood. Python’s popen calls shell’s open, which in turn uses AppleEvents to send GURL AppleEvent to Finder. My theory is that apple events subsystem drops events if target app is “busy”. TotalFinder made this problem more obvious because it does some heavy-lifting when new Finder windows are created by Finder.
I have improved this behaviour in upcoming TotalFinder 1.6.19 (my heavy-lifting is done asynchronously and applescript has some time to finish call).
But still time.sleep(…) is a workaround which works in both cases. You give TotalFinder some time to handle apple event before you issue a new one.
Yes you are right, did some more testing on my end also with more paths. Apparently one can feed Popen() more parameters and make it wait or check for child processes and so on, but your suggested ‘time.sleep()’ seems to be the easiest/quickest workaround I think.
Your theory is right to the point, seems very much like that is what’s happening.
I found time.wait(0.3) to be the magic number through my tests, but to be on the safe side, I’ll be using (0.5).
I tried to wait for popen/open calls. But nothing worked for me.
The problem is that issuing an Apple Event is also asynchronous. From shell’s point of view open finishes early and clean, because it just posts the event to the apple events subsystem, it does not wait for Finder to really finish opening window (or whatever it has to do in response to the event).
Aha, good to know, yeah i didn’t test it fully, only tried popen.wait() to find it didn’t work out of the box like that so assumed one had to write a more complex tests for multiple events, so I settled for the simple wait command to give it some time before moving on…
Thanks for the info, looking forward for your future update on the totalFinder.