From andy.goryachev at oracle.com  Tue Dec  9 20:15:16 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 9 Dec 2025 20:15:16 +0000
Subject: [External] : RichTextArea styling feedback
In-Reply-To: <2EDAA17D-2E79-4374-9E12-001026CCDA5D@getmailspring.com>
References: <2EDAA17D-2E79-4374-9E12-001026CCDA5D@getmailspring.com>
Message-ID: <CY8PR10MB7265DB3E493AFBD01B80D4DFE5A3A@CY8PR10MB7265.namprd10.prod.outlook.com>

Dear Jurgen:

I explored a number of ways we could enable adding highlights/squigglies via attributes.

The main issue is that these decorations might conceivably span segments, or apply to parts of a segment, or both.  The secondary issue is that these attributes could not be considered standard (and you probably don't want us to codify colors or styles anyway).

One way to do so is described in [0] - basically expose the builder within the model.  This way the application can simply extend one or the other standard model to add app-specific attributes.  You can see an example in [1].

Would that work for you and everyone else?  What do you think?

Thank you
-andy


[0] https://github.com/openjdk/jfx/pull/1966#issuecomment-3634052681

[1] https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java



From: Jurgen Doll <jurgen at ivoryemr.co.za>
Date: Tuesday, August 26, 2025 at 08:06
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
Subject: [External] : RichTextArea styling feedback

Hi Andy

I've been looking at the RichTextArea incubator feature and am providing feedback wrt the styling aspect of it.
First off though, thank you for all the effort you have put into this so far and I'm looking forward to when this matures.

Some background: since I use the RichTextFX library in my real world application I wanted to see how easily I could refactor my application to use RichTextArea instead, and then provide you with feedback. Here I'm focusing just on a simple editor control in my application that has some basic styling options (bold, italic, underline, and text color) available for the user while the editor indicates any misspelled words as they type with a wavy underline.

I used a standard RichTextArea with its default RichTextModel and you'll be pleased to hear that without too much fuss I was able to read & write using StyledInput & StyledOutput, as well as convert the styling options part of my text editor control. However styling for spellchecking didn't go as well.

So based off my experience with trying various things I recommend the following API enhancements:


  1.
The following StyleAttributes should be added to StyleAttributeMap:  INLINE_STYLE,  STYLE_NAMES,  TEXT_HIGHLIGHT,  and  WAVY_UNDERLINE. At the moment none of these are easily or directly available, and I believe from a user perspective that they should be.
  2.
Consider splitting StyleAttributes into TextAttributes and ParagraphAttributes then INLINE_STYLE and STYLE_NAMES can appear in both. Possibly then also have a DecoratorAttribute if needed for TEXT_HIGHLIGHT and WAVY_UNDERLINE, if that'll make implementation easier but it should I believe from a user perspective still go into/through StyleAttributeMap as all styling should preferably be in one place.
  3.
The methods applyStyle and setStyle in RichTextArea should have a boolean undo parameter like replaceText.

There's also the following issue that I noticed. When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.

There are some other obervations regarding other aspects of RichTextArea that I hope to give feedback on soon as well.

Thanks again, regards
Jurgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-discuss/attachments/20251209/c1852fba/attachment.htm>

From jurgen at ivoryemr.co.za  Mon Dec 22 09:52:15 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Mon, 22 Dec 2025 11:52:15 +0200
Subject: [External] : RichTextArea styling feedback
In-Reply-To: <CY8PR10MB7265DB3E493AFBD01B80D4DFE5A3A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB7265DB3E493AFBD01B80D4DFE5A3A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <96EDC056-69BB-4C2C-B463-9199B5A037C3@getmailspring.com>

Hi Andy

So your proposal touches on a number of points:

1. Making the RichParagraph.Builder available via buildParagraph(int index)

   Previously when I was trying to figure out how to customise
RichTextArea for my use case I thought this was needed, however now that
I know the control and implementation better I'm more of the opinion
that it shouldn't in principal be necessary and suspect that it maybe
indicates a shortcoming in the API and implementation ?

2. Making RichParagraph.getSegments() public

   I asked for this merely as a convenience and your code comment
suggesting it. Otherwise one has to do tedious code like this:

    List<StyledSegment> segments = new ArrayList<>();
    try {
            exportParagraph( index, 0, getParagraphLength( index ),
true, new StyledOutput() {
            @Override public void consume( StyledSegment seg )
            throws IOException { segments.add( seg ); }
            @Override public void close() throws IOException {}
            @Override public void flush() throws IOException {}
        });
    }
    catch ( IOException IO ) { IO.printStackTrace(); }

   With regards to this it would be nice if SegmentStyledOutput and
StringBuilderStyledOutput be moved from the sun package to be accessible ?

3. You say > "these attributes could not be considered standard"

   Maybe this is true for wavy underlining but I don't think it holds
for text highlighting. So if we can find a solution for the latter then
the former can be accommodated as well. See next.

4. You say > "The main issue is that these decorations might conceivably
span segments, or apply to parts of a segment, or both."

   Actually I think you mean that the biggest problem is that these
decorations can overlap, like you've so neatly demonstrated, and are
unlike other text attributes which are either on/off or like only one
particular text color. This is the core issue since StyleAttributeMap
can only hold one of any one type of attribute (and also needs to be
typed), but what we need is multiple values for these decoration
attributes !

   The straightforward approach then using the existing API paradigm is
to specify the type as an array in StyleAttributeMap, so maybe we add
something like:

   TEXT_HIGHLIGHT = new StyleAttribute<String[]>( "TEXT_HIGHLIGHT",
String[].class, false );
   WAVY_UNDERLINE = new StyleAttribute<Color[]>( "WAVY_UNDERLINE",
Color[].class, false );

   The StyleAttributeMap.Builder gets setTextHighlight( String css )
   as well as setWavyUnderline( Color color ) // both are not arrays
   and merging is maybe accommodated by overloading the setUnguarded
   method with setUnguarded( StyleAttribute, Object[] )
   where arrays are merged without duplicates.
   Yeah it's ugly/bad, maybe you can improve it ?

   Then update RichParagraph to process them, joining matching adjacent
decorations into one contiguous length as needed.

I hope these suggestions have some merit and are workable.

Thanks, regards
Jurgen


On Dec 9 2025, at 10:15 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> Dear Jurgen:
>  
> I explored a number of ways we could enable adding
> highlights/squigglies via attributes.
>  
> The main issue is that these decorations might conceivably span
> segments, or apply to parts of a segment, or both. ?The secondary
> issue is that these attributes could not be considered standard (and
> you probably don't want us to codify colors or styles anyway).
>  
> One way to do so is described in [0] - basically expose the builder
> within the model. ?This way the application can simply extend one or
> the other standard model to add app-specific attributes. ?You can see
> an example in [1].
>  
> Would that work for you and everyone else? ?What do you think?
>  
> Thank you
> -andy
>  
>  
> [0] https://github.com/openjdk/jfx/pull/1966#issuecomment-3634052681
>  
> [1] https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java
>  
>  
>  
> From: Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Tuesday, August 26, 2025 at 08:06
> To: Andy Goryachev <andy.goryachev at oracle.com>,
> openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> Subject: [External] : RichTextArea styling feedback
>  
> Hi Andy
>  
> I've been looking at the RichTextArea incubator feature and am
> providing feedback wrt the styling aspect of it.
> First off though, thank you for all the effort you have put into this
> so far and I'm looking forward to when this matures.
>  
> Some background:?since I use the RichTextFX library in my real world
> application I wanted to see how easily I could refactor my application
> to use RichTextArea instead, and then provide you with feedback. Here
> I'm focusing just on a simple editor control in my application that
> has some basic styling options (bold, italic, underline, and text
> color) available for the user while the editor indicates any
> misspelled words as they type with a wavy underline.
>  
> I used a standard RichTextArea with its default RichTextModel and
> you'll be pleased to hear that without too much fuss I was able to
> read & write using StyledInput & StyledOutput, as well as convert the
> styling options part of my text editor control. However styling for
> spellchecking didn't go as well.
>  
> So based off my experience with trying various things I recommend the
> following API enhancements:
>  
> The following StyleAttributes should be added to StyleAttributeMap:?
> INLINE_STYLE, STYLE_NAMES,? TEXT_HIGHLIGHT,? and? WAVY_UNDERLINE. At
> the moment none of these are easily or directly available, and I
> believe from a user perspective that they should be.
> Consider splitting StyleAttributes into TextAttributes and
> ParagraphAttributes then INLINE_STYLE and STYLE_NAMES can appear in
> both. Possibly then also have a DecoratorAttribute if needed for
> TEXT_HIGHLIGHT and WAVY_UNDERLINE, if that'll make implementation
> easier but it should I believe from a user perspective still go
> into/through StyleAttributeMap as all styling should preferably be in
> one place.
> The methods applyStyle and setStyle in RichTextArea should have a
> boolean undo parameter like replaceText.
> There's also the following issue that I noticed. When typing text, in
> the middle of a sentence, to extend a word that's styled then the
> typed text is not being inserted using the styles of the preceding text.
>  
> There are some other obervations regarding other aspects of
> RichTextArea that I hope to give feedback on soon as well.
>  
> Thanks again, regards
> Jurgen

From jurgen at ivoryemr.co.za  Mon Dec 22 09:52:15 2025
From: jurgen at ivoryemr.co.za (Jurgen Doll)
Date: Mon, 22 Dec 2025 11:52:15 +0200
Subject: [External] : RichTextArea styling feedback
In-Reply-To: <CY8PR10MB7265DB3E493AFBD01B80D4DFE5A3A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB7265DB3E493AFBD01B80D4DFE5A3A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <96EDC056-69BB-4C2C-B463-9199B5A037C3@getmailspring.com>

Hi Andy

So your proposal touches on a number of points:

1. Making the RichParagraph.Builder available via buildParagraph(int index)

   Previously when I was trying to figure out how to customise
RichTextArea for my use case I thought this was needed, however now that
I know the control and implementation better I'm more of the opinion
that it shouldn't in principal be necessary and suspect that it maybe
indicates a shortcoming in the API and implementation ?

2. Making RichParagraph.getSegments() public

   I asked for this merely as a convenience and your code comment
suggesting it. Otherwise one has to do tedious code like this:

    List<StyledSegment> segments = new ArrayList<>();
    try {
            exportParagraph( index, 0, getParagraphLength( index ),
true, new StyledOutput() {
            @Override public void consume( StyledSegment seg )
            throws IOException { segments.add( seg ); }
            @Override public void close() throws IOException {}
            @Override public void flush() throws IOException {}
        });
    }
    catch ( IOException IO ) { IO.printStackTrace(); }

   With regards to this it would be nice if SegmentStyledOutput and
StringBuilderStyledOutput be moved from the sun package to be accessible ?

3. You say > "these attributes could not be considered standard"

   Maybe this is true for wavy underlining but I don't think it holds
for text highlighting. So if we can find a solution for the latter then
the former can be accommodated as well. See next.

4. You say > "The main issue is that these decorations might conceivably
span segments, or apply to parts of a segment, or both."

   Actually I think you mean that the biggest problem is that these
decorations can overlap, like you've so neatly demonstrated, and are
unlike other text attributes which are either on/off or like only one
particular text color. This is the core issue since StyleAttributeMap
can only hold one of any one type of attribute (and also needs to be
typed), but what we need is multiple values for these decoration
attributes !

   The straightforward approach then using the existing API paradigm is
to specify the type as an array in StyleAttributeMap, so maybe we add
something like:

   TEXT_HIGHLIGHT = new StyleAttribute<String[]>( "TEXT_HIGHLIGHT",
String[].class, false );
   WAVY_UNDERLINE = new StyleAttribute<Color[]>( "WAVY_UNDERLINE",
Color[].class, false );

   The StyleAttributeMap.Builder gets setTextHighlight( String css )
   as well as setWavyUnderline( Color color ) // both are not arrays
   and merging is maybe accommodated by overloading the setUnguarded
   method with setUnguarded( StyleAttribute, Object[] )
   where arrays are merged without duplicates.
   Yeah it's ugly/bad, maybe you can improve it ?

   Then update RichParagraph to process them, joining matching adjacent
decorations into one contiguous length as needed.

I hope these suggestions have some merit and are workable.

Thanks, regards
Jurgen


On Dec 9 2025, at 10:15 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> Dear Jurgen:
>  
> I explored a number of ways we could enable adding
> highlights/squigglies via attributes.
>  
> The main issue is that these decorations might conceivably span
> segments, or apply to parts of a segment, or both. ?The secondary
> issue is that these attributes could not be considered standard (and
> you probably don't want us to codify colors or styles anyway).
>  
> One way to do so is described in [0] - basically expose the builder
> within the model. ?This way the application can simply extend one or
> the other standard model to add app-specific attributes. ?You can see
> an example in [1].
>  
> Would that work for you and everyone else? ?What do you think?
>  
> Thank you
> -andy
>  
>  
> [0] https://github.com/openjdk/jfx/pull/1966#issuecomment-3634052681
>  
> [1] https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java
>  
>  
>  
> From: Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Tuesday, August 26, 2025 at 08:06
> To: Andy Goryachev <andy.goryachev at oracle.com>,
> openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> Subject: [External] : RichTextArea styling feedback
>  
> Hi Andy
>  
> I've been looking at the RichTextArea incubator feature and am
> providing feedback wrt the styling aspect of it.
> First off though, thank you for all the effort you have put into this
> so far and I'm looking forward to when this matures.
>  
> Some background:?since I use the RichTextFX library in my real world
> application I wanted to see how easily I could refactor my application
> to use RichTextArea instead, and then provide you with feedback. Here
> I'm focusing just on a simple editor control in my application that
> has some basic styling options (bold, italic, underline, and text
> color) available for the user while the editor indicates any
> misspelled words as they type with a wavy underline.
>  
> I used a standard RichTextArea with its default RichTextModel and
> you'll be pleased to hear that without too much fuss I was able to
> read & write using StyledInput & StyledOutput, as well as convert the
> styling options part of my text editor control. However styling for
> spellchecking didn't go as well.
>  
> So based off my experience with trying various things I recommend the
> following API enhancements:
>  
> The following StyleAttributes should be added to StyleAttributeMap:?
> INLINE_STYLE, STYLE_NAMES,? TEXT_HIGHLIGHT,? and? WAVY_UNDERLINE. At
> the moment none of these are easily or directly available, and I
> believe from a user perspective that they should be.
> Consider splitting StyleAttributes into TextAttributes and
> ParagraphAttributes then INLINE_STYLE and STYLE_NAMES can appear in
> both. Possibly then also have a DecoratorAttribute if needed for
> TEXT_HIGHLIGHT and WAVY_UNDERLINE, if that'll make implementation
> easier but it should I believe from a user perspective still go
> into/through StyleAttributeMap as all styling should preferably be in
> one place.
> The methods applyStyle and setStyle in RichTextArea should have a
> boolean undo parameter like replaceText.
> There's also the following issue that I noticed. When typing text, in
> the middle of a sentence, to extend a word that's styled then the
> typed text is not being inserted using the styles of the preceding text.
>  
> There are some other obervations regarding other aspects of
> RichTextArea that I hope to give feedback on soon as well.
>  
> Thanks again, regards
> Jurgen

From pavelturk2000 at gmail.com  Tue Dec 23 17:21:29 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 23 Dec 2025 19:21:29 +0200
Subject: StageStyle.EXTENDED preview status
Message-ID: <cd774518-a1a2-4219-9c75-e6bb3539bb0a@gmail.com>

Hello,

StageStyle.EXTENDED has been available since JavaFX 25, but it is still marked as deprecated because it is a preview feature.

Is there any rough timeline or criteria for when this API is expected to leave preview and have the deprecation removed?
In other words, when can developers consider it stable enough for long-term use in production applications?

Thanks in advance for any clarification.

Best regards, Pavel

From kevin.rushforth at oracle.com  Tue Dec 23 20:09:42 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 23 Dec 2025 12:09:42 -0800
Subject: StageStyle.EXTENDED preview status
In-Reply-To: <cd774518-a1a2-4219-9c75-e6bb3539bb0a@gmail.com>
References: <cd774518-a1a2-4219-9c75-e6bb3539bb0a@gmail.com>
Message-ID: <6d40a8f3-251a-4876-a50e-7babedc0eb06@oracle.com>

[redirecting to openjfx-dev]

This is a better question for openjfx-dev.

In general, a feature will preview (or incubate) for at least two 
releases in order to get feedback. If there is a significant change in 
the API, or if it a large API surface to begin with, it will likely take 
longer.

For the specific case of StageStyle.EXTENDED, JavaFX 27 would be the 
earliest release to consider making it final. And that would depend on 
how stable the API is for the JavaFX 26 release, since there have been 
changes in 26 (and one more under review).

-- Kevin


On 12/23/2025 9:21 AM, PavelTurk wrote:
> Hello,
>
> StageStyle.EXTENDED has been available since JavaFX 25, but it is 
> still marked as deprecated because it is a preview feature.
>
> Is there any rough timeline or criteria for when this API is expected 
> to leave preview and have the deprecation removed?
> In other words, when can developers consider it stable enough for 
> long-term use in production applications?
>
> Thanks in advance for any clarification.
>
> Best regards, Pavel


From andy.goryachev at oracle.com  Wed Dec 24 17:00:19 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 24 Dec 2025 17:00:19 +0000
Subject: [External] : RichTextArea styling feedback
In-Reply-To: <96EDC056-69BB-4C2C-B463-9199B5A037C3@getmailspring.com>
References: <CY8PR10MB7265DB3E493AFBD01B80D4DFE5A3A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <96EDC056-69BB-4C2C-B463-9199B5A037C3@getmailspring.com>
Message-ID: <CY8PR10MB72656E0591146C88A70DE735E5B2A@CY8PR10MB7265.namprd10.prod.outlook.com>

Dear Jurgen:

Thank you for your feedback!  Some very interesting ideas - let me think about it for a while.

You are right - the overlapping is an issue, and that - at least in my original design - requires separate attributes.  The whole thing is complicated enough already ;-)

Nevertheless, the code is still in an incubator, so we have some freedom to tweak the APIs.

-andy





From: Jurgen Doll <jurgen at ivoryemr.co.za>
Date: Monday, December 22, 2025 at 01:52
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
Subject: Re: [External] : RichTextArea styling feedback

Hi Andy

So your proposal touches on a number of points:

1. Making the RichParagraph.Builder available via buildParagraph(int index)

   Previously when I was trying to figure out how to customise
RichTextArea for my use case I thought this was needed, however now that
I know the control and implementation better I'm more of the opinion
that it shouldn't in principal be necessary and suspect that it maybe
indicates a shortcoming in the API and implementation ?

2. Making RichParagraph.getSegments() public

   I asked for this merely as a convenience and your code comment
suggesting it. Otherwise one has to do tedious code like this:

    List<StyledSegment> segments = new ArrayList<>();
    try {
            exportParagraph( index, 0, getParagraphLength( index ),
true, new StyledOutput() {
            @Override public void consume( StyledSegment seg )
            throws IOException { segments.add( seg ); }
            @Override public void close() throws IOException {}
            @Override public void flush() throws IOException {}
        });
    }
    catch ( IOException IO ) { IO.printStackTrace(); }

   With regards to this it would be nice if SegmentStyledOutput and
StringBuilderStyledOutput be moved from the sun package to be accessible ?

3. You say > "these attributes could not be considered standard"

   Maybe this is true for wavy underlining but I don't think it holds
for text highlighting. So if we can find a solution for the latter then
the former can be accommodated as well. See next.

4. You say > "The main issue is that these decorations might conceivably
span segments, or apply to parts of a segment, or both."

   Actually I think you mean that the biggest problem is that these
decorations can overlap, like you've so neatly demonstrated, and are
unlike other text attributes which are either on/off or like only one
particular text color. This is the core issue since StyleAttributeMap
can only hold one of any one type of attribute (and also needs to be
typed), but what we need is multiple values for these decoration
attributes !

   The straightforward approach then using the existing API paradigm is
to specify the type as an array in StyleAttributeMap, so maybe we add
something like:

   TEXT_HIGHLIGHT = new StyleAttribute<String[]>( "TEXT_HIGHLIGHT",
String[].class, false );
   WAVY_UNDERLINE = new StyleAttribute<Color[]>( "WAVY_UNDERLINE",
Color[].class, false );

   The StyleAttributeMap.Builder gets setTextHighlight( String css )
   as well as setWavyUnderline( Color color ) // both are not arrays
   and merging is maybe accommodated by overloading the setUnguarded
   method with setUnguarded( StyleAttribute, Object[] )
   where arrays are merged without duplicates.
   Yeah it's ugly/bad, maybe you can improve it ?

   Then update RichParagraph to process them, joining matching adjacent
decorations into one contiguous length as needed.

I hope these suggestions have some merit and are workable.

Thanks, regards
Jurgen


On Dec 9 2025, at 10:15 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> Dear Jurgen:
>
> I explored a number of ways we could enable adding
> highlights/squigglies via attributes.
>
> The main issue is that these decorations might conceivably span
> segments, or apply to parts of a segment, or both.  The secondary
> issue is that these attributes could not be considered standard (and
> you probably don't want us to codify colors or styles anyway).
>
> One way to do so is described in [0] - basically expose the builder
> within the model.  This way the application can simply extend one or
> the other standard model to add app-specific attributes.  You can see
> an example in [1].
>
> Would that work for you and everyone else?  What do you think?
>
> Thank you
> -andy
>
>
> [0] https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1966*issuecomment-3634052681__;Iw!!ACWV5N9M2RV99hQ!KNUsqIxjKc5gFAUQruuD1MvS7GZLjTAJIv4mBXqBzOLEfTF19mXFoOiOfWL9Z5bfFMryPk80wYMHpvWZEF6SROg$
>
> [1] https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java__;!!ACWV5N9M2RV99hQ!KNUsqIxjKc5gFAUQruuD1MvS7GZLjTAJIv4mBXqBzOLEfTF19mXFoOiOfWL9Z5bfFMryPk80wYMHpvWZD6_Xark$
>
>
>
> From: Jurgen Doll <jurgen at ivoryemr.co.za>
> Date: Tuesday, August 26, 2025 at 08:06
> To: Andy Goryachev <andy.goryachev at oracle.com>,
> openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> Subject: [External] : RichTextArea styling feedback
>
> Hi Andy
>
> I've been looking at the RichTextArea incubator feature and am
> providing feedback wrt the styling aspect of it.
> First off though, thank you for all the effort you have put into this
> so far and I'm looking forward to when this matures.
>
> Some background: since I use the RichTextFX library in my real world
> application I wanted to see how easily I could refactor my application
> to use RichTextArea instead, and then provide you with feedback. Here
> I'm focusing just on a simple editor control in my application that
> has some basic styling options (bold, italic, underline, and text
> color) available for the user while the editor indicates any
> misspelled words as they type with a wavy underline.
>
> I used a standard RichTextArea with its default RichTextModel and
> you'll be pleased to hear that without too much fuss I was able to
> read & write using StyledInput & StyledOutput, as well as convert the
> styling options part of my text editor control. However styling for
> spellchecking didn't go as well.
>
> So based off my experience with trying various things I recommend the
> following API enhancements:
>
> The following StyleAttributes should be added to StyleAttributeMap:
> INLINE_STYLE, STYLE_NAMES,  TEXT_HIGHLIGHT,  and  WAVY_UNDERLINE. At
> the moment none of these are easily or directly available, and I
> believe from a user perspective that they should be.
> Consider splitting StyleAttributes into TextAttributes and
> ParagraphAttributes then INLINE_STYLE and STYLE_NAMES can appear in
> both. Possibly then also have a DecoratorAttribute if needed for
> TEXT_HIGHLIGHT and WAVY_UNDERLINE, if that'll make implementation
> easier but it should I believe from a user perspective still go
> into/through StyleAttributeMap as all styling should preferably be in
> one place.
> The methods applyStyle and setStyle in RichTextArea should have a
> boolean undo parameter like replaceText.
> There's also the following issue that I noticed. When typing text, in
> the middle of a sentence, to extend a word that's styled then the
> typed text is not being inserted using the styles of the preceding text.
>
> There are some other obervations regarding other aspects of
> RichTextArea that I hope to give feedback on soon as well.
>
> Thanks again, regards
> Jurgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-discuss/attachments/20251224/272ae045/attachment-0001.htm>