Alexander Klenin wrote: > On Fri, Dec 12, 2008 at 21:37, Martin Friebe <laza...@mfriebe.de> wrote: > >> In The current structure >> SynEdit is the Visual control, and therefore also the control that takes >> all events such as mouse/key down/up/move. Often it is SynEdits work to >> react to this, but often it also needs to call back to SourceEditor. >> >> It is at least worth reviewing if this order could/should be changed (I >> am not sure about it): >> - SourceEditor could be a visual component with all the Key/Mouse event >> handlers. >> - It would *not* inherit from SynEdit, but same as now it would have a >> SynEdit instance that it can make calls to. This SynEdit would not paint >> on it's own canvas, but rather paint on the SourceEditors canvas >> - Instead of SynEdit making all the callbacks to SourceEditor, now all >> events go to SourceEditor first, and SourceEditor can decide what to >> forward. >> > Sigh, if we are dreaming anyway, here is my dream: > > 1) Logic should be separated from the presentation, so first there should be > 'TAbstractSynEdit' class, concerning itself purely with text manipulations, > such as text insertion/deletion, cursor position changes, text > attribute calculation, > save/loading, codetools etc. > TAbstractSynEdit should not depend on any visual code, in partucular it should > descend from TObject/TPersistent, not TControl. > Well I am in the process of breaking it up into smaller bits. - The gutter drawing moved to its own class. - Folding is partly abstracted - Trim Trailing spaces has been abstracted into a class of its own. (a view of SynEditLines) - Caret and block have been started
Of course, they do still have heavy dependencies. But those can not easily be removed yet, other parts have to be broken free first. > 2) Logic should be covered by automated tests, e.g. using fpcunit framework. > Also started (mainly folding), so they need heavy cleanup. I cam from other test frame-works and forcefully attempted to abuse fpcunit... But as far as I am concerned, you can not write code without having automated tests. > 3) Presentation and user interaction should be the concern of TSynEdit class, > aggregating TAbstractSynEdit and delegating all actual logic to the latter. > > 4) SourceEditor should be removed (or converted into a trivial wrapper), > TSourceNotebook should reference TSynEdit directly. > > >> On the other hand, it is probably not worth the amount of work. Well the >> future will show, if there is a use case for it... >> > > True. Proper design requires lots of effort, and (especially > short-term) benefits > might not outweight the costs. > > _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus