Exactly. That’s an excellent example and should work fine. Great solution.
On Jul 19, 2011, at 11:59 PM, Michael Crawford wrote: > Well, I suppose I could make sure the window's contentView is not layer > backed and then put all of the content that used to be in that view into a > new layer-backed view and then add the new layer-backed view as a subview of > the contentView. > > Next, I create my layer-hosting view and add it to the contentView as a > subview, making it a peer of the layer-backed view. > > Is that what you mean by restructuring the view hierarchy? > > -Michael > > On Jul 19, 2011, at 23:44, Scott Anguish <sc...@cocoadoc.com> wrote: > >> >> On Jul 19, 2011, at 12:27 PM, Michael Crawford wrote: >> >>> Graham; Scott, >>> >>> I have a follow-up question on this topic, if you don't mind. Do either of >>> you have a recommendation on the idea of adding a layer-hosting view as a >>> subview of a layer-backed view? >> >> Yes. You shouldn’t. >> >> When you turn on layer-backing for a view, you turn it on for the entire >> subview hierarchy. So none of those layers are your’s to mess with. >> Typically the way around this is to restructure the view hierarchy some. >> >> >>> I'm thinking of adding a virtual keyboard to an existing app that is >>> layer-backed. I would like this VK view to have all the benefits that >>> NSView brings including event handling without all of the heavy-weight of >>> multiple subviews for the keyboard mechanics. >>> >>> Can I mix these? >>> >>> (Please reply to the thread for everyone's benefit.) >>> >>> -Michael >>> >>> On Jun 22, 2011, at 3:02 AM, Scott Anguish wrote: >>> >>>>> Yep, I'm aware of the setWantsLayer/setLayer order making a difference. >>>>> >>>>> In my case I want a layer-hosting view, not a layer-backed view. >>>>> >>>>> However, my question isn't really about that, but about what is done when >>>>> you check the box next to the layer in Interface Builder, in the >>>>> 'setWantsLayer' panel. Does this provide layer backing or layer hosting? >>>>> My thoughts were that is provides layer hosting, but I'm not 100% sure. >>>>> Proceeding on the basis that this is the case, it seems to work. >>>>> >>>> >>>> layer-backed. >>>> >>>> >>>> >>>> >>>>> >>>>>> Again this is not in line with my expectations, which is that the frame >>>>>> of a sublayer is expressed in the coordinate system of its superlayer, >>>>>> not the underlying window. >>>>> >>>>> I found the cause of this issue, which was that in my layer delegate, I >>>>> was not saving, setting and restoring the context passed to >>>>> drawLayer:inContext:. I was assuming that the context was set, but having >>>>> found a code snippet in the docs that indicated it wasn't, I added these >>>>> calls and my graphics are drawing in the right place now. >>>>> >>>> >>>> great!_______________________________________________ >>>> >>>> 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: >>>> http://lists.apple.com/mailman/options/cocoa-dev/michaelacrawford%40me.com >>>> >>>> This email sent to michaelacrawf...@me.com >>> >> _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
