Re: NSSplitView divider tracking-area
Re: NSSplitView divider tracking-area
- Subject: Re: NSSplitView divider tracking-area
- From: Quincey Morris <email@hidden>
- Date: Thu, 30 Oct 2014 19:19:31 +0000
On Oct 30, 2014, at 11:19 , edward taffel <email@hidden> wrote:
>
> i agree! do you feel it should always track? [anyone else?]
There’s an argument that says it should change the cursor if and only if mouse down while the cursor is changed would “grab” the splitter. (So that would be a “yes” in your scenario, wouldn’t it? Does it grab the splitter anyway?)
But there’s *also* a potential argument that says it should *not* change if the window containing the splitter is inactive, even if mouse down would grab the splitter, to avoid capturing the user’s attention when the mouse pointer happens to move over the splitter on its way to something else. (So that might be a “no” in your scenario, except…)
If you see any value in that argument, then there’s also a potential question of what constitutes an inactive window (for this purpose). Does it need to be main to be active? Key? Any window in the active app? (So that might be a “yes” or a “no” in your scenario.)
Finally, FWIW, I’ve encountered many situations in regular windows in many apps — when key-ness is not a factor AFAICT — where the cursor just doesn’t change when hovering over the splitter. Grabbing the splitter “fixes” the problem, in the sense that the cursor usually changes properly after releasing it, until the next time it happens. So there might be some non-intentional flakiness in the cursor tracking that just happens to be repeatable in the case you’ve described.
Because of all that, I’d say it’s well worth a bug report to ask for clarification.
_______________________________________________
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