On 18 November 2012 17:56, Camillo Bruni <[email protected]> wrote: > > 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. >
i have only one question: - shall we do this surgery (with announcer stuff) in base model, or - shall we make a separate model which wraps around existing model,and then provides a notification(s). my main source of disdain about notifications is that in single class we will have to mix an action and notification about it i.e.. Selection>>cut self doThingsToCut. ... self announcer announce: IJustCutMyself. this is IMO a bit stinky. I would prefer a notification(s) to be in a separate layer: SelectionWatcher/Controller>>cut selection cut. ... self announcer announce: SelectionWasJustCut despite that it looks like more costly in terms of implementation. But i don't like mixing multiple concerns in single place. >> 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 > > -- Best regards, Igor Stasenko.
