pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: TextArea/RichTextArea
Date Fri, 10 Sep 2010 11:27:14 GMT
On 10 September 2010 08:42, Greg Brown <gkbrown@mac.com> wrote:

> 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'.

If it is baggage from the perspective of another component that wishes to
build upon the first, but doesn't need that functionality, then couldn't
there be a case for refactoring the existing component into non-editable
base class and an editable subclass?

The 'TextPane' could then subclass or delegate to the non-editable version.

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. We can
always document any limitations it might have, and describe it as a
relatively new and lightly tested component if required.

Obviously we wouldn't want to keep obsolete Components within the Pivot code
base, but even playing devil's advocate and assuming that there are issues
with the existing Component, wouldn't those issues would only affect users
who choose to use it?

> We don't necessarily need to decide right now, but I'm thinking that
> "TextPane" might be a more appropriate name for this component either way.
> It also has a bit more parity with the "org.apache.pivot.wtk.text" package,
> and the view classes, which currently live in org.apache.pivot.wtk.skin,
> could be moved to org.apache.pivot.wtk.skin.text.
> Let me know what you think.
> G
> I can't really comment on the naming until I understand what the components
there will be and their differing functionalities.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message