>> The existing (rich) TextArea class can certainly be used for this purpose, >> but it currently has a lot of baggage since it supports editing. A pure >> "text pane" wouldn't need such support, so it would significantly simplify >> the codebase if we were to eliminate it. > > Perhaps I am misunderstanding something (or very possibly confusing the > names of existing & future/proposed components), but it seems a little odd > to describe the editing capabilities of a component designed for editing to > be 'baggage'.
It was originally designed for editing, but the implementation is quite complex. This complexity is the main reason I created the new plain TextArea component, which is designed specifically to be easier to understand and maintain. > The 'TextPane' could then subclass or delegate to the non-editable version. In what I am proposing, TextPane would be the non-editable version (and also possibly the editable version - see below). >> I think there may be a lot more long-term value in a "TextPane" class than a >> "RichTextArea" component. It would also be a lot easier to maintain (which >> is a very valid concern in a volunteer-driven effort like Pivot). >> > > I only took a cursory look at Noel's rich text demo when he committed it, > but it seemed to be working OK. Assuming the component is functional, I > don't see that it would require any unusual level of maintenance. I noticed a few bugs, though Noel may be planning to work these out before we release 2.0. Also, we'd ideally want to include a RichTextToolbar component along with RichTextArea, since most developers will want to use the two together. > We can > always document any limitations it might have, and describe it as a > relatively new and lightly tested component if required. Yes, we can do this. But I am genuinely concerned about the stability and maintenance of RichTextArea - not because the work that Noel has done recently, but because I think the original design (which I am responsible for) is too heavy. The current editing features are based heavily on the concept of paragraph separators. This is required in a plain text editor, but may bot be strictly necessary for rich text editing. It just adds overhead and complexity (i.e. "baggage"). I'd like to eliminate this baggage and keep the good parts (the layout). Later, we can then think about how editing might best be implemented in a rich text editor, not a rich text editor that is trying to do double-duty as a plain text editor as well. I'd be much more comfortable renaming this component TextPane and positioning it as a layout container for Pivot 2.0. That would allow us to pull out all editing related features, including node offset and range maintenance, keyboard handling, etc. It will really thin out the component, and we can focus on making it stable. I suspect that once we have done that, we may see an easier way to re-integrate the editing capabilities. I think this represents a better long-term strategy since it allows us to release a stable and very useful component in a shorter timeframe, and then build on it later (add editing, add rich text toolbar, etc.). This approach is consistent with agile development concepts, which seem to work well on OSS projects. It is also why I think the name "TextPane" works well. It makes sense for a non-editable initial version but also works when/if we revisit editing (as does "TextPaneToolbar"). G
