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.
