Folding ParagraphEditor and TextEditorController

Hey Travis,

In VW 7.6 we have:
    PE: 2 over, 5 ext
    TEC: 8 over, 4 ext, and override of class def to add 'maximumChars' ivar

As I understand it, there is a functional difference between the two besides "more bells and whistles" (unless that funcional difference is part of what you meant by that phrase).

ParagraphEditor is more basic because it was designed to handle smaller texts as a single contiguous sequence, without regard to breaks, ideal for scrolling horizontally to provide a limited view of a single line, as one would expect for an input field.

TextEditorController adds the notion of tracking text broken up by carriage returns into multiple lines (paragraphs) to optimize handling of larger documents. It handles wrapping as an alternative to horizontal scrolling, as well as vertical scrolling of large texts with many paragraphs.

Presumably you would need to maintain the distinct modes as you combine the two classes, so we don't have input fields suddenly behaving more like text editors. I wonder then what the benefit is of combining them? I would think some refactoring would suffice to better facilitate the un/re-do stack by simplifying the code and more clearly delineating the differences.

Dave Stevenson
[hidden email]

---

From: Travis Griggs <[hidden email]>
To: vwnc NC <[hidden email]>
Sent: Wed, April 20, 2011 12:46:21 AM
Subject: [vwnc] Folding ParagraphEditor and TextEditorController

In the original ObjectWorks Smalltalk (maybe in ST-80 itself?), we had the ParagraphEditor object. When ParcPlace implemented the VisualWorks layer, at some point, a subclass of ParagraphEditor was introduced: TextEditorController. The archeology behind the two would seem to indicate that TEC was meant as a "version 2" of PE, one that had more bells and whistles, as well as some optimizations. And then, they were both left in the system. In fact, while PE is the defaultControllerClass of plain ComposedTextView, most cases where the tools create CTV's, it replaces the default PE with the higher powered TEC subclass.

There's some long overdue maintenance on these classes. For one thing, I'd like to (_f_i_n_a_l_l_y_) have a real undo/redo stack. The problem is that there are lots of large (subclass) overrides, with differences, that honestly are not often understood anymore. And there's lots of coupling between the two classes. This makes figuring out how to integrate an undo/redo stack, or other features such as better notifications, difficult to implement, and a pain to maintain.

I'd like to fold the two classes together.

To do so with the least amount of work for those of you downstream, I'd like to gather some data up front about which of these two you (the users and developers) have messed with more, and how. Do you subclass PE? Do you subclass TEC? Have you add extension methods to PE? or TEC? Are they more on the one than the other? And of course, what about overrides (as in method patches)?

TIA

--
Travis Griggs
Objologist
My Other Machine runs OSX. But then... so does this one.




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc