Re: NSUndoManager retain/release of arguments - ad infinitum
Re: NSUndoManager retain/release of arguments - ad infinitum
- Subject: Re: NSUndoManager retain/release of arguments - ad infinitum
- From: Graham Cox <email@hidden>
- Date: Tue, 11 Jan 2011 22:47:51 +1100
On 11/01/2011, at 10:27 PM, steven Hooley wrote:
> I don't mean to hijack this thread, but my first thought, for what
> it's worth is that either :-
>
> a) sort order is a property of the window, not your model and
> shouldn't be undoable at all.
I agree. In fact I don't typically make sorting undoable, though reordering can be, depending on the object being reordered. When that is done, you should unhighlight the sorting column, though I seem to recall that there's a bug in NSTableView that means you can't force it to unhighlight very easily, even if you discard the table's sort descriptors. (I might be misremembering the details of this bug, so don't take that as gospel). Undoing such a reordering *should* put back the column highlighting for the previous sort order, but in fact it's hard to make this work so I've actually never bothered to go to those lengths and so the UI is sometimes in a state inconsistent with the data. No-one has noticed and/or complained.
> What happens if you want another view - say a grid view, with nice big
> icons - of the same data?. Should that be sorted in the same way as
> your tableView? Should clicking the tableView header rearrange views
> in other windows?
Probably would depend on the app. I have a situation where the user can switch between two views of the same data in a single window - list view and icon view. I let the list (table) view also set the sort order for the icon view, but there's also a toolbar menu that the user can use to choose sorting in either mode. In the list mode, the table UI follows the toolbar menu. Sorting isn't undoable.
Generally treating sorting as a view feature is ideal, and so forgetting about undo is OK. However I do find it useful to be able to ask my model for sorted data, given some sort descriptors. The model caches the result to prevent sorting for every request - to do that it has to save the descriptors so it can tell when they change. Without caching, sorting on the fly can be quite a performance drag depending on where the data comes from.
> Ok, so you never want to add another view, you're happy with the
> single table view. I expect an undoable-action to be a
> saveable-action. ie, normally, if i can undo it i expect it to make
> the document dirty and need saving. This might be different in your
> app but i don't normally expect to have to Save a document because i
> switched between sorting alphabetically-ascending and
> alphabetically-descending order.
Agree, undoing sorting is unnecessary. But if you were to, storing the sort descriptors should be sufficient provided all other data reordering is also undoable.
> the sort order is inherently part of your model, your data is an
> ordered-set and the user can arbitrarily order the items as she
> pleases. In this case you probably won't be presenting your data with
> a sort descriptor, clicking on the column header will actually
> rearrange your model data.
Sort descriptors are still a very useful way to handle it, you'd just make the 'current sort descriptors' also part of the same model.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden