Overlay windows
-
Afternoon folks (over here anyway),
I'm about to add an overlay window over my graphics view so as to
remove the need to frequently redraw the (expensive) graphics
unnecessarily, and I have a few questions that I'd like to ask. I've
watched WWDC 2004's Cocoa Tips & Tricks session (411) where they
discuss creating an overlay window as a child window of the 'visible'
window, but there are some complexities I'd like to know the answer to:
[1] The overlay view needs to stay locked onto (same size / position
as) my graphics view. Bearing in mind my graphics window has a toolbar
that the user may show / hide mid-app, how do I guarantee that my
overlay view fits over my graphics view, and that it does not appear an
NSToolBar's height above / below it? Do I just catch the
graphicsWindows -windowDidResize notification and update then?
[2] My graphics view is inside a scrollview. Bearing in mind it is the
job of the overlay view to draw things (eg. selection handles) over the
appropriate objects in the graphics view, it's important that the
overlay view respects the scrolled location of the graphics view. So
what's the easiest way of tallying the overlay view's scrolled position
to the graphics view's scrolled position? Do I even need the overlay
view to be in a scrollview, or should I just offset the overlayView's
coordinate system relative to the scrolled position of the
graphicsView?
If notifications wouldn't work in [1] I'm thinking maybe bindings could
be used to bind the [[overlayWindow contentView] frame] to
[[graphicsWindow contentView] frame], which should allow for a toolbar
shifting the graphics window's contentView up / down.
Ditto I was wondering if I could somehow bind the overlayView's frame,
bounds and scrolled position to the graphicsView's respective
attributes, so that my selection handles appear in the right places
(and are only drawn for visible objects etc.)?
Stop me if I'm barking up the wrong tree here 8^)
Have a great weekend, especially those of you lucky enough to get your
ADC Tiger discs today (we live in the sticks here in the UK!),
Ken
- - - - - - - - - -
Dr. Ken Tabb
Mac & UNIX Developer - Health & Human Sciences
Machine Vision & Neural Network researcher - School of Computer Science
University of Hertfordshire, UK
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider -
On Apr 29, 2005, at 8:24 AM, Ken Tabb wrote:> Afternoon folks (over here anyway),
>
> I'm about to add an overlay window over my graphics view so as to
> remove the need to frequently redraw the (expensive) graphics
> unnecessarily, and I have a few questions that I'd like to ask.
> I've watched WWDC 2004's Cocoa Tips & Tricks session (411) where
> they discuss creating an overlay window as a child window of the
> 'visible' window, but there are some complexities I'd like to know
> the answer to:
>
> [1] The overlay view needs to stay locked onto (same size /
> position as) my graphics view. Bearing in mind my graphics window
> has a toolbar that the user may show / hide mid-app, how do I
> guarantee that my overlay view fits over my graphics view, and that
> it does not appear an NSToolBar's height above / below it? Do I
> just catch the graphicsWindows -windowDidResize notification and
> update then?
You can do that, or you could tell your graphics view to post frame/
bounds changed notifications, and update your overlay window when you
get those notifications. The tricky part would be clipping your
overlay if your graphics view's selection is clipped by its enclosing
scrollview. Doable, certainly, but potentially annoying to sort out ;-)
I should probably update the "Cropped Image" sample to use an overlay
window. I didn't use one originally, because overlays were rather
more work under Jaguar, and I wanted to keep the example simple.>
> [2] My graphics view is inside a scrollview. Bearing in mind it is
> the job of the overlay view to draw things (eg. selection handles)
> over the appropriate objects in the graphics view, it's important
> that the overlay view respects the scrolled location of the
> graphics view. So what's the easiest way of tallying the overlay
> view's scrolled position to the graphics view's scrolled position?
> Do I even need the overlay view to be in a scrollview, or should I
> just offset the overlayView's coordinate system relative to the
> scrolled position of the graphicsView?
Sign up for the frame changed notifications, and adjust your drawing
as you like... Remember that the coordinate system of your custom
view is yours to manipulate as you like for your own convenience.> If notifications wouldn't work in [1] I'm thinking maybe bindings
> could be used to bind the [[overlayWindow contentView] frame] to
> [[graphicsWindow contentView] frame], which should allow for a
> toolbar shifting the graphics window's contentView up / down.>
> Ditto I was wondering if I could somehow bind the overlayView's
> frame, bounds and scrolled position to the graphicsView's
> respective attributes, so that my selection handles appear in the
> right places (and are only drawn for visible objects etc.)?
That should work.. You'll probably need to write some accessors and
override -setFrame: and -setBounds: to post the KVO notifications
yourself, though. Out of the box, NSView doesn't vend any size-
related bindings.> Stop me if I'm barking up the wrong tree here 8^)
I don't think you are... I did something similar in the CoreData
"Stickies" example, to get the window frames into my data model.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
