On Sun, May 29, 2011 at 5:54 PM, Ajay Sabhaney <co...@mothercreative.com> wrote:
> I have a suspicion that the reason for this has something to do with the fact 
> that the NSTextView instance is being added as a subview of a layer-hosting 
> view.

Yes, this is very much unsupported. You will need to stop using
NSTextView in this way.

In our forthcoming Mac applications, including the available beta of
OmniPlan 2 [1], we use thousands of layers to draw our outline view.
This view obviously contains editable text. Following an Apple
engineer's previous advice, we put an NSTextView in a sibling view of
our layer-hosting view. We get to do all our fancy animations and
effects with layers, but when editing text the user is interacting
with a field editor. So the view hierarchy looks like this:

NSScrollView (layer-backed)
    +-- NSClipView (layer-backed)
        +-- Empty NSView (layer-backed)
        |   +-- Field editor (layer-backed; added/removed on demand)
        +-- Outline View (layer-hosting)

The problem with this setup is that layer-backed NSScrollViews on Snow
Leopard are still fundamentally broken if their document views return
YES from -isFlipped. rdar://problem/8009542 It is not currently
possible to fix this brokenness without calling private API.

Also, NSTextView draws its spell-check lines incorrectly if it's
layer-backed. rdar://problem/8644121 This problem was solved by Craig
Hockenberry in Twitteriffic 4 for Mac by manually drawing the spelling
underlines. I don't think we've made the same fix yet for our apps.

As for actually drawing the text in your layers when the user isn't
editing the text, we have a "layered text cell" class that renders its
text into a graphics context in -displayLayer. This layout manager is
shared with the field editor; when the user starts editing a cell, the
cell swaps out the field editor's text stack with its own, including
the text storage and layout manager. This is an *incredibly* delicate
process, because ownership of text system objects differs based on
whether the objects were loaded from nib or created using the
designated initializer, and you need to be very careful to set the
selection to a valid range before disassociating the text view from
its text storage.

Sharing the layout manager between the cell and the field editor is a
(significant) performance savings, but if you only have a few cells,
you could probably get away with not sharing the text stack, and just
updating the field editor's text storage contents with the contents of
the cell being edited.

Hope all that helps. Download the beta of OmniPlan 2 and play around
with the outline view to get a feel for how it winds up working out in
practice:

[1] http://www.omnigroup.com/products/omniplan/download/#beta_link

--Kyle Sluder
_______________________________________________

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

Reply via email to