> On Oct 30, 2014, at 3:19 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 30, 2014, at 11:19 , edward taffel <etaf...@me.com 
> <mailto:etaf...@me.com>> 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?)

yes, works fine.

> 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…)

then it’s a rollover.

> 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.)

an open document, if any, is main. panels float & are active; they may be key 
but not main. so, yes—i think the rollover should be active in this context.

> 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.

true—& i might just leave it.

> Because of all that, I’d say it’s well worth a bug report to ask for 
> clarification.

if several NSSplitView users concur it’s a bug, i’ll write it ; otherwise, it’s 
just another enhancement request—& the likelihood for action is small.

thanks for your comments!
_______________________________________________

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to