Aw: Proposal: RichTextArea Control (Incubator)

[Marius Hanl]

After reading everything on this thread, I can understand all sides.

 

I think that a general RichTextArea control inside JavaFX is a nice addition and it somewhat makes sense to me as well.

 

But I also understand the other points, I agree that there is still a lot of work needed to improve and open JavaFX for 3rd Party Developers.

If I can decide where the most time would go in, I would also rather decide to fix existing problems, improve documentation and allow developers to better customize the Controls as needed.


Since there was already a significant amount of work spend to develop a first RichTextArea draft, we should probably continue with it and see what API makes sense and take care that it is as extensible as we think it should be.

 

-- Marius

 

 

 

Gesendet: Mittwoch, 21. Februar 2024 um 19:07 Uhr
Von: "Andy Goryachev" 
An: "openjfx-dev@openjdk.org" 
Betreff: Proposal: RichTextArea Control (Incubator)




Dear JavaFX developers:

 

We would like to propose a new feature - rich text control, RichTextArea, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane.  The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.

 

This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review.  We are, therefore, introducing this in an incubating module, javafx.incubator.richtext.   This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.

 

Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community.  We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3].  For context, the links to the original RFE [4] and a list of missing APIs related to rich text [5] are provided below.

 

Sincerely,

Your friendly JavaFX development team.

 

 

References

 

 

[0] Proposal:  https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md

[1] Discussion points:  https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md

[2] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc

[3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1374

[4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[5] Missing APIs related to rich text control: https://bugs.openjdk.org/browse/JDK-8300569

 

Re: Proposal: RichTextArea Control (Incubator)

[Kevin Rushforth]

All,

Thank you to everyone who has provided feedback on the RichText proposal 
so far. If I could characterize the response, there are some developers 
who want at least a basic rich text control available as part of the 
JavaFX core and other developers who don't think that such a control 
should be in the JavaFX core at all.


This doesn't really come as a surprise to me, since rich text is a 
complex feature, and we really don't have enough feedback to know how 
much of it -- if any -- belongs in the core of JavaFX, and if it does, 
what form the eventual API should take.


I happen to think there is value in providing at least a basic rich text 
control. One of the main reasons for proposing this as an incubating 
feature in a separate, incubator module, is that we don't know whether 
and how application developers will want to use this, and whether this 
proposal hits the sweet spot of a sufficiently full-featured control 
without being too complex, especially in terms of API surface which is 
something I am concerned about.


As an incubating feature, we have the ability to modify the API and 
implementation in incompatible ways in response to feedback, or to drop 
it from the core entirely, perhaps making it available some other way. 
Shipping this in an incubator module is a good way to get that feedback. 
That doesn't mean that it can go in before it is ready. Even as an 
incubator, this will require a fairly long review process; incubator 
modules are not a way to deliver features in early stages of development 
nor "experimental" features.


If this goes in as an incubating feature in some future release of 
JavaFX, subsequent releases will do one of three things: 1) evolve the 
API in response to feedback; 2) finalize the API; 3) drop the API. As an 
aside, I hope that the updated incubator JEP makes this a little more clear.


I'm sure Andy will welcome additional feedback, especially on the 
concepts and on the API. I haven't done a complete review of the API 
myself, and there are areas I am concerned about, but that's what the 
review process will discuss.


-- Kevin


On 2/21/2024 10:07 AM, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose a new feature - rich text control, 
RichTextArea, intended to bridge the functional gap with Swing and its 
StyledEditorKit/JEditorPane.  The main design goal is to provide a 
control that is complete enough to be useful out-of-the box, as well 
as open to extension by the application developers.


This is a complex feature with a large API surface that would be 
nearly impossible to get right the first time, even after an extensive 
review.  We are, therefore, introducing this in an incubating module, 
*javafx.incubator.richtext*.   This will allow us to evolve the API in 
future releases without the strict compatibility constraints that 
other JavaFX modules have.


Please take a look at the proposal [0], a list of discussion points 
[1], and the API Specification (javadoc) [2]. While the proposed API 
is ready for review, it isn't complete nor set in stone. We are 
looking for feedback, and will update the proposal based on the 
suggestions we receive from the community.  We encourage you to 
comment either in the mailing list, or by leaving comments inline in a 
draft pull request [3].  For context, the links to the original RFE 
[4] and a list of missing APIs related to rich text [5] are provided 
below.


Sincerely,

Your friendly JavaFX development team.

References

[0] Proposal: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md


[1] Discussion points: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md


[2] API specification (javadoc): 
https://cr.openjdk.org/~angorya/RichTextArea/javadoc


[3] Draft Pull Request for API comments and feedback: 
https://github.com/openjdk/jfx/pull/1374


[4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[5] Missing APIs related to rich text control: 
https://bugs.openjdk.org/browse/JDK-8300569

Re: Proposal: RichTextArea Control (Incubator)

[Robert Lichtenberger]

Having read the interesting posts following this announcement, let me 
add a few points from my perspective:


I understand and agree we Johan Vos that there are a lot of open issues 
in JBS that should be addressed.


At the same time I would very much appreciate if a RichTextArea were 
implemented in core JavaFX as opposed to a library.


Having good controls implemented within JavaFX makes it more attractive 
to application developers. To that end I don't think it good to develop 
all kinds of controls outside of JavaFX.


The current TextArea makes us laughing stock: If you load any kind of 
medium-sized text in it, you're application will stop to work, because 
there are too many elements in the scene graph.


We're currently using RichTextFX in our application and it gives us some 
headaches (Can't wrap my head around the API, graphic errors under 
Windows, etc.).


I haven't known about Gluon's RichTextArea before. May well be giving it 
a try (but will have to check if commercial licensing is viable for us).


I have some editor building background myself: About 25 years ago, I 
built the editor for a commercial IDE (SNiFF+ by TakeFive, then 
Windriver, now Intel ...), which was written in C++ with ET++. This 
editor was then ported to Java / Swing (called RED Editor)  which was 
already open sourced.


About 6 years ago, I tried to "port" the RED Editor from Swing to JavaFX 
(https://github.com/effad/rtefx). The attempt failed for two reasons: I 
did not have the time to do it properly (Implementing a rich text 
control is a lot of work) and JavaFX was just too closed at that time.



Robert

Re: Proposal: RichTextArea Control (Incubator)

[Nir Lisker]

Hi all,

I don't use RT controls, so I can't comment about the specifics of this or
other implementations. However, people raised some good points that I would
like to be more specific about.

1. Can the "components" of the RTA be separated out so that other controls
can use them? For example, colored text segments and highlights can be
useful in any text control, like Label and TextField.
2. About creating new controls and the difficulty involved, aren't the long
discussions about splitting the behavior, skin, input etc. and John's
proposal in that regard addressing exactly that, giving the ability to
compose "facets" into controls?
3. It's obvious that the bar for what goes into a library (JavaFX, JDK and
all other GUI toolkits) is fluid. We don't *have* to provide a Button
because any 3rd party library can make one, but we all agree that it's a
good idea. More complex controls, like color picker and date picker could
be more controversial as they are not entirely standardized, but I think
it's OK to have them. The question is, how far does this go? Perhaps what
can help here is to look at various GUI toolkits and see what they provide
so we know what users expect. It also matters if they are intended for use
on mobile, in which case the set of controls is somewhat different.

- Nir

On Wed, Feb 21, 2024 at 8:07 PM Andy Goryachev 
wrote:

> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
>
> [1] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [2] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [3] Draft Pull Request for API comments and feedback:
> https://github.com/openjdk/jfx/pull/1374
>
> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [5] Missing APIs related to rich text control:
> https://bugs.openjdk.org/browse/JDK-8300569
>
>
>

Re: Proposal: RichTextArea Control (Incubator)

[Thiago Milczarek Sayão]

This is a good point, Martin.

I would expect the JavaFX RTA to be basic, but extendable - to allow
companies to offer commercial options for particular needs based on it. I
don't see a single RTA component that would be useful for every need.

Use case examples (that I could think of):
- An IDE code editor;
- A text message writer/viewer that would have emoticons, gifs;
- Maybe a collaborative app where multiple users write;

-- Thiago

Em sex., 23 de fev. de 2024 às 10:31, Martin Desruisseaux <
martin.desruisse...@geomatys.com> escreveu:

> Le 2024-02-23 à 13 h 34, Johan Vos a écrit :
>
> That is not to say that we should not do anything. On the contrary, I'd
> love it if we could do more. But in the right place. Stability and basic
> features inside OpenJFX, experiments and libraries in the ecosystem.
>
> JavaFX could have a "basic" Rich Text Area (RTA) for common needs such as
> syntax coloration, underlining errors, etc., and external projects such as
> Gluon could have more sophisticated controls for more advanced needs. I
> would appreciate a lot to have a Rich Text Area included in JavaFX for
> "basic" needs, because it would avoid adding another dependency. I'm always
> very reluctant to do the latter, because few projects are economical in
> their own dependencies. Many projects bring ton of dependencies, often
> outdated, often conflicting with other projects bringing different versions
> of the same dependencies.
>
> So I do not see a JavaFX RTA and a Gluon RTA as mutually exclusive. I
> would use the JavaFX one for e.g., syntax coloration, and if I need
> something more advanced I would look at the alternatives. This is the same
> situation as other controls such as DatePicker or ColorPicker: they are
> sufficient for "basic" needs, more elaborated alternatives may exist in
> other projects.
>
> Martin
>
>
>

Re: Proposal: RichTextArea Control (Incubator)

[Martin Desruisseaux]

Le 2024-02-23 à 13 h 34, Johan Vos a écrit :

That is not to say that we should not do anything. On the contrary, 
I'd love it if we could do more. But in the right place. Stability and 
basic features inside OpenJFX, experiments and libraries in the ecosystem.


JavaFX could have a "basic" Rich Text Area (RTA) for common needs such 
as syntax coloration, underlining errors, etc., and external projects 
such as Gluon could have more sophisticated controls for more advanced 
needs. I would appreciate a lot to have a Rich Text Area included in 
JavaFX for "basic" needs, because it would avoid adding another 
dependency. I'm always very reluctant to do the latter, because few 
projects are economical in their own dependencies. Many projects bring 
ton of dependencies, often outdated, often conflicting with other 
projects bringing different versions of the same dependencies.


So I do not see a JavaFX RTA and a Gluon RTA as mutually exclusive. I 
would use the JavaFX one for e.g., syntax coloration, and if I need 
something more advanced I would look at the alternatives. This is the 
same situation as other controls such as DatePicker or ColorPicker: they 
are sufficient for "basic" needs, more elaborated alternatives may exist 
in other projects.


    Martin

Re: Proposal: RichTextArea Control (Incubator)

[Pedro Duque Vieira]

Hi,

I agree with what others are saying that perhaps creating and adding this
control is not a priority now for the JavaFX team.
In an ideal world where the JavaFX team had more resources to implement
things (like the team JavaFX had at the time of JavaFX 8 and before), this
would make sense. Given the limited resources, IMHO time would be perhaps
better spent elsewhere, adding much needed features to the core of JavaFX.
Things that can only be implemented by the developers working on the SDK.
Given this is a control that can be implemented by library developers and
given there are already third parties that provide this I don't think
creating this should be a priority.

Providing more hooks for developers to extend javafx functionality (to
counteract the fact that JavaFX is so closed up for extension),
implementing missing features in the JavaFX SDK, perhaps even things that
would make it easier for library developers to implement a RichTextArea,
would IMHO be more of a priority.

My 2 cents,

Thanks, kind regards,


-- 
Pedro Duque Vieira - https://www.pixelduke.com


Sem
vírus.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Proposal: RichTextArea Control (Incubator)

[Johan Vos]

Hi,

Interesting remarks.

> Hello,
>
> >> A 3rd party control, RichTextFX already exists -- what is this new
> proposal adding that RichTextFX does not have?
>
> It uses the standard JavaFX VirtualFlow API and and does not need to work
> with reactive streams. RichtextFX depends on several long unmaintained
> libs: ReactFX (last commit 8 years ago), WellBehavedFX (last commit 6 years
> ago), UndoFX (last commit 3 years ago). To say it's actively maintained is
> a big exaggeration.
>

What do you think about our Rich Text Area project?
https://github.com/gluonhq/rich-text-area
I hear your concerns about depending on unmaintained libs, and it is one of
my own primary filter criteria to either use or not use software

>> What (if anything) is stopping a 3rd party from building a RichTextArea
> themselves?
>
> - The lack of a standard API. The Behavior API has been discussed for
> ages, but is still not implemented. Moreover, WellBehavedFX is literally a
> rejected JEP/CSR implementation.
>
I agree a standard behavior API would be helpful, but I don't think it is
needed for a third party control. I rather hope to see more third party
controls being developed using different approaches, so that the community
in general gets more experience with the different approaches, as that
would give useful feedback on an approach to standardize it in OpenJFX. You
know how it goes with projects in OpenJDK: once something is in, it has to
be maintained and supported for a very long time and it is really hard to
change it.


> - The closedness of JavaFX in general. All internals are explicitly
> private and final. A few simple examples. The date picker popup uses a
> private API to calculate its width based on text size, but you're forbidden
> to do the same thing. All i18n resources are not exported, you're forbidden
> to use them to create a context menu. You're not encouraging 3rd party
> libs, you're going in the opposite direction (for the sake of stability of
> course).
>
Valid point. And it should be addressed. I wasn't part of the discussions
where the decision was to close as much as possible, but I believe the idea
was to close almost everything, and then to open API's when needed, after
it was clear that opening the API would benefit the ecosystem without
giving up stability. This happened a number of times in the past years, but
I agree there is still much room for improvements.


> - The JavaFX community is very small. The "tens of thousands of
> developers" you talk about don't exist. Even famous projects are poorly
> maintained or not maintained at all, including ControlsFX and ScenicView.
> You have fewer features -> you have fewer users/market share -> you have
> less promotion -> you have fewer committers -> you have fewer features.
> It's that simple.
>
I think this is partly true, but it's more nuanced I believe. I am aware of
a number of real large JavaFX projects, with many developers working on
them. Most of these large projects are developed after closed walls, with
lots of duplicated code that could go in a library. For the ecosystem as a
whole, that's not good. It would be much better if we were in a situation
where individual developers or companies would create and maintain
libraries that would then be used in those big projects. For non-technical
reasons, this is unfortunately not the case.


> - There's literally no docs about creating new controls. Even Skin API is
> badly documented. You can only learn from existing control libs.
>
This is a very valid concern. And I believe it is more important for us
(openjfx-dev) to fix this, rather than do everything ourselves in the
OpenJFX core. We need to encourage developers to create new controls, and
provide more documentation, tutorials etc,... In the early days of JavaFX,
there was a big team (it would now be called devrel I guess) that was
working on this, helping developers and the ecosystem, but we know what
happened next. That gap is not yet filled, and this is the price we are
still paying for it.


> This particular feature would be a HUGE step forward. I'm really glad to
> see it. Hopefully it won't get buried under a bunch of pointless abstract
> discussions like the CSS theme CSR. Just get some feedback and implement it
> the way you want. It's a million times better than doing nothing.
>
Well, it's not that we're doing nothing. We are doing a number of things:

1. inside openjfx: keep it working. This should not be underestimated. With
the fast and not always logical changes in platforms/OS code, there is lots
of code under the hood that needs to be maintained and improved. A number
of people on this list are extremely active on this, and spending lots of
time on it. Unfortunately, this doesn't make headlines as the result of the
hard work is often that "existing things keep working". Apart from keeping
it working, I feel we are moving forward and making gradual progress. Over
the past year, I saw more people contributing to OpenJFX and 

Re: Proposal: RichTextArea Control (Incubator)

[mkpaz]

Hello,

>> A 3rd party control, RichTextFX already exists -- what is this new 
proposal adding that RichTextFX does not have?


It uses the standard JavaFX VirtualFlow API and and does not need to 
work with reactive streams. RichtextFX depends on several long 
unmaintained libs: ReactFX (last commit 8 years ago), WellBehavedFX 
(last commit 6 years ago), UndoFX (last commit 3 years ago). To say it's 
actively maintained is a big exaggeration.


>> What (if anything) is stopping a 3rd party from building a 
RichTextArea themselves?


- The lack of a standard API. The Behavior API has been discussed for 
ages, but is still not implemented. Moreover, WellBehavedFX is literally 
a rejected JEP/CSR implementation.
- The closedness of JavaFX in general. All internals are explicitly 
private and final. A few simple examples. The date picker popup uses a 
private API to calculate its width based on text size, but you're 
forbidden to do the same thing. All i18n resources are not exported, 
you're forbidden to use them to create a context menu. You're not 
encouraging 3rd party libs, you're going in the opposite direction (for 
the sake of stability of course).
- The JavaFX community is very small. The "tens of thousands of 
developers" you talk about don't exist. Even famous projects are poorly 
maintained or not maintained at all, including ControlsFX and 
ScenicView. You have fewer features -> you have fewer users/market share 
-> you have less promotion -> you have fewer committers -> you have 
fewer features. It's that simple.
- There's literally no docs about creating new controls. Even Skin API 
is badly documented. You can only learn from existing control libs.


This particular feature would be a HUGE step forward. I'm really glad to 
see it. Hopefully it won't get buried under a bunch of pointless 
abstract discussions like the CSS theme CSR. Just get some feedback and 
implement it the way you want. It's a million times better than doing 
nothing.


On 23/02/2024 14.45, Johan Vos wrote:

I fully agree with John on this.

A RichTextArea is something that can "easily" be developed outside 
OpenJFX .
There are a number of examples already, e.g. RichTextFX, and our 
(Gluon) RichTextArea at

https://github.com/gluonhq/rich-text-area

In the past, we clearly said that this was not a focus for OpenJFX.

There are a huge amount of outstanding issues in JBS that can only be 
fixed in the OpenJFX "core". Developers (of custom 
components/controls) rely on the core OpenJFX development to address 
those issues. That is what this group (the openjfx-dev list) is 
supposed to do.


I highly encourage developers to create custom components and 
controls, but not as part of OpenJFX. As others noted as well, we have 
many other things to fix that can only be fixed in OpenJFX, and that 
is where the priorities of OpenJFX should be, imho.


- Johan

On Fri, Feb 23, 2024 at 2:48 AM John Hendrikx 
 wrote:


Hi,

Far be it from me to tell the FX team what it should do, I am
still wondering the following:

- A 3rd party control, RichTextFX already exists -- what is this
new proposal adding that RichTextFX does not have?
- What (if anything) is stopping a 3rd party from building a
RichTextArea themselves?

In other words, I think the FX team ought to focus on
**facilitating** the building of complex controls like
RichTextArea, by identifying gaps in the current Control API that
is **stopping** 3rd parties from doing this themselves in the same
integrated manner as a "native" FX control.

Enabling thousands or tens of thousand of developers to build more
complicated controls seems to me like a much better investment
than what I think will be a significant investment in one of the
most complex controls imaginable.  RichTextFX was actively
developed over a 4 year period, with 45 contributors and over 1400
commits (for comparison, JavaFX had 250 commits in the past
year).  If it will be significantly less complicated, then what
does it offer over RichTextFX?

--John

On 21/02/2024 19:07, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose a new feature - rich text control,
RichTextArea, intended to bridge the functional gap with Swing
and its StyledEditorKit/JEditorPane.  The main design goal is to
provide a control that is complete enough to be useful out-of-the
box, as well as open to extension by the application developers.

This is a complex feature with a large API surface that would be
nearly impossible to get right the first time, even after an
extensive review.  We are, therefore, introducing this in an
incubating module, *javafx.incubator.richtext*. This will allow
us to evolve the API in future releases without the strict
compatibility constraints that other JavaFX modules have.

Please take a look at the proposal [0], a list of discussion
points [1], and th

Re: Proposal: RichTextArea Control (Incubator)

[Johan Vos]

On Wed, Feb 21, 2024 at 7:09 PM Andy Goryachev 
wrote:

> Dear JavaFX developers:
>
...

> Sincerely,
>
> Your friendly JavaFX development team.
>

Not sure I understand that signature. I believe everyone on this list is
part of the JavaFX development team.

Re: Proposal: RichTextArea Control (Incubator)

[Johan Vos]

I fully agree with John on this.

A RichTextArea is something that can "easily" be developed outside OpenJFX .
There are a number of examples already, e.g. RichTextFX, and our (Gluon)
RichTextArea at
https://github.com/gluonhq/rich-text-area

In the past, we clearly said that this was not a focus for OpenJFX.

There are a huge amount of outstanding issues in JBS that can only be fixed
in the OpenJFX "core". Developers (of custom components/controls) rely on
the core OpenJFX development to address those issues. That is what this
group (the openjfx-dev list) is supposed to do.

I highly encourage developers to create custom components and controls, but
not as part of OpenJFX. As others noted as well, we have many other things
to fix that can only be fixed in OpenJFX, and that is where the priorities
of OpenJFX should be, imho.

- Johan

On Fri, Feb 23, 2024 at 2:48 AM John Hendrikx 
wrote:

> Hi,
>
> Far be it from me to tell the FX team what it should do, I am still
> wondering the following:
>
> - A 3rd party control, RichTextFX already exists -- what is this new
> proposal adding that RichTextFX does not have?
> - What (if anything) is stopping a 3rd party from building a RichTextArea
> themselves?
>
> In other words, I think the FX team ought to focus on **facilitating** the
> building of complex controls like RichTextArea, by identifying gaps in the
> current Control API that is **stopping** 3rd parties from doing this
> themselves in the same integrated manner as a "native" FX control.
>
> Enabling thousands or tens of thousand of developers to build more
> complicated controls seems to me like a much better investment than what I
> think will be a significant investment in one of the most complex controls
> imaginable.  RichTextFX was actively developed over a 4 year period, with
> 45 contributors and over 1400 commits (for comparison, JavaFX had 250
> commits in the past year).  If it will be significantly less complicated,
> then what does it offer over RichTextFX?
>
> --John
> On 21/02/2024 19:07, Andy Goryachev wrote:
>
> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
>
> [1] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [2] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [3] Draft Pull Request for API comments and feedback:
> https://github.com/openjdk/jfx/pull/1374
>
> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [5] Missing APIs related to rich text control:
> https://bugs.openjdk.org/browse/JDK-8300569
>
>
>
>

Re: [External] : Re: Proposal: RichTextArea Control (Incubator)

[Daniel Peintner]

Dear Andy, others,

Thank you for your feedback. Yes, having a one-line TextArea, mocking up a
TextField, that contains a longer text with some sub-strings being able to
style is enough for my use-case.

Anyhow, I agree with others that having the possibility to "style" parts of
other controls like Label, TextField, etc would be very astonishing. This
might introduce a lot of complexity, I guess.

Having said that, this would offer a unique selling point and go beyond
what other external libraries did. Anyhow, this would most probably
facilitate such work in the future.

Best,

-- Daniel


On Thu, Feb 22, 2024 at 5:29 PM Andy Goryachev 
wrote:

> Dear Daniel:
>
>
>
> Thank you for your kind words!
>
>
>
> Re: StyledTextArea/TextField.
>
>
>
> This is a very interesting question.  It is definitely out of scope right
> now, but we can certainly talk about it.
>
>
>
> One major difference between the new control and the regular
> TextField/TextArea is that we add a separate rich text model, while
> TextField/Area expose a String 'text' property.  We could think of using
> the same model, or constructing some kind of StyledDocument, but in any
> case it won't be a drop-in replacement for TextField/TextArea.
>
>
>
> The other aspect is the visuals.  Whereas a StyledTextArea might require
> the same kinds of surrounding toolbars and controls to function as a
> useable editor (font, style, color, etc.), how would a StyledTextField look?
>
>
>
> At the same time, it is possible to easily configure RichTextArea to look
> like a styled text area or one-line styled text field.  It is also possible
> that another use case exists which requires a dedicated control?
>
>
>
>
>
> Re: spell checker.
>
>
>
> Yes, there is a way to add a "squiggly line", see here:
>
>
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md#creating-a-paragraph
>
>
>
> At this moment, this functionality is not a part of any standard model,
> but is certainly possible.
>
>
>
> It might be also possible to add a similar functionality to the regular
> TextField/TextArea using public APIs, simply by adding a "squiggly" line
> shape over the standard control.  Just a thought.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *Daniel Peintner 
> *Date: *Thursday, February 22, 2024 at 03:07
> *To: *Andy Goryachev 
> *Cc: *openjfx-dev@openjdk.org 
> *Subject: *[External] : Re: Proposal: RichTextArea Control (Incubator)
>
> Hi Andy, others,
>
>
>
> I highly appreciate and welcome the effort of a built-in RichTextArea 👍.
>
>
>
> A question that popped up in my mind is whether this work might include
> work in the area of *rich* TextField also? Probably it is out of scope.
> Anyhow, JavaFX Textfields are used in even more areas in UI controls like
> in tables etc and having the possibility to style them would be similarly
> convincing.
>
>
>
> As you might know, some alternative *external* solutions like RichTextFX
> do provide next to StyleClassedTextArea also StyleClassedTextField.
>
>
>
> Anyway, thank you very very much for the continuous development.
>
>
>
> Sincerely,
>
>
>
> -- Daniel
>
>
>
> P.S: Maybe just one line about the use case I have in mind. We do offer
> (based on RichTextFX) the ability to do "spell checking" on text (like you
> know from all word processors). A red underline shows a possible mistake
> and a ContextMenu offers fixes. This red line is therefore needed for text
> in TextArea but also for text in TextField
>
>
>
>
>
> On Wed, Feb 21, 2024 at 7:07 PM Andy Goryachev 
> wrote:
>
> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is r

Re: Proposal: RichTextArea Control (Incubator)

[Christopher Schnick]

Hey Andy and others,

from my perspective as an application developer, I would look for 
providing an abstract but robust implementation that would allow anyone 
to implement such a concrete rich text field without any roadblocks. 
Maybe even going as far as going for a more abstract implementation than 
text areas. I.e. allowing you to define any kind of data model class 
which can be flexibly represented by a set of compound nodes and 
controls and can update and reflect the model state dynamically.


I think that way you would also get a few more people on board who are 
not currently longing for a rich text area because they are either 
satisfied with the existing solutions or their applications that they 
typically work with do not use them. If such a work effort could benefit 
more areas of JavaFX than just rich text editing, people would be happy 
to jump on board.


Instead of creating a RichParagraph.Builder, why not create a more 
generic CompoundControlSegment.Builder, CompoundControl.Builder, 
CompoundControl, etc.? I.e. being able to easily add arbitrary nodes and 
controls in segments/lines, also allowing for an easy way to set style 
classes and inline styles. Being able to bind each node's contents to 
part of the data model, having some undo/redo functionality for this 
model. The StyledAttribute and StyleHandlerRegistry concept can also be 
applied to more than just text areas. And also the idea of the 
ConfigurationParameters to allow for an easy but custom handling of 
other things such as scrollbars for the resulting compound control. This 
would allow developers to use these same principles for other 
implementations as well, for example creating forms. And I can 
definitely find some use for such a concept in other places far away 
from text areas as well.


The proposed actual rich text area can then still be included as a 
concrete implementation of this absraction.


Best
Christopher Schnick

On 21/02/2024 19:07, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose a new feature - rich text control, 
RichTextArea, intended to bridge the functional gap with Swing and its 
StyledEditorKit/JEditorPane.  The main design goal is to provide a 
control that is complete enough to be useful out-of-the box, as well 
as open to extension by the application developers.


This is a complex feature with a large API surface that would be 
nearly impossible to get right the first time, even after an extensive 
review.  We are, therefore, introducing this in an incubating module, 
*javafx.incubator.richtext*.   This will allow us to evolve the API in 
future releases without the strict compatibility constraints that 
other JavaFX modules have.


Please take a look at the proposal [0], a list of discussion points 
[1], and the API Specification (javadoc) [2]. While the proposed API 
is ready for review, it isn't complete nor set in stone. We are 
looking for feedback, and will update the proposal based on the 
suggestions we receive from the community.  We encourage you to 
comment either in the mailing list, or by leaving comments inline in a 
draft pull request [3].  For context, the links to the original RFE 
[4] and a list of missing APIs related to rich text [5] are provided 
below.


Sincerely,

Your friendly JavaFX development team.

References

[0] Proposal: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md


[1] Discussion points: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md


[2] API specification (javadoc): 
https://cr.openjdk.org/~angorya/RichTextArea/javadoc


[3] Draft Pull Request for API comments and feedback: 
https://github.com/openjdk/jfx/pull/1374


[4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[5] Missing APIs related to rich text control: 
https://bugs.openjdk.org/browse/JDK-8300569

Re: Proposal: RichTextArea Control (Incubator)

[David Alayachew]

I'm speaking from ignorance, but in the same way that java 2d lets you do
image reading and writing with great tools to implement it, but it also
provides defaults for png, gif, jpeg, etc.

A good foundation to build your own is critical. But it does not obviate
the need for a useful default.

On Thu, Feb 22, 2024, 8:46 PM John Hendrikx  wrote:

> Hi,
>
> Far be it from me to tell the FX team what it should do, I am still
> wondering the following:
>
> - A 3rd party control, RichTextFX already exists -- what is this new
> proposal adding that RichTextFX does not have?
> - What (if anything) is stopping a 3rd party from building a RichTextArea
> themselves?
>
> In other words, I think the FX team ought to focus on **facilitating** the
> building of complex controls like RichTextArea, by identifying gaps in the
> current Control API that is **stopping** 3rd parties from doing this
> themselves in the same integrated manner as a "native" FX control.
>
> Enabling thousands or tens of thousand of developers to build more
> complicated controls seems to me like a much better investment than what I
> think will be a significant investment in one of the most complex controls
> imaginable.  RichTextFX was actively developed over a 4 year period, with
> 45 contributors and over 1400 commits (for comparison, JavaFX had 250
> commits in the past year).  If it will be significantly less complicated,
> then what does it offer over RichTextFX?
>
> --John
> On 21/02/2024 19:07, Andy Goryachev wrote:
>
> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
>
> [1] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [2] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [3] Draft Pull Request for API comments and feedback:
> https://github.com/openjdk/jfx/pull/1374
>
> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [5] Missing APIs related to rich text control:
> https://bugs.openjdk.org/browse/JDK-8300569
>
>
>
>

Re: Proposal: RichTextArea Control (Incubator)

[John Hendrikx]

Hi,

Far be it from me to tell the FX team what it should do, I am still 
wondering the following:


- A 3rd party control, RichTextFX already exists -- what is this new 
proposal adding that RichTextFX does not have?
- What (if anything) is stopping a 3rd party from building a 
RichTextArea themselves?


In other words, I think the FX team ought to focus on **facilitating** 
the building of complex controls like RichTextArea, by identifying gaps 
in the current Control API that is **stopping** 3rd parties from doing 
this themselves in the same integrated manner as a "native" FX control.


Enabling thousands or tens of thousand of developers to build more 
complicated controls seems to me like a much better investment than what 
I think will be a significant investment in one of the most complex 
controls imaginable.  RichTextFX was actively developed over a 4 year 
period, with 45 contributors and over 1400 commits (for comparison, 
JavaFX had 250 commits in the past year).  If it will be significantly 
less complicated, then what does it offer over RichTextFX?


--John

On 21/02/2024 19:07, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose a new feature - rich text control, 
RichTextArea, intended to bridge the functional gap with Swing and its 
StyledEditorKit/JEditorPane.  The main design goal is to provide a 
control that is complete enough to be useful out-of-the box, as well 
as open to extension by the application developers.


This is a complex feature with a large API surface that would be 
nearly impossible to get right the first time, even after an extensive 
review.  We are, therefore, introducing this in an incubating module, 
*javafx.incubator.richtext*. This will allow us to evolve the API in 
future releases without the strict compatibility constraints that 
other JavaFX modules have.


Please take a look at the proposal [0], a list of discussion points 
[1], and the API Specification (javadoc) [2]. While the proposed API 
is ready for review, it isn't complete nor set in stone. We are 
looking for feedback, and will update the proposal based on the 
suggestions we receive from the community.  We encourage you to 
comment either in the mailing list, or by leaving comments inline in a 
draft pull request [3].  For context, the links to the original RFE 
[4] and a list of missing APIs related to rich text [5] are provided 
below.


Sincerely,

Your friendly JavaFX development team.

References

[0] Proposal: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md


[1] Discussion points: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md


[2] API specification (javadoc): 
https://cr.openjdk.org/~angorya/RichTextArea/javadoc


[3] Draft Pull Request for API comments and feedback: 
https://github.com/openjdk/jfx/pull/1374


[4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[5] Missing APIs related to rich text control: 
https://bugs.openjdk.org/browse/JDK-8300569

Re: [External] : Re: Proposal: RichTextArea Control (Incubator)

[Andy Goryachev]

Dear Daniel:

Thank you for your kind words!

Re: StyledTextArea/TextField.

This is a very interesting question.  It is definitely out of scope right now, 
but we can certainly talk about it.

One major difference between the new control and the regular TextField/TextArea 
is that we add a separate rich text model, while TextField/Area expose a String 
'text' property.  We could think of using the same model, or constructing some 
kind of StyledDocument, but in any case it won't be a drop-in replacement for 
TextField/TextArea.

The other aspect is the visuals.  Whereas a StyledTextArea might require the 
same kinds of surrounding toolbars and controls to function as a useable editor 
(font, style, color, etc.), how would a StyledTextField look?

At the same time, it is possible to easily configure RichTextArea to look like 
a styled text area or one-line styled text field.  It is also possible that 
another use case exists which requires a dedicated control?


Re: spell checker.

Yes, there is a way to add a "squiggly line", see here:
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md#creating-a-paragraph

At this moment, this functionality is not a part of any standard model, but is 
certainly possible.

It might be also possible to add a similar functionality to the regular 
TextField/TextArea using public APIs, simply by adding a "squiggly" line shape 
over the standard control.  Just a thought.

What do you think?

-andy



From: Daniel Peintner 
Date: Thursday, February 22, 2024 at 03:07
To: Andy Goryachev 
Cc: openjfx-dev@openjdk.org 
Subject: [External] : Re: Proposal: RichTextArea Control (Incubator)
Hi Andy, others,

I highly appreciate and welcome the effort of a built-in RichTextArea 👍.

A question that popped up in my mind is whether this work might include work in 
the area of *rich* TextField also? Probably it is out of scope. Anyhow, JavaFX 
Textfields are used in even more areas in UI controls like in tables etc and 
having the possibility to style them would be similarly convincing.

As you might know, some alternative *external* solutions like RichTextFX do 
provide next to StyleClassedTextArea also StyleClassedTextField.

Anyway, thank you very very much for the continuous development.

Sincerely,

-- Daniel

P.S: Maybe just one line about the use case I have in mind. We do offer (based 
on RichTextFX) the ability to do "spell checking" on text (like you know from 
all word processors). A red underline shows a possible mistake and a 
ContextMenu offers fixes. This red line is therefore needed for text in 
TextArea but also for text in TextField


On Wed, Feb 21, 2024 at 7:07 PM Andy Goryachev 
mailto:andy.goryac...@oracle.com>> wrote:
Dear JavaFX developers:

We would like to propose a new feature - rich text control, RichTextArea, 
intended to bridge the functional gap with Swing and its 
StyledEditorKit/JEditorPane.  The main design goal is to provide a control that 
is complete enough to be useful out-of-the box, as well as open to extension by 
the application developers.

This is a complex feature with a large API surface that would be nearly 
impossible to get right the first time, even after an extensive review.  We 
are, therefore, introducing this in an incubating module, 
javafx.incubator.richtext.   This will allow us to evolve the API in future 
releases without the strict compatibility constraints that other JavaFX modules 
have.

Please take a look at the proposal [0], a list of discussion points [1], and 
the API Specification (javadoc) [2]. While the proposed API is ready for 
review, it isn't complete nor set in stone. We are looking for feedback, and 
will update the proposal based on the suggestions we receive from the 
community.  We encourage you to comment either in the mailing list, or by 
leaving comments inline in a draft pull request [3].  For context, the links to 
the original RFE [4] and a list of missing APIs related to rich text [5] are 
provided below.

Sincerely,
Your friendly JavaFX development team.


References


[0] Proposal: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md<https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md__;!!ACWV5N9M2RV99hQ!IlQ3CEOYq-2crYaLlWlt1Ew42B_xiNLnZcLfQ3wun2P4L_fRBJamLh4bu85KnkYW5vrsEW9AOHTpAEdsMKsAlCdn-SoW9xQ$>
[1] Discussion points: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md<https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md__;!!ACWV5N9M2RV99hQ!IlQ3CEOYq-2crYaLlWlt1Ew42B_xiNLnZcLfQ3wun2P4L_fRBJamLh4bu85KnkYW5vrsEW9AOHTpAEdsMKsAlCdn8rIp1eU$>
[2] API specification (javadoc): 
https://cr.openjdk.org/~angorya/RichTextArea/

Re: Proposal: RichTextArea Control (Incubator)

[Daniel Peintner]

Hi Andy, others,

I highly appreciate and welcome the effort of a built-in RichTextArea 👍.

A question that popped up in my mind is whether this work might include
work in the area of *rich* TextField also? Probably it is out of scope.
Anyhow, JavaFX Textfields are used in even more areas in UI controls like
in tables etc and having the possibility to style them would be similarly
convincing.

As you might know, some alternative *external* solutions like RichTextFX do
provide next to StyleClassedTextArea also StyleClassedTextField.

Anyway, thank you very very much for the continuous development.

Sincerely,

-- Daniel

P.S: Maybe just one line about the use case I have in mind. We do offer
(based on RichTextFX) the ability to do "spell checking" on text (like you
know from all word processors). A red underline shows a possible mistake
and a ContextMenu offers fixes. This red line is therefore needed for text
in TextArea but also for text in TextField


On Wed, Feb 21, 2024 at 7:07 PM Andy Goryachev 
wrote:

> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
>
> [1] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [2] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [3] Draft Pull Request for API comments and feedback:
> https://github.com/openjdk/jfx/pull/1374
>
> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [5] Missing APIs related to rich text control:
> https://bugs.openjdk.org/browse/JDK-8300569
>
>
>

Proposal: RichTextArea Control (Incubator)

[Andy Goryachev]

Dear JavaFX developers:

We would like to propose a new feature - rich text control, RichTextArea, 
intended to bridge the functional gap with Swing and its 
StyledEditorKit/JEditorPane.  The main design goal is to provide a control that 
is complete enough to be useful out-of-the box, as well as open to extension by 
the application developers.

This is a complex feature with a large API surface that would be nearly 
impossible to get right the first time, even after an extensive review.  We 
are, therefore, introducing this in an incubating module, 
javafx.incubator.richtext.   This will allow us to evolve the API in future 
releases without the strict compatibility constraints that other JavaFX modules 
have.

Please take a look at the proposal [0], a list of discussion points [1], and 
the API Specification (javadoc) [2]. While the proposed API is ready for 
review, it isn't complete nor set in stone. We are looking for feedback, and 
will update the proposal based on the suggestions we receive from the 
community.  We encourage you to comment either in the mailing list, or by 
leaving comments inline in a draft pull request [3].  For context, the links to 
the original RFE [4] and a list of missing APIs related to rich text [5] are 
provided below.

Sincerely,
Your friendly JavaFX development team.


References


[0] Proposal: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
[1] Discussion points: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
[2] API specification (javadoc): 
https://cr.openjdk.org/~angorya/RichTextArea/javadoc
[3] Draft Pull Request for API comments and feedback: 
https://github.com/openjdk/jfx/pull/1374
[4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
[5] Missing APIs related to rich text control: 
https://bugs.openjdk.org/browse/JDK-8300569