TextArea

[Greg Brown <gk...@mac.com>]

By the way, I finally had a chance to look at the TextArea improvements - very cool! Once the new (plain) TextArea component is done, we can refactor that one to RichTextArea.

I had one thought - feel free to take it or leave it: What if we were to rename the current (rich) TextArea to TextPane and make it read-only? In other words, define it as a container that lays out its children based on text flow vs. some other kind of layout mechanism. I suggest this because there are still some issues with editing in the current TextArea - notably, copy/paste is kinda broken, and the fix will probably be difficult. Also, undo/redo is still not implemented, nor is the RichTextToolbar component we'd need to allow the user to author rich text.

We have gotten more requests on the list for text-based layout than we have for rich text authoring, so I think it is something worth considering. Let me know what you think.

G

Re: TextArea

[Greg Brown <gk...@mac.com>]

It has been a while since I looked at those classes, but I'm pretty sure that it can be done via the existing API. We could potentially use getValue() and putValue() to store the formatted data.

On Jun 17, 2010, at 11:50 AM, Noel Grandin wrote:

> Greg Brown wrote:
>> Re: maintaining styles - I'm not terribly concerned about maintaining styles embedded in other formats such as RTF. As you noted, that would be a pretty tall order, especially cross-platform. However, if we put Pivot-formatted text on the clipboard (either instances of the text DOM classes, or XML containing a serialized form of it), pasting styles should be a non-issue. So copy/pasting formatted styles within a Pivot app would still work.
>> 
>> 
> Sounds like a good idea, but the Pivot clipboard classes don't provide
> the ability to supply the same data in more than one format.
> We'd have to extend our clipboard support to allow supplying the same
> Document in plain-text and rich-text formats.

Re: TextArea

[Noel Grandin <no...@gmail.com>]

Greg Brown wrote:
> Re: maintaining styles - I'm not terribly concerned about maintaining styles embedded in other formats such as RTF. As you noted, that would be a pretty tall order, especially cross-platform. However, if we put Pivot-formatted text on the clipboard (either instances of the text DOM classes, or XML containing a serialized form of it), pasting styles should be a non-issue. So copy/pasting formatted styles within a Pivot app would still work.
>
>   
Sounds like a good idea, but the Pivot clipboard classes don't provide
the ability to supply the same data in more than one format.
We'd have to extend our clipboard support to allow supplying the same
Document in plain-text and rich-text formats.

Re: TextArea

[Greg Brown <gk...@mac.com>]

Copy/paste in Pivot isn't terribly difficult to work with, and it is actually already enabled for TextArea, at least for plain text. The problem is that text is always pasted as a paragraph. Sometimes you want this, but sometimes you want it to be pasted as a span. I'm not sure what the logic should be for detecting this case, but now that I think about it, it may not be as difficult as I thought. Maybe we can paste it as a paragraph when it has a trailing CR, but otherwise paste it as a span.

Re: maintaining styles - I'm not terribly concerned about maintaining styles embedded in other formats such as RTF. As you noted, that would be a pretty tall order, especially cross-platform. However, if we put Pivot-formatted text on the clipboard (either instances of the text DOM classes, or XML containing a serialized form of it), pasting styles should be a non-issue. So copy/pasting formatted styles within a Pivot app would still work.

On Jun 17, 2010, at 11:06 AM, Noel Grandin wrote:

> Hi
> 
> I think it's quite a decent rich-text component already, and it would be
> a pity to dump such a nice feature set.
> It's also reasonably clean internally, so I don't see a big problem with
> fixing up remaining issues.
> 
> I'll have a look at copy and paste and see what needs to be done.
> I seem to remember that the AWT API is fairly awkward to work with, but
> the simple case (plain ascii text) should not be hard to get working.
> 
> If you're talking about the complex case (maintaining styles and
> formatting), then yes, it's sufficiently hard that even Thunderbird
> doesn't manage to get it right very often.
> Getting that right for the 90% case would require almost as much effort
> as re-writing the TextArea component, so I'm not particularly motivated
> to try it.
> It would require serialising and de-serialising to RTF format, since
> that's the lowest-common-denominator format for rich-text applications
> under Windows.
> Under linux, it would simply never work well, since there is no
> equivalent LCD format.
> 
> Undo/redo is not such a big deal in my opinion. Certainly I have never
> even seen anyone notice it's absence on the Pivot mailing list :-)
> But it's probably easier to get going than rich-copy-and-paste.
> 
> -- Noel Grandin
> 
> Greg Brown wrote:
>> By the way, I finally had a chance to look at the TextArea improvements - very cool! Once the new (plain) TextArea component is done, we can refactor that one to RichTextArea.
>> 
>> I had one thought - feel free to take it or leave it: What if we were to rename the current (rich) TextArea to TextPane and make it read-only? In other words, define it as a container that lays out its children based on text flow vs. some other kind of layout mechanism. I suggest this because there are still some issues with editing in the current TextArea - notably, copy/paste is kinda broken, and the fix will probably be difficult. Also, undo/redo is still not implemented, nor is the RichTextToolbar component we'd need to allow the user to author rich text.
>> 
>> We have gotten more requests on the list for text-based layout than we have for rich text authoring, so I think it is something worth considering. Let me know what you think.
>> 
>> G
>> 
>> 
> 

Re: TextArea

[Noel Grandin <no...@gmail.com>]

Hi

I think it's quite a decent rich-text component already, and it would be
a pity to dump such a nice feature set.
It's also reasonably clean internally, so I don't see a big problem with
fixing up remaining issues.

I'll have a look at copy and paste and see what needs to be done.
I seem to remember that the AWT API is fairly awkward to work with, but
the simple case (plain ascii text) should not be hard to get working.

If you're talking about the complex case (maintaining styles and
formatting), then yes, it's sufficiently hard that even Thunderbird
doesn't manage to get it right very often.
Getting that right for the 90% case would require almost as much effort
as re-writing the TextArea component, so I'm not particularly motivated
to try it.
It would require serialising and de-serialising to RTF format, since
that's the lowest-common-denominator format for rich-text applications
under Windows.
Under linux, it would simply never work well, since there is no
equivalent LCD format.

Undo/redo is not such a big deal in my opinion. Certainly I have never
even seen anyone notice it's absence on the Pivot mailing list :-)
But it's probably easier to get going than rich-copy-and-paste.

-- Noel Grandin

Greg Brown wrote:
> By the way, I finally had a chance to look at the TextArea improvements - very cool! Once the new (plain) TextArea component is done, we can refactor that one to RichTextArea.
>
> I had one thought - feel free to take it or leave it: What if we were to rename the current (rich) TextArea to TextPane and make it read-only? In other words, define it as a container that lays out its children based on text flow vs. some other kind of layout mechanism. I suggest this because there are still some issues with editing in the current TextArea - notably, copy/paste is kinda broken, and the fix will probably be difficult. Also, undo/redo is still not implemented, nor is the RichTextToolbar component we'd need to allow the user to author rich text.
>
> We have gotten more requests on the list for text-based layout than we have for rich text authoring, so I think it is something worth considering. Let me know what you think.
>
> G
>
>