On 2012-11-14, at 17:36, Denis Kudriashov <[email protected]> wrote:
> Hello. > > I look deep at TxText package where Igor and Camillo introduced new text > model. > > Text model based on sequence of span objects. There are now two kind of > spans: CharacterSpan and LineSeparator. Each span has reference to next and > previous spans. There is TxSelection object which contains cursor. So you > can insert new text at cursor, you can cut selection, replace selection > with another text. Such maniulation changes text model structure. It can > create new span objects. It can split current span at cursor position, It > can remove selected spans. Also you can move cursor up, down, left, right. > Cursor always know about current span and span position. > > I like design :). And I want use this package. And I have questions and > suggestions: > > 1) Cursor is end of selection object. So now when you move cursor selection > changed, because start of selection stay same. Am I right? yes > I think cursor movement should always reset selection. It is what we see > with basic text editors. > But cursor now is just instance of TxPosition which implements simple > position protocol (move left, up...). It just change current span and span > position by movement. TxPosition knows nothing about TxSelection object. > That's why I think Cursor class should be introduced here which alway reset > text selection by any move. > And if you want to change selection bounds just get explicitly start or end > of selection and use position api. > What do you think? Humm not so sure about this :). Your argument in favor of a default behavior which conforms to other editors is definitely something to consider. In the end it's not that much work to get the a decent default behavior. Somewhere in the view where you modify the mode you can do `text selection collapse`. If you want you can try to implement it ;) and we see how it feels to use it that way (most probably I will be in favor then..) > 2) Next question about changes notification of text model. First I want > Cursor and Selection objects are annnouncers. So I can implement > CursorPresenter and SelectionPresenter to show such objects and handle > changes. For example when CursorMovedAnnouncement happen I can move cursor > caret morph at appropriate position. this sounds like a good idea! I don't remember if we replace/create new instances of the cursors/selections... This might have an impact on where you want to listen for changes. But definitely we want something like that to decouple the model from any view. > Another idea is make span objects announcers. Maybe it is not good idea but > I want to subscribe at SpanAdded, SpanRemoved. SpanChanged, SpanSplitted. > With such events I can make very simple implementation of TextEditor as > list of SpanMorph's. Maybe it is not optimized solution but I think it is > most simple thing. So I want to try it. > > 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 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. 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 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. > If you agree about such logic please suggest good name for such > "restriction object" and instance variable where it will placed (at TxModel > I think) > > Ok, now what do you think about all this? > I want implement all my suggestions. But first I want listen your opinions. > > Best regards, > Denis
