> Do you have time to quickly summarize what text based components &
> containers you envision for Pivot 2.0?
Pivot 2.0 will include the same set of text components as earlier releases:
Label (read-only, optionally wrapping, unstyled label)
TextInput (single-line unstyled text field)
TextArea (mu
Greg,
Do you have time to quickly summarize what text based components &
containers you envision for Pivot 2.0?
Names are not so important here, I am just trying to understand the features
that would be available.
I suppose the most important points are whether they would be editable or
not, comp
> I think it depends on a few factors such as the actual code complexity
As I mentioned earlier, the code is simply more complex than it needs to be at
the moment. Removing what I would consider to be non-essential code from the
existing rich TextArea component and related DOM classes will strea
n
the full editing version in the pivot library.
-Original Message-
From: Greg Brown [mailto:gkbr...@mac.com]
Sent: Thursday, September 09, 2010 10:10 PM
To: Pivot Dev
Cc: Pivot User
Subject: Re: TextArea/RichTextArea
By the way, this suggestion doesn't invalidate any of the (exten
> 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
>> rece
Just a little more background on this - to me, it is as much a question about
process as it is about design. Like most open-source projects, Pivot is a
volunteer-driven effort with limited resources. In order to be successful, we
need to map our development process to these constraints. That's o
Greg Brown wrote:
> 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.
What specific bugs did you find?
I actually like TextPane:
1) As I mentioned in the other email, it doesn't imply editability but can also
support it in the future.
2) The "Pane" suffix makes it clear that it is a container and therefore used
for layout.
3) Since its primary purpose would be to support text-like layouts (wher
>> 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 misund
On 10 September 2010 08:42, Greg Brown 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
Obviously, I'm a little biased, because I did the rich text area work :-), but
I think there is a lot of value in
continuing to support the current rich text editor component.
However, I really like what you are proposing. It sounds a lot like the Eclipse
Forms project,
http://www.eclipse.org/a
By the way, this suggestion doesn't invalidate any of the (extensive) work that
Noel has done recently with TextArea. In fact, it wouldn't be possible without
it. I'm just wondering if a supporting read-only text pane might be a better
long-term strategy than supporting rich text authoring...
Hi all,
I'm about ready to check in final support for the new TextArea. There are still
a few bugs to work out, but it is mostly functional.
I'd like to raise the question again of what to call the new "rich text area".
I'm still pretty excited about the concept of a "TextPane" component - this
13 matches
Mail list logo
