Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
- Subject: Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
- From: Quincey Morris <email@hidden>
- Date: Thu, 12 May 2011 14:26:33 -0700
On May 12, 2011, at 13:42, Brad Stone wrote:
> I'm thinking about the perception of the user. When I'm in Mail.app, for example, clicking in the outlineView (organized by thread) and I click on a row it feels less responsive because there's a pause before the row highlights (a pause until I release the mouse button). When I'm in iTunes and the row highlights as soon as the mouse button is down is just feels more responsive.
You're on shaky ground here. You claim to be thinking about the perception of "the user" but you subsequently make it clear you're thinking about the perception of only one user -- you. :)
Even if you're right, it's not clear that you're doing your users any favors by making your outline views behave different from every other outline view in every other application.
It's certainly possible that you have a usage case where the default NSOutlineView behavior is inappropriate, but if you want to actually do something about it, you're probably going to have to start writing custom UI code.
> I put in NSLog calls to show me when "proposed" and "didChange" get called. NSTableView's delegate gets called on mouseDown while NSOutlineView on mouseUp.
NSTableView could well be the one that's wrong, not NSOutlineView. Dragging something unselected in an outline view doesn't select it, nor (I believe) is it supposed to, and every outline view I could find had that deferred behavior, even if it didn't permit dragging.
Whether NSTableView is wrong, is working according to an older set of usability principles, defaults to an inconsistent compatibility mode, or is simply making a different set of decisions -- that I don't know and don't believe there's any API contract about. That's why I was suggesting it's pointless to take any action based on the actual implementation.
If you want to pursue this, I'd suggest there are probably 3 steps:
1. Examine the Human Interface Guidelines in detail to find out if the intended behavior is spelled out there, and what leeway it gives.
2. Examine the NSTableView and NSOutlineView class references in detail to find out if there are any obscure properties, overridable methods or delegate methods that can modify the behavior.
3. File a bug report complaining about the difference in behavior between the two classes. The response might clarify what's going on, or what's supposed to be going on. (I wouldn't try complaining directly about the behavior you don't like, because you'll just get a response saying it's behaving "as intended".)
_______________________________________________
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