On Jun 30, 2017, at 08:07 , Navneet Kumar <navnee...@me.com> 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 (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
