Re: Focus ring of NSComboBox and text field visible through overlaid views
Re: Focus ring of NSComboBox and text field visible through overlaid views
- Subject: Re: Focus ring of NSComboBox and text field visible through overlaid views
- From: Navneet Kumar <email@hidden>
- Date: Sat, 01 Jul 2017 12:01:55 +0530
Hi,
Thanks for the valuable insights.
I think I’m gonna go with child windows and not sheets as I have to support os
x 10.7.
Thanks again,
Navneet
> On 30-Jun-2017, at 11:25 PM, Quincey Morris
> <email@hidden> wrote:
>
> On Jun 30, 2017, at 08:07 , Navneet Kumar <email@hidden
> <mailto:email@hidden>> wrote:
>>
>> I also have a small project uploaded […]
>>
>> Which shows both the focus ring problem and tooltip problem
>
> I don’t know why, but the focus ring doesn’t bleed through for me (Xcode 9,
> macOS 10.12).
>
> However, I think your solution in the test project is correct: change the
> first responder. My reasoning is philosophical. The window doesn’t really
> understand the view geometry as perceived by the user. That fact that
> siblings overlap (in terms of frame rectangles) doesn’t mean it looks that
> way when transparency and possibly tricky event routing are involved. As far
> as the window is concerned, though, firstResponder is firstResponder, and it
> seems wrong for the combo box to keep the focus ring if you can’t type in it
> (if keystrokes don’t go there by default). Note that you could set
> firstResponder to the window instead of one of the overlay views, with
> approximately the same effect.
>
> In regard to the tooltip, the correct outcome is a bit murky for the same
> reason. The window truly doesn’t know that the significant piece of real
> estate is occluded from the user’s point of view. (Plus, the current behavior
> may well be left over from the days when siblings weren’t really supposed to
> overlap.) I don’t see that you have much choice but to kill the tooltips when
> displaying the overlay, and restore them later.
>
> However, I think the real answer is to use a child window. You really do have
> window-occlusion mechanics — the part of your current window that’s under the
> overlay effectively loses “key” status — and using a separate window would
> resolve the ambiguity of your intentions (from the window’s point of view).
>
> A sheet may work for this, especially since it’s possible to customize the
> placement of a sheet within its window — it doesn’t have to be at the top.
> Also, since the last couple of versions of macOS (10.10+, maybe?), you can
> display a sheet on top of a sheet if you want.
>
> Or, use a separate window and set it to be a child of the initial window.
> I’ve never done it, but it’s been mentioned on this list several times, and
> it seems straightforward.
>
> The child window or sheet might also so another slight problem in your sample
> app. The overlay has a shadow, but it’s the wrong shadow for macOS’s window
> composition metaphor. It’s a subtle thing, and you may actually prefer the
> “wrong” shadow, but using separate windows would give you the standard shadow
> look (and give it to you for free).
>
_______________________________________________
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