Use grabbed hand cursor during tab dragging



Camino Graveyard
Tabbed Browsing
10 years ago
6 years ago


(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Unassigned)



Mac OS X



(1 attachment)

I noticed that Terminal changes the cursor to the grabbed hand once you start dragging (actually, once you click-and-hold, which is a little odd, but maybe not, since you can't do anything else), and it would be a nice bit of polish if we swapped cursors as a visual cue once we were dragging the tab.

Safari, incidentally, does not do this, so it's unclear why Terminal has the better UI :P

Comment 1

10 years ago
I'd be in favour of this, too, despite Safari's current lack of it. I'm not sure whether I'd prefer the swap happen when the actual drag starts or on click-and-hold; I'd like to try out both and see which one "feels" right.
Hardware: Macintosh → All

Comment 2

10 years ago
I do agree that this would be a nice drag indicator, further showing that tabs are in fact draggable, and especially distinguishing fav-icon drags from ones originating everywhere else on the tab.

The only negative aspect I see is that mostly all drags on the system do not display the hand-grab cursor.  Other reordering drags on the system, command dragging NSToolbarItems, and moving applications on the Dock for instance, do not use it.

Comment 3

9 years ago
That's three votes in favour. Is there any reason (other than other apps' lack of consistency) not to confirm this?
(In reply to comment #2)
> The only negative aspect I see is that mostly all drags on the system do not
> display the hand-grab cursor.  Other reordering drags on the system, command
> dragging NSToolbarItems, and moving applications on the Dock for instance, do
> not use it.

I tend to think those are different kinds of UI (particularly, much less commonly dragged), but I do see the point.

Comment 5

9 years ago
[3:43pm] <cl> why haven't we confirmed bug 468262 yet? 
[3:44pm] <ardissone> because of whatever murph said in the bug
[3:45pm] <cl> i agree with you in comment 4, though -- different kinds of UI and much less commonly dragged
[3:45pm] <cl> Terminal feels awesome
[3:46pm] <ardissone> the first part of murph's comment is another good reason to, too
[3:46pm] <ardissone> so i guess m-i-s
[3:46pm] <ardissone> assuming Terminal hasn't lost that in 10.6 :-p
Severity: enhancement → blocker
Ever confirmed: true
Severity: blocker → enhancement

Comment 6

9 years ago
Terminal on 10.6 shows the hand cursor when you start the drag, unlike 10.5 where it shows on click-hold.
Assignee: nobody →
Created attachment 490174 [details] [diff] [review]

I do not believe this patch is a complete implementation, but I would appreciate any insights into the cursor rects problems I am seeing.

On mouse drag, the |mouseDragged| event handler calls the |dragImage| run loop, which processes events until mouse up. I expected that changing the mouse cursor and calling |disableCursorRects| before |dragImage| (and then |enableCursorRects| afterwards) would be adequate.

However, the |NSCoreDragTrackingProc| reenables cursor rects between calls to BrowserTabBarView's |draggedImage:beganAt| and |draggedImage:movedTo|. And cursor rects are also reenabled when the cursor exits or reenters the tab. My improper solution is to reset the closedHandCursor and |disableCursorRects| on every |draggedImage:movedTo|. That mostly works, but it "smells" incorrect and there is some cursor flickering.

Why would cursor rects be reenabled, even though I called |disableCursorRects|? I suspected some tracking rect might be fighting with my |disableCursorRects|, but I couldn't find any proof. I was also surprised to even see calls to BrowserWindow's |resetCursorRects| even though |areCursorRectsEnabled| is NO.

Here is a stack trace showing the |dragImage| run loop reenabling cursor rects against my wishes:

#5	0x00072d5e in -[BrowserWindow enableCursorRects] at
#6	0x992165f9 in NSCoreDragTrackingProc
#7	0x90e22840 in DoTrackingMessage
#8	0x90e22c0e in SendTrackingMessage
#9	0x90e245c9 in DragInApplication
#10	0x90e2510c in CoreDragStartDragging
#11	0x9921562b in -[NSCoreDragManager _dragUntilMouseUp:accepted:]
#12	0x99214fe8 in -[NSCoreDragManager dragImage:fromWindow:at:offset:event:pasteboard:source:slideBack:]
#13	0x9951fc23 in -[NSWindow(NSDrag) dragImage:at:offset:event:pasteboard:source:slideBack:]
#14	0x000c98d6 in -[BrowserTabBarView mouseDragged:] at
#15	0x98ed1da9 in forwardMethod
#16	0x0010e8fb in -[TabButtonView mouseDragged:] at
#17	0x98fbbf6c in -[NSWindow sendEvent:]
#18	0x98ed4aff in -[NSApplication sendEvent:]
#19	0x98e685bb in -[NSApplication run]
#20	0x98e605ed in NSApplicationMain
#21	0x00003d47 in main at main.m:86
Attachment #490174 - Flags: review?(stuart.morgan+bugzilla)

Comment 8

8 years ago
I don't have a whole lot of experience with NSCursor, but I did a bunch of reading, and dredged my memory about battles with cursor rects. The latter didn't turn much up, but based on the former it certainly does seem like what you started out doing should work. Two possibilities that occur to me after researching:
a) Perhaps there are secret, unwritten rules about the interaction between drag operations and messing with cursor rects. Does it make any difference if you move the disableCursorRects call somewhere else, like mouseDown: or mouseDragged: in TBV?
b) Cursor rect code may be rotting a bit, since it's no longer Apple's favored cursor solution. I'd expect there to have been more yelling on the internets if it were a general breakage, so I'm not convinced of this--on the other hand, cursor rects are horrible compared to NSTrackingArea, so maybe everyone has already bailed on cursor rects ;)

Other than a), my only suggestion would be to play with something that would temporarily turn off all the tracking rect code specifically for tabs and see if that helps (for testing, just make some public getter/setter on the tab bar, maybe, and have everything check it before doing cursor operations; a hack is all we need to see if it helps, and if it does we can think about better options).

Comment 9

8 years ago
Comment on attachment 490174 [details] [diff] [review]

(r- this iteration since I agree that this is nasty, and there must be some better approach)
Attachment #490174 - Flags: review?(stuart.morgan+bugzilla) → review-
Perhaps we should just sit on this bug until post-2.1. If Mac OS X 10.4 support is dropped, then we could just use NSTrackingArea (which is only available in 10.5+). :)
Assignee: cpeterson → nobody
You need to log in before you can comment on or make changes to this bug.