I’m wondering if it’s possible, using AppleScript, to display a folder tree in the sidebar of the finder. I think the Finder is a terrible file manager. It takes far too many steps to do simple things like move a file. As it stands, I have to navigate to the folder containing the file I want to move, either copy it or drag it to the desktop or something then navigate to the folder I want to move it to and either paste or drag it in there. (Or, have two finder windows open which obscures 80% of my screen.) I’d like to be able to have a folder tree (like the standard Tree View only with JUST folders, not all the files) on one side of the Finder to navigate my directories and have a file list on the other side. Then, I could have my original file location on the right and navigate to the destination on the left and just drag it over. The standard Tree View, because it displays both folders and files, becomes massively cluttered very quickly and I end up scrolling all over the place. And I get that some people like spring loaded folders, but they never seem to work correctly for me. I’ve spent days trying out other file managers but the only one I’ve found that’s close to this functionality is Macintosh Explorer which runs as slow as molasses flowing uphill in winter. Is this possible? How could it be done?
You may want to try “the goal is the method”. Your goal seems to be an efficient way of moving files, but the method is to “display a folder tree in the sidebar of the finder”, which I don’t think can be done. One of AppleScript’s intended uses is custom file moving. You can come up with some quick, effiecient ways of moving lots of files. You just need to define your routines to come up with parameters for a “move files” script.
You can create a script that is both drag and drop (droplet) and clickable. You can:
Drag one or more files, choose destination folder at “select folder prompt”. Option for destination folder to open after receiving new files.
and/ or
Click app to bring up prompt to select a file or folder, then move that file, folder, or files in folder to destination folder.
Option: Building list of commonly used destination folders for automation of routine moves.
As you define your routines, you find the parameters to build a really nice custom script.
Comments?
SC
My gripe is with the efficiency (or rather inefficiency) of the finder to navigate the file system. Moving files was just one example. I only use a mac at work (i’m a graphic designer) and so i’ve got a ‘jobs’ folder that contains a subfolder for every single job i’ve ever worked on. I’d like to have a listing of just those subfolders so I could open them quickly and move files between them without having to have two finder windows open which not only takes up most of the screen but they often overlap and i’m forced to keep switching the focus. I know some of you zealots will jump down my throat for this but I think a Windows Explorer-like interface is faster.
You just defined your script…
hi doubleoseven,
Why don’t you set up your windows so you’re viewing them in column view? There are many folks who migrated from Billy Box who prefer this method, as it is very similar to what they’re used to.
I recognize this doesn’t address you above issue, but just a thought. 
Why don’t you set up your windows so you’re viewing them in column view? There are many folks who migrated from Billy Box who prefer this method, as it is very similar to what they’re used to.
I currently use the column view. The problem I have with it is that
FOLDER > FOLDER > FOLDER > FOLDER
takes up more space than
FOLDER
FOLDER
FOLDER
FOLDER
especially if your folders have long names. For instance, the subfolders in my jobs directory are things like “20051234 - Client Name - Job Name”.
So, either I have to expand the columns wide enough for me to see the whole name or they get truncated (e.g. 2005123…Name).
If I’m working on three or four jobs at the same time they’re usually close to each other in the folder listing. In column view I have to scroll back to the left to change to another folder. If I could have the folder list in a seperate panel, listing them vertically instead of horizontally, it would be a matter of a single click to change folders with no scrolling. I realize it’s a small difference but when you move around the file system as much as I do an enhancement like this could save me a lot of time overall in a day. Also, if I had a vertical folder listing I could move and copy files without having to either drag them to the left to scroll back over or wait for the spring loaded folders to pop up.
The solution I use now is to have my dock on the left side of the screen with an alias to my jobs folder on it (just above the trash can). I can then click and hold to bring up a vertical list of the folders in it which I then have to scroll down to find the one I want, then click to open the finder. It’s the closest I’ve been able to come.
I’m currently trying to figure out if I could write a Java app containing a folder tree that would hover over the sidebar (and, ideally, stay there and move with the finder) that I could click to change the current directory in the finder window and that I could copy and move files with by dragging them onto it. I’m not that good with Java though, so it could take me a while. (If OSX would support Tk I’d be able to do it no sweat. Why they had to hack up their own version of perl I still don’t know. Anyone know of a Perl Windowing Toolkit that works on OSX?)
ahh … I see what you mean.
hmm … this raises another question. Without changing the topic of this thread, does anyone know of a way to make all windows under the Finder to default to List View?
I’m one of those throwbacks to the List Views under OS 9, which I’m most comfortable using. However, when you first open any window in the Finder, they always default to the windows which have the browser view showing. This is especially true of when a file has been de-compressed, or when opening disk images.
I’ve poked around in the pList’s, but could find nothing which shed clues on how to pull this off. [shrug]
I don’t know of any Perl Toolkit, however I do think there might be something out there using Python. I would have to defer, because this is a blank area for me.
What would be really cool is just to script up a Applescript Studio app which mimics the kind of behavior you’re looking for; ie: a sudo-browser of sorts which runs in the background. It would be just small enough to not have a huge footprint, and not a resource hawg.
You can do something similar with the shareware dock application “DragThing”. The difference with DragThing is that you can navigate a drag-and-drop though your “vertical list” and deposit the dragged item(s) onto the required folder name (and thus into the required folder) without having to open the folder first. During such drags, DragThing dims the names of files, making the folders easier to spot.
There’s much else to like about this app too. It’s virtually the single piece of software (apart from Script Menu and my own scripting ability) that makes OS X usable for me.
I’m not connected in any way with the author or his agents! 
hmm … this raises another question. Without changing the topic of this thread, does anyone know of a way to make all windows under the Finder to default to List View?
Again, my problem with the List View is that, since it displays files as well as folders, you end up with a massively long list of items and spend a lot of time scrolling up and down looking for a single one. Could I possibly set up a Finder window to display in List View but only show the folders and then be able to somehow (Key+Click or something) to open the selected folder in a new finder window?
And I’ve checked out DragThing (and every other similar app I could find) and they all have their good points but still aren’t really what I’m looking for.
Ok, how about this one. Can I use AppleScript to create a panel that would attach to the side of a finder window (I guess you’d call it a drawer) then put a folder tree in that?
You could look into Perl/Tk (you’ll need X11 installed).
Edit: Does anyone know if Path Finder has something that would work for doubleoseven?
PerlTk is not supported on OSX. I wish it were.
Checked out Path Finder too. It’s got a buttload of features but oddly enough still not what I’m looking for. It has a sidebar that you can drop things in like a clipboard but no treeview is avaliable in it (the sidebar).
***** Can I add a drawer to the finder? *****
Thanks for the link guardian but unfortunately, I’ve already been down that road. I spent about a week trying to get Tk installed on this Mac with no luck. Jumped through as many hoops as I could think of. I have done everything short of reinstalling the OS. I simply can’t get Tk to install. I’m not going to start listing my particular problems cause this is supposed to be an AppleScript forum but suffice to say this is not my machine (it’s my computer at work) so I’m not about to go tearing it apart. I really appreciate the help though.
To get back on topic, does anyone know if I can add a drawer to the finder that I might be able to put a directory tree in?
How about this, a droplet for your dock:
Click and a list of your subfolders comes up and you select one. The folder opens and you select one or more files. Drop them back on the script icon and the list of subfolders prompt comes up. You select the folder the file(s) moves to. This allows you to not have two Finder windows open while executing the move.
set FolderList to {}
set MasterJobFolder to alias "HardDisk:Your:Job:Masterfolder"
tell application "Finder" to set FolderPaths to folders of MasterJobFolder
set FoldrCount to count items of FolderPaths
repeat with i from 1 to FoldrCount
tell application "Finder" to set ThisFolder to (name of (item i of FolderPaths))
set FolderList to FolderList & ThisFolder
end repeat
set FolderChoice to choose from list FolderList with prompt "Choose Job Folder To Access"
tell application "Finder" to open folder ("HardDisk:Your:Job:Masterfolder:" & FolderChoice as string)
on open FileList
set FolderList to {}
set MasterJobFolder to alias "HardDisk:Your:Job:Masterfolder:"
tell application "Finder" to set FolderPaths to folders of MasterJobFolder
set FoldrCount to count items of FolderPaths
repeat with i from 1 to FoldrCount
tell application "Finder" to set ThisFolder to (name of (item i of FolderPaths))
set FolderList to FolderList & ThisFolder
end repeat
set DestinationFolder to choose from list FolderList with prompt "Move Files To Folder:"
tell application "Finder" to move FileList to folder ("HardDisk:Your:Job:Masterfolder:" & DestinationFolder as string)
end open
SC
Tested on a MasterFolder with 48 sub folders
That is very cool. I have only 2 questions. I put it in my dock but when I click it it brings up a dialog that says:
Press Run to run this script or Quit to quit.
Can I get rid of this box?
Also, once the folder list comes up, if I click Cancel I get this error:
Can’t get <> “HardDisk:Your:Job:Masterfolder:false” of application “Finder”.
Is it possible to add a drawer to the Finder?
The longer this post hangs the less likely it is…Maybe in ASStudio?
I still think you can script something to at least make your tasks more custom to your routines…
The error message comes from trying to move to a folder not defined when choosing the “Cancel” button. This fixes that:
set FolderList to {}
set MasterJobFolder to alias "HardDisk:Your:Job:Masterfolder"
tell application "Finder" to set FolderPaths to folders of MasterJobFolder
set FoldrCount to count items of FolderPaths
repeat with i from 1 to FoldrCount
tell application "Finder" to set ThisFolder to (name of (item i of FolderPaths))
set FolderList to FolderList & ThisFolder
end repeat
set FolderChoice to choose from list FolderList with prompt "Choose Job Folder To Access"
tell application "Finder" to open folder ("HardDisk:Your:Job:Masterfolder:" & FolderChoice as string)
on open FileList
set FolderList to {}
set MasterJobFolder to alias "HardDisk:Your:Job:Masterfolder:"
tell application "Finder" to set FolderPaths to folders of MasterJobFolder
set FoldrCount to count items of FolderPaths
repeat with i from 1 to FoldrCount
tell application "Finder" to set ThisFolder to (name of (item i of FolderPaths))
set FolderList to FolderList & ThisFolder
end repeat
set DestinationFolder to choose from list FolderList with prompt "Move Files To Folder:"
try--Deals with "Cancel" error message
tell application "Finder" to move FileList to folder ("HardDisk:Your:Job:Masterfolder:" & DestinationFolder as string)
end try
end open
The “Run” box is coming from the “save” dialog. Make sure you format as “application” and have “never show startup screen” checked when you save the script. I would save to a new file with a new name for a clean start.
SC
I’ve wanted something like this for a while, and this thread made a little lightbulb go off in my brain. The bad: My solution requires two windows and not-free software. The good: It’s quick, reliable, and transparent.
First, you need to try or buy PreFab software’s UI Actions:
http://www.versiontracker.com/dyn/moreinfo/macosx/24580
This will let you attach the following script to Finder’s notification for “Focused UI Element Changed”
tell application "Finder"
set currentview to current view of Finder window 2
if current view of Finder window 1 is list view then
get container of (selection as alias)
set target of Finder window 2 to result
else
get target of Finder window 1
set target of Finder window 2 to result
end if
set current view of Finder window 2 to currentview
end tell
Now once this is set up, what I like to do is keep the first window in column view, and the second window in icon view. The beauty of it is that despite using two different views, both windows will always be in perfect sync, displaying the same folder two different ways. I’ve only just started using this setup, but in my testing I haven’t found anything not to like. I’ve been able to drag and drop etc. without any weirdness. It’s also pretty simple to turn the behavior off when I don’t need it.
Edit 1: Modified the script so that it preserves view settings better. Also, just discovered that the “Focused UI Element Changed” notification only traps clicks while ignoring keyboard navigation. This may or may not be desirable depending the user’s need.
Edit 2: Discovered that the UI notification for “Selected Children Changed” will support keyboard navigation, but don’t recommend it because it caused massively unnecessary CPU usage.
Edit 3: Changed script so that it supports list view. Note that if you use this configuration, you must add an additional UI Action notification for the Finder’s “Selected Rows Changed,” but you can attach the same script with these caveats: at the moment, if you select a subfolder of a folder, and then click another subfolder of the same folder, window 2 won’t update. Clicking a folder one level up or down will, however, cause window 2 to update. Kind of annoying if anybody actually wants to use this particular configuration, I might find a way around it though.
For me, this syncing of Finder windows is not working very well.
After some modifications to the script, I got a (slave) window that opens in list view - which indeed follows the target of the master (column) window that can remain upfront.
To make implementation easier, I applied a simple repeat loop instead of a UI extension that looking for mouse activity.
Pressing the command key will exit that routine. The sleep value is a trade-off between faster operation and processer load.
set sb to bounds of (item 1 of (screen list)) -- Jon's xcmd
set screen_height to item 4 of sb -- 768
set screen_width to item 3 of sb --1024
tell application "Finder"
set sel to the selection
if current view of Finder window 1 ≠column view then return
activate
set tg to target of Finder window 1
set wdid to id of Finder window 1
set bds to bounds of Finder window 1
set nwit3 to (item 3 of bds) + 600
if nwit3 > screen_width - 200 then set nwit3 to screen_width - 200
set ListWd to {}
set listIDs to (id of Finder windows whose current view = list view)
repeat with fWd in listIDs
set bds2 to bounds of Finder window id (fWd as string)
if item 1 of bds2 = (item 3 of bds) + 10 and item 2 of bds2 = item 2 of bds ¬
and item 3 of bds2 = nwit3 and item 4 of bds2 = item 4 of bds then set ListWd to Finder window id fWd
end repeat
if ListWd = {} then set ListWd to make new Finder window
set bounds of ListWd to {(item 3 of bds) + 10, item 2 of bds, ¬
nwit3, item 4 of bds}
set target of ListWd to tg
set current view of ListWd to list view
if sel ≠{} then reveal sel
set currDate to current date
repeat until (current date) - currDate > 1000
--tell application "Extra Suites" to set md to ES mouse down
if current view of Finder window id wdid ≠column view then return
set Nwsel to the selection
set nwtg to target of Finder window id wdid
if nwtg ≠tg or Nwsel ≠sel then
set tg to nwtg
set target of ListWd to nwtg
set sel to Nwsel
select ListWd
set current view of ListWd to list view
if sel is in items of tg then reveal sel
open Finder window id wdid
end if
if (keys pressed) contains {"command"} then exit repeat
tell me to do shell script "sleep 4"
end repeat
end tell
Eelco Houwink
That’s a very interesting approach to the mirroring concept, Eelco, thank you for sharing it. There are a few things in there I’m none too crazy about (e.g. repeat loops) but it got me thinking about how I could improve my script. One thing I noticed today was how whenever I try to use more than two Finder windows at a time, everything gets really hilarious really fast. To solve this I decided to implement your idea of a Primary/Secondary relationship. In the revised script I’ve decided the target window should only receive updates, not post them. Identifying the target window is easy enough in your script, but on my side of the fork I can’t expect values to persist between runs. Ergo, I’ve decided to simply target the first window caught without a toolbar. If no toolbar-less window is found, I create one.
tell application "Finder"
set sourceWindow to Finder window 1
if sourceWindow's toolbar visible then
activate
try
set targetWindow to first Finder window whose toolbar visible is false
on error
set targetWindow to make new Finder window
my setView(targetWindow)
end try
set currentview to targetWindow's current view
set iconview to targetWindow's icon view options's properties
if sourceWindow's current view is list view then
get (selection as alias)'s container
set targetWindow's target to result
else
get sourceWindow's target
set targetWindow's target to result
end if
if targetWindow's current view ≠currentview then
my setView(targetWindow)
else if targetWindow's icon view options's properties ≠iconview then
my setView(targetWindow)
end if
(* -- Here follows an idea for managing window focus, definitely not ready for primetime...
tell application "System Events" to tell process "Finder"
perform (window (targetWindow's index))'s action "AXRaise"
perform sourceWindow's action "AXRaise"
end tell *)
end if
end tell
on setView(targetWindow)
tell application "Finder"
tell targetWindow
set toolbar visible to false
set current view to icon view
end tell
tell targetWindow's icon view options
set icon size to "128"
set shows icon preview to true
set arrangement to arranged by kind
end tell
end tell
end setView
Oh, you’ll also notice that I just discovered possessives, and couldn’t have any fun without abusing them mercilessly. (: