Living with Twitter 4

The tweet detail view displays full conversation history, including any replies to the message. I’ve been wanting this for a long time; it’s great! I expect other clients have done this sort of thing before, but I never got round to looking at them. Either way, hopefully there’s an API so third parties don’t have to grope around piecing together the equivalent. Also, the conversation is presented in the correct chronological order — brilliant!

Switching accounts is way more fiddly. I appreciate most people have only the one account, but as someone with a company account on the side, it’s annoyingly awkward.

The Tweetie tab bar used to confuse me regularly as to where exactly I was in the app; going back to the standard one is preferable.

Direct messages are tucked away under the Me tab. I regularly fail to notice the blue glow indicating a new one. Fortunately, for all of its bugginess, a large chunk of what I used DMs for before has shifted over to iMessage. The Discover tab periodically marks itself as “unread”. I don’t give a fig for its contents, so force myself to ignore the blue glow, compounding the problem of not noticing DMs.

Search seems to work better. Placing it under the Discover tab feels a little odd to me, in spite it actually being a pretty logical choice! I miss the ability to search your timeline, even though I used it rarely. The improved — to my perception at least — general search is making up for it so far.

The use of a “grouped” style for the main table views, rather than “plain” seems an odd waste of space. There’s less content on-screen now, which for a service people scan through quickly is irritating.

Improving NSDocument's sheet handling

NSDocument has handy little method: -windowForSheet. Its main purpose is to figure out, when the doc has multiple windows associated with it, which is most appropriate for displaying a sheet.

I’ve found it does have one downside: what if your document is already displaying a sheet? Under such circumstances, the document’s window is still returned, leaving the system no option but to futilely beep as it fails to present a second a sheet.

This is of particular importance with Lion’s new document saving model. If a document is locked and you try to edit it, a sheet comes down informing you that the document is locked, and giving a chance to recover by unlocking, duplicating, or cancelling (performs an undo op). All very well until it happens the edit being made is in a sheet over your document window. Cocoa tries to present that error sheet and fails, leaving the edit intact. This could be just about excusable were it not for the fact that then attempting to undo the edit confuses the system further, bringing that very same warning sheet up, despite the fact you are trying to go back to the unedited state!

Well fear not, here’s a simple tweak you can implement in your document subclass to adjust the default behaviour:

There is of course one potential problem: If you have code that repeatedly tries to show a sheet, regardless of what’s onscreen already, you can end up with quite a stack of sheets, whereas before it was less obtrusive with the secondary sheets just causing a beep. Hopefully your code doesn’t do anything quite so daft as this, but I have found that a failed autosave can trigger this behaviour, should you ignore the initial error and keep switching between apps.

© Mike Abdullah 2007-2012