> What specific bugs did you find? As far as I know, I've worked them all out > now.
I had some trouble getting bulleted lists to work. >> 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. > Maybe you haven't seen too many other examples of editor code, but having > spent some time in the bowels of other Java > text editing components, I can safely say that your design is pretty decent > :-) I have seen some of the Swing code, and yes - I agree that this design is a bit cleaner. :-) But, having written and re-written Pivot's text components several times now, I know we can do even better. > I didn't notice that it was that heavily dependent on the concept of > paragraphs. It is currently based too heavily on carriage returns. These are necessary in plain text editing, since the delimiters are necessary to identify the paragraphs that comprise the "elements" of the "document". However, RichTextArea doesn't really need this concept since it already has a set of DOM classes. I suspect that an editing model based on an "active" or "selected" node would work better than the current "selection index/length" model (which works better for plain text editing), and would allow us to get rid of all of the character-based offset management overhead. Basically, we'd use the character model for TextArea, and the DOM model for RichTextArea/TextPane. > If you think of it as being based > around the concept of laying out rectangular pixel chunks in a left-to-right, > top-to-bottom way, then it (mentally) > works pretty well. Yes, I agree that this works well. This is one of the pieces I think we should keep. :-) G
