Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A discussion on running multiple finders System
Ok. The finder is not threaded and it can be slowed down by processes (like accessing your iDisk). Sure, the rest of the system is not slowed down, but what if I want to navigate my hard drive? Is there some way to launch multiple finders? A while back, someone made the suggestion of having multiple desktops in the beta to be able to be root sometimes, but not others. I tried his suggestions and they don't seem to work anymore.

Here's what I did:
  1. Logged in as root.
  2. Found (located in /system/library/coreservices)
  3. Made a copy of (the application, not the fake finder)
  4. Moved it to /Applications and renamed it
  5. Logged out and in as my normal account
  6. Tried to launch the new app and I got an error that the items are used by the finder and cannot be opened
The reason I did this is to get around times when the finder is busy. There's got to be a way (I think that SJ hinted at it when he said that there may be one day when we have multiple finders at MWSF). Let's get this working!
  • Currently 2.38 / 5
  You rated: 2 / 5 (8 votes cast)

A discussion on running multiple finders | 4 comments | Create New Account
Click here to return to the 'A discussion on running multiple finders' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
MarshMallowMode/Finder replacement
Authored by: Anonymous on Mar 25, '01 07:39:27PM

Go to, and give MarshMallowMode a whirl...

[ Reply to This | # ]
Run multiple finders!
Authored by: kirsch on Mar 26, '01 03:47:08AM
It can totally be done, here's how:
1.- make a copy of the finder to, say, your Desktop
2.- rename it to Finder2 or something (optional, but makes it easier to know what you're swithing from/to later
3.- open it from the terminal... type 'open ~/Desktop/Finder2' The Finder icon will start bouncing.
4.- Switch back and forth from the Force Quit window. You'll see all Finder's there :)

You can even launch "someone else's" Finder, say, root's, by su'ing to that user from the terminal. If you have different Desktop pictures for each user, the behavior can be quite weird. I have a snapshot of my machine running 2 Finders, very low quality so it loads fast (sorry). You can see I opened both Connect To Server windows (try that with 1 Finder!)

Marcos Kirsch
The snapshot!

[ Reply to This | # ]
Re: Run multiple finders!
Authored by: Anonymous on Mar 26, '01 04:07:04AM
you can actually not run someone elses Finder, excwept for root (Although this is what many might want to do, when backing up the hard disc, etc...). When you try to launch someone elses GUI-Progs from the command line, the Window server will refuse it due to access priveliges.

This behaviour is absolutely sensible, but there might be ways to change it for some accounts.

[ Reply to This | # ]

multiple finders NOT going to happen
Authored by: zahadum on Mar 26, '01 11:46:07PM

you missed steves point about "more finders"

1) steve wasnt suggesting that any of the following are the case:

* that the finder will forever remain a carbon app, and therefore poorly threaded.

note: a carbon app lives within a SINGLE posix/mach thread, so even if the can _internally_ balance contention amongst its own multiple threads of execution, at the end of the day all those fractious carbon-threads have to be squeezed through a _single_ external darwin-thread.

* that until there is a native cocoa version of finder available, you will soon be able to launch multiple file-browsers so that when one of them gets bottlenecked (either internally with carbon-threads or externally via the one darwin thread assigned to the carbon app) you can just pop open another - and perforce spawn a completely new, separate darwin-thread in which to run this carbon finder.

* that even when everything is fine (ie Cocoa) the "FINDER" per se will be the exclusive 'portal' through which you access your computer ... indeed, precisely the opposite:

2) there will be "lots of finders" only because each application will be its own, FULL_FLEDGED file-manager!

* In the grand tradition of opendoc (yeah!), every "content model" (ie a self-contained datatype) will carry with itself its own "view" behavior (ie it will invoke its own runtime to execute itself, sometimes read-only access, sometimes with permission to edit the 'Part' ...

each "application service" (to use a somewhat more osx-ish term) will 'handle' itself according to its own unique abilities (and hopefully the needs of the user :)

thus each set of objects (common or mixed) will 'know' how to behave given the context: and will accordingly provide ITS OWN FILE MANAGER (which, when the Finder is Cocoa-ized, will obviously call some Finder classes (for presentation and control) as well as lower-level File I/O accessor classes (to handle the underlying structured storage requirements) - example:

* A a mediaPlayer (not just its dialogbox) will be able to do certain sorts of things that a database client would not _want_ to do with its stuff ...

With a system-wide iMovie in mind (but also in the grand tradition of copland) your desktop might act as light-table when some film-slides are tiled onto your workspace; but they might take up too much room for you to have a bird's eye view, so you would start using the 3D elastic bounding-tool to "stack" a bunch of the ones which belong to a group called '2nd choice' out of the way -- but still close enough to be quickly accessible with just a mouse-click ... and the less important stacks would themselves in turn be put into magazine-cartridge for a virtual carousel projector.

Now you need to match pictures to music, so you pull out some sheet-music from a stack sitting in another part of your desktop ... you can quickly hear each score with a mouse-over any sheet in the stack.

Now you drag & drop slides onto the sheet music (remember you have Quartz's transparency working for you!), move them around and watch them light-up when that part of the score "passes" underneath that slide; when you have some provisional choices, you stick a thumbtack on the selected slides so they dont get pushed around by your mouse, ... and each set of these slides can be stored as an embeded thumnails right on that exact part of the score itself!

You now 'start' the sheet music and now, in order to get your 'timing' (or placement) right, you select the slide you want to experiment with and poof! it becomes your cursor: the music underneath the slide is played as you move the slide anywhere on the sheetmusic. Conversely, you could make the film-slide the fixed frame-of-reference, and move the sheet-music over the slide by enlarging the extents of the slide on your light-table (assume the desktop is your workspace: and you can select MULTIPLE desktops .... *NOT* multiple Finders for the _same_ desktop) ... when you do find a match that interests you (which might be constrained by the placement requirements of other slides with other parts of the score), then that slice of the score would become another layer of the slide, with multiple selections from the score having multiple tabs on the slide - this way you can instantly have a play-list for each slide, which would make exploring different arrangements of the slides much more tractable during the intermediate stages before final assembly.

the whole idea of "switching" between applications sucks.

every process a "prisoner" of its own window-frame: what an impoverished idiom for expressing the relationships amongst what are an intrinsically self-contained, heterogeneous elements.

Give the workspace a MESSEGE-BUS (and a host of other facilities like transactions, and other yummy CORBA-esque stuff) and then there is no need for a windowframe that's been sup'ed-up with a timeline (which is really little more than an array populated by a bunch of pointers generated by a low-level systemtime). (remember that in taligent, there was a high-level time service framework that drove any and every object! whether media container or spreadsheet ... with some sub-classing, you could "turn on" the 'metronome' of an object to watch its 'beat' as another "column" in a file-browser (you could also contemplate subclassing time to wire-up a bunch of objects with a slider-control which would 'transfer' the time-state of one object to another, and this wasnt integer unixtime but real floating-point time, with enough precsision to resolve both the begining of the universe and its end, from the smallest quark to the largest chasms of the universe! but i digress :)

the only reason we use such an antique concept like "windows" is to provide an abstraction of a system process which is MARGINALLY intelligible to human users; the window-frame is a compromise created to hold together both of these two imperatives -- the human and the machine representation of an object ... which perforce MUST be in conflict in a world of procedurally designed applications which - with NO native mechanism (IPC) to communicate with each other - remain isolated from each other.

so of course we should expect that the windowframe to be the representation which is most LEXICALLY orthogonal to the representation of the data (but not _semantically_ orthogonal in the least!).

in such a world we should also expect to have to be constantly running to and from the filebrowser because it is the only windowframe that isnt "overloaded" (in the programming sense) with the freight of the application window, a place where we are forced keep our own private mental picture of how the bits and pieces of our worktask are to be mapped to whole of our worktask; then naturally we'd want to be able to lauch as many of these file-browssers as we needed if it was the the closet we could ever hope to come for quickly, uniformly and directly accessing our workflow.

however the need to do this is a symptom of the underlying disease! the lack of true objects (just processes that are handled in a nominally object-based _style_) ... objects that can go anywhere, do anything, with anyone at anytime in anyplace.

Rich semantics are possible only when we dont herd together the elements in our work materials as though they were sheep; we need to let our content (aka files) roam!

If our workspace were to be designed around THAT idiom in mind ... ie an ensemble of objects (taligent-speak) that can be mixed and matched at will (opendoc-speak) in natural context-appropriate environment (copland-speak) ... the we wouldnt NEED multiple conventional file-browsers: we simply wouldnt know that to do with them because they would be inert, lifeless and not directly useable.


ps: XML is just a _means_ to this end because it allows a 'part' its own native, domain-specific behavior directly attached to itself; the markup allows the object to express itself idiomatically (instead of being forcibly decomposed into lower-order primitives (like tables) and crude actions (like select, join, etc) when an object is 'represented' by an rdms); the XML parser does the the work of "exposing" the interface for an object from this markup; the file-browser is no longer the only way the user can invoke accessor methods on an object - because the object's higher-order attributes (meta-data) are capable of 'running the show' all on their own - eg: markup for chemical-notation (like musical markup) means that the real behavior of those objects is "just waiting" to be instantiated ... plugin a database (driver), a messegebus, a device-driver (virtual or otherwise) and wham! what was a loser -- who can be dressed up but with nowhere to go -- becomes transmorgified into a light-weight applet ready to kick butt!

XML makes an object "pret-a-vivre".

[ Reply to This | # ]