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

Withdrawn: 8313650: Add hasProperties method to MenuItem and Toggle

[duke]

On Fri, 18 Aug 2023 17:06:57 GMT, Andy Goryachev  wrote:

> 1. Creating a new `javafx.scene.ContainsProperties` interface that declares 
> two methods:
> - public ObservableMap getProperties();
> - public boolean hasProperties();
> 
> 2. Node, MenuItem, and Toggle now extend ContainsProperties interface.
> 
> 3. Making implemented methods in Node, MenuItem, and Toggle final.
> 
> While this change is an improvement from a design point of view, it 
> introduces a larger compatibility risk (by adding 'final' keyword similar to 
> [JDK-8313651](https://bugs.openjdk.org/browse/JDK-8313651))
> 
> This change requires CSR.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.org/jfx/pull/1215

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

[Kevin Rushforth]

On Thu, 22 Feb 2024 23:18:46 GMT, Marius Hanl  wrote:

> maybe it's time to setup a VM on my Windows machine. Are there any 
> recommendations I may should follow for the setup? :-)

I don't know of any supported way to run macOS in a VM on a Windows host, but 
perhaps others will be able to help.

> Regarding the system tests, I checked the nested event loop ones on Windows 
> and they work for me.

It worked for me on Windows, too (and on Linux in a headful test run). I would 
want to make sure that we know _why_ they still work on Windows and Linux and 
fail on Mac, but I only saw the failures on Mac.

> I just pushed a change which may fixes this for Mac as well. The change is 
> also logical and is synchronized with the other changes I made to nested 
> event loops. Will ask my colleague as well to test my changes again + run the 
> most obvious (related) system tests on Mac.

I can also fire off a headful test run this afternoon, and post results 
tomorrow.

> I also will do a much bigger testing soon, I have an application that relies 
> heavily on nested event loops for blocking the UI while doing background work.

The results of that testing would be good information.

-

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1960552062

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Kevin Rushforth]

On Thu, 22 Feb 2024 23:11:55 GMT, Nir Lisker  wrote:

>> The only thing I can point at is the OCA (which is linked in the CONTRIBUTOR 
>> guidelines), which states that contributions need to be an original work.
>> 
>> So to double-check: Aside from that image (and the ones derived from it), 
>> are all the others your original work?
>
> Yes, I created the textures in a generator, the schematics I drew myself, and 
> the screenshots are from the 3D Lighting app.

Thanks for confirming.

I'll review the text of the doc changes tomorrow.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500083607

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

[Marius Hanl]

On Thu, 22 Feb 2024 15:41:55 GMT, Kevin Rushforth  wrote:

> @Maran23 I see from the description that you tested this on mac. How did you 
> test it? Did you run with `-PFULL_TEST=true`?

No, I checked the example in the ticket as well as the handling of dialogs in 
general on Mac.
Unfortuantely, I always need to ask a colleague to test my JavaFX Builds on 
Mac, but maybe it's time to setup a VM on my Windows machine. 
Are there any recommendations I may should follow for the setup? :-)

Regarding the system tests, I checked the nested event loop ones on Windows and 
they work for me.

I just pushed a change which may fixes this for Mac as well.
The change is also logical and is synchronized with the other changes I made to 
nested event loops.
Will ask my colleague as well to test my changes again + run the most obvious 
(related) system tests on Mac.

I also will do a much bigger testing soon, I have an application that relies 
heavily on nested event loops for blocking the UI while doing background work.

-

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1960498210

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Andy Goryachev]

On Thu, 22 Feb 2024 23:04:50 GMT, Nir Lisker  wrote:

>> StringJoiner seems to provide little benefit for maps or key=value pairs.  
>> Do you know of an alternative?
>
> A `StringJoiner` seems suitable to me in this case:
> 
> new StringJoiner(",", "PhongMaterial[", "]")
> .add("diffuseColor=" + getDiffuseColor())
> .add("specularPower=" + getSpecularPower())
> ...
> 
> I guess you can make a helper method that takes a property and creates the 
> string for you, like `diffuseColor.getName() + "=" + diffuseColor.getValue()` 
> and then it won't look like a key-value pair in the joiner.
> 
> You might want to search for the default implementation of records and see 
> how they create the `name = value` representation.

It looks like compiler auto-generates code for records.

The last solution is malloc galore: multiple StringBuilders, much worse than 
the original concatenation.

All right, sorry for discussion unrelated to this PR.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500054617

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

On Thu, 22 Feb 2024 23:07:21 GMT, Kevin Rushforth  wrote:

>> Perhaps the contribution guidelines should mention what resources can be 
>> included. In all other open source projects I worked on it was enough that 
>> the resource wasn't licensed (or had something like 
>> https://en.wikipedia.org/wiki/WTFPL).
>
> The only thing I can point at is the OCA (which is linked in the CONTRIBUTOR 
> guidelines), which states that contributions need to be an original work.
> 
> So to double-check: Aside from that image (and the ones derived from it), are 
> all the others your original work?

Yes, I created the textures in a generator, the schematics I drew myself, and 
the screenshots are from the 3D Lighting app.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500052213

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2]

[Marius Hanl]

> This PR fixes the dialog freeze problem once and for all. 
> 
> This one is a bit tricky to understand, here is how it works:
> This bug happens on every platform, although the implementation of nested 
> event loops differs on every platform.
> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we 
> have an own implementation of a nested event loop (while loop), controlled by 
> a boolean flag.
> 
> Funny enough, the reason why this bug happens is always the same: Timing.
> 
> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 
> 2. This will call native code to get out of the nested event loop, e.g. on 
> Windows we try to break out of the while loop with a boolean flag, on Linux 
> we call `gtk_main_quit`.
> 3. Now, if we immediately open a new dialog, we enter a new nested event loop 
> via `_enterNestedEventLoop`, as a consequence we do not break out of the 
> while loop on Windows (the flag is set back again, the while loop is still 
> running), and we do not return from `gtk_main` on Linux.
> 4. And this will result in the Java code never returning and calling 
> `notifyLeftNestedEventLoop`, which we need to recover the UI.
> 
> So it is actually not trivial to fix this problem, and we can not really do 
> anything on the Java side. We may can try to wait until one more frame has 
> run so that things will hopefully be right, but that sounds rather hacky.
> 
> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. 
> Turns out, we don't need to. 
> There is a return value which we actually do not use (it does not have any 
> meaning to us, other that it is used inside an assert statement).
> Without the need of a return value, we also do not need to care when 
> `_enterNestedEventLoop` is returning - instead we cleanup and call 
> `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code 
> was called.
> 
> Lets see if this is the right approach (for all platforms).
> Testing appreciated.
> #
> - [x] Tested on Windows
> - [x] Tested on Linux
> - [x] Tested on Mac
> - [ ] Tested on iOS (although the nested event loop code is the same as for 
> Mac) (I would appreciate if someone can do this as I have no access to an iOS 
> device)
> - [ ] Adjust copyright
> - [ ] Write Systemtest

Marius Hanl has updated the pull request with a new target base due to a merge 
or a rebase. The incremental webrev excludes the unrelated changes brought in 
by the merge/rebase. The pull request contains three additional commits since 
the last revision:

 - Merge remote-tracking branch 'openjfx/master' into 
JDK-8285893-dialog-freezing-略
 - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop
 - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1324/files
  - new: https://git.openjdk.org/jfx/pull/1324/files/98a97b0a..cb8865e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1324=01
 - incr: https://webrevs.openjdk.org/?repo=jfx=1324=00-01

  Stats: 294903 lines in 6630 files changed: 173936 ins; 83950 del; 37017 mod
  Patch: https://git.openjdk.org/jfx/pull/1324.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324

PR: https://git.openjdk.org/jfx/pull/1324

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Kevin Rushforth]

On Thu, 22 Feb 2024 22:51:56 GMT, Nir Lisker  wrote:

>> sorry, Nir.  ;-)
>
> Perhaps the contribution guidelines should mention what resources can be 
> included. In all other open source projects I worked on it was enough that 
> the resource wasn't licensed (or had something like 
> https://en.wikipedia.org/wiki/WTFPL).

The only thing I can point at is the OCA (which is linked in the CONTRIBUTOR 
guidelines), which states that contributions need to be an original work.

So to double-check: Aside from that image (and the ones derived from it), are 
all the others your original work?

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500048531

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

On Thu, 22 Feb 2024 22:50:06 GMT, Andy Goryachev  wrote:

>>> also, the first `+` is unnecessary
>> 
>> I think it was done for uniformity with the other properties. I would use a 
>> `StringJoiner` these days for such a task anyway.
>
> StringJoiner seems to provide little benefit for maps or key=value pairs.  Do 
> you know of an alternative?

A `StringJoiner` seems suitable to me in this case:

new StringJoiner(",", "PhongMaterial[", "]")
.add("diffuseColor=" + getDiffuseColor())
.add("specularPower=" + getSpecularPower())
...

I guess you can make a helper method that takes a property and creates the 
string for you, like `diffuseColor.getName() + "=" + diffuseColor.getValue()` 
and then it won't look like a key-value pair in the joiner.

You might want to search for the default implementation of records and see how 
they create the `name = value` representation.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500046959

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Andy Goryachev]

On Thu, 22 Feb 2024 22:44:05 GMT, Nir Lisker  wrote:

>> Weird, I specifically reverted the auto-formatting, not sure how it got in. 
>> Will revert.
>
>> also, the first `+` is unnecessary
> 
> I think it was done for uniformity with the other properties. I would use a 
> `StringJoiner` these days for such a task anyway.

StringJoiner seems to provide little benefit for maps or key=value pairs.  Do 
you know of an alternative?

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500032969

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

On Thu, 22 Feb 2024 22:42:18 GMT, Andy Goryachev  wrote:

>> OK, it will be after the weekend when I can come back to this. Reviewers can 
>> assume that only the background will change.
>
> sorry, Nir.  ;-)

Perhaps the contribution guidelines should mention what resources can be 
included. In all other open source projects I worked on it was enough that the 
resource wasn't licensed (or had something like 
https://en.wikipedia.org/wiki/WTFPL).

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500034313

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

On Thu, 22 Feb 2024 22:20:56 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java 
>> line 848:
>> 
>>> 846: + ", specularPower=" + getSpecularPower() + ", 
>>> diffuseMap=" + getDiffuseMap() + ", specularMap="
>>> 847: + getSpecularMap() + ", bumpMap=" + getBumpMap() + ", 
>>> selfIlluminationMap=" + getSelfIlluminationMap()
>>> 848: + "]";
>> 
>> could we restore the formatting please?
>> also, the first `+` is unnecessary
>
> Weird, I specifically reverted the auto-formatting, not sure how it got in. 
> Will revert.

> also, the first `+` is unnecessary

I think it was done for uniformity with the other properties. I would use a 
`StringJoiner` these days for such a task anyway.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500028809

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Andy Goryachev]

On Thu, 22 Feb 2024 22:40:59 GMT, Nir Lisker  wrote:

>> All of them, since they were derived from the original. I can still tell 
>> what the source is.
>
> OK, it will be after the weekend when I can come back to this. Reviewers can 
> assume that only the background will change.

sorry, Nir.  ;-)

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500027550

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

On Thu, 22 Feb 2024 22:36:06 GMT, Kevin Rushforth  wrote:

>> Do I only need to switch the ones in the introduction that show the 
>> multiplication of the color and the map, or all of the new images that use 
>> it as a background? The latter will be a lot of work.
>
> All of them, since they were derived from the original. I can still tell what 
> the source is.

OK, it will be after the weekend when I can come back to this. Reviewers can 
assume that only the background will change.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500026555

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Kevin Rushforth]

On Thu, 22 Feb 2024 22:31:59 GMT, Nir Lisker  wrote:

>> To add to this, such approval would be unlikely, and I am not in favor of 
>> making the request. Perhaps you can find suitable images already in the 
>> repo? Here is one that might work:
>> 
>> https://github.com/openjdk/jfx/tree/e0b88bc7cfede46afe28cbb4a2e333df933b5100/apps/toys/FX8-3DFeatures/src/resources
>
> Do I only need to switch the ones in the introduction that show the 
> multiplication of the color and the map, or all of the new images that use it 
> as a background? The latter will be a lot of work.

All of them, since they were derived from the original. I can still tell what 
the source is.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500023069

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

On Thu, 22 Feb 2024 22:21:49 GMT, Kevin Rushforth  wrote:

>> What would an approval require?
>
> To add to this, such approval would be unlikely, and I am not in favor of 
> making the request. Perhaps you can find suitable images already in the repo? 
> Here is one that might work:
> 
> https://github.com/openjdk/jfx/tree/e0b88bc7cfede46afe28cbb4a2e333df933b5100/apps/toys/FX8-3DFeatures/src/resources

Do I only need to switch the ones in the introduction that show the 
multiplication of the color and the map, or all of the new images that use it 
as a background? The latter will be a lot of work.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500019932

Re: Proposal: JavaFX Incubator Modules

[Kevin Rushforth]

Something like this might be reasonable as long as we also add "and 
hasn't been modified in the current release". I could easily image the 
case where an incubating feature goes into, say JavaFX 26 in March, and 
by the time feedback comes in that prompts a change in the API, it's 
July or August already, meaning that any changes will go into JavaFX 28.


The time between when a feature first released (in a GA release) and the 
feature freeze for the next release is only a little over 3 months 
(which is why most features will incubate for at least two releases).


-- Kevin


On 2/22/2024 1:08 PM, Philip Race wrote:
W.r.t to (3) perhaps we could include in the write up an expectation 
that continued incubation implies continued updates.
Meaning if there are no updates in a release then that either means it 
is ready to be final next time round, or that the
author is no longer actively pursuing it and this should inform the 
Project Lead as to what action should be taken next.


-phil.

On 2/21/24 1:55 PM, Kevin Rushforth wrote:

These are all good points.

1. I agree. This seems like a good idea for all the reasons you mention.

2. I'll add the additional information. And I like your suggestion to 
require a JEP (*) to either drop or finalize an incubating feature.


3. Yes, I was deliberately vague on what constitutes a reasonable 
amount of time. Given that we are changing the default to 
"re-incubate" it does make sense to have a "soft timeout" so 
incubating features don't incubate forever without an intentional 
action to keep them alive.


I'll update the proposal accordingly.

Thanks.

-- Kevin

(*) We don't exactly follow the JEP process as described in JEP 2, 
but for larger features we expect a proposal that touches on the 
important points in a JEP-like document and is discussed on the 
mailing list. That's what we mean when we say "needs a JEP".



On 2/21/2024 9:47 AM, Philip Race wrote:
1) The first thing that jumps out at me is the namespace : 
javafx.incubator


The JDK's JEP 11 says "An incubator module is identified by 
the|jdk.incubator.|prefix in its module name"

It says the same about the packages inside the module.
"An incubating API is identified by the|jdk.incubator.|prefix in its 
exported package names".


This is to avoid using the standard namespace prefixes for JDK of 
java. and javax. used for final APIs/modules.


So similarly I think JavaFX incubators should avoid the javafx. 
prefix and I suggest "jfx." be used instead.
This closely mirrors the "jdk." used in JEP 11, taking "java" out of 
the prefix and making it entirely an acronym,

for both module and package names.
The pain of updating your code when the API goes final can be eased 
by IDEs and is something you would
need to do anyway because "incubator" is in all the names in either 
case.


2) The second thing is you don't say what the steps are to promote 
the incubating module to final.
JEP 11 says a new JEP is needed for that, but it also says a new JEP 
is needed to re-incubate

which is something JavaFX will not require.
So do you expect it will be a new JEP for that ?
I think that would be best to do that as the JEP to propose the 
incubator could be several years old and stale by then.

You also don't say what it takes to drop it.

So how about the basic process is that the first JEP simply proposes 
the incubating module, once

it is in as you say it evolves by normal RFEs across releases ?
Then when it is EITHER ready to go final OR be removed, a new JEP 
must be proposed for that.

A removal JEP should generally be quite short :-)

So I suggest to add a sentence along those lines to the proposal.
"To either make the API of an incubating module final, or to remove 
it, then a new JEP should be submitted,

referencing the incubator JEP".

3) The "reasonably small number of JavaFX releases" is I am sure 
intentionally vague, but perhaps

we could say
(1) Incubators which span beyond a 24 month period and are not yet 
ready will need
a simple public approval from the project lead to remain for some 
additiional period at the discretion
of the Project Lead by adding a simple comment in the JEP, otherwise 
the Project Lead will submit a removal JEP and

(2) the submitter of the JEP can propose to remove it at any time.

-phil.

On 2/21/24 9:37 AM, Kevin Rushforth wrote:
JEP 11 [1] defines a process for delivering non-final JDK APIs in 
incubator modules.


Similarly, some JavaFX APIs would benefit from spending a period of 
time in a JavaFX release prior to being deemed stable. I propose 
JavaFX incubator modules as a means of putting non-final API in the 
hands of developers, while the API progresses towards either 
finalization or removal in a future release. This is especially 
useful for complex features with a large API surface.


The JavaFX proposal is largely the same as the JDK one, but has 
some important differences.


Please take a look at the preliminary proposal [2]. I have also 
created a Draft PR 

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Nir Lisker]

> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
> `Material`). Except for the introduction, I divided the documentation into 3 
> sections: qualitative explanation, mathematical model (I wouldn't think it 
> necessary, but the current doc explains it), and examples.
> 
> The reason for the verbosity of the doc is that I envisioned 2 target 
> audiences for this class. One is a Java developer who wants to understand the 
> terminology and workings of computer graphics or of the artists who are 
> already familiar with this domain. (How many Java developers know what 
> diffuse, specular and normal maps are?) The other is an artist who is already 
> familiar with the domain, but wants to see how this class compares with other 
> renderers. For this reason, I looked at the terminology used by engines like 
> Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump 
> vs. height vs. normal maps, or specular vs. roughness/smoothness).
> 
> The examples I chose and some of the schematics are not the best, looking at 
> it retroactively, but I want to give enough time for reviewers and get this 
> into 22.

Nir Lisker has updated the pull request incrementally with one additional 
commit since the last revision:

  Revert unintended formatting

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1378/files
  - new: https://git.openjdk.org/jfx/pull/1378/files/34bbc561..0130d0f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1378=02
 - incr: https://webrevs.openjdk.org/?repo=jfx=1378=01-02

  Stats: 53 lines in 1 file changed: 4 ins; 0 del; 49 mod
  Patch: https://git.openjdk.org/jfx/pull/1378.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378

PR: https://git.openjdk.org/jfx/pull/1378

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Nir Lisker]

On Thu, 22 Feb 2024 22:18:38 GMT, Andy Goryachev  wrote:

>> Nir Lisker has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update copyright year
>
> modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java 
> line 848:
> 
>> 846: + ", specularPower=" + getSpecularPower() + ", 
>> diffuseMap=" + getDiffuseMap() + ", specularMap="
>> 847: + getSpecularMap() + ", bumpMap=" + getBumpMap() + ", 
>> selfIlluminationMap=" + getSelfIlluminationMap()
>> 848: + "]";
> 
> could we restore the formatting please?
> also, the first `+` is unnecessary

Weird, I specifically reverted the auto-formatting, not sure how it got in. 
Will revert.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r157027

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Kevin Rushforth]

On Thu, 22 Feb 2024 22:19:27 GMT, Nir Lisker  wrote:

>> But it's still third-party content and cannot go in without approval.
>
> What would an approval require?

To add to this, such approval would be unlikely, and I am not in favor of 
making the request. Perhaps you can find suitable images already in the repo? 
Here is one that might work:

https://github.com/openjdk/jfx/tree/e0b88bc7cfede46afe28cbb4a2e333df933b5100/apps/toys/FX8-3DFeatures/src/resources

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r159761

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Andy Goryachev]

On Thu, 22 Feb 2024 22:17:27 GMT, Nir Lisker  wrote:

>> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
>> `Material`). Except for the introduction, I divided the documentation into 3 
>> sections: qualitative explanation, mathematical model (I wouldn't think it 
>> necessary, but the current doc explains it), and examples.
>> 
>> The reason for the verbosity of the doc is that I envisioned 2 target 
>> audiences for this class. One is a Java developer who wants to understand 
>> the terminology and workings of computer graphics or of the artists who are 
>> already familiar with this domain. (How many Java developers know what 
>> diffuse, specular and normal maps are?) The other is an artist who is 
>> already familiar with the domain, but wants to see how this class compares 
>> with other renderers. For this reason, I looked at the terminology used by 
>> engines like Blender, Maya, UE4 and Unity and tried to mention the 
>> comparisons (like bump vs. height vs. normal maps, or specular vs. 
>> roughness/smoothness).
>> 
>> The examples I chose and some of the schematics are not the best, looking at 
>> it retroactively, but I want to give enough time for reviewers and get this 
>> into 22.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update copyright year

modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java 
line 848:

> 846: + ", specularPower=" + getSpecularPower() + ", 
> diffuseMap=" + getDiffuseMap() + ", specularMap="
> 847: + getSpecularMap() + ", bumpMap=" + getBumpMap() + ", 
> selfIlluminationMap=" + getSelfIlluminationMap()
> 848: + "]";

could we restore the formatting please?
also, the first `+` is unnecessary

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r150870

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Nir Lisker]

On Thu, 22 Feb 2024 22:13:33 GMT, Kevin Rushforth  wrote:

>> No, it's a standard in image processing: https://en.wikipedia.org/wiki/Lenna.
>
> But it's still third-party content and cannot go in without approval.

What would an approval require?

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r152472

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Kevin Rushforth]

On Thu, 22 Feb 2024 22:10:35 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/color and 
>> map/map.png line 1:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> Is this a licensed image?
>
> No, it's a standard in image processing: https://en.wikipedia.org/wiki/Lenna.

But it's still third-party content and cannot go in without approval.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r146926

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Nir Lisker]

On Thu, 22 Feb 2024 20:49:20 GMT, Andy Goryachev  wrote:

>> Nir Lisker has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update copyright year
>
> modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/color and 
> map/map.png line 1:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Is this a licensed image?

No, it's a standard in image processing: https://en.wikipedia.org/wiki/Lenna.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r144625

Re: RFR: 8314147: Updated the PhongMaterial documentation [v2]

[Nir Lisker]

> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
> `Material`). Except for the introduction, I divided the documentation into 3 
> sections: qualitative explanation, mathematical model (I wouldn't think it 
> necessary, but the current doc explains it), and examples.
> 
> The reason for the verbosity of the doc is that I envisioned 2 target 
> audiences for this class. One is a Java developer who wants to understand the 
> terminology and workings of computer graphics or of the artists who are 
> already familiar with this domain. (How many Java developers know what 
> diffuse, specular and normal maps are?) The other is an artist who is already 
> familiar with the domain, but wants to see how this class compares with other 
> renderers. For this reason, I looked at the terminology used by engines like 
> Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump 
> vs. height vs. normal maps, or specular vs. roughness/smoothness).
> 
> The examples I chose and some of the schematics are not the best, looking at 
> it retroactively, but I want to give enough time for reviewers and get this 
> into 22.

Nir Lisker has updated the pull request incrementally with one additional 
commit since the last revision:

  Update copyright year

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1378/files
  - new: https://git.openjdk.org/jfx/pull/1378/files/b744540c..34bbc561

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1378=01
 - incr: https://webrevs.openjdk.org/?repo=jfx=1378=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1378.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378

PR: https://git.openjdk.org/jfx/pull/1378

Re: RFR: 8314147: Updated the PhongMaterial documentation

[Kevin Rushforth]

On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker  wrote:

> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
> `Material`). Except for the introduction, I divided the documentation into 3 
> sections: qualitative explanation, mathematical model (I wouldn't think it 
> necessary, but the current doc explains it), and examples.
> 
> The reason for the verbosity of the doc is that I envisioned 2 target 
> audiences for this class. One is a Java developer who wants to understand the 
> terminology and workings of computer graphics or of the artists who are 
> already familiar with this domain. (How many Java developers know what 
> diffuse, specular and normal maps are?) The other is an artist who is already 
> familiar with the domain, but wants to see how this class compares with other 
> renderers. For this reason, I looked at the terminology used by engines like 
> Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump 
> vs. height vs. normal maps, or specular vs. roughness/smoothness).
> 
> The examples I chose and some of the schematics are not the best, looking at 
> it retroactively, but I want to give enough time for reviewers and get this 
> into 22.

@lukostyra would be another good reviewer of this.

-

PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1960405983

Re: Proposal: JavaFX Incubator Modules

[Philip Race]

W.r.t to (3) perhaps we could include in the write up an expectation 
that continued incubation implies continued updates.
Meaning if there are no updates in a release then that either means it 
is ready to be final next time round, or that the
author is no longer actively pursuing it and this should inform the 
Project Lead as to what action should be taken next.


-phil.

On 2/21/24 1:55 PM, Kevin Rushforth wrote:

These are all good points.

1. I agree. This seems like a good idea for all the reasons you mention.

2. I'll add the additional information. And I like your suggestion to 
require a JEP (*) to either drop or finalize an incubating feature.


3. Yes, I was deliberately vague on what constitutes a reasonable 
amount of time. Given that we are changing the default to 
"re-incubate" it does make sense to have a "soft timeout" so 
incubating features don't incubate forever without an intentional 
action to keep them alive.


I'll update the proposal accordingly.

Thanks.

-- Kevin

(*) We don't exactly follow the JEP process as described in JEP 2, but 
for larger features we expect a proposal that touches on the important 
points in a JEP-like document and is discussed on the mailing list. 
That's what we mean when we say "needs a JEP".



On 2/21/2024 9:47 AM, Philip Race wrote:
1) The first thing that jumps out at me is the namespace : 
javafx.incubator


The JDK's JEP 11 says "An incubator module is identified by 
the|jdk.incubator.|prefix in its module name"

It says the same about the packages inside the module.
"An incubating API is identified by the|jdk.incubator.|prefix in its 
exported package names".


This is to avoid using the standard namespace prefixes for JDK of 
java. and javax. used for final APIs/modules.


So similarly I think JavaFX incubators should avoid the javafx. 
prefix and I suggest "jfx." be used instead.
This closely mirrors the "jdk." used in JEP 11, taking "java" out of 
the prefix and making it entirely an acronym,

for both module and package names.
The pain of updating your code when the API goes final can be eased 
by IDEs and is something you would

need to do anyway because "incubator" is in all the names in either case.

2) The second thing is you don't say what the steps are to promote 
the incubating module to final.
JEP 11 says a new JEP is needed for that, but it also says a new JEP 
is needed to re-incubate

which is something JavaFX will not require.
So do you expect it will be a new JEP for that ?
I think that would be best to do that as the JEP to propose the 
incubator could be several years old and stale by then.

You also don't say what it takes to drop it.

So how about the basic process is that the first JEP simply proposes 
the incubating module, once

it is in as you say it evolves by normal RFEs across releases ?
Then when it is EITHER ready to go final OR be removed, a new JEP 
must be proposed for that.

A removal JEP should generally be quite short :-)

So I suggest to add a sentence along those lines to the proposal.
"To either make the API of an incubating module final, or to remove 
it, then a new JEP should be submitted,

referencing the incubator JEP".

3) The "reasonably small number of JavaFX releases" is I am sure 
intentionally vague, but perhaps

we could say
(1) Incubators which span beyond a 24 month period and are not yet 
ready will need
a simple public approval from the project lead to remain for some 
additiional period at the discretion
of the Project Lead by adding a simple comment in the JEP, otherwise 
the Project Lead will submit a removal JEP and

(2) the submitter of the JEP can propose to remove it at any time.

-phil.

On 2/21/24 9:37 AM, Kevin Rushforth wrote:
JEP 11 [1] defines a process for delivering non-final JDK APIs in 
incubator modules.


Similarly, some JavaFX APIs would benefit from spending a period of 
time in a JavaFX release prior to being deemed stable. I propose 
JavaFX incubator modules as a means of putting non-final API in the 
hands of developers, while the API progresses towards either 
finalization or removal in a future release. This is especially 
useful for complex features with a large API surface.


The JavaFX proposal is largely the same as the JDK one, but has some 
important differences.


Please take a look at the preliminary proposal [2]. I have also 
created a Draft PR [3], for illustrative purposes only, to show how 
this might work.


Please reply to this message with any feedback.

Thanks.

-- Kevin

[1] https://openjdk.org/jeps/11
[2] 
https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md

[3] https://github.com/openjdk/jfx/pull/1375

Re: RFR: 8314147: Updated the PhongMaterial documentation

[Andy Goryachev]

On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker  wrote:

> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
> `Material`). Except for the introduction, I divided the documentation into 3 
> sections: qualitative explanation, mathematical model (I wouldn't think it 
> necessary, but the current doc explains it), and examples.
> 
> The reason for the verbosity of the doc is that I envisioned 2 target 
> audiences for this class. One is a Java developer who wants to understand the 
> terminology and workings of computer graphics or of the artists who are 
> already familiar with this domain. (How many Java developers know what 
> diffuse, specular and normal maps are?) The other is an artist who is already 
> familiar with the domain, but wants to see how this class compares with other 
> renderers. For this reason, I looked at the terminology used by engines like 
> Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump 
> vs. height vs. normal maps, or specular vs. roughness/smoothness).
> 
> The examples I chose and some of the schematics are not the best, looking at 
> it retroactively, but I want to give enough time for reviewers and get this 
> into 22.

modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/color and 
map/map.png line 1:

> (failed to retrieve contents of file, check the PR for context)
Is this a licensed image?

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1499917718

Re: RFR: 8314147: Updated the PhongMaterial documentation

[Nir Lisker]

On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker  wrote:

> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
> `Material`). Except for the introduction, I divided the documentation into 3 
> sections: qualitative explanation, mathematical model (I wouldn't think it 
> necessary, but the current doc explains it), and examples.
> 
> The reason for the verbosity of the doc is that I envisioned 2 target 
> audiences for this class. One is a Java developer who wants to understand the 
> terminology and workings of computer graphics or of the artists who are 
> already familiar with this domain. (How many Java developers know what 
> diffuse, specular and normal maps are?) The other is an artist who is already 
> familiar with the domain, but wants to see how this class compares with other 
> renderers. For this reason, I looked at the terminology used by engines like 
> Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump 
> vs. height vs. normal maps, or specular vs. roughness/smoothness).
> 
> The examples I chose and some of the schematics are not the best, looking at 
> it retroactively, but I want to give enough time for reviewers and get this 
> into 22.

@kevinrushforth Please review this. Perhaps the second reviewer can be 
@jayathirthrao or @arapte.

-

PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1960282365

RFR: 8314147: Updated the PhongMaterial documentation

[Nir Lisker]

Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
`Material`). Except for the introduction, I divided the documentation into 3 
sections: qualitative explanation, mathematical model (I wouldn't think it 
necessary, but the current doc explains it), and examples.

The reason for the verbosity of the doc is that I envisioned 2 target audiences 
for this class. One is a Java developer who wants to understand the terminology 
and workings of computer graphics or of the artists who are already familiar 
with this domain. (How many Java developers know what diffuse, specular and 
normal maps are?) The other is an artist who is already familiar with the 
domain, but wants to see how this class compares with other renderers. For this 
reason, I looked at the terminology used by engines like Blender, Maya, UE4 and 
Unity and tried to mention the comparisons (like bump vs. height vs. normal 
maps, or specular vs. roughness/smoothness).

The examples I chose and some of the schematics are not the best, looking at it 
retroactively, but I want to give enough time for reviewers and get this into 
22.

-

Commit messages:
 - Whitespace
 - Initial commit

Changes: https://git.openjdk.org/jfx/pull/1378/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1378=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314147
  Stats: 637 lines in 41 files changed: 525 ins; 17 del; 95 mod
  Patch: https://git.openjdk.org/jfx/pull/1378.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378

PR: https://git.openjdk.org/jfx/pull/1378

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
[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: 

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

[Kevin Rushforth]

On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl  wrote:

> This PR fixes the dialog freeze problem once and for all. 
> 
> This one is a bit tricky to understand, here is how it works:
> This bug happens on every platform, although the implementation of nested 
> event loops differs on every platform.
> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we 
> have an own implementation of a nested event loop (while loop), controlled by 
> a boolean flag.
> 
> Funny enough, the reason why this bug happens is always the same: Timing.
> 
> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 
> 2. This will call native code to get out of the nested event loop, e.g. on 
> Windows we try to break out of the while loop with a boolean flag, on Linux 
> we call `gtk_main_quit`.
> 3. Now, if we immediately open a new dialog, we enter a new nested event loop 
> via `_enterNestedEventLoop`, as a consequence we do not break out of the 
> while loop on Windows (the flag is set back again, the while loop is still 
> running), and we do not return from `gtk_main` on Linux.
> 4. And this will result in the Java code never returning and calling 
> `notifyLeftNestedEventLoop`, which we need to recover the UI.
> 
> So it is actually not trivial to fix this problem, and we can not really do 
> anything on the Java side. We may can try to wait until one more frame has 
> run so that things will hopefully be right, but that sounds rather hacky.
> 
> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. 
> Turns out, we don't need to. 
> There is a return value which we actually do not use (it does not have any 
> meaning to us, other that it is used inside an assert statement).
> Without the need of a return value, we also do not need to care when 
> `_enterNestedEventLoop` is returning - instead we cleanup and call 
> `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code 
> was called.
> 
> Lets see if this is the right approach (for all platforms).
> Testing appreciated.
> #
> - [x] Tested on Windows
> - [x] Tested on Linux
> - [x] Tested on Mac
> - [ ] Tested on iOS (although the nested event loop code is the same as for 
> Mac) (I would appreciate if someone can do this as I have no access to an iOS 
> device)
> - [ ] Adjust copyright
> - [ ] Write Systemtest

As I was afraid of, this change causes many test failures (see below for just 
one example). I think a different approach is needed, one that preserves the 
synchronous nature of these methods.


NestedEventLoopTest > testCanEnterAndExitNestedEventLoop FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at org.junit.Assert.assertFalse(Assert.java:75)
at 
test.javafx.stage.NestedEventLoopTest.lambda$testCanEnterAndExitNestedEventLoop$2(NestedEventLoopTest.java:120)
at test.util.Util.lambda$submit$0(Util.java:108)
at 
javafx.graphics@23-ea/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:456)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at 
javafx.graphics@23-ea/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:455)
at 
javafx.graphics@23-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at 
javafx.graphics@23-ea/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native
 Method)
at 
javafx.graphics@23-ea/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(MacApplication.java:169)
at 
javafx.graphics@23-ea/com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:512)
at 
javafx.graphics@23-ea/com.sun.glass.ui.EventLoop.enter(EventLoop.java:107)
at 
javafx.graphics@23-ea/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:656)
at 
javafx.graphics@23-ea/javafx.application.Platform.enterNestedEventLoop(Platform.java:310)
at 
test.javafx.stage.NestedEventLoopTest.lambda$testCanEnterAndExitNestedEventLoop$0(NestedEventLoopTest.java:112)

@Maran23 I see from the description that you tested this on mac. How did you 
test it? Did you run with `-PFULL_TEST=true`?

-

Changes requested by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1324#pullrequestreview-1896186878
PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1959717323

Integrated: 8278021: Fix warnings in macOS glass native code and treat warnings as errors

[Martin Fox]

On Wed, 1 Dec 2021 17:44:21 GMT, Martin Fox  wrote:

> Turning on warnings-as-errors for the macOS glass native code. Deprecated 
> declarations are excluded and still appear as warnings.
> 
> In the code that tries to locate the application's dock icon there were three 
> instances where `NO` was being passed into a method that required a pointer 
> to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path 
> pointed to an existing file but not a directory. Since JavaFX has gone this 
> long without screening out directories correctly I decided not to fix that 
> behavior except at the very end.
> 
> The only other changes of note are sending some NSNotification objects to 
> delegate API's that require them even though we know they're ignored on the 
> other side. It was the easiest way to get rid of the warning.

This pull request has now been integrated.

Changeset: e0b88bc7
Author:Martin Fox 
URL:   
https://git.openjdk.org/jfx/commit/e0b88bc7cfede46afe28cbb4a2e333df933b5100
Stats: 59 lines in 17 files changed: 39 ins; 5 del; 15 mod

8278021: Fix warnings in macOS glass native code and treat warnings as errors

Reviewed-by: kcr, aghaisas

-

PR: https://git.openjdk.org/jfx/pull/687

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]

[Kevin Rushforth]

On Mon, 19 Feb 2024 11:45:04 GMT, Thiago Milczarek Sayao  
wrote:

>> Jose Pereda has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Add compile-time checks to GdkSeat
>
> The rationale was:
> 
> This tells which events get delivered to the window while grabbing. XWayland 
> might be sensitive to `GDK_TOUCH_MASK` while Xorg is not.
> 
> So the Idea was to keep the current way (with `gdk_pointer_grab` or 
> `gdk_device_grab`, and adding the "deliver TOUCH events to me" might fix it.
> 
> Another place to investigate is:
> 
> 
> #define GDK_FILTERED_EVENTS_MASK 
> static_cast(GDK_ALL_EVENTS_MASK \
> & ~GDK_TOUCH_MASK)
> 
> 
> 
> It seems that Xorg converts touch events to regular mouse events, but 
> XWayland might be different.

@tsayao can you re-review?

-

PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-195959

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

[Kevin Rushforth]

On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl  wrote:

> This PR fixes the dialog freeze problem once and for all. 
> 
> This one is a bit tricky to understand, here is how it works:
> This bug happens on every platform, although the implementation of nested 
> event loops differs on every platform.
> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we 
> have an own implementation of a nested event loop (while loop), controlled by 
> a boolean flag.
> 
> Funny enough, the reason why this bug happens is always the same: Timing.
> 
> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 
> 2. This will call native code to get out of the nested event loop, e.g. on 
> Windows we try to break out of the while loop with a boolean flag, on Linux 
> we call `gtk_main_quit`.
> 3. Now, if we immediately open a new dialog, we enter a new nested event loop 
> via `_enterNestedEventLoop`, as a consequence we do not break out of the 
> while loop on Windows (the flag is set back again, the while loop is still 
> running), and we do not return from `gtk_main` on Linux.
> 4. And this will result in the Java code never returning and calling 
> `notifyLeftNestedEventLoop`, which we need to recover the UI.
> 
> So it is actually not trivial to fix this problem, and we can not really do 
> anything on the Java side. We may can try to wait until one more frame has 
> run so that things will hopefully be right, but that sounds rather hacky.
> 
> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. 
> Turns out, we don't need to. 
> There is a return value which we actually do not use (it does not have any 
> meaning to us, other that it is used inside an assert statement).
> Without the need of a return value, we also do not need to care when 
> `_enterNestedEventLoop` is returning - instead we cleanup and call 
> `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code 
> was called.
> 
> Lets see if this is the right approach (for all platforms).
> Testing appreciated.
> #
> - [x] Tested on Windows
> - [x] Tested on Linux
> - [x] Tested on Mac
> - [ ] Tested on iOS (although the nested event loop code is the same as for 
> Mac) (I would appreciate if someone can do this as I have no access to an iOS 
> device)
> - [ ] Adjust copyright
> - [ ] Write Systemtest

@Maran23 Please merge in the latest upstream master, since your branch is out 
of date.

-

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1959579953

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

[Kevin Rushforth]

On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl  wrote:

> This PR fixes the dialog freeze problem once and for all. 
> 
> This one is a bit tricky to understand, here is how it works:
> This bug happens on every platform, although the implementation of nested 
> event loops differs on every platform.
> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we 
> have an own implementation of a nested event loop (while loop), controlled by 
> a boolean flag.
> 
> Funny enough, the reason why this bug happens is always the same: Timing.
> 
> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 
> 2. This will call native code to get out of the nested event loop, e.g. on 
> Windows we try to break out of the while loop with a boolean flag, on Linux 
> we call `gtk_main_quit`.
> 3. Now, if we immediately open a new dialog, we enter a new nested event loop 
> via `_enterNestedEventLoop`, as a consequence we do not break out of the 
> while loop on Windows (the flag is set back again, the while loop is still 
> running), and we do not return from `gtk_main` on Linux.
> 4. And this will result in the Java code never returning and calling 
> `notifyLeftNestedEventLoop`, which we need to recover the UI.
> 
> So it is actually not trivial to fix this problem, and we can not really do 
> anything on the Java side. We may can try to wait until one more frame has 
> run so that things will hopefully be right, but that sounds rather hacky.
> 
> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. 
> Turns out, we don't need to. 
> There is a return value which we actually do not use (it does not have any 
> meaning to us, other that it is used inside an assert statement).
> Without the need of a return value, we also do not need to care when 
> `_enterNestedEventLoop` is returning - instead we cleanup and call 
> `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code 
> was called.
> 
> Lets see if this is the right approach (for all platforms).
> Testing appreciated.
> #
> - [x] Tested on Windows
> - [x] Tested on Linux
> - [x] Tested on Mac
> - [ ] Tested on iOS (although the nested event loop code is the same as for 
> Mac) (I would appreciate if someone can do this as I have no access to an iOS 
> device)
> - [ ] Adjust copyright
> - [ ] Write Systemtest

Hmm. There was a reason we added a return value to `_enterNestedEventLoop`, but 
I'll take a closer look. Have you run all of the headful tests?

-

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1959569754

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v4]

[Kevin Rushforth]

On Tue, 20 Feb 2024 12:16:12 GMT, Jose Pereda  wrote:

>> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and 
>> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and 
>> wrapped functions for GTK 3.20+ (so systems without it still run with GTK 
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Revert changes and add touch mask to gdk pointer grab function

Marked as reviewed by kcr (Lead).

-

PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1895996832

Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20]

[Kevin Rushforth]

On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao  
wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative 
>> positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 
>> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base 
> due to a merge or a rebase. The pull request now contains 94 commits:
> 
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>
># Conflicts:
>#  modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not 
> officially supported)
>- Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - Account the case of !filtered
>  - Fix change of focus when on preedit + add filter on key release
>  - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565

Confirmed. A CSR is no longer needed.

-

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1959434563

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
>
>
>

Re: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5]

[Ajit Ghaisas]

On Mon, 5 Feb 2024 16:46:40 GMT, Martin Fox  wrote:

>> Turning on warnings-as-errors for the macOS glass native code. Deprecated 
>> declarations are excluded and still appear as warnings.
>> 
>> In the code that tries to locate the application's dock icon there were 
>> three instances where `NO` was being passed into a method that required a 
>> pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that 
>> the path pointed to an existing file but not a directory. Since JavaFX has 
>> gone this long without screening out directories correctly I decided not to 
>> fix that behavior except at the very end.
>> 
>> The only other changes of note are sending some NSNotification objects to 
>> delegate API's that require them even though we know they're ignored on the 
>> other side. It was the easiest way to get rid of the warning.
>
> Martin Fox has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Work-around for using a call not present in the Xcode 13.3 SDK.
>  - Need correctly formed NSNotification when running tests

The fix looks good.
Verified on macOS 14.3.

-

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/687#pullrequestreview-1895559966

[jfx21u] RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView

[Jose Pereda]

Hi all,

This pull request contains a clean backport of commit 
[ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd)
 from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Jose Pereda on 21 Dec 2023 and was 
reviewed by Andy Goryachev.

Thanks!

-

Commit messages:
 - Backport ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd

Changes: https://git.openjdk.org/jfx21u/pull/44/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx21u=44=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321970
  Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx21u/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/44/head:pull/44

PR: https://git.openjdk.org/jfx21u/pull/44

[Linux] JavaFX is displaying unicode characters incorrectly

[Thiago Milczarek Sayão]

Hi,

This possible bug is reported here:
https://bugs.openjdk.org/browse/JDK-8322251

Running the code bellow produces incorrect text on Ubuntu 24.04 (still not
released). I would like to fix it, but some hints would be appreciated.

I might be missing a font, but the same text render fine on GTK based
applications.

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.TextArea;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class TextAreaSample extends Application {

@Override
public void start(Stage primaryStage) {
TextArea textArea = new TextArea();
textArea.setText("你好，世界");

StackPane root = new StackPane();
root.getChildren().add(textArea);

Scene scene = new Scene(root, 300, 200);
primaryStage.setTitle("Test");
primaryStage.setScene(scene);

primaryStage.show();
}

public static void main(String[] args) {
launch(TextAreaSample.class, args);
}
}


Ubuntu 22.04
[image: image.png]

Ubuntu 24.04 (nightly build):
[image: image.png]

-- Thiago


import javafx.application.Application;
import javafx.scene.Scene;

import javafx.scene.control.TextArea;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class TextAreaSample extends Application {

@Override
public void start(Stage primaryStage) {
TextArea textArea = new TextArea();
textArea.setText("你好，世界");

StackPane root = new StackPane();
root.getChildren().add(textArea);

Scene scene = new Scene(root, 300, 200);
primaryStage.setTitle("Test");
primaryStage.setScene(scene);

primaryStage.show();
}

public static void main(String[] args) {
launch(TextAreaSample.class, args);
}
}

Re: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11]

[Karthik P K]

On Tue, 20 Feb 2024 15:48:26 GMT, Andy Goryachev  wrote:

>> I see that the tests don't run on all the platforms. I will look into this 
>> and update the PR
>
> A valid concern about specific fonts, similar to 
> https://github.com/openjdk/jfx/pull/1236#issuecomment-1937022815
> 
> What was the resolution there?  To use a hard-coded font based on the 
> platform, or pick an available one from the list?

The tests passes on Mac and Linux. The  failures I mentioned above were because 
this branch was not upto date with the master and completely unrelated to this 
PR.
Im facing some issue with my Windows system. I will check in windows once it is 
sorted and update the details here.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1499026529

Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20]

[Thiago Milczarek Sayao]

On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao  
wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative 
>> positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 
>> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base 
> due to a merge or a rebase. The pull request now contains 94 commits:
> 
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>
># Conflicts:
>#  modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not 
> officially supported)
>- Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - Account the case of !filtered
>  - Fix change of focus when on preedit + add filter on key release
>  - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565

The CSR requirement can be removed (probably) because the change that required 
it was reverted.

-

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1959135127

[jfx21u] Integrated: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls

[Jose Pereda]

On Tue, 20 Feb 2024 10:18:36 GMT, Jose Pereda  wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit 
> [90cbc663](https://github.com/openjdk/jfx/commit/90cbc66305d0a1380cf3a8cd99ad40db240e554c)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Kevin Rushforth on 15 Jan 2024 
> and was reviewed by Phil Race, Prasanta Sadhukhan and Sergey Bylokhov.
> 
> Thanks!

This pull request has now been integrated.

Changeset: e00407b6
Author:Jose Pereda 
URL:   
https://git.openjdk.org/jfx21u/commit/e00407b6919cfe6fedefc74dba55c160640c5267
Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod

8221261: Deadlock on macOS in JFXPanel app when handling IME calls

Reviewed-by: jvos
Backport-of: 90cbc66305d0a1380cf3a8cd99ad40db240e554c

-

PR: https://git.openjdk.org/jfx21u/pull/43

Re: [jfx21u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls

[Johan Vos]

On Tue, 20 Feb 2024 10:18:36 GMT, Jose Pereda  wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit 
> [90cbc663](https://github.com/openjdk/jfx/commit/90cbc66305d0a1380cf3a8cd99ad40db240e554c)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Kevin Rushforth on 15 Jan 2024 
> and was reviewed by Phil Race, Prasanta Sadhukhan and Sergey Bylokhov.
> 
> Thanks!

Marked as reviewed by jvos (Reviewer).

-

PR Review: https://git.openjdk.org/jfx21u/pull/43#pullrequestreview-1895310437