Re: Choosing a view for terminal like app

FROM : Mike Ferris
DATE : Sun Dec 15 13:45:01 2002

Whether to use an NSTextView may come down to whether you wish to
actually support Terminal emulation...

If you want a dumb tty, then using NSTextView is pretty simple.  If you
want Terminal emulation it gets trickier.  At that point it becomes a
question of whether it is harder to get NSTextView to be a Terminal
emulator or to write your own class that handles the text.  You could
probably use a lot of the lower layers of the text system to deal with
some of the layout even if you do your own view...


Also, note that subclassing NSTextStorage is not that tricky.  You only
need to override the primitives from NSMutableAttributedString (three
methods I think) and whatever additional primitives NSTextStorage has
(I don't remember exactly, but it isn't many.)

Mike Ferris


Begin forwarded message:

> From: Dave Dribin <<email_removed>>
> Date: Sun Dec 15, 2002  8:43:46 AM US/Pacific
> To: <email_removed>
> Subject: Choosing a view for terminal like app
>
> Hello,
>
> I am new to OS X and Cocoa and I'm having a hard time deciding which
> view/widget I should use for a terminal-like application.  I will be
> programming this in Cocoa and Objective-C.  I have been reading the
> Sam's "Cocoa Programming" book and reading over Apple's developer
> docs.  The first choice would be to use NSTextView or one of it's
> relatives.  However, I will not be using an attributed string as the
> backing store.  My backing store is more line-based rather than one
> big continuous chunk of text.  I see 3 options:
>
> 1) Convert my backing store into an NSTextStorage so that it can be
> placed inside NSTextView.
>
> 2) Subclass NSTextStorage using my backing store as the real storage
> and use NSTextView.
>
> 3) Create a custom view using my backing store as the model.
>
> Option 1 seems very inefficient.  If my backing store changes often
> and is large, then this conversion could be very slow.  My gut tells
> me this will be way to slow and inefficient to be practical.
>
> Option 2 seems like an OK idea.  However, this means I will have to
> implement all the methods, which seems like a lot of work.  This
> includes all methods that modify NSTextStorage and
> NSMutableAttributedString.  Since all modifications will not happen
> through the view, these methods will not really be used, so
> implementing these methods seem like unnecessary work and may not be
> efficient to implement for my backing store.  Also, NSTextView doesn't
> really fit well with what I need, either.  I do not need probably 90%
> of the interface.
>
> Option 3 seems like the best idea, but I do not even know how to
> approach it.  I do not want to draw the text using drawAtPoint from
> NSString.  That would seem very slow.  Using NSBezierPath doesn't seem
> right, either.  Especially when you have to resort to using private,
> undocumented methods of NSFont to access glyphs, as described in the
> Cocoa book.
>
> I decided to open up Terminal.app's NIB and sure enough they are using
> their own custom TermView.  That makes Option 3 even more attractive. 
> I do not know how they implemented it, but it shows they did not use
> NSTextView or NSText.
>
> So, does my decision process sound sane?  And if I go for the custom
> view, what's the best way to draw lots of text efficiently?  Convert
> glyphs to bitmaps and just copy them on the screen?  Use NSBezierPath?
>  Is there some other method I've overlooked?  Thanks!
>
> -Dave
>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev