On May 12, 2011, at 1:42 PM, 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. > > 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.
That shouldn't be true...and I'm not sure I believe it. Do you have a backtrace showing this case? FWIW, the implementation for both is in NSTableView. So, I don't think NSOutlineView would do something different. Selection changing is highly dependent on how you have the table/outline setup. Allows multi-selection? Vertical selection begins drag? These affect things. The HI designed way this should work: Selection doesn't change on mouse down, because you may want to select and drag that row without changing the selection. Instead, selection happens in mouse up. Also, it allows one to multi-select (drag select) without sending a bunch of selection changed notifications until the user has lifted the mouse. corbin > > On May 12, 2011, at 2:06 PM, Quincey Morris wrote: > >> On May 12, 2011, at 10:05, Brad Stone wrote: >> >>> For my NSTableView (NSIndexSet *)tableView:(NSTableView *)tableView >>> selectionIndexesForProposedSelection:(NSIndexSet *)proposedSelectionIndexes >>> fires on mouseDown and (void)tableViewSelectionDidChange:(NSNotification >>> *)aNotification fires on mouseUp. >>> >>> For my NSOutlineView (NSIndexSet *)outlineView:(NSOutlineView *)outlineView >>> selectionIndexesForProposedSelection:(NSIndexSet *)proposedSelectionIndexes >>> and (void)outlineViewSelectionDidChange:(NSNotification *)notification fire >>> only on mouseUp. >> >> This can't be true. >> >> For a start, thinking of the delegate methods as "firing" on mouse events >> seems like a way to lead yourself astray. There are *various* ways to change >> a selection, only some of which start at a mouse down event, and the >> delegate methods are invoked at *various* points in the procedure depending >> on circumstances, no matter how it starts. (Well, ...DidChange presumably >> gets invoked only at the end, but what constitutes the end may vary.) >> >> Specifically, if NSOutlineView's 'selectionIndexesForProposedSelection:...' >> method wasn't ever called until a mouse up event (after an initial mouse >> down, I mean), it wouldn't be possible to prevent rows from getting selected >> while the mouse is being dragged, and it *is* possible to do so. >> >> There may be specific scenarios where the view decides not to invoke the >> delegate until mouse up, but that fact just demonstrates the pointlessness >> of trying to parse the mouse event behavior. >> >> > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com > > This email sent to corb...@apple.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
