Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
On May 13, 2011, at 10:56 AM, Quincey Morris wrote: > On May 13, 2011, at 10:36, Corbin Dunn wrote: > >> On May 12, 2011, at 1:42 PM, Brad Stone wrote: >> >>> 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? > > I was able to confirm the difference in behavior that Brad observed, but I > didn't try to find the cause. > > In the example I looked at, there were two implementation differences between > the table and outline view: > > -- The outline view data source implements > 'outlineView:writeItems:toPasteboard:' (etc), while the table view data > source does not implement 'tableView:writeRowsWithIndexes:toPasteboard:' > (etc). > > -- The outline view delegate implements > 'outlineView:selectionIndexesForProposedSelection:', while the table view > (which dates back to older code) uses 'tableView:shouldSelectRow:'. > > I'm guessing one of these causes the difference in behavior, most likely the > first. > That is correct -- if you implement drag, then things are delayed slightly to allow the drag to start. But, the ordering is identical for tableview and outlineview, if implement the same delegate/datasource methods. corbin ___ 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
Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
On May 13, 2011, at 10:36, Corbin Dunn wrote: > On May 12, 2011, at 1:42 PM, Brad Stone wrote: > >> 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? I was able to confirm the difference in behavior that Brad observed, but I didn't try to find the cause. In the example I looked at, there were two implementation differences between the table and outline view: -- The outline view data source implements 'outlineView:writeItems:toPasteboard:' (etc), while the table view data source does not implement 'tableView:writeRowsWithIndexes:toPasteboard:' (etc). -- The outline view delegate implements 'outlineView:selectionIndexesForProposedSelection:', while the table view (which dates back to older code) uses 'tableView:shouldSelectRow:'. I'm guessing one of these causes the difference in behavior, most likely the first. ___ 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
Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
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
Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
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 (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
Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
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. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: selectionIndexesForProposedSelection on mouse Up or mouse Down
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
selectionIndexesForProposedSelection on mouse Up or mouse Down
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. Is this normal behavior? I would prefer the NSOutlineView fire on mouseDown like the NSTableView. Is there a way to change that? (In Mail.app, if you organize by thread selection happens on mouseUp but in iTunes, the podcast outlineView selects on mouseDown).___ 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
