Sean P. DeNigris wrote

I did a first pass

I made some of the more obvious fixes/enhancements... Issue 15414: TxText Cleanup for Pharo 5.0 #1 Fixes in Tx repo: TxText-Styler-SeanDeNigris.4 - Update for TxCursorAttribute to TxMouseCursorAttribute rename TxText-Model-SeanDeNigris.52 Higher-level: - Rename TxCursorAttribute to TxMouseCursorAttribute; we must differentiate between the insertion cursor, which is already named the "Cursor" Cleanups: - Rename TxModel>>#setNewContents, which does not follow Constructor Parameter Method, to #initializeContents - Many comment enhancements - Several small refactorings - Extract TxInterval>>#normalize to return a copy with start < end; this logic was duplicated everywhere TxText-Athens-SeanDeNigris.45 Higher-level: - Initial TxBlockCursor implementation as an experiment, mostly copied from TxCaretCursor. It might be to have a pluggable drawing strategy instead of a whole separate class... Cleanups: - Many comment enhancements - Several small refactorings ----- Cheers, Sean -- View this message in context: http://forum.world.st/Tx-Pass-tp4822173p4822193.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On 27/04/15 15:58, Sean P. DeNigris wrote:

Design Questions: - TxModel - what is the advantage of a double linked list vs the old Text implementation?

I vaguely remember being told in a data structures class to use circular linked lists instead of begin and end markers. I assume that could have performance implications. It was also assumed to be much easier to get right. The performance of a 2-array-backed structure like the old Text becomes unacceptable for larger texts. It is fine when just adding at the end, but editing somewhere in the middle gets slow.

- Why no strike fonts? Why is Verdana commented out in TxFontAttribute class>>#defaultValue?

AFAIK the default font needs to either be supplied by the image or be platform dependent. I assume the Athens renderer is (was?) not able to render strike fonts. It took me a while to realize that text in TxBasicSpan is the TxModel. Stephan

Hello,

On 27 Apr 2015, at 15:58, Sean P. DeNigris <sean@clipperadams.com> wrote:

Just like Bloc (which has *great* class comments), I think it's crucial to document the high level design decisions in Tx. I did a first pass and noted some initial impressions...

Design Questions: - TxModel - what is the advantage of a double linked list vs the old Text implementation?

I think it facilitates the moving for one text element to another, and the implementation of new text elements. as an example, Igor added TxEmbeddedObjectSpan in one day. It allows the adding of Morps (or what ever object) as text elements. The same was done for the current Paragraph, the implementation was a messy hack. drawback, I find the model difficult to understand.

- TxLayoutViewMorph vs. TxTextEditorMorph - I'm not clear on the purpose/relationship/pattern here?

TxLayoutViewMorph: presents a sub part of the text and implements the scrolling (no need for a scroll pane). TxTextEditorMorph: owns a TxLayoutViewMorph, a controller (an editor) and a cursor to allow text editing. Thus, TxTextEditorMorph implements text editing (insert: aString ). When the text is changed, only the subpart of the text is layouted (by the TxLayoutViewMorph). Also, only the viewed sub-part of the text is re-layouted in case of scrolling, not the whole text as in Paragraph. Thus, the editing efficiency stay acceptable even for big text the drawback is for the scrollbar: its value must be approximate.

Implementation Questions: - TxBasicSpan#< seems overly complex. Why two-way searching. Was it the result of profiling? Intuition? Random? - TxTextEditorMorph>>#openInWindowWithText: says not part of API, but this code is pretty much the only way to use it for now, right?

yes, near from what is needed for real

- applyAttribute:to: sends an unimplemented message, but I'm not sure what should be done here - Why no strike fonts? Why is Verdana commented out in TxFontAttribute class>>#defaultValue?

I guess lack of time to integrate strike fonts properly. but do we need it ?

- TxLayoutViewMorph class>>#text: sends #asTxModel to argument, but TxTextEditorMorph doesn't. Which one is right? I think there's not much harm in sending it in both to make it a bit easier for users…

I think #asTxModel should be sent for both Cheers Alain

- TxBasicViewMorph>>#fullDrawOnAthensCanvas: checks if fullBounds are visible on canvas, then checks #bounds again. Are both necessary?

Tx already seems very usable! I'm starting to play with it in one of my projects... I've been dreaming about this for a long time :)

----- Cheers, Sean -- View this message in context: http://forum.world.st/Tx-Pass-tp4822173.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.