Re: NSWindow Level Side Effect - PopUp to Normal
Re: NSWindow Level Side Effect - PopUp to Normal
- Subject: Re: NSWindow Level Side Effect - PopUp to Normal
- From: Caylan Larson <email@hidden>
- Date: Mon, 28 Oct 2013 22:28:12 -0500
On Oct 28, 2013, at 9:38 PM, Caylan Larson <email@hidden> wrote:
>> Ken Thomas wrote:
>>
>> I believe that ordering your window behind the other window would work (after you've reduced its level), but you're not correctly identifying the target window. The window number list includes the menu bar and perhaps some other system windows. You can try to use the CGWindow API to identify the real window you want to order relative to, but you'll be making a lot of unsupported assumptions in any such heuristic.
>
> Hmm. It does. But like you wrote, the assumptions are a bit … unsupported. In short, the window list from CGWindowListCopyWindowInfo shows the topmost user window directly after kCGWindowName as “Dock.” And this works, but I’m not going to press my luck. I guess this see-all scope will have to wait until later. :)
I could use advice on interface implementation. My app takes the screen real-estate behind its window and rasterizes the screen data using different filters - it then prints the raster data to thermal printers (label, receipt, etc.).
http://files.caylan.net/skitch/labelscope-20131028-220538.png
This interface is made up of one main window (the paper media in b/w) and the rest of the windows are children (5 of them): gray background with a hole punched out, two rulers, toolbar, and the orientation arrow. For moving the window, each child’s NSView implements mouseDragged to setFrameOrigin on the parent window using the mouse location delta.
This works great… except when the window nears the main menu. If I get close to the main menu, the child window’s frames start to get limited in upward mobility. This causes drawing bugs. Strangely, the redrawing doesn’t happen until I setFrame: (vs setFrameOrigin). However, dragging is not the only one use case where the main menu breaks the design - it happens when the window resizes vertically and tries to cross the main menu boundary (user drag and user zoom gesture).
In short, this is why I was leaning toward NSWindow’s level via NSPopUpMenuWindowLevel or NSMainMenuWindowLevel. I could just rise above the main menu and not even worry about it. It works - except for the details in the first post of this thread. In the “level” design, the the app's UI would be accessible for people scoping at the top of their display (sure, I could move the toolbar to the bottom of the window… but the border will still get mangled by the main menu).
This is my 2nd Mac App as an independent developer. I’m feeling comfortable enough with auto-layout to start merging the child windows into fewer windows. I could have one main window (the background/toolbar/rulers) and one child (the paper media in b/w). However, I don’t think this will cure my problem.
Any way to salvage the design? I’m happy to hear recommendations on adding elegance to this design.
Stuck between a rock and a menu bar,
Caylan
_______________________________________________
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