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 <john.hendrikx at gmail.com> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240222/d46827db/attachment-0001.htm>