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