Can you add part of this mail as class comment? Tx
On Nov 21, 2012, at 10:58 PM, Igor Stasenko wrote: > On 20 November 2012 21:30, Denis Kudriashov <[email protected]> wrote: >> Hello. >> >> Can you add me as project contributor. I try to upload version with detailed >> comment from my first mail but can't. >> >> 2012/11/18 Camillo Bruni <[email protected]> >>> >>> I don't think the basic model should know about the visual lines. We >>> discussed >>> that for a while, but in the end that's purely a view on the basic model. >> >> >> If such behaviour will be at view simple Cursor>>moveUp/moveDown will never >> work right from user perspective. So why you need cursor at text model which >> will never reflect state of visual cursor at screen? >> To me text model should completelly represent what user see at text view. >> Otherwise why you call it model? Otherwise it is just raw data like Text in >> current TextMorph. >> > > because same model can have multiple different views. and each view > can have different > dimensions and show different portion(s) of model (text). > The parts we implemented so far is about editing the model itself. > Next step would be to implement text attribute(s) management, > and then implement View(s) which will lay out the text for rendering > it on screen. > > About cursor: The cursor is actually a convenience method in current model, > to avoid using > 'text selection end' every time. > > The selection/cursor in text model there because this should be is the > only way how you can modify text: > - you should not be able to modify text without using selection(s)/cursor. > Any direct usage, like in existing Text , should be prohibited. Only > high level operations via selection. > And no illusions about that you can operate with text as with an > ordinal Collection. > If you want to turn text model into 'collection', you have to pay the > price: use #asString. > An way to treat text as a collection of characters is imo futile and > falls short once you think how to introduce non-textual objects into > text (images etc). > > More about selections: > It is not necessary to have a direct correspondence between model > selection and visual text editor > selection/cursor. And often, actually would be counterproductive. > > Camillo may disagree, but i think the main purpose of selection/cursor > objects and their protocol is to provide a convenient interface for > editing the model. > And the fact that you can have visual selection/cursor == model > selection/cursoe is imo secondary to that, > and completely unnecessary. > > Yes, we tried to map text navigation/selection protocol to look most > natural, as if you editing the text in text editor. > And tests which we have is actually telling that we're on the right > way: we've been able to edit the text without having 'text editor' and > without counting characters, but using high-level commands to > cursor/selection. Which is IMO good. > >>> >>> For instance if you want to get the insertion point when clicking on some >>> text view you have to take so many model-unrelated things into account >>> (global transformation, font sizes). >> >> >> I think It can be solve easilly if text model will reflect visual lines of >> text. >> For example, imagine my simple idea where TextView is just list of >> SpanMorph's. When user click on text concrete span morph will handle it >> because TextView is just morph with submorphs (no special behaviour). So >> target SpanMorph should just compute span position under mouse and change >> text model cursor position appropriatelly. Then cursor will announce >> #changed event and CursorMorph will reflect this automatically. >> > > The decision to use spans was to denote a portion of text which has > same attributes, > so a rendering engine can set up all attributes once, at the start of span, > and render all text characters in single pass, without need to do any > other checks for attribute changes. > I don't think representing spans with morphs will be a good idea. > > >>> 3) What about auto wrap behaviour? >>> If you have auto wrap option at text editors you have line width >>> restriction. And you should spit real lines of text to visual lines which >>> satisfed this restriction. And text mode should know about such restriction >>> because any text insertion can require new visual lines creation. >>> I think insertion single line text at span position should be executed by >>> special "restriction object". It should return new characters of span which >>> satisfied that restriction. And it should return new span object (or just >>> remains characters) which will present new visual lines. Then this "remains >>> characters" should be inserted to next span at 0 position. >>> When wrap behavior not needed "restriction object" just inserts new text >>> into current characters at given position and returns result. >> >> >> Just remember two kinds of such line width restrictions: width in pixels and >> width in characters. First is usual text wrapping behaviour when line width >> restricted by view width. Last is when editor wrap lines which contains >100 >> characters for example. >> > > text wrapping is visual/layout information. > The data flow when you rendering text is following: > > (Text) -> (Layout information) -> (Screen) > > The text , as a model , has nothing to do with layout information. > More than that, don't forget about multiple views for same model, > which can have different dimensions and different wrapping rules. So, > it would be bad idea to mix layout information with text model itself. > > -- > Best regards, > Igor Stasenko. >
