i made a simple AppleScript to toggle the sidebar of the frontmost Finder window. I’d like to put it inside the finder’s toolbar. By saving the script as an application it works nearly fine. There is only one serial flaw: when clicking it, I get an annoying delay until the sidebar is toggled. During this delay the “Toggle sidebar.app” icon appears in the dock (cause it’s an .app launching). I can execute the script without appearing in the dock and without any delays in several different ways (launching it from the scripts menu, calling osascript from the command line, running from script editor). Thus the delay is definitely unnecessary. Is there any way to put an icon in the finder toolbar which will simply execute a script not bundled as an application? (or at least run the script without delay…)
The delay is probably caused by saving it as an application. (A small piece of code launches, which then runs the script.) However, I’m not aware of any other way to use a script from the Finder toolbar.
Also, you can save your script as stay open application and add a reopen handler. The script app stays open and waiting. Something like this:
on run
tell application “Finder”
activate
display dialog “hi”
end tell
end run
on reopen
run
end reopen
Another way is to use a script runner. It stays open and runs compiled scripts, something like the script menu exept that the runner takes the place of system events and you set the compiled script to open with this app. You can make any app background only also so it doesn’t show in the dock.
A suppose an easy variation on this would be the Folder Actions system. Attach the script to a folder called, say, “Toggle Sidebar”, that’s hidden away somewhere, and put the folder in the Finder window tool bar. It’s a bit Heath Robinson, but it works well and is faster than opening the script as an application:
on opening folder thisfolder
set maxWidth to 124
tell application "Finder"
set w to front Finder window
if (w's sidebar width is maxWidth) then
set w's sidebar width to 0
else
set w's sidebar width to maxWidth
end if
end tell
tell application "System Events"
tell application process "Finder"
set frontmost to true
keystroke "[" using command down
end tell
end tell
end opening folder
Afterthought: I use “Text only” in my tool bars. If you use icons, the appeal of the above will depend on whether you can bear the sight of a folder icon in the tool bar.
Nigel, I was thinking of folder actions, but couldn’t think how you could make it easy.
One thing about the script runner I have problems with is that you can’t trash the compiled script after it was opened with the script runner. In it’s simplest form:
on open p
run script p
end open
I think the scirpt runner doesn’t reply back to the Finder that it’s done with the compiled script. Anybody know how to make it so the Finder thinks that the script app is through with the compiled script? How do you return an I’m done with the file and still stay open?
That’s an annoyingly transient problem! At first I couldn’t reproduce it. Then I could. Then I couldn’t. Then it wouldn’t go away. Now, after a restart, I can’t get it to happen again. I’ve tried a few things like only using local variables in the script and having the script return a value, but I can’t prove that these make any difference. I suppose it’s only rarely that anyone would want to delete a script in such a situation, so perhaps a restart beforehand (if necessary) wouldn’t be too much of an imposition.
On my machine, your runner approach seems to work slightly faster than the folder action, though it produces a slightly more violent flicker of the Finder window owing to the switch between the Finder and the runner as the frontmost apps. (Perhaps this doesn’t happen when the runner’s hidden.)
I also use a background-only, stay-open app to act as a script runner (although I haven’t yet been able to replicate the behaviour you describe).
Another benefit of this approach relates to the fact that some of my scripts need to display certain application properties (including property labels, coerced to text). Running such a script from Script Menu displays some labels correctly (such as those from System Events), while others (from, say, Finder) would be displayed as raw codes (e.g: «class abcd»). So originally, each affected script would include a routine that loaded the required terminology before executing the main routines - although this involved a small delay each time the script was run. I now get the script runner to load any required terminology at login - and this effectively removes the need for a loading mechanism in each individual script.
Some of these scripts also contain script properties whose value may change each time the script is run. With the construct that kel outlined, I found that the properties weren’t being saved from one run to the next. So the method I currently use is (in simplified form):
on open f
set s to load script f
run s
store script s in f replacing yes
end open
This saves any modified properties to the relevant script file perfectly.
When attempting to trash a script file here, neither method reproduces the aforementioned difficulties. So I couldn’t say whether this approach improves that behaviour. Might be worth a try, though…
I tried the load/store script approach and Finder still thinks the compiled script is in use. I quit and activated the Finder and could empty the trash. Strange how this happens all the time on my computer. Good idea though.
At first I couldn’t reproduce it. Then I could. Then I couldn’t. Then it wouldn’t go away. Now, after a restart, I can’t get it to happen again. I’ve tried a few things like only using local variables in the script and having the script return a value, but I can’t prove that these make any difference. I suppose it’s only rarely that anyone would want to delete a script in such a situation, so perhaps a restart beforehand (if necessary) wouldn’t be too much of an imposition.