Hello. I am working on a cocoa-based text editor. Should I base it on NSTextView or is there a more efficient option? Keep in mind that I plan to support tabs so there can be many editors open at the same time.
A:
NSTextView is probably the simplest way to go if you want to get a ton of nice features for free. It can't do everything, but it's an awesome start.
Dave DeLong
2010-04-03 20:22:24
Thanks, it's just that I keep reading how you should avoid creating too many subclasses of NSView for efficiency purposes.
Bret
2010-04-03 22:05:09
user308444: Either you're taking that out of context or it's just plain wrong. Subclasses don't cost anything except developer time, and instances cost hardly anything to create unless you're (1) running on early iPhone-OS hardware or (2) creating thousands of instances. Not to mention, you aren't creating a subclass of NSView when you use NSTextView; in fact, any “more efficient option” would probably be a new subclass. More importantly, the correct order is write, then profile, then optimize. Putting optimization first leads to bad decisions and unnecessarily-complex code.
Peter Hosey
2010-04-04 05:42:34
+2
A:
I am working on a cocoa-based text editor. Should I base it on NSTextView
Yes.
or is there a more efficient option?
No, assuming “efficiency” includes your own time and effort weighed against the feature set you want to support—Cocoa's text system does a lot for you, which you'd be throwing away if you rolled your own.
Some examples:
- Undo support
- Advanced editing (emacs keys)
- Support for input managers/input methods
- Support for all of Unicode
- Mouse selection
- Keyboard selection
- Multiple selection
- Fonts
- Colors
- Images
- Sounds
- Find
- Find and Replace
- Spelling-checking
- Grammar-checking
- Text replacement
- Accessibility
If you roll your own, you get to spend months reinventing and debugging some if not most if not all of those wheels. I call that inefficient.
The text system you already have, meanwhile, is fast nearly all of the time. You need huge texts with long lines (or maybe lots of embedded images/sounds) to bog it down.
Keep in mind that I plan to support tabs so there can be many editors open at the same time.
Unless the user is going to be typing into all of them at once, I don't see how that will cause a performance problem. 0% CPU × N or N-1 views = 0% CPU.
The one place where you might have a problem is memory usage, if the documents are both many and large. They'd have to be both in the extreme, as even a modest Mac nowadays has 1 GiB of RAM, and text doesn't weigh much.
If that's the case, then you could only keep the N most recently used unmodified texts in memory, and otherwise remember only the arrays of selection ranges. But 99% of the time, swapping texts in and out will be far more expensive than just leaving them all in memory.
Peter Hosey
2010-04-04 05:55:52