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: Quincey Morris <email@hidden>
- Date: Fri, 30 Jun 2017 10:55:50 -0700
On Jun 30, 2017, at 08:07 , Navneet Kumar <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