Re: Wrong placement with -[NSWindow initWithContentRect:styleMask:backing:defer:screen:]
Re: Wrong placement with -[NSWindow initWithContentRect:styleMask:backing:defer:screen:]
- Subject: Re: Wrong placement with -[NSWindow initWithContentRect:styleMask:backing:defer:screen:]
- From: Jack Repenning <email@hidden>
- Date: Mon, 8 Feb 2010 10:12:39 -0800
On Feb 6, 2010, at 10:17 PM, Graham Cox wrote:
> So you're hard-coding the position of a window based on intimate knowledge of how your personal system happens to be set up. Presumably you can see why that might not be a good idea.
Oh, sure: that was just to make the example as closed-form as possible. IRL, it's based on a mouse click (the "window" I'm creating is actually a menu). The point I was trying to make was, if I click in some spots, the net effect is that the menu appears just under the mouse, as expected, but if I click in other screen regions, even just a pixel or two away, behavior becomes very odd.
In that regard, it's interesting to note that -[NSMenu popUpMenuPositioningItem:atLocation:inView:] behaves perfectly when passed the mouse location directly. That makes it about a hundred times easier than the approach I presently use, which involves several coordinate transformations between local-screen, whole-screen, and single-window coordinates (which, yes, I've checked again and again, but still might be the culprit, they being so convoluted). But this routine is new for 10.6, and I'm trying to support back to 10.4.
> Initially placing windows can be a bit of an art, precisely because the exact size, number and placement of screens in the real world varies enormously. It's probably best to place any window initially somewhere guaranteed to exist, which means asking NSScreen for information about the screens, and placing the window somewhere valid. Then, allow the user to move it somewhere else, and remember that location. NSWindow takes care of most of that for you. You could place the window on the secondary screen initially provided that you find out a) whether it actually exists and b) where it is, and also provide a fallback case for when a) is false.
Since my placement is based on a mouse click, it seems pretty safe to assume the location exists.
> I'm not sure why you're seeing what you're seeing, given that in your case you have special knowledge that suggests the rect is valid. It might be something to do with detecting the so-called 'standard' and 'user' states of the window which are based on being 'close to' the screen's available rect, for some definition of 'close to'.
"For some definition of 'close to'" sure sounds like it might be the behavior I'm seeing, but I'm unfamiliar with "the so-called 'standard' and 'user' states." Can you hint me a bit more on that?
-==-
Jack Repenning
email@hidden
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
_______________________________________________
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