NSWindow -frame doesn't update synchronously when dragging (which is weird,
because other NSWindow public API that also depend on the exact window frame,
e.g. NSWindow -mouseLocationOutsideOfEventStream, work as expected during
window drags).
One option might be to grab the NSWindow's rect via the CGWindow APIs, which
will be accurate during drags. Something like:
CGRect directWindowFrameForWindow(NSWindow *window)
{
CGRect rect;
CGWindowID windowID = (CGWindowID)[window windowNumber];
CFArrayRef windowArray =
CGWindowListCopyWindowInfo(kCGWindowListOptionIncludingWindow, windowID);
if (CFArrayGetCount(windowArray))
{
CFDictionaryRef windowInfoDictionary =
(CFDictionaryRef)CFArrayGetValueAtIndex ((CFArrayRef)windowArray, 0);
if (CFDictionaryContainsKey(windowInfoDictionary, kCGWindowBounds))
{
CFDictionaryRef bounds =
(CFDictionaryRef)CFDictionaryGetValue(windowInfoDictionary, kCGWindowBounds);
if (bounds)
{
CGRectMakeWithDictionaryRepresentation(bounds, &rect);
}
}
}
CFRelease(windowArray);
return rect;
}
If there's a better way of obtaining this through Cocoa/AppKit I'd like to know
as well.
-Matt
> On Dec 17, 2015, at 4:32 PM, Cem Karan <[email protected]> wrote:
>
> Hi all, I'm working on an application that has one primary window and
> multiple support windows. The support windows show auxiliary information for
> what is in the primary window, but not off to the side; they are more like
> color filters or X-ray glasses. You slide them over the primary, and they
> show their extra information. To get an idea of what I'm talking about,
> clone https://github.com/ckaran/glfw/tree/transparent_windows, (that's the
> 'transparent_windows' branch) build it, and run the example that corresponds
> to
> https://github.com/ckaran/glfw/blob/transparent_windows/examples/filters.c.
> You'll get 3 windows, red, green, and blue. As you drag the blue window over
> the red one, a triangle will be drawn on the blue window that is centered on
> the red window.
>
> All that works, but the problem is that I'm not getting window positions
> quickly enough; as long as a window is being dragged, it won't send out a
> notification about its position, which means all the windows get out of sync
> with one another. This is annoying. I traced it down to the OS X code by
> logging where the windows thought they were, so I know it really is Cocoa and
> not GLFW. I tried polling the position of the window, but that doesn't work
> (the polling is happening, but it prints the same position continuously until
> dragging stops). So, how do I get the window to update where it actually,
> truly is at the moment I ask it?
>
> Thanks,
> Cem Karan
> _______________________________________________
>
> Cocoa-dev mailing list ([email protected])
>
> 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/mreagan2652%40gmail.com
>
> This email sent to [email protected]
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
