Pivot
  1. Pivot
  2. PIVOT-31

Add rich text support to TextPane (formerly TextArea)

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: wtk
    • Labels:
      None
    1. patch.txt
      23 kB
      Noel Grandin
    2. patch.txt
      11 kB
      Noel Grandin

      Issue Links

        Activity

        Hide
        Noel Grandin added a comment -

        What would constitute a good beginning for rich-text support?
        i.e.what features would be the minimum set that would be useful?

        I'm asking because i'm looking through the text code, and it doesn't look hard to add some basic stuff like different fonts and background/foreground colors.

        Obviously tables, etc. are a whole different ball of wax, but I think we could deliver something reasonably useful without much effort, given how good the existing TextArea infra-structure is.

        Show
        Noel Grandin added a comment - What would constitute a good beginning for rich-text support? i.e.what features would be the minimum set that would be useful? I'm asking because i'm looking through the text code, and it doesn't look hard to add some basic stuff like different fonts and background/foreground colors. Obviously tables, etc. are a whole different ball of wax, but I think we could deliver something reasonably useful without much effort, given how good the existing TextArea infra-structure is.
        Hide
        Noel Grandin added a comment -

        Proof-of-concept patch.

        Implemented the most simple thing I could think of - adding a Font property to the Element class.

        Seems to work OK.

        Show
        Noel Grandin added a comment - Proof-of-concept patch. Implemented the most simple thing I could think of - adding a Font property to the Element class. Seems to work OK.
        Hide
        Greg Brown added a comment -

        Hey Noel,
        The Element class, etc. are deprecated for Pivot 1.5 and will be removed in 1.5.1 (see PIVOT-457). Obviously we won't throw the code away, since it will still be in SVN - maybe we can consider re-introducing it at a later time, when we have more time to test/maintain.
        Greg

        Show
        Greg Brown added a comment - Hey Noel, The Element class, etc. are deprecated for Pivot 1.5 and will be removed in 1.5.1 (see PIVOT-457). Obviously we won't throw the code away, since it will still be in SVN - maybe we can consider re-introducing it at a later time, when we have more time to test/maintain. Greg
        Hide
        Noel Grandin added a comment -

        Thanks Greg, I have no pressing need for this functionality, just thought I'd see what would be involved in solving this issue.
        It seemed pertinent because we've had a number of requests for simple styled text on the mailing list lately, and this could resolve those requests.

        My solution would look something like this:
        (1) copy TextArea to RichTextArea
        (2) continue with making TextArea a simple, non-styled, optimised widget
        (3) add styling features gradually to RichTextArea, as they become necessary

        I'm convinced that we can hit a sweet spot of functionality with only a small amount of effort - although people keep saying they want an HTML rendering widget, or a really fancy rich-text widget, in my experience, fonts and colours alone will cover 99% of the use cases out there.

        Show
        Noel Grandin added a comment - Thanks Greg, I have no pressing need for this functionality, just thought I'd see what would be involved in solving this issue. It seemed pertinent because we've had a number of requests for simple styled text on the mailing list lately, and this could resolve those requests. My solution would look something like this: (1) copy TextArea to RichTextArea (2) continue with making TextArea a simple, non-styled, optimised widget (3) add styling features gradually to RichTextArea, as they become necessary I'm convinced that we can hit a sweet spot of functionality with only a small amount of effort - although people keep saying they want an HTML rendering widget, or a really fancy rich-text widget, in my experience, fonts and colours alone will cover 99% of the use cases out there.
        Hide
        Greg Brown added a comment - - edited

        I agree. When we update TextArea for 1.6, I'll rename the old version to RichTextArea. That means that we should probably un-deprecate the org.apache.pivot.wtk.text classes, since RichTextArea will need them. I will do this for Pivot 1.5 so I can also resolve PIVOT-494.

        Show
        Greg Brown added a comment - - edited I agree. When we update TextArea for 1.6, I'll rename the old version to RichTextArea. That means that we should probably un-deprecate the org.apache.pivot.wtk.text classes, since RichTextArea will need them. I will do this for Pivot 1.5 so I can also resolve PIVOT-494.
        Hide
        Noel Grandin added a comment -

        My patch now implements text fonts, foreground and background colors successfully.

        The next logical step would be to support the stuff from java.awt.font.TextAttribute like UNDERLINE, SUPERSCRIPT, etc.

        However, that would require some more drastic changes to our painting strategy i.e. we would have to either
        (a) figure out how to paint these things ourselves
        (b) delegate the painting to the java.awt.font.TextLayout class and drop our optimised font-glyph painting strategy.

        Show
        Noel Grandin added a comment - My patch now implements text fonts, foreground and background colors successfully. The next logical step would be to support the stuff from java.awt.font.TextAttribute like UNDERLINE, SUPERSCRIPT, etc. However, that would require some more drastic changes to our painting strategy i.e. we would have to either (a) figure out how to paint these things ourselves (b) delegate the painting to the java.awt.font.TextLayout class and drop our optimised font-glyph painting strategy.
        Hide
        Greg Brown added a comment -

        We used to use TextLayout, but I'd like to stay away from it now if possible. LabelSkin currently handles underlined text without TextLayout - we could probably do something similar here. Could possibly punt on sub/superscript for now.

        It might be interesting to attempt to add a ComponentNode class next. That would facilitate the kind of layout discussed in this thread:

        http://mail-archives.apache.org/mod_mbox/pivot-user/201005.mbox/%3c916368.75600.qm@web25404.mail.ukl.yahoo.com%3e

        We'll have to make TextArea extend Container (and TextAreaSkin extend ContainerSkin) for this to work, but it is certainly doable. In fact, there used to be a TODO in TextAreaSkin about this, but it looks like it was removed at some point.

        Show
        Greg Brown added a comment - We used to use TextLayout, but I'd like to stay away from it now if possible. LabelSkin currently handles underlined text without TextLayout - we could probably do something similar here. Could possibly punt on sub/superscript for now. It might be interesting to attempt to add a ComponentNode class next. That would facilitate the kind of layout discussed in this thread: http://mail-archives.apache.org/mod_mbox/pivot-user/201005.mbox/%3c916368.75600.qm@web25404.mail.ukl.yahoo.com%3e We'll have to make TextArea extend Container (and TextAreaSkin extend ContainerSkin) for this to work, but it is certainly doable. In fact, there used to be a TODO in TextAreaSkin about this, but it looks like it was removed at some point.
        Hide
        Greg Brown added a comment -

        One other thought - if you don't mind, I'd like to hold off on applying this patch until after 1.5 is released. Then we can make improving text support a major focus for Pivot 1.6. Sound OK?

        Show
        Greg Brown added a comment - One other thought - if you don't mind, I'd like to hold off on applying this patch until after 1.5 is released. Then we can make improving text support a major focus for Pivot 1.6. Sound OK?
        Hide
        Noel Grandin added a comment -

        Greg, that's fine by me.

        WRT the ComponentNode use-case you mentioned, that sounds potentially very useful, but it brings some interesting problems

        Problem 1
        --------------
        It means that the Document model is no longer share-able between multiple TextArea instances, because the Component will need to get inserted into the TextArea's containment hierarchy.

        I don't see it as a real problem, it's just something that will need to get noted in the docs and checked for (with nice exceptions) in the code.

        Problem 2
        --------------
        Keyboard/mouse/focus interaction is going to be "interesting" with editable documents and live components, and will likely lead to some surprising results when people stick Components into their documents.

        I'm inclined to say that we should enforce that we only support live components in documents in non-editable TextArea's.

        Show
        Noel Grandin added a comment - Greg, that's fine by me. WRT the ComponentNode use-case you mentioned, that sounds potentially very useful, but it brings some interesting problems Problem 1 -------------- It means that the Document model is no longer share-able between multiple TextArea instances, because the Component will need to get inserted into the TextArea's containment hierarchy. I don't see it as a real problem, it's just something that will need to get noted in the docs and checked for (with nice exceptions) in the code. Problem 2 -------------- Keyboard/mouse/focus interaction is going to be "interesting" with editable documents and live components, and will likely lead to some surprising results when people stick Components into their documents. I'm inclined to say that we should enforce that we only support live components in documents in non-editable TextArea's.
        Hide
        Greg Brown added a comment -

        Good points. I hadn't considered the document sharing issue, but I think it is OK as long as we address it with exceptions and Javadoc, as you noted.

        I'm not sure it will be necessary to preclude the combination of editability and live components. As currently implemented, a TextArea can still receive the focus even when non-editable. This allows the user to select text using the keyboard, even though the text can't be modified. However, we could consider removing that capability, if necessary.

        I'd suggest that we see how it goes. If we run into any major issues, we can certainly disable live component support for editable text areas.

        Show
        Greg Brown added a comment - Good points. I hadn't considered the document sharing issue, but I think it is OK as long as we address it with exceptions and Javadoc, as you noted. I'm not sure it will be necessary to preclude the combination of editability and live components. As currently implemented, a TextArea can still receive the focus even when non-editable. This allows the user to select text using the keyboard, even though the text can't be modified. However, we could consider removing that capability, if necessary. I'd suggest that we see how it goes. If we run into any major issues, we can certainly disable live component support for editable text areas.
        Hide
        Greg Brown added a comment -

        This is mostly done, though the feature seems to have some minor issues and will remain experimental for v2.

        Show
        Greg Brown added a comment - This is mostly done, though the feature seems to have some minor issues and will remain experimental for v2.

          People

          • Assignee:
            Noel Grandin
            Reporter:
            Greg Brown
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development