Kuwi either Dan Frakes or TidBITS have talked about that, but I'm too damn tired to remember.
The drag from display-to-display, rearranging Spaces, or Mission Control in general? Not that I need to know urgently or anything, so rest up and post if you remember.
I checked both and couldn't quickly find anything.
Though one of the TibBITS posts reminded me of one thing I was worried about: Autosave and Versions behavior with network and non-HFS+ volumes. Now the text editors I use now don't support either anyway, so I've yet to worry about this, but since I expect (well,
hope) they do so in the future, and with iCloud coming, I have to wonder how this will work. As it is, Versions doesn't work with non-HFS+ volumes. The most recent changes are autosaved, but all previous versions are erased on the non-HFS+ volume. But what about when these changes are synced back to the original HFS+ volume? This may become particularly problematic for me since many of my documents are Dropbox-synced to a departmental Linux server.
If I make changes over SSH via vim or emacs, are all my Versions lost? Apparently they aren't! I just tried this with a plain text document in TextEdit, and Dropbox syncs the most recent version back to my Mac and the old Versions are still intact and browsable. I can *not* browse old Versions on the network drive — which isn't HFS+ — after closing it, but it appears the sync still preserves the Versions on my Mac. Versions manages seems to recognize it's an update to an old document, even if made in a completely non-Versions-enabled app like vim, and updates accordingly. When opening the newly synced, network-saved document, I naturally see the most recent version, with changes saved in vim over SSH, and when I go into browse all Versions, I still see the old Versions that I'd saved in TextEdit locally. Perfect! I may not be able to browse all Versions while on the non-HFS+ network drive, but I was never able to do that before anyway.
It could result in bad, unexpected behavior if your *only* copy is on a non-HFS+ drive and you quit without saving with an autosave-enabled app, but if you have a copy on an HFS+ drive, you'll still have browsable Versions on the HFS+ drive. The other downside is that whereas every time you save in an Autosave/Versions enabled app, you get a new Version, no matter how many saves you make in a non-Autosave/Versions-enabled app (e.g., vim) all of the in-between saves are lost, and Versions on the Mac will not create Versions out of them — it will only grab the most recent save. So while you get to keep your Versions despite changes made in non-Autosave/Versions-enabled editors, Versions won't track the updates. Which makes sense in some ways, certainly, but I feel like if Versions is smart enough to grab the latest change and preserve your versions, it should be able to create a new Version whenever it gets an updated binary. I wonder what kind of under-the-hood magic it's doing that allows the former, but not the latter? I wonder Apple could enable the latter down-the-road sometime, or not? I feel like if it they could have, they'd have done it that way from the beginning, but that still leaves me wondering how my Versions are preserved despite syncing back from the network, non-HFS+ volume. I fully expected that not to work given what I understood of Apple's implementation. Nonetheless, it's a nice surprise.
Okay, Bare Bones, get your asses onto a Cocoa code base and implement Versions NOW!
ETA: Just checked — Dropbox isn't doing anything special, it works with a plain-ol' copy-and-replace, too.
ETA2: And what else I'm still really curious about is how this will work for iCloud-synced documents that are
also Dropbox-synced to non-HFS+ volumes. Anyone with a 10.7.2 beta who has tried this and care to comment?
