July 14, 2006
And then I realized that, in the future, each instance of an application will have only one document. Which is to say, if the user opens 10 TextEdit documents, she'll actually have 10 instances of TextEdit running.
The advantage to this is that, if you do something that is slow or modal in one TextEdit document, you don't have to, like, go check your mail or do something else -- you can edit another TextEdit document while you wait. When you think about it from a user's point of view, why is it that when TextEdit is hung (doing something really intensive on one document, or even just hanging for the fun of it), you can access Mail or Safari documents, but not other TextEdit documents? Is there some research that shows you are more likely to want to go send a Mail message than edit another text document? This is an app-centric feature in what should be a document-centric world.
But imagine if, say, some crazy web page made Safari crash, but it was that only one window, and all your other Safari windows were still open. Imagine if you hung Preview by saving something as a JPEG2000 while playing a movie (true story) and you could just kill off that document and all your other images you were working with were still around?
So, how would this work? Well, at a lowest level (the OS), it's pretty simple. Mach already will automatically share pages mapped in from the application's resources and object code, between running instances of the app. (In fact, I believe this sharing of resources happens right now if two users use Fast User Switching and run the same app.) The OS would have to actually launch the application multiple times to create multiple documents, which would mean there'd be an extra memory overhead of a whole application's stack being created (and the objective-c environment being fired up, classes being initialized, etc), and there'd be a speed hit from this as well. However, speed and memory are two things that are getting cheaper, whereas programmer time is not. And startup times are getting faster and faster even without hardware improvements, thanks to cool OS and Cocoa tricks. I certainly don't think those are exhausted (freeze-dried apps, anyone?).
Then, at the Mac workspace (Finder) level, Apple would have to do some work with things like AppleScript and LaunchServices so they are aware that there is no longer just one, say, "TextEdit" to which it can send messages. Some things would work just fine with little reworking -- if you have an AppleScript that says, "Open this document in TextEdit and do blah blah" you already don't know and don't care how many documents TextEdit has open right now, so this change wouldn't matter. But if you look at an AppleScript that says, "Go through TextEdit's open documents and tell the first one..." then that would obviously require some OS glue to work correctly.
On the dock, Apple would only show one icon for any given app, no matter how many instances of it were running. Apple could pretty easily rework the workspace so all documents that were running in the same base application were shown/hidden together, even though they were in different address spaces. The Windows menu wouldn't be hard to modify so that it just brought another app to front, as well, if you selected a different document.
The user wouldn't (necessarily) want inspector windows to move around when she switched documents inside a single application, but that would be easy to handle -- it wouldn't be hard to do some simple messaging between instances of the application telling them all where their "Blah Inspector" should be located and whether it should be hidden, for example. This kind of coordination of the "shared look" of the app would be easily built into AppKit -- you'd simply decide ahead of time what should stay the same between documents (maybe you have a special icon dock that sits at the top and should be there for every document, for instance) and AppKit would make sure that all running instances are in the same state, much as it does right now with toolbars (albeit in a single process, but the extension is not hard). Consider, for instance, the color panel, where swatches are always the same across all running programs, or the font panel, which displays the same fonts and groups no matter the app. This is a solved problem.
The user experience for all this could be just like the current one under OS X, except crashes and hangs and modal operations in a document would be handled MUCH more gracefully, and the task of writing document-based Cocoa programs would get simpler. Imagine, for instance, if you're populating a popup button somewhere with, say, the names of all the objects in a Graffle document. The neat thing would be, you wouldn't need a backpointer! There's only one document, so you can just treat it as a global: "Hey, global document, give me all your object names." You're done. (Sure, you can ask the NSApp for its currently active document right now, but there are instances when you're doing work for a document but you can't be sure that it's the active document -- it could be one of the background ones. This would eliminate that uncertainty.)
Conceptually, this whole model seems a lot cleaner to me, basically because different documents inside an app almost never talk to each other. There's really no reason have them in the same address space, except for the fact that launching apps was expensive (up to now) and took up memory.
But as we switch to these new Intel machines, we're finding app launches are, like, a fraction of a second. And, history has shown us, whenever we have an excess of speed or memory, we use it to make programming simpler for ourselves, which allows us to make cooler programs for users.
Heck, in the old days, we only had one address space, and if you crashed a program your whole machine was S.O.L. Now we can't even imagine such a barbaric time. I think one day we'll look back to the days when a single application had multiple documents and say, "Why? That's such a pain to deal with! What if one document corrupts memory! They'll all get messed up! That's crazy!"
I write the software for
- Note to Bill Gates: I'll take your bet, for $10,00...
- Pimp My Code, Part 11: This Sheet is Tight
- E*Theft @ E*Trade...
- Thomas Dolby Rocks.
- Pimp My Code, Part 10: Whining about Cocoa
- Climate Crisis...
- Pimp My Code, Part 9: Beginner code.
- This Post is Microsoft Enhanced (TM).
- Pimp My Code, Part 8: Mary, Mary, why you buggin?
- TED, Final Days.
Pimp My Code
- Free Programming Tips are Worth Every Penny.
- I will insult your code!
- Part 1: Code Insults, Mark I
- Part 2: self = [stupid init];
- Part 3: Gradient TableViews
- Part 4: Returning late to return early
- JPEG2000: Cool but SLOW.
- Unit testing is teh suck, Urr.
- Part 5: Special Apple Sample Code Edition...
- Interlude: Free Code
- Pimp, Pimp Thyself.
- Frameworks are Teh Suck, Err.
- Part 6: The Pimp Before Christmas
- Thinking, boxes, & what kittens can do to them.
- Part 7: Pimplette?
- Part 8: Mary, Mary, why you buggin?
- Part 9: Beginner Code
- Part 10: Whining about Cocoa
- Part 11: This Sheet is Tight
- Part 12: Frozen in Carbonite
- Part 13: The Pimp Before Christmas, Redux
- Part 14: Be Inflexible!
- Part 15: The Greatest Bug of All
- Part 16: On Heuristics and Human Factors
- Part 17: Lost in Translations