[Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

Martin Friebe lazarus at mfriebe.de
Fri Dec 12 14:26:35 CET 2008


Alexander Klenin wrote:
> On Fri, Dec 12, 2008 at 21:37, Martin Friebe <lazarus at 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.
>
>   



More information about the Lazarus mailing list