RichTextArea: API Review

Wed Aug 14 14:45:16 UTC 2024

>
> - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for
> commercial projects
>

Didn't know. That's a good point.

> - RichTextFX depends on several long-unmaintained libraries, namely
> ReactFX.
>

ReactFX is mostly finished. I have been using it for years, there are only
a few bugs there that I have hit. Some of the features there were even
imported to JavaFX. Otherwise, I don't know about the 3rd party libraries
situation there.

having a basic rich text control with reasonable extension points would
> already be a significant improvement.
>

Having a lot of things in JavaFX will be a significant improvement. The
question we're discussing is, is this worth the time compared to other
things that could have a bigger impact. The developer resources are very
limited. As someone who doesn't need this level of rich text support, I
would personally like to see time invested elsewhere, but as a maintainer I
acknowledge that others do want this, so I don't mind supporting it. Tray
icon support is one of the most requested features (which I also don't
require personally), maybe that's a better time investment, I don't know.

On Wed, Aug 14, 2024 at 4:35 PM quizynox <quizynox at gmail.com> wrote:

> Hello,
>
> As also mentioned in the proposal, there are already 3rd party RTAs -
> RichTextFX and Gluon's. Does the proposed RTA offer more than these
> (besides the ease of use by being in JavaFX)? Do the building blocks of
> these offer advantages that the proposed building blocks don't? An abstract
> test that can be done is to see if these controls can be "retrofitted" with
> the proposed new building blocks (no need to actually rewrite the code). If
> not, it could hint to an incompatibility or a limit of the proposal that
> makes it less appealing.
>
> - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for
> commercial projects (even internal non-profit projects). It can't be an
> alternative, because of this alone.
> - RichTextFX depends on several long-unmaintained libraries, namely
> ReactFX. There is nothing that can be done from the OpenJFX side, as it
> would require rewriting RichTextFX from scratch.
>
> I don't think anyone expects OpenJFX to provide something as complex as
> CodeMirror. However, having a basic rich text control with reasonable
> extension points would already be a significant improvement.
> On 14/08/2024 16.03, Nir Lisker wrote:
>
> My questions are similar to the ones in the previous discussion, but now I
> can be more specific.
>
> I see a list of "building blocks" in
> https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically,
> two types of building blocks additions are important as I see it: rich
> text-specific ones like document models and a way to add decorations/colors
> etc., and the split of controls in general into skin/input/behavior (on
> which there has been a long discussion). My questions are:
>
> 1. If these are provided to the user, how difficult is it for them to
> compose a RTA? JavaFX doesn't provide some somewhat-common controls that
> you see in various other libraries with the reasoning that the library
> should give the user the ability to create their own controls (which is not
> so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
> 2. Can these building blocks be used to enhance existing controls? For
> example, to help with TextArea's performance with long texts, or allow rich
> text-like features in other controls, like the squiggly red line under the
> text in a TextField?
> 3. As also mentioned in the proposal, there are already 3rd party RTAs -
> RichTextFX and Gluon's. Does the proposed RTA offer more than these
> (besides the ease of use by being in JavaFX)? Do the building blocks of
> these offer advantages that the proposed building blocks don't? An abstract
> test that can be done is to see if these controls can be "retrofitted" with
> the proposed new building blocks (no need to actually rewrite the code). If
> not, it could hint to an incompatibility or a limit of the proposal that
> makes it less appealing.
>
> Thanks,
> Nir
>
>
> On Fri, Aug 2, 2024 at 10:41 PM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
>> Dear fellow developers:
>>
>>
>>
>> Thank you for the early feedback on the RichTextArea proposal [0].
>>
>>
>>
>> We are moving to the next phase by submitting the public pull request [1].
>> The main goal is to include the new control in an incubating module [8],
>> hopefully in jfx24, as a means of putting non-final API in the hands of
>> developers while the API and implementation progress towards either
>> finalization or removal in a future release.
>>
>>
>>
>> For your convenience, two test applications are provided -
>> *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new
>> controls with a number of different models.  In addition to these two
>> testers, please check out a simple standalone rich text editor application,
>> *RichEditorDemoApp*,
>>
>>
>>
>> We would encourage anyone - the javafx developers, and especially the
>> application developers, to take a look at the public API [3].  It's
>> probably less important at this stage to do a deep code review of the
>> implementation, but we would certainly appreciate and welcome your code
>> review comments.
>>
>>
>>
>> Thank you in advance,
>>
>> -andy
>>
>>
>>
>>
>>
>> [0] Proposal:
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>>
>> [1] Pull request: https://github.com/openjdk/jfx/pull/1524
>>
>> [2] Discussion points:
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>>
>> [3] API specification (javadoc):
>> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>>
>> [4] CSS Reference:
>> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>>
>> [5] Behavior doc:
>> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>>
>> [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>>
>> [7] Previous (now obsolete) draft pull request:
>> https://github.com/openjdk/jfx/pull/1374
>>
>> [8] Incubator module JEP:
>> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/547c96f8/attachment.htm>