[Biococoa-dev] BCSequenceView

[Charles PARNOT]

At 6:42 PM -0500 3/5/05, Koen van der Drift wrote:
>On Mar 3, 2005, at 3:01 AM, Charles PARNOT wrote:
>
>>My gut feeling is that subclassing NSTextView is 'evil', and that instead the NSTextView should be a ivar and a subview (taking all the space for now, but in the future a BCSequenceView could have several subviews with several text fields like 'sequence length', 'current selection',...), and that BCSequenceView could be the NSTextView delegate to respond to user input and reformat the text view contents accordingly. Sorry this is not very detailed, so you can ignore it if that does not make sense!
>
>
>If BCSequenceView is the delegate, then I wouldn't call it a view :) Apple actually documents subclassing an NSTextView, so I don't see why it is evil. I think what you have in mind is more a complete window, with a view, and several widgets. For that you would need to create a controller class, probably a NSWindowController subclass.
>
>If we want more control over the way the sequence is displayed in a view, overriding NSLayoutManager et al, as explained by Alex is probably the way to go. I am not sure however, if that would be in place 'in the framework' of BioCocoa.
>
>- Koen.

Yes, sorry, I just wrote that email too fast, and 'evil' should have been 'scares me', and I should just read the docs before opening my big mouth, sometimes. I don't know anything about the text layout in Cocoa, so shame on me! The way I thought of BCSequenceView was more a superview composed of different prebuilt elements, with an NSTextView being central to it and displaying the sequence per se, but maybe also a little text field with the length, sequence type, some other text fields for symbol counts,... That would be easy for me. I agree that a better integrated NSTextView might do a better job (as long as you get it to work!).

I continue this email 3 hours later...

Well, now that I think more about it, I actually have a maybe more meaningful concern. When you make your own program and subclass NSTextView, it is fine, because you are the only user of it, you design it, you know how to use it and the limitations. But when you try to create a class for a framework that other people will use, you may want to make the object more encpasulated. If it is a subclass of NSTextView, it clearly inherits many different things from it that users may be tempted to use. Even if you put warnings about not doing this or that with it, we may not able to predict all the subtleties and consequences. Conversely, if you wrap the NSTextView in an NSView subclass, and  have a limited number of public methods, it may be easier to use and document. This NSView subclass would just add a layer around the objects in it, and shield the NSTextView from being abused and misunderstood. In addition, it might be easier to later change the internals and/or have several widgets composing the final view.

An example is the WebView in Apple's framework. It could have been made a subclass of NSTextView. After all, it is usually a lot of text, and scrollers. But that would be confusing to use, with all the inheritage from NSTextView + the new stuff dealing with web connections. OK, a web view is more complicated that a sequence view, so it is not the best example, but I hope you see my point.

just my 2 cents, from a naive user perspective

charles

-- 
Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Charles Parnot
charles.parnot at stanford.edu

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021