Apple has updated their page on Lion with descriptions and screenshots of (all? At least all those mentioned in the linked article) its new features: http://www.apple.com/macosx/lion/
How many of the coolest-sounding features like Auto-Save, Versions and Resume will require special support per application? Resume is the only one that seems doable without that; they can piggyback on the existing OS support for suspend-to-disk hibernation.
This is one of those things where having the platform vendor provide an app store (especially one that is presumed to become the dominant method of app distribution and that they've shown they're willing to "curate aggressively" when they feel like it) can allow the vendor to push forward faster - they can easily lay down the law that all apps on the Store have to support these features as appropriate by, say, 3 mos after Lion ships.
It prioritizes the platform vendor's feature desires over those of the developer or the users' direct vote, but I think it's wonderful for the industry to have at least one vendor (and one who arguably has good taste!) doing so.
I also think it's wonderful. If Apple leaves progress up to developers, you have people like Aldus inventing new things like Desktop Publishing. Then again, if Apple leaves progress up to developers who are waiting for user demand, you'd never get a Macintosh in the first place.
Nobody wanted a mouse until they were shown what you could do with a mouse and Aldus Pagemaker. Nobody wanted "undo" consistently implemented across all applications. And absolutely nobody wanted their applications to run in fully little "windows" on the screen.
From this cherry-picked example, I conclude that a good platform does allow the vendor to push certain features forward, but it also gives developers a certain amount of leeway to innovate.
That's where I think Apple doesn't have as much of a problem as many devs want them to have: they give a lot of leeway already to devs to create tons of apps that people want. C.f. the various App Stores. And when (eventually? I don't know of it happening yet) some "killer app" appears on another platform that isn't possible on Apple's platforms, they can just narrowly relax the rules to allow it.
This is why I'm happy to see both models exist and thrive. Android would look like an old Blackberry if not for Apple. And likewise Apple can pick up any advantage that Android has (other than a few, such as meeting the needs of markets outside Apple's target).
That's a great point. I'm really excited about the future of the Mac with developments like these. Hopefully the API hooks are simple enough that it's a no-brainer choice for developers to make.
From what I can figure out, Auto-Save and Versions are pretty-much built-in. Assuming an application that uses standard Cocoa approaches to document management, it just needs to declare its support for the auto-save functionality, and pretty much everything else will be handled by the system libraries. Fairly trivial.
Resume is more involved, however: the application is responsible for (de)serializing its state. Again, for a document-based application that doesn't stray far from the "recommended" path, it should be fairly simple to implement. It's just a matter of the document and UI being auto-saved on termination, which requires little work from the developer. One very interesting side-effect of the Resume feature is that it removes the need for applications to stay running: the system can silently terminate unused applications, and bring them back if they're needed again. What's really exciting about this, is that it's turning applications into something that is "always there".
Full-screen apps, auto save, versions, and resume all have an asterisk in their descriptions: available with apps that have been developed to work with Lion.
Resume looks good, and if properly coupled with Bootcamp it can be great. (think: run a Windows app from OSX, have it reboot straight into the app, and back to OSX as-it-was when you leave Windows :)
ive been fairly confused about how versions will work, im guessing applications will need to be versions aware for it to be useful, you can do it in the filesystem but without seeing the document in the application that seems kinda useless
In that video it looks like safari now auto hides the scrollbar when it's not being used (kinda like on the iphone), seems like an odd thing to do, since 20px of screen space isn't as precious on a desktop as it is on a phone.
I don't think saving the screen space is really the point.
It's more likely about reducing the amount of clutter on the screen. If you don't need something, why put it on the screen? Apple's minimalist design strikes again.
The question is how to display things like that on a desktop OS that might be used with a mouse. With a touch gesture, you touch and then move vertically as a continous action. On a mouse, you click or turn a wheel, much more discrete actions.
Edit: Aha, they addressed this: "With the new scrollbars, if all of the user’s pointing devices support both horizontal and vertical touch scrolling, the scrollbars are hidden during normal use. They will appear as an overlay on top of the window's content while the user is scrolling, and remain visible briefly to allow scrollbar dragging."
"Mac OS X Lion introduces overlay scrollbars similar to those in iOS. These scrollbars appear as an overlay on top of the window's content while the user is scrolling and remain visible briefly to allow scrollbar dragging."
Do you read that to mean that all standard Aqua scrollbars will be rendered as overlay scrollbars in Lion? My initial impression was just that the overlay version will be made available to developers. That said, some OSX apps already use them, so I'm not sure why it has been highlighted as a new feature of Lion... any thoughts?
