> 82:      * @param control the control being tested

Remove `@param` line

modules/javafx.controls/src/test/java/test/javafx/scene/control/behavior/PasswordFieldBehaviorTest.java line 63:

> 61:     @Override
> 62:     public void testCopy() {
> 63:         // copy is disabled

An empty test case simply gets reported as passed.
Do you want to assert that the "copy is disabled" somehow?
There are a few other test cases in this file which are of similar nature.
If they need to be worked upon in future, we can mark them as TODO.
If they are just for information, we can keep the entire test cases commented so that they do not execute and report as passed.

modules/javafx.controls/src/test/java/test/javafx/scene/control/behavior/TextAreaBehaviorTest.java line 64:

> 62:     @Override
> 63:     public void testConsumeEnter() {
> 64:         // does not consume ENTER

Similar comment about empty test cases in this file.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1348247510
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1348248822
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1348251246
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1348254369
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1348257106

From michaelstrau2 at gmail.com  Fri Oct  6 14:13:19 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 6 Oct 2023 16:13:19 +0200
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
Message-ID: 

Hi Andy,

I think the opaqueness of JavaFX controls is one of the greatest
shortcomings of the framework, so I welcome an enhancement.

Some thoughts:

1. It seems that the behavior implementation is still hard-coded into
the skin implementation. For example, TextFieldSkin uses
TextFieldBehavior; it doesn't seem like I can have a TextFieldSkin
that uses my custom behavior. Do you plan on changing that?

2. The InputMap can have a lot of mappings that are set on each
individual control. However, in almost all cases, the input mappings
are semantically equivalent for all instances of a control. Wouldn't
it make sense to associate input mappings with the control class,
instead of the control instance? Aside from more closely conveying the
semantics of a "default mapping", this should also cut down on the
number of object instances we need to keep around. Of course, it
should still be possible to override a default mapping with a
per-instance mapping.

3. Why are FunctionTags defined on the control class, yet they don't
seem to match the functionality offered by the control class? For
example, there's TextInputControl.DELETE_NEXT_WORD, but there's no
corresponding functionality in TextInputControl. The functionality is
actually implemented in TextInputControlBehavior. But if the
implementation is only available in this particular behavior, why is
the FunctionTag defined on the control class?

4. I'm missing a clear delineation between controls and their
behaviors. For example, there's TextInputControl.selectNextWord(), but
no TextInputControl.deleteNextWord(). The latter is implemented in
TextInputControlBehavior. Why is selectNextWord() implemented in the
control, but deleteNextWord() in the behavior? This is just one
example of lots of peculiarities.

5. More generally, we should start by clearly defining concepts. Up
until now, behaviors were just an implementation detail, so this
wasn't necessary. But what is a behavior? What is the relationship
between a control, its skin and behavior? How would a control author
decide what needs to be put into the control class, and what needs to
be put into the behavior class (cf. selectNextWord/deleteNextWord)?

On Sat, Sep 30, 2023 at 1:18?AM Andy Goryachev
 wrote:
>
> Dear fellow JavaFX developers:
>
>
>
> For some time now, we?ve been working to identify missing features in JavaFX that hinder application development.  We?ve been working on adding some of the missing features (for which we?ll have a separate announcement), but I feel that engaging wider community is a rather important part of the process.
>
>
>
> I would like to share with you one such missing feature - ability to extend behavior of the existing components (and make the task of creating new components easier) by adding a public InputMap and BehaviorBase.
>
>
>
> Please find the actual proposal here
>
> https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09
>
>
>
> We are very much interested in your feedback.  Thank you in advance.
>
>
>
> -andy
>
>

From andy.goryachev at oracle.com  Fri Oct  6 17:16:30 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 6 Oct 2023 17:16:30 +0000
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 

Message-ID: 

Michael:

Thank you for a very thoughtful analysis!  These are very good questions; allow me to clarify.

1. It seems that the behavior implementation is still hard-coded into
the skin implementation. For example, TextFieldSkin uses
TextFieldBehavior; it doesn't seem like I can have a TextFieldSkin
that uses my custom behavior. Do you plan on changing that?

There are many facets to this question.  Yes, in my opinion, we should make all the behaviors public similarly to Swing, though it does represent a substantial amount of work.  I?d say it is still a possibility, albeit a distant one.

The next best thing is this proposal, which makes it possible to redefine the behavior by re-registering some if not all of the functions declared by the control.  Another possibility would be to create a new skin with a custom behavior (though it might be a bit too much for an app developer).

One good thing about this proposal is that it should offer immediate benefits to the application developers in many cases by giving the ability to redefine a small subset of control?s functionality without the need to go deep into implementation (and without making the behavior public).

2. The InputMap can have a lot of mappings that are set on each
individual control. However, in almost all cases, the input mappings
are semantically equivalent for all instances of a control. Wouldn't
it make sense to associate input mappings with the control class,
instead of the control instance? Aside from more closely conveying the
semantics of a "default mapping", this should also cut down on the
number of object instances we need to keep around. Of course, it
should still be possible to override a default mapping with a
per-instance mapping.

This is an interesting idea, we might explore it further ? there is nothing in the proposed APIs that preclude us from doing this optimization, even though the actual savings in terms of memory may not be that noticeable: unlike Node, a typical number of Controls in the scene graphs is not that great.  But still, worth exploring.  Thank you!

3. Why are FunctionTags defined on the control class, yet they don't
seem to match the functionality offered by the control class? For
example, there's TextInputControl.DELETE_NEXT_WORD, but there's no
corresponding functionality in TextInputControl. The functionality is
actually implemented in TextInputControlBehavior. But if the
implementation is only available in this particular behavior, why is
the FunctionTag defined on the control class?

The function tags belong to the control class so that the user can redefine them.

And thank you for pointing out the situation with DELETE_NEXT_WORD.  You are right - the actual control class should declare a public method for each tag, so the functionality is available programmatically at the control level.  It?s not currently done in this PR in order to minimize the amount of changes, and I expect we?ll do it in a separate enhancement.

4. I'm missing a clear delineation between controls and their
behaviors. For example, there's TextInputControl.selectNextWord(), but
no TextInputControl.deleteNextWord(). The latter is implemented in
TextInputControlBehavior. Why is selectNextWord() implemented in the
control, but deleteNextWord() in the behavior? This is just one
example of lots of peculiarities.

I tried to address this in the proposal, perhaps I did not emphasized it strongly enough.  As with your previous comment, a concrete control class should declare a public method for each function tag, which simply executes that function tag.  In essence, there should be 1:1:1 correspondence between function tags, public method in the control class, and a public method in the corresponding behavior.  The latter is not available directly because right now the actual behavior is not public, but it is available programmatically via getDefaultFunction().

I?d expect there will be subsequent enhancements to add these methods to each control, once we all agree with the proposed design and finalize the APIs.

5. More generally, we should start by clearly defining concepts. Up
until now, behaviors were just an implementation detail, so this
wasn't necessary. But what is a behavior? What is the relationship
between a control, its skin and behavior? How would a control author
decide what needs to be put into the control class, and what needs to
be put into the behavior class (cf. selectNextWord/deleteNextWord)?

Good point.  Perhaps the best place to explain this is in FunctionTag Javadoc?

Any function that the skin, or the application developer, or the end user might want to redefine, or set a key binding for, or unbind ? should have a corresponding function tag.  I?d expect there should be a public method in the control that executes the tag, but it is not a strict requirement.

The relationship between the skin and control is a more subtle one.  For example, selectNextWord may not need a skin (it can operate directly on the data model, using a BreakIterator), but TextArea.LINE_END needs the skin to determine where the text layout wrapped the line.  A null skin is also technically possible (though it makes no sense).  My point is that, given this dependency on the skin, the behavior is typically instantiated by the skin, but it does not have to be.  Nothing prevents us from initializing the behavior in the control, and designing this behavior to get the skin when needed.  However, this design might have a price of adding some public APIs to the concrete skins.

This proposal does not require making behaviors public, does not mandate additional public APIs in skins, so we are free to change it later if deemed necessary.

Hope this discussion spurs more discussion.  My goal is to make FX more extensible and easier to use, and your feedback and comments are very important.

Thank you!

-andy

From: Michael Strau? 
Date: Friday, October 6, 2023 at 07:13
To: Andy Goryachev 
Cc: openjfx-dev at openjdk.org 
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
Hi Andy,

I think the opaqueness of JavaFX controls is one of the greatest
shortcomings of the framework, so I welcome an enhancement.

Some thoughts:

1. It seems that the behavior implementation is still hard-coded into
the skin implementation. For example, TextFieldSkin uses
TextFieldBehavior; it doesn't seem like I can have a TextFieldSkin
that uses my custom behavior. Do you plan on changing that?

2. The InputMap can have a lot of mappings that are set on each
individual control. However, in almost all cases, the input mappings
are semantically equivalent for all instances of a control. Wouldn't
it make sense to associate input mappings with the control class,
instead of the control instance? Aside from more closely conveying the
semantics of a "default mapping", this should also cut down on the
number of object instances we need to keep around. Of course, it
should still be possible to override a default mapping with a
per-instance mapping.

3. Why are FunctionTags defined on the control class, yet they don't
seem to match the functionality offered by the control class? For
example, there's TextInputControl.DELETE_NEXT_WORD, but there's no
corresponding functionality in TextInputControl. The functionality is
actually implemented in TextInputControlBehavior. But if the
implementation is only available in this particular behavior, why is
the FunctionTag defined on the control class?

4. I'm missing a clear delineation between controls and their
behaviors. For example, there's TextInputControl.selectNextWord(), but
no TextInputControl.deleteNextWord(). The latter is implemented in
TextInputControlBehavior. Why is selectNextWord() implemented in the
control, but deleteNextWord() in the behavior? This is just one
example of lots of peculiarities.

5. More generally, we should start by clearly defining concepts. Up
until now, behaviors were just an implementation detail, so this
wasn't necessary. But what is a behavior? What is the relationship
between a control, its skin and behavior? How would a control author
decide what needs to be put into the control class, and what needs to
be put into the behavior class (cf. selectNextWord/deleteNextWord)?

On Sat, Sep 30, 2023 at 1:18?AM Andy Goryachev
 wrote:
>
> Dear fellow JavaFX developers:
>
>
>
> For some time now, we?ve been working to identify missing features in JavaFX that hinder application development.  We?ve been working on adding some of the missing features (for which we?ll have a separate announcement), but I feel that engaging wider community is a rather important part of the process.
>
>
>
> I would like to share with you one such missing feature - ability to extend behavior of the existing components (and make the task of creating new components easier) by adding a public InputMap and BehaviorBase.
>
>
>
> Please find the actual proposal here
>
> https://urldefense.com/v3/__https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09__;!!ACWV5N9M2RV99hQ!LvBDJOf2E21l1kuyLzVGMuLC-fz3U_lgl_5RBWp9nwRKm2IsRgmKcm7bMHRKSh7bmVIfkHiUAE5F1E7tZIeGKujFuEb7$
>
>
>
> We are very much interested in your feedback.  Thank you in advance.
>
>
>
> -andy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Fri Oct  6 18:16:17 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 6 Oct 2023 18:16:17 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v9]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: 

On Fri, 6 Oct 2023 05:20:06 GMT, Ajit Ghaisas  wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   allowed characters
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/behavior/PasswordFieldBehaviorTest.java line 63:
> 
>> 61:     @Override
>> 62:     public void testCopy() {
>> 63:         // copy is disabled
> 
> An empty test case simply gets reported as passed.
> Do you want to assert that the "copy is disabled" somehow?
> There are a few other test cases in this file which are of similar nature.
> If they need to be worked upon in future, we can mark them as TODO.
> If they are just for information, we can keep the entire test cases commented so that they do not execute and report as passed.

good point, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1349169611

From angorya at openjdk.org  Fri Oct  6 18:58:56 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 6 Oct 2023 18:58:56 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v10]
In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>
Message-ID: 

> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
> 
> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
> 
> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
> 
> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
> 
> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
 - allowed characters
 - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
 - check
 - test typing
 - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
 - cleanup
 - key modifier
 - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test
 - ... and 34 more: https://git.openjdk.org/jfx/compare/25862787...8b8112b8

-------------

Changes: https://git.openjdk.org/jfx/pull/1221/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=09
  Stats: 2741 lines in 14 files changed: 2725 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1221.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221

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

From john.hendrikx at gmail.com  Sat Oct  7 17:43:17 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 7 Oct 2023 19:43:17 +0200
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
Message-ID: <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

I've read the proposal.

I think it would be good to take a step back first and look at the 
classes and interfaces involved: Control, Behavior, InputMap, Skin -- 
the time is now to take a good look at these before making more public.

They're currently very interwoven which is usually a sign that they are 
not well enough abstracted. They cyclically reference each other 
indicating they have overlapping concerns.? I think this should be 
addressed first before making the existing InputMap and BehaviorBase public.

The main odd thing that jumps out immediately is the fact that Behaviors 
and InputMaps need a reference to their linked Node. This will result in 
chicken-egg style problems where you can't create the Control without an 
InputMap, and you can't create an InputMap without a Control.? It will 
also lead to problems where if a Behavior is replaced that we must take 
care to dispose it, or use only weak references to the Control.? The 
Skin API suffers from this problem, and I think we can do better.

InputMap
========

Looking at InputMap first, I see no real reason why it needs the Node.? 
It is only used for installing and removing the event handlers.? This 
action should not be triggered by the InputMap, and instead should be 
inverted so it is triggered by the Control. This can be achieved in 
multiple ways; InputMap could simply produce the required event handlers 
on demand:

 ???? Map> createEventHandlers();

The Control can then add these to the appropriate handlers, and track 
them for later removal (using a Subscription for example).

Or you could ask the InputMap to install them by providing the Node (the 
idea here being that Node is not stored, but provided as context):

 ???? Subscription installEventHandlers(Node node);

Note that the above returns a Subscription, which can be used to remove 
the event handlers again without requiring an interaction with the InputMap.

The removal should be fairly trivial, and will lead to a better 
encapsulated and easier to reason about InputMap class that does not 
suffer from the chicken egg problem, and is not generically typed.

That brings us to InputMap's being mutable.? I would first spend some 
serious effort to see if this is strictly needed, and what benefits that 
would provide, as currently what I see is that InputMaps are mainly 
mutable in order to add mappings during construction (something a 
Contructor or Builder can do). Immutable InputMaps would simplify things 
enormously, and would prevent mappings being modified (by a Skin or 
Behavior) that must be undone when the Skin or Behavior changes.? This 
would also mean there is no need to have multiple input maps in memory.? 
Cells have behaviors, and you can easily have 1000's on screen, 
requiring 1000's of Behavior and InputMap copies currently.

If they must be mustable however, then controls must listen for changes; 
this will inevitably mean that an InputMap refers each Control that 
listens for changes.? For a shared global InputMap this can mean that 
such Controls won't be GC'd, so we need to apply one of the usual 
strategies here to prevent this problem:

1. Use a weak listener (relying on GC)
2. Use a conditional listener (deterministic)

If InputMaps must be mutable, then the second one has by far the 
preference, and can be done by only listening for InputMap changes when 
the control is showing.? The best way to achieve this is for Controls to 
delay registering the InputMap's event handlers until they're about to 
become shown, and remove the event handlers when they're about to be 
unshown.? Note that this is not the same as visible/invisible and so 
won't lead to registration/unregistration upon toggling visibility.

Behavior
=======

First, I think there should be a real Behavior interface.? A required 
abtract base class will just lead to the tempatation to use JavaFX 
internals when things get inconvenient for internal Controls (using the 
accessor pattern), and will result in users not being able to replicate 
all the behaviors that FX controls can exhibit (as they won't have 
access to the same internals).

BehaviorBase immediately shows the same problem as InputMap. Even though 
you'd expect that a Behavior should be sharable between controls (it is 
after all the case that for most controls of a certain type all their 
behaviors will be the same) it has elected to explicitely couple itself 
to a specific control instance.? The base class itself only does this 
because InputMap needs the Node, however, subclasses are using this 
judiciously everywhere to access the Node linked to a Behavior.

As Behaviors respond to events however, there is I think no real need to 
have a direct reference to the Node -- the Event provides this already; 
it just needs to be extracted, or perhaps in some cases, this 
information needs to be added first as it is pertinent to the event.

Looking at various uses of `getNode` (used in about 200-300 places) I 
haven't found one yet that isn't responding to an event.? This makes 
sense, as that's probably the primary way a Behavior does its thing, it 
install event handlers and responds to them.

So I think that with a bit of refactoring, Behaviors can be made to not 
require the Node.? This will then allow Behaviors to be installed with a 
trivial setter, and would not need the install/dispose mechanism that 
Skins use.

TLDR;

I think that we should really be seeing if it is possible to remove the 
dependency on Controls before making these API's public.? This would 
remove the generic parameter from the signatures of both InputMap and 
Behavior(Base), and remove the chicken-egg dependency they currently 
have with Control.? It will simplify the design, and probably make a lot 
of classes and code a lot easier to reason about.

--John

On 30/09/2023 00:44, Andy Goryachev wrote:
>
> Dear fellow JavaFX developers:
>
> For some time now, we?ve been working to identify missing features in 
> JavaFX that hinder application development.? We?ve been working on 
> adding some of the missing features (for which we?ll have a separate 
> announcement), but I feel that engaging wider community is a rather 
> important part of the process.
>
> I would like to share with you one such missing feature - ability to 
> extend behavior of the existing components (and make the task of 
> creating new components easier) by adding a public InputMap and 
> BehaviorBase.
>
> Please find the actual proposal here
>
> https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09
>
> We are very much interested in your feedback.? Thank you in advance.
>
> -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jgneff at openjdk.org  Sat Oct  7 20:03:14 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Sat, 7 Oct 2023 20:03:14 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime
In-Reply-To: 
References: 
Message-ID: <5BtpKCJgp9lyUhjx3moIS07Xu_-6HB43QWtaSeE8nA4=.836e2df8-20e0-4168-a534-830e05fb396a@github.com>

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger  wrote:

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

@FlorianKirmaier Florian, I would appreciate any comments you might have, too, or even a formal review if you have the time. Don't feel obligated, though, as you've already helped enough by discovering and patching the bug. ?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1253#issuecomment-1751806158

From michaelstrau2 at gmail.com  Sat Oct  7 21:00:57 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 7 Oct 2023 23:00:57 +0200
Subject: New properties: focusOwner and focusOwnerWithin
Message-ID: 

JavaFX has two closely related focus concepts: `Node.focused`, which
can apply to any number of nodes in a scene graph, and
`Scene.focusOwner`, which is the single node in a scene graph that
accepts user input.

JavaFX 19 added `Node.focusWithin`, which is a flag set on any node
that contains a `focused` node. However, there is no flag on `Node`
for the single focus owner, and also no flag that is set if a node
contains the single focus owner.

Tickets like [0] show that there might be a need for these additional
flags. One could argue that it might not be the best idea to set the
`focused` flag on a node that is not the focus owner (TableView does
this quite a lot), but I think that ship has sailed.

I've prepared a draft PR [1] that shows the proposed API of this
enhancement. The functionality can in theory be implemented by
applications, since the `Scene.focusOwner` property is already
available, but this is far from easy (especially when CSS is
involved).

I'm interested in your thoughts on whether this is an API that we want
to have in JavaFX.

[0] https://bugs.openjdk.org/browse/JDK-8317426
[1] https://github.com/openjdk/jfx/pull/1255

From pedro.duquevieira at gmail.com  Sat Oct  7 21:04:37 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sat, 7 Oct 2023 22:04:37 +0100
Subject: [Request for Comments] Behavior / InputMap
Message-ID: 

I second the opinions of others that JavaFX is too closed which, I think,
hinders the work of library and app developers.

I wonder if the reasons that were used to make this design decision back
when JavaFX was being created still hold true. Back in the beginning there
were more developers involved in developing JavaFX, significant features
were added at a fast pace so the fact that it was closed wasn't such a big
drawback as things were changing quickly and missing features that were
spotted could be added relatively quick.

Commenting more specifically on your question... I think Skins could
benefit generally from being easier to extend. The promise of skins is that
you could easily replace a control behavior and visuals without changing
its model (the model being the part of the control that developers usually
interact with) but the problem is that the JavaFX SDK control's skins are
very difficult to extend. Say, if you only want to add a specific visual
feature (something that CSS can't do) it takes a significant effort.
What you usually see is that developers opt to create completely new
controls rather than just new skins.
My attempt at providing new skins for existing javafx sdk controls is here:
https://github.com/dukke/FXSkins
Still it required quite a bit of effort.. at least more than it could
ideally take (I think).
The advantage of this kind of approach (providing new Skins) and the
library I created "FXSkins" is that you can enhance the controls of your
existing app very easily by setting new skins in the CSS stylesheet. You
won't need to change anything directly in the code.

Regarding the current state of the JavaFX SDK Skins, there isn't a clear
MVC separation, the skin does the Controller and View part at the same
time. Perhaps ideally there would be a clear View part that could easily be
extended to add different advanced visuals to the control (by advanced I
mean, anything that can't be done with CSS). And then perhaps also the
Behavior part where you can easily change the control's functionality. I
remember at some point Richard Bair saying that it was a goal to make
Behaviors public.

Thanks!
-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.hendrikx at gmail.com  Sun Oct  8 08:10:47 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 8 Oct 2023 10:10:47 +0200
Subject: New properties: focusOwner and focusOwnerWithin
In-Reply-To: 
References: 
Message-ID: <7618de08-d74f-0581-fdff-17b1fcb84133@gmail.com>

I would be interested to know what use cases for these are, and what 
would be then left of the use cases for the existing focusWithin and 
focusVisible properties?? The ticket referred doesn't give one and only 
reports a bug.

Before implementing a second set of these types of properties, I would 
like to know:

- What would be the distinct uses for focusOwnerWithin vs focusWithin, 
are both actually needed?
- Isn't focusOwnerProperty basically a "better" focusedProperty now 
because of how focusedProperty is abused by some controls?
- Why indeed is TableView doing this and should it really be doing this 
instead of doing this another way?? If it just wants to show nodes in 
their focused style, that can (and should IMHO) be achieved differently.

There seems to be a need to have some controls retain their focused look 
without them actually being the focus owner. TableView seems to be one 
of them, and I personally have another (I would like Nodes to keep 
looking focused even when their Stage has lost focus). The focused look 
relies on the `focused` pseudo class, which is now strictly controlled 
by the focusedProperty. It may be a good idea to look in another 
direction; one could change the style sheet for example to also have 
controls in focused look when they have a different pseudo class, say 
`fake-focused`.? TableView could then use this (and so could I).

With the TableView problem solved, the original focusWithin, 
focusVisible and focused properties then can serve the purposes they 
were intended for, instead of basically replacing them with a new set 
that acts slightly differently to work around a problem with TableView.

If this does move forward though, I wonder why these need to be 
properties specifically, given how hesistant we were to add properties 
to Node?? The `shownProperty` which IMHO has far more uses given the 
essential role it can play in deterministic clean-up was rejected over 
such an argument.? Why isn't simply checking the psuedoClassState 
sufficient for these properties: 
`getPseudoClassStates().contains(FOCUS_OWNER_PSEUDOCLASS_STATE)`?

--John

On 07/10/2023 23:00, Michael Strau? wrote:
> JavaFX has two closely related focus concepts: `Node.focused`, which
> can apply to any number of nodes in a scene graph, and
> `Scene.focusOwner`, which is the single node in a scene graph that
> accepts user input.
>
> JavaFX 19 added `Node.focusWithin`, which is a flag set on any node
> that contains a `focused` node. However, there is no flag on `Node`
> for the single focus owner, and also no flag that is set if a node
> contains the single focus owner.
>
> Tickets like [0] show that there might be a need for these additional
> flags. One could argue that it might not be the best idea to set the
> `focused` flag on a node that is not the focus owner (TableView does
> this quite a lot), but I think that ship has sailed.
>
> I've prepared a draft PR [1] that shows the proposed API of this
> enhancement. The functionality can in theory be implemented by
> applications, since the `Scene.focusOwner` property is already
> available, but this is far from easy (especially when CSS is
> involved).
>
> I'm interested in your thoughts on whether this is an API that we want
> to have in JavaFX.
>
> [0] https://bugs.openjdk.org/browse/JDK-8317426
> [1] https://github.com/openjdk/jfx/pull/1255

From r.lichtenberger at gmail.com  Mon Oct  9 08:59:10 2023
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Mon, 9 Oct 2023 10:59:10 +0200
Subject: Testing Code that uses HostServices
Message-ID: 

I have the task of testing some code that eventually calls 
javafx.application.HostServices.showDocument(...) with a URL that will 
open the web browser in production.

During the test runs I don't want the browser to be opened but instead 
have some custom code be executed.

Unfortunately HostServices ist final, so I cannot overwrite it. Is there 
another way to install "my own" host services?

Best regards,

Robert

From aghaisas at openjdk.org  Mon Oct  9 12:45:15 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 9 Oct 2023 12:45:15 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v10]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: 

On Fri, 6 Oct 2023 18:58:56 GMT, Andy Goryachev  wrote:

>> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
>> 
>> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
>> 
>> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
>> 
>> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
>> 
>> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - allowed characters
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - check
>  - test typing
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - cleanup
>  - key modifier
>  - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test
>  - ... and 34 more: https://git.openjdk.org/jfx/compare/25862787...8b8112b8

Tests look good to me!

-------------

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1221#pullrequestreview-1664367293

From kcr at openjdk.org  Mon Oct  9 13:29:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Oct 2023 13:29:11 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger  wrote:

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

@arapte or @johanvos Can one of you also review this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1253#issuecomment-1753011903

From arapte at openjdk.org  Mon Oct  9 15:05:28 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 9 Oct 2023 15:05:28 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8
Message-ID: 

This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
With this change the warnings get fixed and no error is observed with gradle 8.3
Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.

Warnings that are fixed:
1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
-> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`

2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
-> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning

3. Various dependency warnings like one below:
Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
-> There are several such warning messages observed.
-> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.

An easy way to review would be.
1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
1.1 All above warnings can be observed and build completes successfully.

2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
2.1 Without this change build would fail citing above warnings as errors
2.2 With this change build completes successfully and above warnings do not occur

-------------

Commit messages:
 - remove gradle7.6 warnings

Changes: https://git.openjdk.org/jfx/pull/1256/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314486
  Stats: 54 lines in 1 file changed: 34 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1256.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1256/head:pull/1256

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

From arapte at openjdk.org  Mon Oct  9 15:05:30 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 9 Oct 2023 15:05:30 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 9 Oct 2023 14:56:39 GMT, Ambarish Rapte  wrote:

> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
> With this change the warnings get fixed and no error is observed with gradle 8.3
> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
> 
> Warnings that are fixed:
> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
> 
> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
> 
> 3. Various dependency warnings like one below:
> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> -> There are several such warning messages observed.
> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
> 
> An easy way to review would be.
> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
> 1.1 All above warnings can be observed and build completes successfully.
> 
> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
> 2.1 Without this change build would fail citing above warnings as errors
> 2.2 With this change build completes successfully and above warnings do not occur

build.gradle line 5168:

> 5166:         if (project.tasks.getByName("modularPublicationJar$t.capital") != null) {
> 5167:             project.tasks.getByName("modularPublicationJar$t.capital").dependsOn(buildModuleClassesTask)
> 5168:         }

The null check here is required as `project` can be the `rootProject`, which does not have those tasks and so would result in build failure with an error.
The failure can be observed by removing the null checks.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1256#discussion_r1350422541

From martin at martinfox.com  Mon Oct  9 16:25:30 2023
From: martin at martinfox.com (Martin Fox)
Date: Mon, 9 Oct 2023 09:25:30 -0700
Subject: New properties: focusOwner and focusOwnerWithin
In-Reply-To: 
References: 
Message-ID: 

> On Oct 7, 2023, at 2:00 PM, Michael Strau?  wrote:
> 
> JavaFX has two closely related focus concepts: `Node.focused`, which
> can apply to any number of nodes in a scene graph, and
> `Scene.focusOwner`, which is the single node in a scene graph that
> accepts user input.

The current JavaDoc for Node.focused is straight-forward and intuitive.

     Indicates whether this Node currently has the input focus.
     To have the input focus, a node must be the Scene's focus
     owner, and the scene must be in a Stage that is visible
     and active.

The way TableView is using this property violates all of these criteria.

The proposed focusOwner property is not a replacement because it only meets one of these criteria; a node can be the focusOwner on a stage that is not active in which case it doesn?t actually have the input focus (but it will when the stage is activated). So the proposed focus-owner-within pseudo-class will apply even in windows that aren?t active. It might have it?s uses but it?s not a replacement for focus-within and won?t address the issue in the original bug report.

I think JDK-8317426 should be re-opened. The current implementation of Node.focused is out-of-spec so everything downstream from it (including focus-within) is out-of-spec. But the real issue is that the behavior of Node.focused is utterly unintuitive.

Put another way, if we were to leave the implementation as-is and just update the Node.focused JavaDoc what would the new wording be?

From kcr at openjdk.org  Mon Oct  9 17:20:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Oct 2023 17:20:06 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 9 Oct 2023 14:56:39 GMT, Ambarish Rapte  wrote:

> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
> With this change the warnings get fixed and no error is observed with gradle 8.3
> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
> 
> Warnings that are fixed:
> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
> 
> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
> 
> 3. Various dependency warnings like one below:
> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> -> There are several such warning messages observed.
> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
> 
> An easy way to review would be.
> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
> 1.1 All above warnings can be observed and build completes successfully.
> 
> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
> 2.1 Without this change build would fail citing above warnings as errors
> 2.2 With this change build completes successfully and above warnings do not occur

Looks like there some GHA failures which will need to be resolved. Possibly a missing dependency?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1256#issuecomment-1753380526

From angorya at openjdk.org  Mon Oct  9 17:49:08 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 17:49:08 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v10]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: 

On Fri, 6 Oct 2023 18:58:56 GMT, Andy Goryachev  wrote:

>> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
>> 
>> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
>> 
>> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
>> 
>> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
>> 
>> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - allowed characters
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - check
>  - test typing
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - cleanup
>  - key modifier
>  - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test
>  - ... and 34 more: https://git.openjdk.org/jfx/compare/25862787...8b8112b8

@karthikpandelu could you also take a look at this please?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1221#issuecomment-1753414635

From andy.goryachev at oracle.com  Mon Oct  9 18:38:46 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 9 Oct 2023 18:38:46 +0000
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
Message-ID: 

Thank you for the feedback!

You are right: even though Skins are public classes now, they are very difficult to extend ? at least, much more difficult that Swing UIs.  It?s a source of constant discussions within the team ? how much of it should be made public (protected) to allow for extension vs. how much of it should be hidden as implementation detail to minimize the API surface and allow for evolution.  While opening it all up might alleviate developers? pain when extending, it poses a great(er) danger of introducing of all sorts of compatibility issues with respect to bug fixes and other changes.

If we speak about extending skins specifically, a good question might be: what exactly is missing?  Which APIs do we need to enable easier extension of skins?

One thing I would like to clarify is that the Behavior / InputMap proposal is not about extending skins.  It is also not about making the concrete behaviors public (a task which is probably as large as adding missing public APIs to skins).

The main goal is to allow for extending and slightly modifying the behavior ? like altering the way navigation works in a text control, or adding a new key binding.  As a result, the overall proposal is smaller than it could be.

Having said that, nothing prevents us from exploring options to open up skins, or making behaviors public.

To summarize:

  *   What are the missing APIs in Skins that we can add to simplify extension of skins?
  *   Would this proposal (BehaviorBase + InputMap) prevent us from moving forward?

What do you think?

-andy

From: openjfx-dev  on behalf of Pedro Duque Vieira 
Date: Saturday, October 7, 2023 at 14:05
To: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
I second the opinions of others that JavaFX is too closed which, I think, hinders the work of library and app developers.

I wonder if the reasons that were used to make this design decision back when JavaFX was being created still hold true. Back in the beginning there were more developers involved in developing JavaFX, significant features were added at a fast pace so the fact that it was closed wasn't such a big drawback as things were changing quickly and missing features that were spotted could be added relatively quick.

Commenting more specifically on your question... I think Skins could benefit generally from being easier to extend. The promise of skins is that you could easily replace a control behavior and visuals without changing its model (the model being the part of the control that developers usually interact with) but the problem is that the JavaFX SDK control's skins are very difficult to extend. Say, if you only want to add a specific visual feature (something that CSS can't do) it takes a significant effort.
What you usually see is that developers opt to create completely new controls rather than just new skins.
My attempt at providing new skins for existing javafx sdk controls is here: https://github.com/dukke/FXSkins
Still it required quite a bit of effort.. at least more than it could ideally take (I think).
The advantage of this kind of approach (providing new Skins) and the library I created "FXSkins" is that you can enhance the controls of your existing app very easily by setting new skins in the CSS stylesheet. You won't need to change anything directly in the code.

Regarding the current state of the JavaFX SDK Skins, there isn't a clear MVC separation, the skin does the Controller and View part at the same time. Perhaps ideally there would be a clear View part that could easily be extended to add different advanced visuals to the control (by advanced I mean, anything that can't be done with CSS). And then perhaps also the Behavior part where you can easily change the control's functionality. I remember at some point Richard Bair saying that it was a goal to make Behaviors public.

Thanks!
--
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Mon Oct  9 20:24:30 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 9 Oct 2023 20:24:30 +0000
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>
Message-ID: 

Dear John:

Thank you for a very thoughtful analysis!  I wanted to initiate a discussion, with the goal of making FX better.  Let me try to respond to your comments.

The main odd thing that jumps out immediately is the fact that Behaviors and InputMaps need a reference to their linked Node. This will result in chicken-egg style problems where you can't create the Control without an InputMap, and you can't create an InputMap without a Control.  It will also lead to problems where if a Behavior is replaced that we must take care to dispose it, or use only weak references to the Control.

If we were to place FX parts in the standard MVC paradigm, behavior is the controller, skin is the view, and the model is a part of control (at least in the case of TextInputControl).  In FX world I would say the control represents a fa?ade which provides programmatic access to the control functionality to the app developers.  Since the behavior needs access to both the view and the model, it having a pointer to the control is not an issue.

With the InputMap having a pointer ? it?s a convenience.  I mean, we could hide the input map altogether and add a bunch of methods to the Control for manipulating the key bindings ? would that be better?  I personally don?t think so, but it?s definitely an option.

There is no problem (anymore) with disposal or life cycle of skins and associated behaviors: there is Skin.install() and Skin.dispose().

The Skin API suffers from this problem, and I think we can do better.

Let?s keep in mind that a major redesign which will create a compatibility issues for all the controls and their skins is most likely not an option, but I would be very interested to hear how we can do it better within the constraints of the existing design.

Looking at InputMap first, I see no real reason why it needs the Node

Mainly for convenience, and to prevent the user from supplying completely unrelated control reference.  Yes, it?s a waste of a pointer, but the alternative is to move the APIs to Control.

     Subscription installEventHandlers(Node node);

Note that the above returns a Subscription, which can be used to remove the event handlers again without requiring an interaction with the InputMap.
What would prevent the user from supplying a totally unrelated Node (or rather, Control)?

And, as it currently stands, there is no need to use Subscription, as all the mappings created by the behavior will be automatically removed with BaseBehavior.uninstall().  (And Subscription would waste more bytes for each instance that one InputMap.control, wouldn?t you agree?)

That brings us to InputMap's being mutable.  I would first spend some serious effort to see if this is strictly needed

Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.

A shared InputMap (or, strictly speaking a shared InputMap and a per-control InputMap) is an alternative that might have some benefit in terms of memory consumption, at the expense of some complication.  It will, however, change the design as right now FX does not have such a global map.  I can see how we can explore this avenue at a later date, since it will not require public API changes as far as I can tell.

First, I think there should be a real Behavior interface.  A required abtract base class will just lead to the tempatation to use JavaFX internals when things get inconvenient for internal Controls (using the accessor pattern), and will result in users not being able to replicate all the behaviors that FX controls can exhibit (as they won't have access to the same internals).
Can you explain what you mean?  I see no need for an interface, the base class provides all the necessary methods to deal with the control?s InputMap.  We are not (at this time) talking about making the actual behaviors public as it is a much larger task, but nothing precludes us from doing so in the future.  We do need the base class public though.

BehaviorBase immediately shows the same problem as InputMap. Even though you'd expect that a Behavior should be sharable between controls (it is after all the case that for most controls of a certain type all their behaviors will be the same) it has elected to explicitely couple itself to a specific control instance.  The base class itself only does this because InputMap needs the Node, however, subclasses are using this judiciously everywhere to access the Node linked to a Behavior.

I would not expect a shared behavior.  This isn?t how FX works right now, it isn?t how Swing works, and it is certainly not a requirement.  It might be considered as an optimization in some cases, but the key bindings and event handlers are certainly added on a per-control basis.

Looking at various uses of `getNode` (used in about 200-300 places) I haven't found one yet that isn't responding to an event.

Behavior, being a ?controller? needs a pointer to the view and the model, so having control instance (renamed from getNode()) is a non-issue.  And nobody is going to rewrite 200-300 places, realistically speaking.

To summarize, I think that having control pointer in the InputMap or BehaviorBase is a non-issue, there are no cycling dependencies or chicken-egg problem because the life cycle is well determined.

Please don?t regard my responses as dismissals but rather as clarifications, and most certainly I welcome further discussion.  I think this proposal provides a good benefit-to-cost ratio, unless somebody can find a scenario where things would definitely not work.

What do you think?

-andy

From: openjfx-dev  on behalf of John Hendrikx 
Date: Saturday, October 7, 2023 at 10:43
To: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap

I've read the proposal.

I think it would be good to take a step back first and look at the classes and interfaces involved: Control, Behavior, InputMap, Skin -- the time is now to take a good look at these before making more public.

They're currently very interwoven which is usually a sign that they are not well enough abstracted. They cyclically reference each other indicating they have overlapping concerns.  I think this should be addressed first before making the existing InputMap and BehaviorBase public.

The main odd thing that jumps out immediately is the fact that Behaviors and InputMaps need a reference to their linked Node. This will result in chicken-egg style problems where you can't create the Control without an InputMap, and you can't create an InputMap without a Control.  It will also lead to problems where if a Behavior is replaced that we must take care to dispose it, or use only weak references to the Control.  The Skin API suffers from this problem, and I think we can do better.

InputMap
========

Looking at InputMap first, I see no real reason why it needs the Node.  It is only used for installing and removing the event handlers.  This action should not be triggered by the InputMap, and instead should be inverted so it is triggered by the Control.  This can be achieved in multiple ways; InputMap could simply produce the required event handlers on demand:

     Map> createEventHandlers();

The Control can then add these to the appropriate handlers, and track them for later removal (using a Subscription for example).

Or you could ask the InputMap to install them by providing the Node (the idea here being that Node is not stored, but provided as context):

     Subscription installEventHandlers(Node node);

Note that the above returns a Subscription, which can be used to remove the event handlers again without requiring an interaction with the InputMap.

The removal should be fairly trivial, and will lead to a better encapsulated and easier to reason about InputMap class that does not suffer from the chicken egg problem, and is not generically typed.

That brings us to InputMap's being mutable.  I would first spend some serious effort to see if this is strictly needed, and what benefits that would provide, as currently what I see is that InputMaps are mainly mutable in order to add mappings during construction (something a Contructor or Builder can do).  Immutable InputMaps would simplify things enormously, and would prevent mappings being modified (by a Skin or Behavior) that must be undone when the Skin or Behavior changes.  This would also mean there is no need to have multiple input maps in memory.  Cells have behaviors, and you can easily have 1000's on screen, requiring 1000's of Behavior and InputMap copies currently.

If they must be mustable however, then controls must listen for changes; this will inevitably mean that an InputMap refers each Control that listens for changes.  For a shared global InputMap this can mean that such Controls won't be GC'd, so we need to apply one of the usual strategies here to prevent this problem:

1. Use a weak listener (relying on GC)
2. Use a conditional listener (deterministic)

If InputMaps must be mutable, then the second one has by far the preference, and can be done by only listening for InputMap changes when the control is showing.  The best way to achieve this is for Controls to delay registering the InputMap's event handlers until they're about to become shown, and remove the event handlers when they're about to be unshown.  Note that this is not the same as visible/invisible and so won't lead to registration/unregistration upon toggling visibility.
Behavior
=======

First, I think there should be a real Behavior interface.  A required abtract base class will just lead to the tempatation to use JavaFX internals when things get inconvenient for internal Controls (using the accessor pattern), and will result in users not being able to replicate all the behaviors that FX controls can exhibit (as they won't have access to the same internals).

BehaviorBase immediately shows the same problem as InputMap. Even though you'd expect that a Behavior should be sharable between controls (it is after all the case that for most controls of a certain type all their behaviors will be the same) it has elected to explicitely couple itself to a specific control instance.  The base class itself only does this because InputMap needs the Node, however, subclasses are using this judiciously everywhere to access the Node linked to a Behavior.

As Behaviors respond to events however, there is I think no real need to have a direct reference to the Node -- the Event provides this already; it just needs to be extracted, or perhaps in some cases, this information needs to be added first as it is pertinent to the event.

Looking at various uses of `getNode` (used in about 200-300 places) I haven't found one yet that isn't responding to an event.  This makes sense, as that's probably the primary way a Behavior does its thing, it install event handlers and responds to them.

So I think that with a bit of refactoring, Behaviors can be made to not require the Node.  This will then allow Behaviors to be installed with a trivial setter, and would not need the install/dispose mechanism that Skins use.

TLDR;

I think that we should really be seeing if it is possible to remove the dependency on Controls before making these API's public.  This would remove the generic parameter from the signatures of both InputMap and Behavior(Base), and remove the chicken-egg dependency they currently have with Control.  It will simplify the design, and probably make a lot of classes and code a lot easier to reason about.

--John

On 30/09/2023 00:44, Andy Goryachev wrote:
Dear fellow JavaFX developers:

For some time now, we?ve been working to identify missing features in JavaFX that hinder application development.  We?ve been working on adding some of the missing features (for which we?ll have a separate announcement), but I feel that engaging wider community is a rather important part of the process.

I would like to share with you one such missing feature - ability to extend behavior of the existing components (and make the task of creating new components easier) by adding a public InputMap and BehaviorBase.

Please find the actual proposal here
https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09

We are very much interested in your feedback.  Thank you in advance.

-andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mhanl at openjdk.org  Mon Oct  9 21:02:10 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 9 Oct 2023 21:02:10 GMT
Subject: Integrated: JDK-8313628: Column drag header,
 overlay and line are not correctly aligned
In-Reply-To: 
References: 
Message-ID: <4VNgBAkXi3OK2Gqro1foqsqf8NrWWNP8iJze4uNLen0=.833d5e5c-1397-4b7f-921d-8ad86afbbe2e@github.com>

On Wed, 2 Aug 2023 16:36:47 GMT, Marius Hanl  wrote:

> When a table has padding or the `layoutChildren` method inside the table skin is overridden (and x/y are modified), the drag drag header, column overlay and column line are not correctly aligned.
> 
> The reason is that the positions were calculated incorrectly.
> - **Column overlay and column line**
> Always calculate in the x and y from the table. The x and y variables contain the snapped insets (padding) and possible modifications from subclasses.
> - **Drag header**
> Calculate the drag x offset local bounds from the parent header (which is either the parent column header or the root header)
> Before, the local bounds were calculated from the table, which will wrongly calculate in the padding.
> We do not want to know the local bounds based of the whole table but of our header we are in.

This pull request has now been integrated.

Changeset: 2ec33435
Author:    Marius Hanl 
URL:       https://git.openjdk.org/jfx/commit/2ec33435da44e6dc4791ecb1a37c064125c2ca13
Stats:     371 lines in 5 files changed: 336 ins; 7 del; 28 mod

8313628: Column drag header, overlay and line are not correctly aligned

Reviewed-by: angorya, kpk

-------------

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

From mhanl at openjdk.org  Mon Oct  9 21:03:04 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 9 Oct 2023 21:03:04 GMT
Subject: Integrated: JDK-8316590: Rendering artifact after JDK-8311983
In-Reply-To: <2UeXnbeC8NKkb73d3SDcnUP2DbbM7OvEtfDG4LLHGwg=.3be6dd19-75f9-4e5e-b924-3ab02e11c50e@github.com>
References: <2UeXnbeC8NKkb73d3SDcnUP2DbbM7OvEtfDG4LLHGwg=.3be6dd19-75f9-4e5e-b924-3ab02e11c50e@github.com>
Message-ID: <-OlJkyoG283L_8zUTUvrpl36PvDjVIjIP2mkSEtNEEU=.1891350d-ad99-43d0-aae8-6feab8e0b3ea@github.com>

On Thu, 21 Sep 2023 14:27:59 GMT, Marius Hanl  wrote:

> Fixes the regression by basically reverting one change introduced in https://bugs.openjdk.org/browse/JDK-8311983.
> The problem is that it is actually required to get the size from a cell with the index -1, which technically does not exist (the accumCell is used then).
> 
> Furthermore, unlike the name suggests, the call to `addLeadingCells()` is always needed, even if there are none.
> This is because the method does much more than what you would think first. 
> 
> In future, it would probably be good to revisit this code. Also performance wise, since this looks like something that can be optimized. But that is another story, not related to this fix.

This pull request has now been integrated.

Changeset: ec9a11bc
Author:    Marius Hanl 
URL:       https://git.openjdk.org/jfx/commit/ec9a11bc2b5f2f01c3109a13ccc03274e8ed7678
Stats:     67 lines in 2 files changed: 62 ins; 1 del; 4 mod

8316590: Rendering artifact after JDK-8311983

Reviewed-by: jvos, kpk, angorya

-------------

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

From arapte at openjdk.org  Mon Oct  9 21:06:36 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 9 Oct 2023 21:06:36 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8 [v2]
In-Reply-To: 
References: 
Message-ID: <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>

> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
> With this change the warnings get fixed and no error is observed with gradle 8.3
> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
> 
> Warnings that are fixed:
> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
> 
> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
> 
> 3. Various dependency warnings like one below:
> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> -> There are several such warning messages observed.
> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
> 
> An easy way to review would be.
> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
> 1.1 All above warnings can be observed and build completes successfully.
> 
> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
> 2.1 Without this change build would fail citing above warnings as errors
> 2.2 With this change build completes successfully and above warnings do not occur

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  fix test failures and remove rest warnings

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1256/files
  - new: https://git.openjdk.org/jfx/pull/1256/files/14877233..fee55c79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1256&range=00-01

  Stats: 28 lines in 1 file changed: 0 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1256.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1256/head:pull/1256

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

From prr at openjdk.org  Mon Oct  9 22:04:04 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Oct 2023 22:04:04 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
Message-ID: 

On Tue, 22 Aug 2023 20:46:21 GMT, Andy Goryachev  wrote:

> The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
> 
> I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660
> 
> This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day).

modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 759:

> 757:     /**
> 758:      * Returns a cached instance of character break iterator, creating it if necessary.
> 759:      * The instance is initialized with the given text.

"updated with the current text" might be more accurate ? It obviously has to be up to date to be used.
I'm also unsure of the performance consequences of having a BI spanning the entire text of the TextControl, which could be quite large, but that's what the code was already doing I suppose.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 572:

> 570:         if (isRTL()) {
> 571:             // Text node is mirrored.
> 572:             moveRight = !moveRight;

This method confuses me as to what it actually wants to do and why
As in, "move right, no, your other right" (!)

isRTL() checks the NodeOrientation so it seems in such a case "right" means "left".
Have you checked the fix with both orientations ?
Seems to me it reverses the meaning of the arrow keys without regard to the text.

And he BreakIterator is getting the next logical position, but this method claims to move to the next visual position.
The method is called nextCharacterVISUALLY, but with this code its actually moving LOGICALLY,
so I'm not seeing how this works for mixed directional text for either setting of "isRTL()" which seems to me to be very questionable to even check here. IMO the arrow key should work the same way no matter whether the UI is laid out with nodes from RTL or LTR.

Perhaps the word "Visually" was not the best choice of name here ? And "right" is questionable too. But I'm not 100% sure.
if you really do want LOGICALLY, then this code will probably work, except I find the isRTL() questionable even then.

What exactly was wrong in the existing code ? Other than it being very complex. How did its calculations go wrong ?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350772981
PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350820007

From angorya at openjdk.org  Mon Oct  9 22:04:05 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 22:04:05 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 20:44:24 GMT, Phil Race  wrote:

>> The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
>> 
>> I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660
>> 
>> This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day).
>
> modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 759:
> 
>> 757:     /**
>> 758:      * Returns a cached instance of character break iterator, creating it if necessary.
>> 759:      * The instance is initialized with the given text.
> 
> "updated with the current text" might be more accurate ? It obviously has to be up to date to be used.
> I'm also unsure of the performance consequences of having a BI spanning the entire text of the TextControl, which could be quite large, but that's what the code was already doing I suppose.

+1 thanks!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350822221

From prr at openjdk.org  Mon Oct  9 22:17:03 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Oct 2023 22:17:03 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 21:58:54 GMT, Phil Race  wrote:

>> The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
>> 
>> I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660
>> 
>> This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day).
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 572:
> 
>> 570:         if (isRTL()) {
>> 571:             // Text node is mirrored.
>> 572:             moveRight = !moveRight;
> 
> This method confuses me as to what it actually wants to do and why
> As in, "move right, no, your other right" (!)
> 
> isRTL() checks the NodeOrientation so it seems in such a case "right" means "left".
> Have you checked the fix with both orientations ?
> Seems to me it reverses the meaning of the arrow keys without regard to the text.
> 
> And he BreakIterator is getting the next logical position, but this method claims to move to the next visual position.
> The method is called nextCharacterVISUALLY, but with this code its actually moving LOGICALLY,
> so I'm not seeing how this works for mixed directional text for either setting of "isRTL()" which seems to me to be very questionable to even check here. IMO the arrow key should work the same way no matter whether the UI is laid out with nodes from RTL or LTR.
> 
> Perhaps the word "Visually" was not the best choice of name here ? And "right" is questionable too. But I'm not 100% sure.
> if you really do want LOGICALLY, then this code will probably work, except I find the isRTL() questionable even then.
> 
> What exactly was wrong in the existing code ? Other than it being very complex. How did its calculations go wrong ?

PS if I just use simple ASCII text and set Node Orientation to RTL, then with your fix
then left arrow moves right and right arrow moves left.
In JDK 8 left arrow moved left and right arrow moved right.
With an FX 17 build I have around, then the nothing moves.
So it looks like things might have been better when this code was written and some other change broke it.
Your fix unbreaks it, but I'm not entirely sure its restoring intended behaviour.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350852862

From angorya at openjdk.org  Mon Oct  9 22:20:08 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 22:20:08 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 22:14:10 GMT, Phil Race  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 572:
>> 
>>> 570:         if (isRTL()) {
>>> 571:             // Text node is mirrored.
>>> 572:             moveRight = !moveRight;
>> 
>> This method confuses me as to what it actually wants to do and why
>> As in, "move right, no, your other right" (!)
>> 
>> isRTL() checks the NodeOrientation so it seems in such a case "right" means "left".
>> Have you checked the fix with both orientations ?
>> Seems to me it reverses the meaning of the arrow keys without regard to the text.
>> 
>> And he BreakIterator is getting the next logical position, but this method claims to move to the next visual position.
>> The method is called nextCharacterVISUALLY, but with this code its actually moving LOGICALLY,
>> so I'm not seeing how this works for mixed directional text for either setting of "isRTL()" which seems to me to be very questionable to even check here. IMO the arrow key should work the same way no matter whether the UI is laid out with nodes from RTL or LTR.
>> 
>> Perhaps the word "Visually" was not the best choice of name here ? And "right" is questionable too. But I'm not 100% sure.
>> if you really do want LOGICALLY, then this code will probably work, except I find the isRTL() questionable even then.
>> 
>> What exactly was wrong in the existing code ? Other than it being very complex. How did its calculations go wrong ?
>
> PS if I just use simple ASCII text and set Node Orientation to RTL, then with your fix
> then left arrow moves right and right arrow moves left.
> In JDK 8 left arrow moved left and right arrow moved right.
> With an FX 17 build I have around, then the nothing moves.
> So it looks like things might have been better when this code was written and some other change broke it.
> Your fix unbreaks it, but I'm not entirely sure its restoring intended behaviour.

what if you have a mixture of RTL and LTR text in JDK8?
I am going to double check the behavior in JTextArea as well.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350861969

From angorya at openjdk.org  Mon Oct  9 22:27:05 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 22:27:05 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 22:17:50 GMT, Andy Goryachev  wrote:

>> PS if I just use simple ASCII text and set Node Orientation to RTL, then with your fix
>> then left arrow moves right and right arrow moves left.
>> In JDK 8 left arrow moved left and right arrow moved right.
>> With an FX 17 build I have around, then the nothing moves.
>> So it looks like things might have been better when this code was written and some other change broke it.
>> Your fix unbreaks it, but I'm not entirely sure its restoring intended behaviour.
>
> what if you have a mixture of RTL and LTR text in JDK8?
> I am going to double check the behavior in JTextArea as well.

what is going on??  JTextArea inside a Scene with RTL orientation:

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350875555

From prr at openjdk.org  Mon Oct  9 22:45:07 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Oct 2023 22:45:07 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 22:24:37 GMT, Andy Goryachev  wrote:

>> what if you have a mixture of RTL and LTR text in JDK8?
>> I am going to double check the behavior in JTextArea as well.
>
> what is going on??  JTextArea inside a Scene with RTL orientation:
> 
> 

JDK 8u doesn't have the fixes to deal with all of the macOS fonts in current macOS, so its a little hard for me to test Arabic/bidi there since I get garbage text.

I don't see that mirroring that you see, neither setting it on the TextArea or on the Scene, but the text is way off to the right.
Some layout issue.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350927629

From angorya at openjdk.org  Mon Oct  9 22:45:07 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 22:45:07 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 22:41:21 GMT, Phil Race  wrote:

>> what is going on??  JTextArea inside a Scene with RTL orientation:
>> 
>> 
>
> JDK 8u doesn't have the fixes to deal with all of the macOS fonts in current macOS, so its a little hard for me to test Arabic/bidi there since I get garbage text.
> 
> I don't see that mirroring that you see, neither setting it on the TextArea or on the Scene, but the text is way off to the right.
> Some layout issue.

^^ this looks like a separate bug, as it merely mirror images the whole SwingNode or its content.
Setting ComponentOrientation produces desired result, so perhaps we'd need to bind SwingNode's content component orientation to its node orientation.

But anyway, within JTextArea, the RIGHT arrow *always* moves to the right, and the LEFT arrow always moves to the left (of screen), regardless of component orientation which I think might be the "objectively correct" behavior.

Curiously, MS Word does not work this way, instead moving cursor *logically*.

The fixed code works similarly to what MS Word does, reversing the apparent direction within RTL/LTR blocks:
- In the LTR orientation, left moves the cursor left and right - to right within LTR text, which is what we want.
- In the RTL orientation, left moves left and right moves right within RTL text, which is also what we want.

I suppose the decision to work similarly to MS Word (and differently from swing?) was made early on and we are stuck with it.

Sooo, I guess the fix works as designed?
(I agree with your other objections to naming and javadoc, will fix).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350930618

From kcr at openjdk.org  Mon Oct  9 22:51:07 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Oct 2023 22:51:07 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8 [v2]
In-Reply-To: <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>
References: 
 <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>
Message-ID: 

On Mon, 9 Oct 2023 21:06:36 GMT, Ambarish Rapte  wrote:

>> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
>> With this change the warnings get fixed and no error is observed with gradle 8.3
>> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
>> 
>> Warnings that are fixed:
>> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
>> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
>> 
>> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
>> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
>> 
>> 3. Various dependency warnings like one below:
>> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
>> -> There are several such warning messages observed.
>> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
>> 
>> An easy way to review would be.
>> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
>> 1.1 All above warnings can be observed and build completes successfully.
>> 
>> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
>> 2.1 Without this change build would fail citing above warnings as errors
>> 2.2 With this change build completes successfully and above warnings do not occur
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test failures and remove rest warnings

My testing so far is green. I'll review more carefully tomorrow. I can see that you had to add a number of additional dependencies. I guess these all represent latent dependency bugs in our `build.gradle`?

@johanvos @tiainen Would either of you be willing to be the second reviewer?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1256#issuecomment-1754011406

From angorya at openjdk.org  Mon Oct  9 22:54:08 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 22:54:08 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: 
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>

Message-ID: 

On Mon, 9 Oct 2023 22:42:45 GMT, Andy Goryachev  wrote:

>> JDK 8u doesn't have the fixes to deal with all of the macOS fonts in current macOS, so its a little hard for me to test Arabic/bidi there since I get garbage text.
>> 
>> I don't see that mirroring that you see, neither setting it on the TextArea or on the Scene, but the text is way off to the right.
>> Some layout issue.
>
> ^^ this looks like a separate bug, as it merely mirror images the whole SwingNode or its content.
> Setting ComponentOrientation produces desired result, so perhaps we'd need to bind SwingNode's content component orientation to its node orientation.
> 
> But anyway, within JTextArea, the RIGHT arrow *always* moves to the right, and the LEFT arrow always moves to the left (of screen), regardless of component orientation which I think might be the "objectively correct" behavior.
> 
> Curiously, MS Word does not work this way, instead moving cursor *logically*.
> 
> The fixed code works similarly to what MS Word does, reversing the apparent direction within RTL/LTR blocks:
> - In the LTR orientation, left moves the cursor left and right - to right within LTR text, which is what we want.
> - In the RTL orientation, left moves left and right moves right within RTL text, which is also what we want.
> 
> I suppose the decision to work similarly to MS Word (and differently from swing?) was made early on and we are stuck with it.
> 
> Sooo, I guess the fix works as designed?
> (I agree with your other objections to naming and javadoc, will fix).

> JDK 8u doesn't have the fixes to deal with all of the macOS fonts in current macOS, so its a little hard for me to test Arabic/bidi there since I get garbage text.

if I remember correctly, explicitly setting an Arabic font removes the garbage.

> I don't see that mirroring that you see, neither setting it on the TextArea or on the Scene, but the text is way off to the right.

I've added this to the MonkeyTester (standalone revision)
https://github.com/andy-goryachev-oracle/MonkeyTest
Tools -> JTextArea 
and
Window -> Orientation: RTL

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1220#discussion_r1350934479

From angorya at openjdk.org  Mon Oct  9 23:12:36 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Oct 2023 23:12:36 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text [v2]
In-Reply-To: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
Message-ID: 

> The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
> 
> I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660
> 
> This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day).

Andy Goryachev 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 five additional commits since the last revision:

 - naming changes only
 - Merge remote-tracking branch 'origin/master' into 8296266.navigation
 - added robot test
 - exposing cached break iterators
 - using break iterator

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1220/files
  - new: https://git.openjdk.org/jfx/pull/1220/files/e41da6df..94bba45e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1220&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1220&range=00-01

  Stats: 6959 lines in 121 files changed: 5173 ins; 1013 del; 773 mod
  Patch: https://git.openjdk.org/jfx/pull/1220.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1220/head:pull/1220

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

From arapte at openjdk.org  Tue Oct 10 05:33:10 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 10 Oct 2023 05:33:10 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8 [v2]
In-Reply-To: 
References: 
 <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>

Message-ID: 

On Mon, 9 Oct 2023 22:48:18 GMT, Kevin Rushforth  wrote:

> I can see that you had to add a number of additional dependencies. I guess these all represent latent dependency bugs in our `build.gradle`?

Yes Kevin, Some tasks use output directory of other tasks without declaring dependency: This behavior is not supported from gradle 8 onwards, hence explicit specification of dependency. [ Reference doc : https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency ]

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1256#issuecomment-1754416594

From arapte at openjdk.org  Tue Oct 10 05:36:06 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 10 Oct 2023 05:36:06 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8
In-Reply-To: 
References: 

Message-ID: 

On Mon, 9 Oct 2023 17:17:03 GMT, Kevin Rushforth  wrote:

> Looks like there some GHA failures which will need to be resolved. Possibly a missing dependency?

Yes, I had used `mustRunAfter` to specify order of execution of tasks but looks like it does not guarantee the order of execution. Changing `mustRunAfter` to `dependsOn` fixed the problem

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1256#issuecomment-1754418851

From jvos at openjdk.org  Tue Oct 10 08:54:07 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 10 Oct 2023 08:54:07 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger  wrote:

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

@tiainen can you review?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1253#issuecomment-1754743752

From jvos at openjdk.org  Tue Oct 10 11:20:51 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 10 Oct 2023 11:20:51 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8 [v2]
In-Reply-To: <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>
References: 
 <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>
Message-ID: 

On Mon, 9 Oct 2023 21:06:36 GMT, Ambarish Rapte  wrote:

>> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
>> With this change the warnings get fixed and no error is observed with gradle 8.3
>> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
>> 
>> Warnings that are fixed:
>> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
>> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
>> 
>> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
>> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
>> 
>> 3. Various dependency warnings like one below:
>> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
>> -> There are several such warning messages observed.
>> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
>> 
>> An easy way to review would be.
>> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
>> 1.1 All above warnings can be observed and build completes successfully.
>> 
>> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
>> 2.1 Without this change build would fail citing above warnings as errors
>> 2.2 With this change build completes successfully and above warnings do not occur
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test failures and remove rest warnings

The changes make sense to me, and I tested it (on linux) following the provided procedures (with gradle 7.6 and 8.3) with the expected outcomes.
I still think it's better to remove more lines from build.gradle than to add lines to it, but I understand that would be very hard in this PR (where the dependencies really needed to be added etc).

-------------

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1256#pullrequestreview-1667349574

From kcr at openjdk.org  Tue Oct 10 11:53:53 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Oct 2023 11:53:53 GMT
Subject: RFR: 8314486: JavaFX build uses deprecated features that will be
 removed in gradle 8 [v2]
In-Reply-To: <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>
References: 
 <2ANm3wCPenxE581OLZfxmlfHeJWWBCy3sywPELsTdcg=.afc2aaaa-0ae0-467a-9d3f-631b63364875@github.com>
Message-ID: 

On Mon, 9 Oct 2023 21:06:36 GMT, Ambarish Rapte  wrote:

>> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
>> With this change the warnings get fixed and no error is observed with gradle 8.3
>> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
>> 
>> Warnings that are fixed:
>> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
>> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
>> 
>> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
>> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
>> 
>> 3. Various dependency warnings like one below:
>> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
>> -> There are several such warning messages observed.
>> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
>> 
>> An easy way to review would be.
>> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
>> 1.1 All above warnings can be observed and build completes successfully.
>> 
>> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
>> 2.1 Without this change build would fail citing above warnings as errors
>> 2.2 With this change build completes successfully and above warnings do not occur
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test failures and remove rest warnings

+1

The additional explanation makes sense.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1256#pullrequestreview-1667410780

From arapte at openjdk.org  Tue Oct 10 12:07:19 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 10 Oct 2023 12:07:19 GMT
Subject: Integrated: 8314486: JavaFX build uses deprecated features that will
 be removed in gradle 8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 9 Oct 2023 14:56:39 GMT, Ambarish Rapte  wrote:

> This is gradle only change, which fixes few warnings that are observed with gradle 7.6 and which eventually result to an error with gradle 8.3
> With this change the warnings get fixed and no error is observed with gradle 8.3
> Verified that several gradle tasks(all, sdk, javadoc, apps, shims, test) complete without any failure.
> 
> Warnings that are fixed:
> 1. The SourceDirectorySet.outputDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the classesDirectory property instead. See https://docs.gradle.org/7.6/dsl/org.gradle.api.file.SourceDirectorySet.html#org.gradle.api.file.SourceDirectorySet:outputDir for more details.
> -> As per this [7.x to 8.0 upgrade guide](https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#sourcedirectoryset_api_cleanup) outputDir should be replaced with `destinationDirectory`
> 
> 2. The AbstractCompile.destinationDir property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the destinationDirectory property instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#compile_task_wiring
> -> As per the above doc, replacing `destinationDir` with `destinationDirectory` resolves the warning
> 
> 3. Various dependency warnings like one below:
> Gradle detected a problem with the following location: '/rt/modules/javafx.base/build/module-classes'. Reason: Task ':base:modularJarStandaloneMac' uses this output of task ':base:buildModuleMac' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> -> There are several such warning messages observed.
> -> Each warning required an explicit inclusion of dependency. All dependency changes are to fix this warning.
> 
> An easy way to review would be.
> 1. Build with gradle 7.6 (using  `--warning-mode all`  gradle option)
> 1.1 All above warnings can be observed and build completes successfully.
> 
> 2. Build with gradle 8.3 (using  `--warning-mode all`  gradle option)
> 2.1 Without this change build would fail citing above warnings as errors
> 2.2 With this change build completes successfully and above warnings do not occur

This pull request has now been integrated.

Changeset: 73e690fc
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/73e690fc118c55d0c59fb567e884434a03243fff
Stats:     55 lines in 1 file changed: 28 ins; 0 del; 27 mod

8314486: JavaFX build uses deprecated features that will be removed in gradle 8

Reviewed-by: jvos, kcr

-------------

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

From kcr at openjdk.org  Tue Oct 10 12:13:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Oct 2023 12:13:35 GMT
Subject: RFR: 8313321 : Set minimum python version in WebKit cmake scripts
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Aug 2023 15:52:03 GMT, Hima Bindu Meda  wrote:

>> I tested this on my MacBook Pro running macOS 13.3.1 and discovered that it has python 3.7.x:
>> 
>> 
>>   Could NOT find Python3: Found unsuitable version "3.7.3", but required is
>>   at least "3.8.0" (found /usr/bin/python3, found components: Interpreter)
>> 
>> 
>> Since the motivation for checking the minimum was both to avoid python2, and because there is a problem with python 3.7 on Windows, I wonder if it would be better to only have Windows require 3.8 and have Mac join Linux in allowing 3.6. Of course, I could upgrade my python, but I wonder if other developers might run into it.
>
>> I tested this on my MacBook Pro running macOS 13.3.1 and discovered that it has python 3.7.x:
>> 
>> ```
>>   Could NOT find Python3: Found unsuitable version "3.7.3", but required is
>>   at least "3.8.0" (found /usr/bin/python3, found components: Interpreter)
>> ```
>> 
>> Since the motivation for checking the minimum was both to avoid python2, and because there is a problem with python 3.7 on Windows, I wonder if it would be better to only have Windows require 3.8 and have Mac join Linux in allowing 3.6. Of course, I could upgrade my python, but I wonder if other developers might run into it.
> 
> Based on the observation, changed the minimum version to 3.6 for mac and linux , and 3.8 for Windows

@HimaBinduMeda Can you merge in the latest master? I'll re-review once you do.

Regarding John's comment:

> Just a note that I was unable to build WebKit on Windows using the latest Python version 3.9

Let's file a follow-up bug for this if one is not already filed.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1205#issuecomment-1755254910

From john.hendrikx at gmail.com  Tue Oct 10 15:00:17 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 10 Oct 2023 17:00:17 +0200
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

Message-ID: <3a7f8443-367d-1970-ea0b-79d6e2d36131@gmail.com>

On 09/10/2023 22:24, Andy Goryachev wrote:
>
> Dear John:
>
> Thank you for a very thoughtful analysis! I wanted to initiate a 
> discussion, with the goal of making FX better.? Let me try to respond 
> to your comments.
>
> The main odd thing that jumps out immediately is the fact that 
> Behaviors and InputMaps need a reference to their linked Node. This 
> will result in chicken-egg style problems where you can't create the 
> Control without an InputMap, and you can't create an InputMap without 
> a Control.? It will also lead to problems where if a Behavior is 
> replaced that we must take care to dispose it, or use only weak 
> references to the Control.
>
> If we were to place FX parts in the standard MVC paradigm, behavior is 
> the controller, skin is the view, and the model is a part of control 
> (at least in the case of TextInputControl).? In FX world I would say 
> the control represents a fa?ade which provides programmatic access to 
> the control functionality to the app developers. Since the behavior 
> needs access to both the view and the model, it having a pointer to 
> the control is not an issue.
>
The MVC paradigm is not really relevant here, and has been superceded by 
much better paradigms; what we need is good abstractions that are easy 
to use and reason about.? Attaching a Behavior should be a simple one 
step process:

 ???? void setBehavior(Behavior behavior);

This has repercussions for how Behaviors should be designed; first it 
should not take the control as a contructor parameter (and nor should 
InputMap).? This isn't needed; the context the Behavior needs to do its 
job is provided through Events.

After calling the above setter, the Control will first call the old 
Behavior to remove its hooks, and then call the new Behavior to install 
the necessary hooks on the control.? The Control is in the lead here, as 
it should be given that it is what actually represents a control.? This 
also means that an interface is needed, something like:

 ???? interface Behavior {
 ?????????? Subscription addBehaviorListeners(T control);
 ???? }

As you can see, the control is passed here, allowing the Behavior to 
either: keep track of the control with the listeners it registers (but 
don't store it in a field), or only use the control to install the 
listeners and rely on the Event#getSource or Observable passed to 
listeners if it needs the control.? This latter option allows all the 
installed listeners to be shared amongst all controls -- as Behaviors 
often install quite a few listeners, let's not underestimate how much 
resources this could potentially save.? Duplicating all these just to 
keep track of a different control is not the high level of optimization 
I've come to expect from JavaFX.

The above also means that a Behavior is stateless; all its state is 
captured in the listeners it registers (if any is needed). Stateless 
objects can be shared, so I can do:

 ????? TextField f1, f2;
 ????? Behavior behavior = new MyBehavior();

 ????? f1.setBehavior(behavior);
 ????? f2.setBehavior(behavior);

... or for cell factories, a single behavior can be set on all cells 
created.

> With the InputMap having a pointer ? it?s a convenience.? I mean, we 
> could hide the input map altogether and add a bunch of methods to the 
> Control for manipulating the key bindings ? would that be better?? I 
> personally don?t think so, but it?s definitely an option.
>
A Control always has an InputMap.? This means any methods InputMap 
exposes are available if you have a Control.? Effectively this means the 
methods could have been put on Control as well (they'd just be 
shortcuts), but to avoid clutter it is nicer to put them on a new 
concept, the InputMap.? Such a new concept should be easy to use for 
anybody now, not just for Controls when InputMap was just an 
implementation detail.? An InputMap, when it was an implementation 
detail, can have a "convenient" pointer back to the control, as nobody 
could use InputMaps before and nobody could construct them incorrectly.? 
That changes when you make it public, and so its design should be 
reconsidered.

Mirroring the above, an InputMap can be constructed without providing a 
Control, mappings can be added and removed (or just provided in a 
constructor immedaitely), and then such an InputMap can be set with a 
single setter on a control.? The only state it needs is its mappings, 
and as long as you want the same mappings, the same InputMap can be 
shared amongst however many controls you'd want.? Sample:

 ????? InputMap map = new InputMap(Map.of(KEY_A, FunctionKey.of("type A"));

 ????? control.setInputMap(map);

 ????? // control is in the lead, and first removes any mappings from 
the previous InputMap,
 ????? // then calls methods on InputMap to get the new mappings installed

> There is no problem (anymore) with disposal or life cycle of skins and 
> associated behaviors: there is Skin.install() and Skin.dispose().
>
Skins use this solution because there was no other option anymore as 
their API was already public.? It is however not a good solution, but 
the best possible given the restrictions imposed by API's that were 
already public.? I'm not criticizing that solution.

Skins could however have been much easier to use if they had foregone 
their pointer to the control, and if the API was not public yet (or if 
we were willing to create a SkinV2 imlementation).? A simple 
"setSkin(STATIC_SKIN)" would have sufficed.? Skins would then be called 
to install their hooks with a reference to the control.? The hooks 
themselves are passed the control on every callback (through Observable) 
but could in theory also track this information by capturing the control 
variable:

 ????? class MySkin implements Skin {
 ????????? // called by the control
 ? ?? ???? Subscription applySkin(T control) {
 ????????????????? return Subscription.combine(
 ????????????????????? ?? control.backgroundProperty().subscribe(v -> {
 ?????????????????????????????? // do something with captured control 
here, or use a listener's Observable
 ???????????????????????? })
 ????????????????? };
 ??? ? ? ? }
 ???? }

> The Skin API suffers from this problem, and I think we can do better.
>
> Let?s keep in mind that a major redesign which will create a 
> compatibility issues for all the controls and their skins is most 
> likely not an option, but I would be very interested to hear how we 
> can do it better within the constraints of the existing design.
>
You misunderstand, I'm not criticizing the solution for Skins here, the 
current solution is the best that could be done given the API's that 
were already public and in place.

Behaviors and InputMap however are not public yet, and so I think their 
design should be carefully considered.

> Looking at InputMap first, I see no real reason why it needs the Node
>
> Mainly for convenience, and to prevent the user from supplying 
> completely unrelated control reference. Yes, it?s a waste of a 
> pointer, but the alternative is to move the APIs to Control.
>
If InputMaps are not control specific, then this becomes irrelevant.? 
I'm not sure why you'd think that the only alternative then would be to 
put these API's on Control.
>
> Subscription installEventHandlers(Node node);
>
> Note that the above returns a Subscription, which can be used to 
> remove the event handlers again without requiring an interaction with 
> the InputMap.
>
> What would prevent the user from supplying a totally unrelated Node 
> (or rather, Control)?
>
Nothing, it does not need to be prevented.? The user already has full 
access to the Control and can do anything to that Control, including 
installing their own event handlers to create a whole different InputMap 
system.? Calling it the "wrong" way just installs some (more) handlers 
without the Control being in the lead; to uninstall these, the user 
needs to call `unsubcribe` themselves.? If you however want to make 
things easy for yourself and you wish to fully replace the standard 
InputMap, then you'd call `Control.setInputMap`.? If you just want to 
add a few bindings, you can either create a full fledged subclass of an 
existing InputMap you like, or provide a partial InputMap that you 
install directly yourself.? Or of course you can keep the option to add 
separate mappings.

The same applies to Skins really.? A control can be skinned without 
using the Skin system, all it takes is making a subclass to get access 
to (mutable) getChildren and layoutChildren.? This is done often enough 
to create new (adhoc) Controls with a new look without having to bother 
with creating a Skin as well.

> And, as it currently stands, there is no need to use Subscription, as 
> all the mappings created by the behavior will be automatically removed 
> with BaseBehavior.uninstall().? (And Subscription would waste more 
> bytes for each instance that one InputMap.control, wouldn?t you agree?)
>
A single Subscription can track as many resources as you'd like, so I 
don't think that's correct.? What would however save a lot of memory is 
if Behaviors were stateless, as all the listeners can then be re-used 
accross controls, only wrapping the uninstall logic in a Subscription.? 
Effectively a Behavior would go from one behavior instance + X event 
handler instances per control to a single Behavior global instance, X 
stateless event handlers + 1 Subscription per control.? The Subscription 
effectively carries any state that Behaviors may need per Control instance.
>
> That brings us to InputMap's being mutable.? I would first spend some 
> serious effort to see if this is strictly needed
>
> Yes, one of the features the new design provides is ability to modify 
> key mappings by the user at runtime.? So yes, not only it needs to be 
> mutable, but it also adds some APIs for exactly that.
>
Having Immutable input maps does not preclude you from changing 
mappings. It would just mean that if there's is need for an InputMap 
with some mappings changed, that you'd create a new one to install on 
the control.

Something I've been wondering: what are the use cases currently? I would 
imagine that if I want to change a mapping for a certain type of control 
(let's say I want Buttons to react to ), do I need to make a 
ButtonFactory that will call "addMapping" on every button I create?? Can 
I override the standard Button InputMap somewhere globally?? Will it be 
possible with CSS (so I can do it globally)?? Currently, I already can 
do this to affect all Buttons:

privatestaticvoidbuttonsRespondToEnter(Scene scene) {

scene.addEventHandler(KeyEvent.KEY_PRESSED, e -> {

if(!e.isConsumed() && e.getCode() == KeyCode.ENTER) {

Node node = scene.getFocusOwner();

if(node instanceofButton button) {

button.fire();

e.consume();

}

}

});

}

Will the new API be able to this as easily?

I struggle to think of a good use case for an addMapping method that 
only works for a single instance of a control.? In almost all cases I'd 
want to modify **all** controls of a certain type, or perhaps with a 
certain style associated with them.

> A shared InputMap (or, strictly speaking a shared InputMap and a 
> per-control InputMap) is an alternative that might have some benefit 
> in terms of memory consumption, at the expense of some complication.? 
> It will, however, change the design as right now FX does not have such 
> a global map.? I can see how we can explore this avenue at a later 
> date, since it will not require public API changes as far as I can tell.
>
InputMap as it is currently requires a control in its constructor, that 
would preclude making them shareable later. Same for BehaviorBase.

Also they're not interfaces, they really should be if you want to design 
them now correctly to allow for user provided Behaviors and InputMaps later.

> First, I think there should be a real Behavior interface.? A required 
> abtract base class will just lead to the tempatation to use JavaFX 
> internals when things get inconvenient for internal Controls (using 
> the accessor pattern), and will result in users not being able to 
> replicate all the behaviors that FX controls can exhibit (as they 
> won't have access to the same internals).
>
> Can you explain what you mean?? I see no need for an interface, the 
> base class provides all the necessary methods to deal with the 
> control?s InputMap.? We are not (at this time) talking about making 
> the actual behaviors public as it is a much larger task, but nothing 
> precludes us from doing so in the future.? We do need the base class 
> public though.
>
You're making BehaviorBase public (it's not package private), and 
locking any Behavior classes into providing several protected methods 
(like getControl and getInputMap). This would preclude major design 
shifts later.? For example, I'm not so sure that a behavior should have 
a reference to the InputMap or the Control, at least not if you are 
introducing the FunctionTag mechanic.

> BehaviorBase immediately shows the same problem as InputMap. Even 
> though you'd expect that a Behavior should be sharable between 
> controls (it is after all the case that for most controls of a certain 
> type all their behaviors will be the same) it has elected to 
> explicitely couple itself to a specific control instance.? The base 
> class itself only does this because InputMap needs the Node, however, 
> subclasses are using this judiciously everywhere to access the Node 
> linked to a Behavior.
>
> I would _not_ expect a shared behavior.? This isn?t how FX works right 
> now, it isn?t how Swing works, and it is certainly not a requirement.? 
> It _might_ be considered as an optimization in some cases, but the key 
> bindings and event handlers are certainly added on a per-control basis.
>
 From a user point of view, a Behavior is the same accross many 
controls.? How Swing does things does not figure into this.? The 
handlers are indeed added on a control basis, but they can be the same 
shared handlers.

> Looking at various uses of `getNode` (used in about 200-300 places) I 
> haven't found one yet that isn't responding to an event.
>
> Behavior, being a ?controller? needs a pointer to the view and the 
> model, so having control instance (renamed from getNode()) is a 
> non-issue.? And nobody is going to rewrite 200-300 places, 
> realistically speaking.
>
Its responding to an event, which has this pointer, so this is basically 
disproven.

The "rewrite" would be a minor refactoring where to get the control 
pointer, certainly worth considering when introducing and committing to 
new API's forever.? I don't think all need to be adjusted immediately 
either.

>
> To summarize, I think that having control pointer in the InputMap or 
> BehaviorBase is a non-issue, there are no cycling dependencies or 
> chicken-egg problem because the life cycle is well determined.
>
It currently is well determined and guarded as they're private. This 
will not be the case when these classes/interfaces become public.? 
Repeating the solution for Skins is sub-optimal and was necessity 
driven, so saying its a non-issue given the roundabout ways Skins 
currently need to be installed, and how we struggled to find a 
satisfactory solution there seems to me somewhat unfair.

The design should look much further ahead if it is truly a goal to keep 
evolving JavaFX into a better framework. Once these classes are public, 
they can't be changed, so we better make absolutely sure that if we 
indeed want to do things like sharing behaviors or inputmaps, or 
allowing user made custom behaviors, that that is indeed going to be 
possible with what is being made public now.

> Please don?t regard my responses as dismissals but rather as 
> clarifications, and most certainly I welcome further discussion.? I 
> think this proposal provides a good benefit-to-cost ratio, unless 
> somebody can find a scenario where things would definitely not work.
>
> What do you think?
>
I welcome the work, I just have this feeling we're not designing far 
enough ahead, and letting existing private code dictate the design. When 
it comes to API's, the costs of not thinking far enough ahead are 
massive, so I changing a bit of existing non-public code should never 
figure into a design choice.

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Tue Oct 10 15:43:18 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Oct 2023 15:43:18 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger  wrote:

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

The fix and new test both look good. Testing is green.

Can you also change the following in [`UPDATING-VERSION.md`](https://github.com/openjdk/jfx/blob/4d9a8ebe3b0cddfef2a2e9df5915b0f0b8382207/UPDATING-VERSION.md)?

> ```
> modify the testMajorVersion method to increment the feature version number
> from `N` to `N+1`.
> ```

to something like:

modify the `FEATURE` variable to increment the feature version number
from `N` to `N+1`.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1253#pullrequestreview-1668138205

From jgneff at openjdk.org  Tue Oct 10 16:00:27 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 10 Oct 2023 16:00:27 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger  wrote:

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

Thanks, Kevin. I'll fix that.

To all reviewers: I added tests of the method [VersionInfo.setupSystemProperties][1] to the test cases in my [personal repository][2]. It's kind of overkill, and not necessary to prevent this bug, but let me know if I should add them anyway.

[1]: https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/version-info/VersionInfo.java#L152
[2]: https://github.com/jgneff/version-info-test/commit/573f559

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1253#issuecomment-1755744955

From jgneff at openjdk.org  Tue Oct 10 16:24:42 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 10 Oct 2023 16:24:42 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

John Neffenger has updated the pull request incrementally with one additional commit since the last revision:

  Update the documentation in UPDATING-VERSION.md

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1253/files
  - new: https://git.openjdk.org/jfx/pull/1253/files/4d9a8ebe..70c0de1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1253&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1253&range=00-01

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

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

From kcr at openjdk.org  Tue Oct 10 16:36:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Oct 2023 16:36:17 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 Oct 2023 16:24:42 GMT, John Neffenger  wrote:

>> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.
>
> John Neffenger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the documentation in UPDATING-VERSION.md

Looks good.

> To all reviewers: I added tests of the method [VersionInfo.setupSystemProperties](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/version-info/VersionInfo.java#L152) to the test cases in my [personal repository](https://github.com/jgneff/version-info-test/commit/573f559). It's kind of overkill, and not necessary to prevent this bug, but let me know if I should add them anyway.

Yeah, I probably wouldn't add them.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1253#pullrequestreview-1668250025
PR Comment: https://git.openjdk.org/jfx/pull/1253#issuecomment-1755804456

From michaelstrau2 at gmail.com  Tue Oct 10 17:35:44 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 10 Oct 2023 19:35:44 +0200
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

Message-ID: 

> Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>

I struggle to see a use case for this feature. I can imagine that
there might be some use cases that call for customized input mappings,
but why would this translate to a _mutable_ input map? That's quite a
departure from the way other parts of JavaFX work.

For example, skins are also immutable. If you want to have a different
skin for a control, you don't somehow modify the existing skin
instance; instead, you'd create a new skin class (or -- somehow --
extend an existing skin class), and then install that new skin on your
control.

An input map shouldn't bind input events directly to instance methods
of a particular control instance. It should define the mapping of
events to methods symbolically:

Instead of mapping Event => instance.method(), it should map Event =>
Control::method. The input map could then be stateless and immutable,
and can be set on any control instance. If you want to change the
mappings, just set a different input map instance. There's no need
that an input map would retain a reference to any particular control,
since the control reference can be passed into the input map just as
easily.

From andy.goryachev at oracle.com  Tue Oct 10 17:54:46 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 10 Oct 2023 17:54:46 +0000
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

Message-ID: 

Re-sending with a smaller image (256kb limit, really?).

From: Andy Goryachev 
Date: Tuesday, October 10, 2023 at 10:49
To: Michael Strau? 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
Dear Michael:

Here is a use case for (re-)mapping by the user at runtime:

[cid:image002.jpg at 01D9FB68.032C8480]

(key mappings UI in Eclipse).

I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.

Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.

-andy

From: openjfx-dev  on behalf of Michael Strau? 
Date: Tuesday, October 10, 2023 at 10:36
To:
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
> Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>

I struggle to see a use case for this feature. I can imagine that
there might be some use cases that call for customized input mappings,
but why would this translate to a _mutable_ input map? That's quite a
departure from the way other parts of JavaFX work.

For example, skins are also immutable. If you want to have a different
skin for a control, you don't somehow modify the existing skin
instance; instead, you'd create a new skin class (or -- somehow --
extend an existing skin class), and then install that new skin on your
control.

An input map shouldn't bind input events directly to instance methods
of a particular control instance. It should define the mapping of
events to methods symbolically:

Instead of mapping Event => instance.method(), it should map Event =>
Control::method. The input map could then be stateless and immutable,
and can be set on any control instance. If you want to change the
mappings, just set a different input map instance. There's no need
that an input map would retain a reference to any particular control,
since the control reference can be passed into the input map just as
easily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: image002.jpg
URL: 

From arapte at openjdk.org  Tue Oct 10 18:07:50 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 10 Oct 2023 18:07:50 GMT
Subject: RFR: 8314484: Update Gradle to 8.4
Message-ID: 

Upgrade gradle to version 8.4.
It also includes a change for adding task dependency for windows platform that was missed in [JDK-8314486](https://bugs.openjdk.org/browse/JDK-8314486)

-------------

Commit messages:
 - chmod 644 gradlew
 - fix win task dependency
 - upgrade gradle to 8.4

Changes: https://git.openjdk.org/jfx/pull/1257/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1257&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314484
  Stats: 261 lines in 7 files changed: 11 ins; 236 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/1257.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1257/head:pull/1257

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

From kcr at openjdk.org  Tue Oct 10 18:17:19 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Oct 2023 18:17:19 GMT
Subject: RFR: 8314484: Update Gradle to 8.4
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 17:39:53 GMT, Ambarish Rapte  wrote:

> Upgrade gradle to version 8.4.
> It also includes a change for adding task dependency for windows platform that was missed in [JDK-8314486](https://bugs.openjdk.org/browse/JDK-8314486)

@johanvos or @tiainen can one of you be the second reviewer?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1257#issuecomment-1755980364

From kcr at openjdk.org  Tue Oct 10 20:34:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Oct 2023 20:34:17 GMT
Subject: RFR: 8314484: Update Gradle to 8.4
In-Reply-To: 
References: 
Message-ID: <9-WgdRjZV-zpndzmBNkaDQUNq3uC0mdjQvc7RvZ6z-k=.eed662f4-9b28-49db-96b9-f4270da36c9a@github.com>

On Tue, 10 Oct 2023 17:39:53 GMT, Ambarish Rapte  wrote:

> Upgrade gradle to version 8.4.
> It also includes a change for adding task dependency for windows platform that was missed in [JDK-8314486](https://bugs.openjdk.org/browse/JDK-8314486)

Looks good. I tested on Windows and confirm that it produces the same artifacts as the current build.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1257#pullrequestreview-1668833732

From andy.goryachev at oracle.com  Tue Oct 10 22:45:53 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 10 Oct 2023 22:45:53 +0000
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: <3a7f8443-367d-1970-ea0b-79d6e2d36131@gmail.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <3a7f8443-367d-1970-ea0b-79d6e2d36131@gmail.com>
Message-ID: 

Dear John:

Thanks again for a detailed response!

I noticed a theme that perhaps we should discuss first.  It looks like there is a desire to have:

  1.  stateless, shared behavior
  2.  behavior separated from the skin
  3.  input map as a separate entity (or entity that can be used by any Node)
  4.  input maps are not control-specific
  5.  immutable input maps
  6.  whether changes to behavior span one control or all controls

so, in the order listed:

1. I understand the desire to have a stateless/shared behaviors comes mainly from trying to save a few thousand bytes (a noble goal, no question).  When we look at the current behaviors we can see that they are not stateless (TextInputControlBehavior.contextMenu, AccordionBehavior.focusModel, etc.)  Perhaps these can be redesigned to arrive at a ?better FX framework?, but the way I see it we have one major constraint ? nobody is going to do that in the foreseeable future.  Having announced this limitation, I?d say stateless/shared behaviors is not a requirement.

2. Behaviors are currently tightly coupled with the skin.  Separating the two would require additional APIs in Skin, and possibly in Behavior(Base).  I think we might explore this, likely for a subset of controls, in some distant future, but it is currently out of scope.  I don?t think this proposal makes it impossible ? please correct me if I am wrong.

3. I would strongly argue against using InputMaps for anything other that Controls.  Making it a property of Control makes possible to customize key mappings on per-control basis regardless of the current skin/behavior, which is one of the requirements outlined in the proposal.

4. Input maps are (by design) control-specific, to allow for per-control customization.  For example, a RichTextArea might offer two instances working off the same data model with different editable areas or navigation rules.

5. I don?t know where this is coming from.  Runtime customization is one of the requirements (one possible use case was described in a previous message referring to Eclipse?s key settings UI).  Input map is mutable, mutable at runtime, and also supporting reverting back to the original mappings).

6. This is a different use case, that should be addressed by extensibility of the skin/behavior.  It is currently out of scope since this proposal does not require public behaviors, but nothing precludes us from making certain behaviors public.  A possible workaround might involve subclassing the control and modifying its input map.

Perhaps there is something I missed, please correct me.

-andy

From: John Hendrikx 
Date: Tuesday, October 10, 2023 at 08:00
To: Andy Goryachev , openjfx-dev at openjdk.org 
Subject: [External] : Re: [Request for Comments] Behavior / InputMap

On 09/10/2023 22:24, Andy Goryachev wrote:
Dear John:

Thank you for a very thoughtful analysis!  I wanted to initiate a discussion, with the goal of making FX better.  Let me try to respond to your comments.

The main odd thing that jumps out immediately is the fact that Behaviors and InputMaps need a reference to their linked Node. This will result in chicken-egg style problems where you can't create the Control without an InputMap, and you can't create an InputMap without a Control.  It will also lead to problems where if a Behavior is replaced that we must take care to dispose it, or use only weak references to the Control.

If we were to place FX parts in the standard MVC paradigm, behavior is the controller, skin is the view, and the model is a part of control (at least in the case of TextInputControl).  In FX world I would say the control represents a fa?ade which provides programmatic access to the control functionality to the app developers.  Since the behavior needs access to both the view and the model, it having a pointer to the control is not an issue.

The MVC paradigm is not really relevant here, and has been superceded by much better paradigms; what we need is good abstractions that are easy to use and reason about.  Attaching a Behavior should be a simple one step process:

     void setBehavior(Behavior behavior);

This has repercussions for how Behaviors should be designed; first it should not take the control as a contructor parameter (and nor should InputMap).  This isn't needed; the context the Behavior needs to do its job is provided through Events.

After calling the above setter, the Control will first call the old Behavior to remove its hooks, and then call the new Behavior to install the necessary hooks on the control.  The Control is in the lead here, as it should be given that it is what actually represents a control.  This also means that an interface is needed, something like:

     interface Behavior {
           Subscription addBehaviorListeners(T control);
     }

As you can see, the control is passed here, allowing the Behavior to either: keep track of the control with the listeners it registers (but don't store it in a field), or only use the control to install the listeners and rely on the Event#getSource or Observable passed to listeners if it needs the control.  This latter option allows all the installed listeners to be shared amongst all controls -- as Behaviors often install quite a few listeners, let's not underestimate how much resources this could potentially save.  Duplicating all these just to keep track of a different control is not the high level of optimization I've come to expect from JavaFX.

The above also means that a Behavior is stateless; all its state is captured in the listeners it registers (if any is needed).  Stateless objects can be shared, so I can do:

      TextField f1, f2;
      Behavior behavior = new MyBehavior();

      f1.setBehavior(behavior);
      f2.setBehavior(behavior);

... or for cell factories, a single behavior can be set on all cells created.

With the InputMap having a pointer ? it?s a convenience.  I mean, we could hide the input map altogether and add a bunch of methods to the Control for manipulating the key bindings ? would that be better?  I personally don?t think so, but it?s definitely an option.

A Control always has an InputMap.  This means any methods InputMap exposes are available if you have a Control.  Effectively this means the methods could have been put on Control as well (they'd just be shortcuts), but to avoid clutter it is nicer to put them on a new concept, the InputMap.  Such a new concept should be easy to use for anybody now, not just for Controls when InputMap was just an implementation detail.  An InputMap, when it was an implementation detail, can have a "convenient" pointer back to the control, as nobody could use InputMaps before and nobody could construct them incorrectly.  That changes when you make it public, and so its design should be reconsidered.

Mirroring the above, an InputMap can be constructed without providing a Control, mappings can be added and removed (or just provided in a constructor immedaitely), and then such an InputMap can be set with a single setter on a control.  The only state it needs is its mappings, and as long as you want the same mappings, the same InputMap can be shared amongst however many controls you'd want.  Sample:

      InputMap map = new InputMap(Map.of(KEY_A, FunctionKey.of("type A"));

      control.setInputMap(map);

      // control is in the lead, and first removes any mappings from the previous InputMap,
      // then calls methods on InputMap to get the new mappings installed

There is no problem (anymore) with disposal or life cycle of skins and associated behaviors: there is Skin.install() and Skin.dispose().

Skins use this solution because there was no other option anymore as their API was already public.  It is however not a good solution, but the best possible given the restrictions imposed by API's that were already public.  I'm not criticizing that solution.

Skins could however have been much easier to use if they had foregone their pointer to the control, and if the API was not public yet (or if we were willing to create a SkinV2 imlementation).  A simple "setSkin(STATIC_SKIN)" would have sufficed.  Skins would then be called to install their hooks with a reference to the control.  The hooks themselves are passed the control on every callback (through Observable) but could in theory also track this information by capturing the control variable:

      class MySkin implements Skin {
          // called by the control
          Subscription applySkin(T control) {
                  return Subscription.combine(
                         control.backgroundProperty().subscribe(v -> {
                               // do something with captured control here, or use a listener's Observable
                         })
                  };
          }
     }

The Skin API suffers from this problem, and I think we can do better.

Let?s keep in mind that a major redesign which will create a compatibility issues for all the controls and their skins is most likely not an option, but I would be very interested to hear how we can do it better within the constraints of the existing design.

You misunderstand, I'm not criticizing the solution for Skins here, the current solution is the best that could be done given the API's that were already public and in place.

Behaviors and InputMap however are not public yet, and so I think their design should be carefully considered.

Looking at InputMap first, I see no real reason why it needs the Node

Mainly for convenience, and to prevent the user from supplying completely unrelated control reference.  Yes, it?s a waste of a pointer, but the alternative is to move the APIs to Control.
If InputMaps are not control specific, then this becomes irrelevant.  I'm not sure why you'd think that the only alternative then would be to put these API's on Control.

      Subscription installEventHandlers(Node node);

Note that the above returns a Subscription, which can be used to remove the event handlers again without requiring an interaction with the InputMap.
What would prevent the user from supplying a totally unrelated Node (or rather, Control)?

Nothing, it does not need to be prevented.  The user already has full access to the Control and can do anything to that Control, including installing their own event handlers to create a whole different InputMap system.  Calling it the "wrong" way just installs some (more) handlers without the Control being in the lead; to uninstall these, the user needs to call `unsubcribe` themselves.  If you however want to make things easy for yourself and you wish to fully replace the standard InputMap, then you'd call `Control.setInputMap`.  If you just want to add a few bindings, you can either create a full fledged subclass of an existing InputMap you like, or provide a partial InputMap that you install directly yourself.  Or of course you can keep the option to add separate mappings.

The same applies to Skins really.  A control can be skinned without using the Skin system, all it takes is making a subclass to get access to (mutable) getChildren and layoutChildren.  This is done often enough to create new (adhoc) Controls with a new look without having to bother with creating a Skin as well.

And, as it currently stands, there is no need to use Subscription, as all the mappings created by the behavior will be automatically removed with BaseBehavior.uninstall().  (And Subscription would waste more bytes for each instance that one InputMap.control, wouldn?t you agree?)
A single Subscription can track as many resources as you'd like, so I don't think that's correct.  What would however save a lot of memory is if Behaviors were stateless, as all the listeners can then be re-used accross controls, only wrapping the uninstall logic in a Subscription.  Effectively a Behavior would go from one behavior instance + X event handler instances per control to a single Behavior global instance, X stateless event handlers + 1 Subscription per control.  The Subscription effectively carries any state that Behaviors may need per Control instance.

That brings us to InputMap's being mutable.  I would first spend some serious effort to see if this is strictly needed

Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.

Having Immutable input maps does not preclude you from changing mappings. It would just mean that if there's is need for an InputMap with some mappings changed, that you'd create a new one to install on the control.

Something I've been wondering: what are the use cases currently?  I would imagine that if I want to change a mapping for a certain type of control (let's say I want Buttons to react to ), do I need to make a ButtonFactory that will call "addMapping" on every button I create?  Can I override the standard Button InputMap somewhere globally?  Will it be possible with CSS (so I can do it globally)?  Currently, I already can do this to affect all Buttons:

private static void buttonsRespondToEnter(Scene scene) {

scene.addEventHandler(KeyEvent.KEY_PRESSED, e -> {

if(!e.isConsumed() && e.getCode() == KeyCode.ENTER) {

Node node = scene.getFocusOwner();

if(node instanceof Button button) {

button.fire();

e.consume();

}

}

});

}

Will the new API be able to this as easily?

I struggle to think of a good use case for an addMapping method that only works for a single instance of a control.  In almost all cases I'd want to modify **all** controls of a certain type, or perhaps with a certain style associated with them.

A shared InputMap (or, strictly speaking a shared InputMap and a per-control InputMap) is an alternative that might have some benefit in terms of memory consumption, at the expense of some complication.  It will, however, change the design as right now FX does not have such a global map.  I can see how we can explore this avenue at a later date, since it will not require public API changes as far as I can tell.

InputMap as it is currently requires a control in its constructor, that would preclude making them shareable later.  Same for BehaviorBase.

Also they're not interfaces, they really should be if you want to design them now correctly to allow for user provided Behaviors and InputMaps later.

First, I think there should be a real Behavior interface.  A required abtract base class will just lead to the tempatation to use JavaFX internals when things get inconvenient for internal Controls (using the accessor pattern), and will result in users not being able to replicate all the behaviors that FX controls can exhibit (as they won't have access to the same internals).
Can you explain what you mean?  I see no need for an interface, the base class provides all the necessary methods to deal with the control?s InputMap.  We are not (at this time) talking about making the actual behaviors public as it is a much larger task, but nothing precludes us from doing so in the future.  We do need the base class public though.

You're making BehaviorBase public (it's not package private), and locking any Behavior classes into providing several protected methods (like getControl and getInputMap). This would preclude major design shifts later.  For example, I'm not so sure that a behavior should have a reference to the InputMap or the Control, at least not if you are introducing the FunctionTag mechanic.

BehaviorBase immediately shows the same problem as InputMap. Even though you'd expect that a Behavior should be sharable between controls (it is after all the case that for most controls of a certain type all their behaviors will be the same) it has elected to explicitely couple itself to a specific control instance.  The base class itself only does this because InputMap needs the Node, however, subclasses are using this judiciously everywhere to access the Node linked to a Behavior.

I would not expect a shared behavior.  This isn?t how FX works right now, it isn?t how Swing works, and it is certainly not a requirement.  It might be considered as an optimization in some cases, but the key bindings and event handlers are certainly added on a per-control basis.

>From a user point of view, a Behavior is the same accross many controls.  How Swing does things does not figure into this.  The handlers are indeed added on a control basis, but they can be the same shared handlers.

Looking at various uses of `getNode` (used in about 200-300 places) I haven't found one yet that isn't responding to an event.

Behavior, being a ?controller? needs a pointer to the view and the model, so having control instance (renamed from getNode()) is a non-issue.  And nobody is going to rewrite 200-300 places, realistically speaking.

Its responding to an event, which has this pointer, so this is basically disproven.

The "rewrite" would be a minor refactoring where to get the control pointer, certainly worth considering when introducing and committing to new API's forever.  I don't think all need to be adjusted immediately either.

To summarize, I think that having control pointer in the InputMap or BehaviorBase is a non-issue, there are no cycling dependencies or chicken-egg problem because the life cycle is well determined.

It currently is well determined and guarded as they're private.  This will not be the case when these classes/interfaces become public.  Repeating the solution for Skins is sub-optimal and was necessity driven, so saying its a non-issue given the roundabout ways Skins currently need to be installed, and how we struggled to find a satisfactory solution there seems to me somewhat unfair.

The design should look much further ahead if it is truly a goal to keep evolving JavaFX into a better framework. Once these classes are public, they can't be changed, so we better make absolutely sure that if we indeed want to do things like sharing behaviors or inputmaps, or allowing user made custom behaviors, that that is indeed going to be possible with what is being made public now.

Please don?t regard my responses as dismissals but rather as clarifications, and most certainly I welcome further discussion.  I think this proposal provides a good benefit-to-cost ratio, unless somebody can find a scenario where things would definitely not work.

What do you think?

I welcome the work, I just have this feeling we're not designing far enough ahead, and letting existing private code dictate the design. When it comes to API's, the costs of not thinking far enough ahead are massive, so I changing a bit of existing non-public code should never figure into a design choice.

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hmeda at openjdk.org  Wed Oct 11 03:58:01 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 11 Oct 2023 03:58:01 GMT
Subject: RFR: 8313321 : Set minimum python version in WebKit cmake scripts
 [v3]
In-Reply-To: 
References: 
Message-ID: <4ECYiY4TFwB3iWE8uFNOvhG7k9OJJT_0pXQDeD5YkS4=.109cec14-bf71-47ed-9556-34177898a2ca@github.com>

> Minimum version of python ,to run webkit build , on linux is set to 3.6 and for other platforms, minimum version of python is set to 3.8.
> 
> Verified build on all platforms. No issue seen

Hima Bindu Meda 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 branch 'master' into python_update
 - change minimum version for mac to 3.6
 - Add check for python version for various platforms

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1205/files
  - new: https://git.openjdk.org/jfx/pull/1205/files/6b73ba2e..6e829316

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1205&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1205&range=01-02

  Stats: 8102 lines in 161 files changed: 6201 ins; 1035 del; 866 mod
  Patch: https://git.openjdk.org/jfx/pull/1205.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1205/head:pull/1205

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

From duke at openjdk.org  Wed Oct 11 06:52:14 2023
From: duke at openjdk.org (duke)
Date: Wed, 11 Oct 2023 06:52:14 GMT
Subject: Withdrawn: JDK-8187314: All Cells: must show backing data always
In-Reply-To: 
References: 
Message-ID: <95yS9ayOD9kJ3ZH55aZ0YkLuR6_YcErJIw7dNvDqgVQ=.3b0f9464-cd9b-4174-aedd-d012cbb8752e@github.com>

On Fri, 4 Aug 2023 18:13:34 GMT, Marius Hanl  wrote:

> Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`.
> This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise).
> We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value.
> 
> Changed and added tests for all 4 cells.

This pull request has been closed without being integrated.

-------------

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

From john.hendrikx at gmail.com  Wed Oct 11 08:03:58 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 11 Oct 2023 10:03:58 +0200
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

Message-ID: <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>

I'm sorry, but that providing an arbitrary key mapping system seems 
completely out of scope and not something that JavaFX should concern 
itself with.? It's much too high level, when the key mappings involved 
should only be for actions that the control can provide on its own.

I think the problem we should be solving is that JavaFX control 
behaviors shouldn't be first in line when it comes to consuming events 
(which currently is only the case due to event handlers being added at 
the earliest possible opportunity, and event handlers being called in 
order).? If something as trivial as:

 ?????? control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
 ????????????? if (e.getCode() == KeyCode.LEFT) {
 ??????????????????? e.consume();? // stop default behavior
 ????????????? }
 ?????? });

... actually worked, then there is much less need to redefine/disable 
behavior key mappings, and no need for a secondary system that deals 
with mappings (the first system, event handlers, can simply be used for 
this).? If user event handlers had priority over behavior ones, then 
everything you want can be achieved with the above, including:

- Stopping default behavior
- Triggering different behavior (just call something on control, of 
course, make sure all behavior actions are available on the control in 
the first place)
- Remapping (a combination of the above two)
- Adding an alternative key for the same behavior

A system to remap keys can then be left squarely in the realm of user 
space, and much nicer solutions can be build by users than whatever 
JavaFX will provide out of the box.

Changes to the Behavior system can then focus on replacing complete 
behaviors (including their input map) and being able to use these by 
default for a certain subset of controls (like -fx-skin provide in CSS), 
as this is something users currently can't do.

So in short, what I think this should be about is:

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
- Ensure that if a key is handled by the control, that it is ONLY 
consumed when it actually triggers an action (navigation keys get 
consumed regardless, even if no focus change results, that's wrong).

Future:

- Make behaviors public and allow Behaviors to be replaced with 
-fx-behavior type CSS syntax / control.setBehavior calls

--John

The focus should be on being able to modify standard behavior of 
controls (arrow-left, enter, ctrl-shift-right, etc.), specifically also 
to be able to disable these when undesired, and, on top of that, that 
they bubble up when NOT used even when they are configured (focus 
navigation keys currently are always consumed, whether they actually do 
something or not -- that's a big issue). The other focus should be on 
providing an alternative behavior (or at least mappings) for all 
controls of a certain type -- I don't see the need for adding a mapping 
to a specific control, that's already covered with event handlers; the 
problem is mostly that behaviors currently steal certain events before 
the user can get at them.

Custom behaviors can then be constructed that provide more things that 
may need mapping.? I'd expect those however to be limited in scope to 
what the control offers, certainly not an arbitrary key/action mapping 
system (that wouldn't even work, as most of these would be in the scope 
of several controls or be global). This kind of functionality is much 
better provided by event handlers at the correct level for a group of 
controls, and I wouldn't expect to find such an eloborate system 
incorporated in behaviors.

In fact, thinking about all of this a bit more,

On 10/10/2023 19:54, Andy Goryachev wrote:

> Re-sending with a smaller image (256kb limit, really?).
>
> *From: *Andy Goryachev 
> *Date: *Tuesday, October 10, 2023 at 10:49
> *To: *Michael Strau? 
> *Cc: *openjfx-dev at openjdk.org 
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> Dear Michael:
>
> Here is a use case for (re-)mapping by the user at runtime:
>
> (key mappings UI in Eclipse).
>
> I can think of several other cases (mentioned in the proposal, I 
> think) so I think we can put the concept of immutable or global 
> InputMap to rest.
>
> Whether the InputMap contains the reference to its control or not is a 
> minor implementation detail, I think.
>
> -andy
>
> *From: *openjfx-dev  on behalf of 
> Michael Strau? 
> *Date: *Tuesday, October 10, 2023 at 10:36
> *To: *
> *Cc: *openjfx-dev at openjdk.org 
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> > Yes, one of the features the new design provides is ability to modify 
> key mappings by the user at runtime.? So yes, not only it needs to be 
> mutable, but it also adds some APIs for exactly that.
> >
>
> I struggle to see a use case for this feature. I can imagine that
> there might be some use cases that call for customized input mappings,
> but why would this translate to a _mutable_ input map? That's quite a
> departure from the way other parts of JavaFX work.
>
> For example, skins are also immutable. If you want to have a different
> skin for a control, you don't somehow modify the existing skin
> instance; instead, you'd create a new skin class (or -- somehow --
> extend an existing skin class), and then install that new skin on your
> control.
>
> An input map shouldn't bind input events directly to instance methods
> of a particular control instance. It should define the mapping of
> events to methods symbolically:
>
> Instead of mapping Event => instance.method(), it should map Event =>
> Control::method. The input map could then be stateless and immutable,
> and can be set on any control instance. If you want to change the
> mappings, just set a different input map instance. There's no need
> that an input map would retain a reference to any particular control,
> since the control reference can be passed into the input map just as
> easily.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: not available
URL: 

From jdv at openjdk.org  Wed Oct 11 11:18:17 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 11 Oct 2023 11:18:17 GMT
Subject: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of
 minute difference in values [v3]
In-Reply-To: 
References: 
Message-ID: 

> Two perspective lod tests fail because of minute differences in expected values.
> 
> Failing tests:
> test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java:
> test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: 
> 
> Exception:
> test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure
> org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but was 50180.137157440186' has not been reached in 1000 milliseconds
> at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93)
> at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117)
> at test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
> at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> These little difference in values are seen both initial drawing and updates.
> These tests are not run from long time and change in product might change lod values.
> 
> With updated lod values i have verified that both the tests pass in OpenGL and Metal pipeline with both retina display(scale = 2) and external monitor(scale = 1).

Jayathirth D V 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 'upstream/master' into lod_tests
 - Add lod tolerance
 - 8315896: Perspective lod tests fail because of minute difference in values

-------------

Changes:
  - all: https://git.openjdk.org/jfx-tests/pull/6/files
  - new: https://git.openjdk.org/jfx-tests/pull/6/files/7dcb21aa..70895516

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=01-02

  Stats: 437 lines in 186 files changed: 277 ins; 16 del; 144 mod
  Patch: https://git.openjdk.org/jfx-tests/pull/6.diff
  Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/6/head:pull/6

PR: https://git.openjdk.org/jfx-tests/pull/6

From martin at martinfox.com  Wed Oct 11 17:26:25 2023
From: martin at martinfox.com (Martin Fox)
Date: Wed, 11 Oct 2023 10:26:25 -0700
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
Message-ID: <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>

> On Oct 11, 2023, at 1:03 AM, John Hendrikx  wrote:

After reading John's message I realize that the InputMap proposal doesn?t list the limitations of the current design. It seems to be addressing some of the sequencing issues John mentions but doesn?t state outright that it?s doing so or why. I would set aside the proposal and focus on writing a problem statement document first.
> A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.
> 
Seconded. Whatever Eclipse is doing to implement their key binding interface is deep and complex and there?s no way JavaFX could craft a solution Eclipse would use. I think that will be true for most apps that allow user customizable key bindings. And I?m pretty sure that when the user customizes a key binding Eclipse is not tracking down all of the affected controls and updating their per-instance key binding maps. Those maps have to be centralized and shared in some manner.
> So in short, what I think this should be about is:
> 
> - Ensure user event handlers have priority over behavior/inputmap added ones
> - Ensure all behavior actions are available as methods on controls
> 
I have another recommendation (which may be more of a feature request). There should be a centralized way of mapping common keys to actions to ensure a consistent vocabulary across the user interface. As an example, on many controls Shift + up arrow should map to something like ?moveUpAndExtendTheSelection?. There are a lot of these standardized bindings, some of them are platform specific, and it?s a really tall order to expect all of the individual control classes to get this right.

On macOS there are two primary means of mapping a key event to an action and both are global. This means most of these mappings happen outside the individual controls and that the mappings are consistent across controls. This also addresses part of what John mentioned above; to make this work controls have to make their actions visible through callable methods.

Phrased as problem statement: currently individual control classes need to separately implement a large set of standardized keyboard bindings. This is a maintenance and testing issue.
> - Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).
> 
As I recall this is an issue with the traversal engine which is a maybe a separate topic (?) Was a bug ever entered on this?

Martin

> On 10/10/2023 19:54, Andy Goryachev wrote:
> 
>> Re-sending with a smaller image (256kb limit, really?).
>>  
>> From: Andy Goryachev  
>> Date: Tuesday, October 10, 2023 at 10:49
>> To: Michael Strau?  
>> Cc: openjfx-dev at openjdk.org   
>> Subject: Re: [Request for Comments] Behavior / InputMap
>> 
>> Dear Michael:
>>  
>> Here is a use case for (re-)mapping by the user at runtime:
>>  
>> 
>>  
>> (key mappings UI in Eclipse).
>>  
>> I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.
>>  
>> Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.
>>  
>> -andy
>>  
>>  
>> From: openjfx-dev   on behalf of Michael Strau?  
>> Date: Tuesday, October 10, 2023 at 10:36
>> To: 
>> Cc: openjfx-dev at openjdk.org   
>> Subject: Re: [Request for Comments] Behavior / InputMap
>> 
>> > Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>> >
>> 
>> I struggle to see a use case for this feature. I can imagine that
>> there might be some use cases that call for customized input mappings,
>> but why would this translate to a _mutable_ input map? That's quite a
>> departure from the way other parts of JavaFX work.
>> 
>> For example, skins are also immutable. If you want to have a different
>> skin for a control, you don't somehow modify the existing skin
>> instance; instead, you'd create a new skin class (or -- somehow --
>> extend an existing skin class), and then install that new skin on your
>> control.
>> 
>> An input map shouldn't bind input events directly to instance methods
>> of a particular control instance. It should define the mapping of
>> events to methods symbolically:
>> 
>> Instead of mapping Event => instance.method(), it should map Event =>
>> Control::method. The input map could then be stateless and immutable,
>> and can be set on any control instance. If you want to change the
>> mappings, just set a different input map instance. There's no need
>> that an input map would retain a reference to any particular control,
>> since the control reference can be passed into the input map just as
>> easily.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Wed Oct 11 17:44:22 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 11 Oct 2023 17:44:22 +0000
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
Message-ID: 

Dear John:

Seems like addEventFilter() was specifically designed to intercept events before any other handlers, so I see no problem there.

I somewhat disagree about the purpose of the key mapping system ? the proposed solution solves two existing issues (the skin/behavior mappings and the user mappings) in one neat package.  Every other instrument such as addEventHandler/Filter is still there.

And, if we look at the three bullet points

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
- Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).
I absolutely agree, and in fact the first three are indeed a part of the proposal.  Well, the 3rd one might unfortunately be a subject of backward compatibility limitation since one of the requirements was no behavior change w.r.t. the earlier versions.  We can always change the behavior if we have a completing reason and go through the usual process, nothing in the proposal precludes that.

Making the behaviors completely independent with setBehavior() and FXML, as you said, might be a future effort, perhaps we could attempt opening up certain controls at some point.  On one hand, I am for increasing the extensibility of FX, on the other hand the same argument can be made against it (as in solidifying a particular way of constructing skins and behaviors), but I feel it?s a separate issue that is independent of this proposal.

-andy

From: openjfx-dev  on behalf of John Hendrikx 
Date: Wednesday, October 11, 2023 at 01:04
To: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap

I'm sorry, but that providing an arbitrary key mapping system seems completely out of scope and not something that JavaFX should concern itself with.  It's much too high level, when the key mappings involved should only be for actions that the control can provide on its own.
I think the problem we should be solving is that JavaFX control behaviors shouldn't be first in line when it comes to consuming events (which currently is only the case due to event handlers being added at the earliest possible opportunity, and event handlers being called in order).  If something as trivial as:

       control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
              if (e.getCode() == KeyCode.LEFT) {
                    e.consume();  // stop default behavior
              }
       });

... actually worked, then there is much less need to redefine/disable behavior key mappings, and no need for a secondary system that deals with mappings (the first system, event handlers, can simply be used for this).  If user event handlers had priority over behavior ones, then everything you want can be achieved with the above, including:

- Stopping default behavior
- Triggering different behavior (just call something on control, of course, make sure all behavior actions are available on the control in the first place)
- Remapping (a combination of the above two)
- Adding an alternative key for the same behavior

A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.

Changes to the Behavior system can then focus on replacing complete behaviors (including their input map) and being able to use these by default for a certain subset of controls (like -fx-skin provide in CSS), as this is something users currently can't do.

So in short, what I think this should be about is:

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
- Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).

Future:

- Make behaviors public and allow Behaviors to be replaced with -fx-behavior type CSS syntax / control.setBehavior calls

--John

The focus should be on being able to modify standard behavior of controls (arrow-left, enter, ctrl-shift-right, etc.), specifically also to be able to disable these when undesired, and, on top of that, that they bubble up when NOT used even when they are configured (focus navigation keys currently are always consumed, whether they actually do something or not -- that's a big issue).  The other focus should be on providing an alternative behavior (or at least mappings) for all controls of a certain type -- I don't see the need for adding a mapping to a specific control, that's already covered with event handlers; the problem is mostly that behaviors currently steal certain events before the user can get at them.

Custom behaviors can then be constructed that provide more things that may need mapping.  I'd expect those however to be limited in scope to what the control offers, certainly not an arbitrary key/action mapping system (that wouldn't even work, as most of these would be in the scope of several controls or be global).  This kind of functionality is much better provided by event handlers at the correct level for a group of controls, and I wouldn't expect to find such an eloborate system incorporated in behaviors.

In fact, thinking about all of this a bit more,

On 10/10/2023 19:54, Andy Goryachev wrote:
Re-sending with a smaller image (256kb limit, really?).

From: Andy Goryachev 
Date: Tuesday, October 10, 2023 at 10:49
To: Michael Strau? 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
Dear Michael:

Here is a use case for (re-)mapping by the user at runtime:

[cid:part1.QozIrk7S.Ii0xHc4n at gmail.com]

(key mappings UI in Eclipse).

I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.

Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.

-andy

From: openjfx-dev  on behalf of Michael Strau? 
Date: Tuesday, October 10, 2023 at 10:36
To:
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
> Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>

I struggle to see a use case for this feature. I can imagine that
there might be some use cases that call for customized input mappings,
but why would this translate to a _mutable_ input map? That's quite a
departure from the way other parts of JavaFX work.

For example, skins are also immutable. If you want to have a different
skin for a control, you don't somehow modify the existing skin
instance; instead, you'd create a new skin class (or -- somehow --
extend an existing skin class), and then install that new skin on your
control.

An input map shouldn't bind input events directly to instance methods
of a particular control instance. It should define the mapping of
events to methods symbolically:

Instead of mapping Event => instance.method(), it should map Event =>
Control::method. The input map could then be stateless and immutable,
and can be set on any control instance. If you want to change the
mappings, just set a different input map instance. There's no need
that an input map would retain a reference to any particular control,
since the control reference can be passed into the input map just as
easily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: image002.jpg
URL: 

From duke at openjdk.org  Wed Oct 11 17:45:25 2023
From: duke at openjdk.org (Travis Furrer)
Date: Wed, 11 Oct 2023 17:45:25 GMT
Subject: RFR: 8313956: focusWithin on parents of a newly-added focused node
 is not updated [v2]
In-Reply-To: 
References: 
 <4ZbkdyxsP21OmH31jN73d0zMX6yZSmfkdATkupq0s6A=.1728e838-5aa9-4aed-a2b6-6b6c8f412e52@github.com>

Message-ID: 

On Fri, 18 Aug 2023 21:55:41 GMT, Marius Hanl  wrote:

> > The `focusWithin` count cannot be negative, and there is no possible way for applications to misuse the API to cause a negative count. If it ends up being negative, that's because of a bug, and I think that bugs should be fixed and not logged.
> 
> Yes, the reason I was asking this is that we actually have this problem right now, that it could be negative, although it should not. If we would have logged that, we probably found that bug much earlier. In any case, I think with the new logic and the `count > 0`, it is fine as is.

@Maran23  Just to clarify...
If I have a case (with jfx21) where the count goes negative, is this still a bug that I should file?  Or are you saying that it's understood as expected behavior now?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1210#issuecomment-1758168869

From duke at openjdk.org  Wed Oct 11 17:52:40 2023
From: duke at openjdk.org (Travis Furrer)
Date: Wed, 11 Oct 2023 17:52:40 GMT
Subject: RFR: 8313956: focusWithin on parents of a newly-added focused node
 is not updated [v4]
In-Reply-To: 
References: 

 <8-zpvhr-S2NNO6KLrBFnqG_UfEV6eyd8TV2CRHkm21M=.e74933f3-0e6d-4b6e-8ebe-e3d58185a5af@github.com>

Message-ID: 

On Fri, 18 Aug 2023 21:16:03 GMT, Michael Strau?  wrote:

>> question: what happens when the user navigates away when editing the cell?  it looks like the fix correctly handles the situation.  are there any other possible scenarios?
>> 
>> 
>
>> question: what happens when the user navigates away when editing the cell? it looks like the fix correctly handles the situation. are there any other possible scenarios?
> 
> I don't think there are, because now we're correctly handling the two scenarios that affect the `focusWithin` count:
> 1. Removing a non-zero focusWithin node from the scene graph
> 2. Adding a non-zero focusWithin node to the scene graph
> 
> As for your question what happens when the user navigates away from an editable cell: I think there's [JDK-8089514](https://bugs.openjdk.org/browse/JDK-8089514) to track that.

@mstr2 or @Maran23 Does "focus owner" == "input focus" == "scene focus owner" == where key events will be sent?

I ask because the javadoc on Node.focusWithin says "Indicates whether this Node or any of its descendants currently has the **_input focus_**.", but in discussions it has been said that focusWithin includes a TableView's "focused item" even if that is not the scene's current focus owner (i.e. where key events will be sent).

It would be great if the javadoc for Node.focusWithin could be improved to avoid this kind of widespread confusion about what it really means...

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1210#issuecomment-1758183502

From mstrauss at openjdk.org  Wed Oct 11 18:01:13 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Oct 2023 18:01:13 GMT
Subject: RFR: 8313956: focusWithin on parents of a newly-added focused node
 is not updated [v2]
In-Reply-To: 
References: 
 <4ZbkdyxsP21OmH31jN73d0zMX6yZSmfkdATkupq0s6A=.1728e838-5aa9-4aed-a2b6-6b6c8f412e52@github.com>

Message-ID: 

On Wed, 11 Oct 2023 17:36:21 GMT, Travis Furrer  wrote:

> > > The `focusWithin` count cannot be negative, and there is no possible way for applications to misuse the API to cause a negative count. If it ends up being negative, that's because of a bug, and I think that bugs should be fixed and not logged.
> > 
> > 
> > Yes, the reason I was asking this is that we actually have this problem right now, that it could be negative, although it should not. If we would have logged that, we probably found that bug much earlier. In any case, I think with the new logic and the `count > 0`, it is fine as is.
> 
> @Maran23 Just to clarify... If I have a case (with jfx21) where the count goes negative, is this still a bug that I should file? Or are you saying that it's understood as expected behavior now?

If you have a situation where the focusWithin count is negative, please file it as a bug. That's not expected behavior.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1210#issuecomment-1758197481

From duke at openjdk.org  Wed Oct 11 18:01:13 2023
From: duke at openjdk.org (Travis Furrer)
Date: Wed, 11 Oct 2023 18:01:13 GMT
Subject: RFR: 8313956: focusWithin on parents of a newly-added focused node
 is not updated [v2]
In-Reply-To: 
References: 
 <4ZbkdyxsP21OmH31jN73d0zMX6yZSmfkdATkupq0s6A=.1728e838-5aa9-4aed-a2b6-6b6c8f412e52@github.com>

Message-ID: 

On Wed, 11 Oct 2023 17:56:15 GMT, Michael Strau?  wrote:

>>> > The `focusWithin` count cannot be negative, and there is no possible way for applications to misuse the API to cause a negative count. If it ends up being negative, that's because of a bug, and I think that bugs should be fixed and not logged.
>>> 
>>> Yes, the reason I was asking this is that we actually have this problem right now, that it could be negative, although it should not. If we would have logged that, we probably found that bug much earlier. In any case, I think with the new logic and the `count > 0`, it is fine as is.
>> 
>> @Maran23  Just to clarify...
>> If I have a case (with jfx21) where the count goes negative, is this still a bug that I should file?  Or are you saying that it's understood as expected behavior now?
>
>> > > The `focusWithin` count cannot be negative, and there is no possible way for applications to misuse the API to cause a negative count. If it ends up being negative, that's because of a bug, and I think that bugs should be fixed and not logged.
>> > 
>> > 
>> > Yes, the reason I was asking this is that we actually have this problem right now, that it could be negative, although it should not. If we would have logged that, we probably found that bug much earlier. In any case, I think with the new logic and the `count > 0`, it is fine as is.
>> 
>> @Maran23 Just to clarify... If I have a case (with jfx21) where the count goes negative, is this still a bug that I should file? Or are you saying that it's understood as expected behavior now?
> 
> If you have a situation where the focusWithin count is negative, please file it as a bug. That's not expected behavior.

@mstr2  Ok, I will try to get a bug filed eventually.  It will take time because I've only observed this in a complex application, and it may be difficult to produce a minimal example.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1210#issuecomment-1758199949

From andy.goryachev at oracle.com  Wed Oct 11 18:08:50 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 11 Oct 2023 18:08:50 +0000
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
 <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>
Message-ID: 

Dear Martin:

I think the limitation of the current design were expressly listed in the Summary.

The Eclipse example was a use case example, we are not saying we will provide any kind of UI or the framework to synchronize the behavior between multiple instances.  This proposal does, however, make it possible.

The question of priority was addressed in my recent response to John?s email (addEventFilter) and I feel it?s not relevant to the problem at hand, which is to provide customization of key bindings, including at run time.

The ?feature request? (common keys) in the second part of your message is a separate and possibly valid concern, but it?s a separate issue.  Perhaps you could start a new thread listing some (all?) examples?  I don?t think we have any existing documentation of the key bindings, so here we go:
https://github.com/andy-goryachev-oracle/jfx/tree/8314906.behavior.test/doc-files/behavior

The question I have is: is there anything in this proposal that makes it impossible to do something, and if so, what is it specifically?  Is there a concrete design you would like to propose that might be better?

Thank you
-andy

From: openjfx-dev  on behalf of Martin Fox 
Date: Wednesday, October 11, 2023 at 10:27
To: John Hendrikx 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap

On Oct 11, 2023, at 1:03 AM, John Hendrikx  wrote:

After reading John's message I realize that the InputMap proposal doesn?t list the limitations of the current design. It seems to be addressing some of the sequencing issues John mentions but doesn?t state outright that it?s doing so or why. I would set aside the proposal and focus on writing a problem statement document first.

A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.
Seconded. Whatever Eclipse is doing to implement their key binding interface is deep and complex and there?s no way JavaFX could craft a solution Eclipse would use. I think that will be true for most apps that allow user customizable key bindings. And I?m pretty sure that when the user customizes a key binding Eclipse is not tracking down all of the affected controls and updating their per-instance key binding maps. Those maps have to be centralized and shared in some manner.

So in short, what I think this should be about is:

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
I have another recommendation (which may be more of a feature request). There should be a centralized way of mapping common keys to actions to ensure a consistent vocabulary across the user interface. As an example, on many controls Shift + up arrow should map to something like ?moveUpAndExtendTheSelection?. There are a lot of these standardized bindings, some of them are platform specific, and it?s a really tall order to expect all of the individual control classes to get this right.

On macOS there are two primary means of mapping a key event to an action and both are global. This means most of these mappings happen outside the individual controls and that the mappings are consistent across controls. This also addresses part of what John mentioned above; to make this work controls have to make their actions visible through callable methods.

Phrased as problem statement: currently individual control classes need to separately implement a large set of standardized keyboard bindings. This is a maintenance and testing issue.

- Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).

As I recall this is an issue with the traversal engine which is a maybe a separate topic (?) Was a bug ever entered on this?

Martin

On 10/10/2023 19:54, Andy Goryachev wrote:
Re-sending with a smaller image (256kb limit, really?).

From: Andy Goryachev 
Date: Tuesday, October 10, 2023 at 10:49
To: Michael Strau? 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
Dear Michael:

Here is a use case for (re-)mapping by the user at runtime:

(key mappings UI in Eclipse).

I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.

Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.

-andy

From: openjfx-dev  on behalf of Michael Strau? 
Date: Tuesday, October 10, 2023 at 10:36
To:
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
> Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>

I struggle to see a use case for this feature. I can imagine that
there might be some use cases that call for customized input mappings,
but why would this translate to a _mutable_ input map? That's quite a
departure from the way other parts of JavaFX work.

For example, skins are also immutable. If you want to have a different
skin for a control, you don't somehow modify the existing skin
instance; instead, you'd create a new skin class (or -- somehow --
extend an existing skin class), and then install that new skin on your
control.

An input map shouldn't bind input events directly to instance methods
of a particular control instance. It should define the mapping of
events to methods symbolically:

Instead of mapping Event => instance.method(), it should map Event =>
Control::method. The input map could then be stateless and immutable,
and can be set on any control instance. If you want to change the
mappings, just set a different input map instance. There's no need
that an input map would retain a reference to any particular control,
since the control reference can be passed into the input map just as
easily.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Wed Oct 11 18:14:50 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Oct 2023 18:14:50 GMT
Subject: RFR: JDK-8187314: All Cells: must show backing data always
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Aug 2023 18:13:34 GMT, Marius Hanl  wrote:

> Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`.
> This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise).
> We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value.
> 
> Changed and added tests for all 4 cells.

Do you have a SCCE for TreeTableView similar to the TreeView example in the ticket?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1197#issuecomment-1758220284

From mstrauss at openjdk.org  Wed Oct 11 20:22:26 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Oct 2023 20:22:26 GMT
Subject: RFR: 8313956: focusWithin on parents of a newly-added focused node
 is not updated [v2]
In-Reply-To: 
References: 
 <4ZbkdyxsP21OmH31jN73d0zMX6yZSmfkdATkupq0s6A=.1728e838-5aa9-4aed-a2b6-6b6c8f412e52@github.com>

Message-ID: <6RGs25KGRCmss4UJvogHef7euzkDvrZ1zH2ktqlSQz4=.a9ae1a29-93c6-4afb-bf3e-1b977aa477c7@github.com>

On Wed, 11 Oct 2023 17:56:15 GMT, Michael Strau?  wrote:

>>> > The `focusWithin` count cannot be negative, and there is no possible way for applications to misuse the API to cause a negative count. If it ends up being negative, that's because of a bug, and I think that bugs should be fixed and not logged.
>>> 
>>> Yes, the reason I was asking this is that we actually have this problem right now, that it could be negative, although it should not. If we would have logged that, we probably found that bug much earlier. In any case, I think with the new logic and the `count > 0`, it is fine as is.
>> 
>> @Maran23  Just to clarify...
>> If I have a case (with jfx21) where the count goes negative, is this still a bug that I should file?  Or are you saying that it's understood as expected behavior now?
>
>> > > The `focusWithin` count cannot be negative, and there is no possible way for applications to misuse the API to cause a negative count. If it ends up being negative, that's because of a bug, and I think that bugs should be fixed and not logged.
>> > 
>> > 
>> > Yes, the reason I was asking this is that we actually have this problem right now, that it could be negative, although it should not. If we would have logged that, we probably found that bug much earlier. In any case, I think with the new logic and the `count > 0`, it is fine as is.
>> 
>> @Maran23 Just to clarify... If I have a case (with jfx21) where the count goes negative, is this still a bug that I should file? Or are you saying that it's understood as expected behavior now?
> 
> If you have a situation where the focusWithin count is negative, please file it as a bug. That's not expected behavior.

> @mstr2 or @Maran23 Does "focus owner" == "input focus" == "scene focus owner" == where key events will be sent?

This is true in general. Note that an unfocused window will not receive input events, but the scene can have a focus owner nonetheless.

> I ask because the javadoc on Node.focusWithin says "Indicates whether this Node or any of its descendants currently has the **_input focus_**.", but in discussions it has been said that focusWithin includes a TableView's "focused item" even if that is not the scene's current focus owner (i.e. where key events will be sent).
> 
> It would be great if the javadoc for Node.focusWithin could be improved to avoid this kind of widespread confusion about what it really means.

Yes, the documentation is misleading. We should at the very least fix that.

By the way, there's an ongoing discussion on the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-October/042864.html

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1210#issuecomment-1758473325

From michaelstrau2 at gmail.com  Wed Oct 11 20:55:12 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 11 Oct 2023 22:55:12 +0200
Subject: New properties: focusOwner and focusOwnerWithin
In-Reply-To: <7618de08-d74f-0581-fdff-17b1fcb84133@gmail.com>
References: 
 <7618de08-d74f-0581-fdff-17b1fcb84133@gmail.com>
Message-ID: 

I think the cleanest solution would be to have the implementation of
Node.focused match its specification:

    Indicates whether this {@code Node} currently has the input focus.
    To have the input focus, a node must be the {@code Scene}'s focus
    owner, and the scene must be in a {@code Stage} that is visible
    and active.

Obviously, the Node.focused property is not implemented and used as
specified. But the problem is that Node.setFocused(boolean) is public
API. If we wanted the implementation to conform to its specification,
we would probably need to deprecate this API, and also make it
ineffective so that user code cannot change the focused property. Then
we need to fix all controls that use this API.

Maybe we can also just fix the controls without removing the
Node.setFocused API. But it begs the question why we would keep around
an API that is only useful in circumventing the specification of a
property. What do you think?

On Sun, Oct 8, 2023 at 10:11?AM John Hendrikx  wrote:
>
> I would be interested to know what use cases for these are, and what
> would be then left of the use cases for the existing focusWithin and
> focusVisible properties?  The ticket referred doesn't give one and only
> reports a bug.
>
> Before implementing a second set of these types of properties, I would
> like to know:
>
> - What would be the distinct uses for focusOwnerWithin vs focusWithin,
> are both actually needed?
> - Isn't focusOwnerProperty basically a "better" focusedProperty now
> because of how focusedProperty is abused by some controls?
> - Why indeed is TableView doing this and should it really be doing this
> instead of doing this another way?  If it just wants to show nodes in
> their focused style, that can (and should IMHO) be achieved differently.
>
> There seems to be a need to have some controls retain their focused look
> without them actually being the focus owner. TableView seems to be one
> of them, and I personally have another (I would like Nodes to keep
> looking focused even when their Stage has lost focus). The focused look
> relies on the `focused` pseudo class, which is now strictly controlled
> by the focusedProperty. It may be a good idea to look in another
> direction; one could change the style sheet for example to also have
> controls in focused look when they have a different pseudo class, say
> `fake-focused`.  TableView could then use this (and so could I).
>
> With the TableView problem solved, the original focusWithin,
> focusVisible and focused properties then can serve the purposes they
> were intended for, instead of basically replacing them with a new set
> that acts slightly differently to work around a problem with TableView.
>
> If this does move forward though, I wonder why these need to be
> properties specifically, given how hesistant we were to add properties
> to Node?  The `shownProperty` which IMHO has far more uses given the
> essential role it can play in deterministic clean-up was rejected over
> such an argument.  Why isn't simply checking the psuedoClassState
> sufficient for these properties:
> `getPseudoClassStates().contains(FOCUS_OWNER_PSEUDOCLASS_STATE)`?
>
> --John
>

From martin at martinfox.com  Wed Oct 11 21:53:07 2023
From: martin at martinfox.com (Martin Fox)
Date: Wed, 11 Oct 2023 14:53:07 -0700
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
 <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>

Message-ID: <6C26F8E1-271E-466E-A63E-6801376D2EF3@martinfox.com>

Andy,

This might be just a matter of style but IMHO the limitations of the current design aren?t listed in the Summary. For example, I have to get down to the description section before I see this requirement:

	ensure that user-defined mappings overwrite default ones and survive a skin change

There?s nothing indicating that this is currently not working (or why it?s not working). But perhaps this is something I should already know since I do spend most of my time down in the platform code.

> Perhaps you could start a new thread listing some (all?) examples?  I don?t think we have any existing documentation of the key bindings, so here we go:
> https://github.com/andy-goryachev-oracle/jfx/tree/8314906.behavior.test/doc-files/behavior

That?s a long list with several platform-specific nuances. You?ll need to re-implement a big chunk of them for the table and tree view controls. In your proposal you give an example of a RichTextArea and it will also need to re-implement all of these.

In macOS 10.14 Apple created the NSStandardKeyBindingResponding  protocol to encapsulate some of the potential binding targets. It?s overkill and doesn?t cover a bunch of common bindings like Shortcut+C for Copy. BTW, there?s a way for power-users to alter these bindings but it relies on them being global.

I?ll dig into the proposal a bit more but probably not before next week.

Martin

>  
> From: openjfx-dev  on behalf of Martin Fox 
> Date: Wednesday, October 11, 2023 at 10:27
> To: John Hendrikx 
> Cc: openjfx-dev at openjdk.org 
> Subject: Re: [Request for Comments] Behavior / InputMap
> 
>  
> On Oct 11, 2023, at 1:03 AM, John Hendrikx  wrote:
>  
> After reading John's message I realize that the InputMap proposal doesn?t list the limitations of the current design. It seems to be addressing some of the sequencing issues John mentions but doesn?t state outright that it?s doing so or why. I would set aside the proposal and focus on writing a problem statement document first.
> A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.
> 
> Seconded. Whatever Eclipse is doing to implement their key binding interface is deep and complex and there?s no way JavaFX could craft a solution Eclipse would use. I think that will be true for most apps that allow user customizable key bindings. And I?m pretty sure that when the user customizes a key binding Eclipse is not tracking down all of the affected controls and updating their per-instance key binding maps. Those maps have to be centralized and shared in some manner.
> So in short, what I think this should be about is:
> 
> - Ensure user event handlers have priority over behavior/inputmap added ones
> - Ensure all behavior actions are available as methods on controls
> 
> I have another recommendation (which may be more of a feature request). There should be a centralized way of mapping common keys to actions to ensure a consistent vocabulary across the user interface. As an example, on many controls Shift + up arrow should map to something like ?moveUpAndExtendTheSelection?. There are a lot of these standardized bindings, some of them are platform specific, and it?s a really tall order to expect all of the individual control classes to get this right.
>  
> On macOS there are two primary means of mapping a key event to an action and both are global. This means most of these mappings happen outside the individual controls and that the mappings are consistent across controls. This also addresses part of what John mentioned above; to make this work controls have to make their actions visible through callable methods.
>  
> Phrased as problem statement: currently individual control classes need to separately implement a large set of standardized keyboard bindings. This is a maintenance and testing issue.
> - Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).
> 
> As I recall this is an issue with the traversal engine which is a maybe a separate topic (?) Was a bug ever entered on this?
> 
> Martin
> 
> On 10/10/2023 19:54, Andy Goryachev wrote:
> 
> Re-sending with a smaller image (256kb limit, really?).
>  
> From: Andy Goryachev  
> Date: Tuesday, October 10, 2023 at 10:49
> To: Michael Strau?  
> Cc: openjfx-dev at openjdk.org   
> Subject: Re: [Request for Comments] Behavior / InputMap
> 
> Dear Michael:
>  
> Here is a use case for (re-)mapping by the user at runtime:
>  
> 
>  
> (key mappings UI in Eclipse).
>  
> I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.
>  
> Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.
>  
> -andy
>  
>  
> From: openjfx-dev   on behalf of Michael Strau?  
> Date: Tuesday, October 10, 2023 at 10:36
> To: 
> Cc: openjfx-dev at openjdk.org   
> Subject: Re: [Request for Comments] Behavior / InputMap
> 
> > Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
> >
> 
> I struggle to see a use case for this feature. I can imagine that
> there might be some use cases that call for customized input mappings,
> but why would this translate to a _mutable_ input map? That's quite a
> departure from the way other parts of JavaFX work.
> 
> For example, skins are also immutable. If you want to have a different
> skin for a control, you don't somehow modify the existing skin
> instance; instead, you'd create a new skin class (or -- somehow --
> extend an existing skin class), and then install that new skin on your
> control.
> 
> An input map shouldn't bind input events directly to instance methods
> of a particular control instance. It should define the mapping of
> events to methods symbolically:
> 
> Instead of mapping Event => instance.method(), it should map Event =>
> Control::method. The input map could then be stateless and immutable,
> and can be set on any control instance. If you want to change the
> mappings, just set a different input map instance. There's no need
> that an input map would retain a reference to any particular control,
> since the control reference can be passed into the input map just as
> easily.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Wed Oct 11 22:12:13 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 11 Oct 2023 22:12:13 +0000
Subject: Question: bidi navigation
Message-ID: 

Hi.

I have a question for people who routinely use right-to-left RTL languages (Arabic, Hebrew, etc.):

What is your expectation for navigating text using left/right arrow keys when the text contains a mixture of RTL and LTR?

It looks like there is no standard when it comes to modern applications ? see a small sample:
https://gist.github.com/andy-goryachev-oracle/4802f9380fb03ec2be7ac36bd98a2059

In javafx, the navigation of bidirectional (bidi) text might have been broken sometime after jfx8, and even jfx8 might have issues, see
https://bugs.openjdk.org/browse/JDK-8296266

It looks like the most modern applications use logical navigation and logical selection (that is, when navigating using left/right arrow keys, the cursor position reflects previous/next insertion indexes in the text, rather than visual position).  This causes the cursor to change the direction of movement when it crosses the bidi boundary.  Would you say this is the expected behavior?

Thank you
-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Wed Oct 11 22:36:02 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 11 Oct 2023 22:36:02 +0000
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: <6C26F8E1-271E-466E-A63E-6801376D2EF3@martinfox.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
 <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>

 <6C26F8E1-271E-466E-A63E-6801376D2EF3@martinfox.com>
Message-ID: 

Martin:

Right, the user-specific mappings are simply not possible in the current version of FX.

Speaking of the platform nuances ? this might be relevant to the ongoing platform API discussion.  Right now FX picks up nothing from the preferences set by the user within the OS.  You are right, macOS allows the user to change key modifiers (for example, switch control and command keys, Settings -> Keyboard -> Keyboard Shortcuts -> Modifier Keys) and FX remains oblivious to this change.

Should FX pick up this user setting?  Should it propagate to FX and Swing shortcut keys?  Should FX pick up custom colors?  And so on...

Getting back to the input map proposal, it followed a JEP format convention, but one thing it isn?t is the requirements document.  I wouldn?t mind creating one or adding a section to the proposal, but I wanted to hear the community feedback first (and got plenty, thanks!).  Let?s see what else we could find.

Thank you
-andy

From: Martin Fox 
Date: Wednesday, October 11, 2023 at 14:53
To: Andy Goryachev 
Cc: John Hendrikx , openjfx-dev at openjdk.org 
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
Andy,

This might be just a matter of style but IMHO the limitations of the current design aren?t listed in the Summary. For example, I have to get down to the description section before I see this requirement:

ensure that user-defined mappings overwrite default ones and survive a skin change

There?s nothing indicating that this is currently not working (or why it?s not working). But perhaps this is something I should already know since I do spend most of my time down in the platform code.

Perhaps you could start a new thread listing some (all?) examples?  I don?t think we have any existing documentation of the key bindings, so here we go:
https://github.com/andy-goryachev-oracle/jfx/tree/8314906.behavior.test/doc-files/behavior

That?s a long list with several platform-specific nuances. You?ll need to re-implement a big chunk of them for the table and tree view controls. In your proposal you give an example of a RichTextArea and it will also need to re-implement all of these.

In macOS 10.14 Apple created the NSStandardKeyBindingResponding protocol to encapsulate some of the potential binding targets. It?s overkill and doesn?t cover a bunch of common bindings like Shortcut+C for Copy. BTW, there?s a way for power-users to alter these bindings but it relies on them being global.

I?ll dig into the proposal a bit more but probably not before next week.

Martin

From: openjfx-dev  on behalf of Martin Fox 
Date: Wednesday, October 11, 2023 at 10:27
To: John Hendrikx 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap

On Oct 11, 2023, at 1:03 AM, John Hendrikx  wrote:

After reading John's message I realize that the InputMap proposal doesn?t list the limitations of the current design. It seems to be addressing some of the sequencing issues John mentions but doesn?t state outright that it?s doing so or why. I would set aside the proposal and focus on writing a problem statement document first.

A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.
Seconded. Whatever Eclipse is doing to implement their key binding interface is deep and complex and there?s no way JavaFX could craft a solution Eclipse would use. I think that will be true for most apps that allow user customizable key bindings. And I?m pretty sure that when the user customizes a key binding Eclipse is not tracking down all of the affected controls and updating their per-instance key binding maps. Those maps have to be centralized and shared in some manner.

So in short, what I think this should be about is:

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
I have another recommendation (which may be more of a feature request). There should be a centralized way of mapping common keys to actions to ensure a consistent vocabulary across the user interface. As an example, on many controls Shift + up arrow should map to something like ?moveUpAndExtendTheSelection?. There are a lot of these standardized bindings, some of them are platform specific, and it?s a really tall order to expect all of the individual control classes to get this right.

On macOS there are two primary means of mapping a key event to an action and both are global. This means most of these mappings happen outside the individual controls and that the mappings are consistent across controls. This also addresses part of what John mentioned above; to make this work controls have to make their actions visible through callable methods.

Phrased as problem statement: currently individual control classes need to separately implement a large set of standardized keyboard bindings. This is a maintenance and testing issue.

- Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).

As I recall this is an issue with the traversal engine which is a maybe a separate topic (?) Was a bug ever entered on this?

Martin

On 10/10/2023 19:54, Andy Goryachev wrote:
Re-sending with a smaller image (256kb limit, really?).

From: Andy Goryachev 
Date: Tuesday, October 10, 2023 at 10:49
To: Michael Strau? 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
Dear Michael:

Here is a use case for (re-)mapping by the user at runtime:

(key mappings UI in Eclipse).

I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.

Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.

-andy

From: openjfx-dev  on behalf of Michael Strau? 
Date: Tuesday, October 10, 2023 at 10:36
To:
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
> Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>

I struggle to see a use case for this feature. I can imagine that
there might be some use cases that call for customized input mappings,
but why would this translate to a _mutable_ input map? That's quite a
departure from the way other parts of JavaFX work.

For example, skins are also immutable. If you want to have a different
skin for a control, you don't somehow modify the existing skin
instance; instead, you'd create a new skin class (or -- somehow --
extend an existing skin class), and then install that new skin on your
control.

An input map shouldn't bind input events directly to instance methods
of a particular control instance. It should define the mapping of
events to methods symbolically:

Instead of mapping Event => instance.method(), it should map Event =>
Control::method. The input map could then be stateless and immutable,
and can be set on any control instance. If you want to change the
mappings, just set a different input map instance. There's no need
that an input map would retain a reference to any particular control,
since the control reference can be passed into the input map just as
easily.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.hendrikx at gmail.com  Wed Oct 11 23:15:38 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 12 Oct 2023 01:15:38 +0200
Subject: New properties: focusOwner and focusOwnerWithin
In-Reply-To: 
References: 
 <7618de08-d74f-0581-fdff-17b1fcb84133@gmail.com>

Message-ID: <69ce289d-3e58-97fe-524d-c90f0908ff7a@gmail.com>

I don't see how a method like `setFocused` could possibly work without 
violating its specification.? When a Scene is present, it could in 
theory update the focusOwner, but when no Scene is present it probably 
needs to remain `false` even when set to `true` (as otherwise you could 
set multiple nodes to focused, unless you did a full scan of the entire 
UI hierarchy to avoid that...).

Perhaps it is possible to make setFocused do something useful; let it 
immediately change focus/focusOwner -- that could be tough as I think 
focus changes can be veto'd; the purpose of requestFocus would then only 
be to also focus the window.? The setFocused method would then be a 
useful feature.? It would still need a Scene to work (but its 
specification agrees with that part, so it can indeed remain false if 
not attached to a scene).? All nodes would need to clear focus status 
when the Scene is null'd, and when calling setFocused on a Node, any 
currently focused node in the same Scene needs to lose it (probably best 
to remove focus first so those notifications happen before the new node 
gains focus).

`setFocused(false)` would also need some special treatment; either it's 
not allowed at all, or some other node gets picked as the new focus 
owner (perhaps it switches to the first focusable node, sort of like a 
focus reset as if the UI was freshly created).

If the above ain't realistically possible, then I guess deprecation is 
the only option.

--John

On 11/10/2023 22:55, Michael Strau? wrote:
> I think the cleanest solution would be to have the implementation of
> Node.focused match its specification:
>
>      Indicates whether this {@code Node} currently has the input focus.
>      To have the input focus, a node must be the {@code Scene}'s focus
>      owner, and the scene must be in a {@code Stage} that is visible
>      and active.
>
> Obviously, the Node.focused property is not implemented and used as
> specified. But the problem is that Node.setFocused(boolean) is public
> API. If we wanted the implementation to conform to its specification,
> we would probably need to deprecate this API, and also make it
> ineffective so that user code cannot change the focused property. Then
> we need to fix all controls that use this API.
>
> Maybe we can also just fix the controls without removing the
> Node.setFocused API. But it begs the question why we would keep around
> an API that is only useful in circumventing the specification of a
> property. What do you think?
>
>
> On Sun, Oct 8, 2023 at 10:11?AM John Hendrikx  wrote:
>> I would be interested to know what use cases for these are, and what
>> would be then left of the use cases for the existing focusWithin and
>> focusVisible properties?  The ticket referred doesn't give one and only
>> reports a bug.
>>
>> Before implementing a second set of these types of properties, I would
>> like to know:
>>
>> - What would be the distinct uses for focusOwnerWithin vs focusWithin,
>> are both actually needed?
>> - Isn't focusOwnerProperty basically a "better" focusedProperty now
>> because of how focusedProperty is abused by some controls?
>> - Why indeed is TableView doing this and should it really be doing this
>> instead of doing this another way?  If it just wants to show nodes in
>> their focused style, that can (and should IMHO) be achieved differently.
>>
>> There seems to be a need to have some controls retain their focused look
>> without them actually being the focus owner. TableView seems to be one
>> of them, and I personally have another (I would like Nodes to keep
>> looking focused even when their Stage has lost focus). The focused look
>> relies on the `focused` pseudo class, which is now strictly controlled
>> by the focusedProperty. It may be a good idea to look in another
>> direction; one could change the style sheet for example to also have
>> controls in focused look when they have a different pseudo class, say
>> `fake-focused`.  TableView could then use this (and so could I).
>>
>> With the TableView problem solved, the original focusWithin,
>> focusVisible and focused properties then can serve the purposes they
>> were intended for, instead of basically replacing them with a new set
>> that acts slightly differently to work around a problem with TableView.
>>
>> If this does move forward though, I wonder why these need to be
>> properties specifically, given how hesistant we were to add properties
>> to Node?  The `shownProperty` which IMHO has far more uses given the
>> essential role it can play in deterministic clean-up was rejected over
>> such an argument.  Why isn't simply checking the psuedoClassState
>> sufficient for these properties:
>> `getPseudoClassStates().contains(FOCUS_OWNER_PSEUDOCLASS_STATE)`?
>>
>> --John
>>

From duke at openjdk.org  Thu Oct 12 05:58:32 2023
From: duke at openjdk.org (Martin Fox)
Date: Thu, 12 Oct 2023 05:58:32 GMT
Subject: RFR: 8316419: [macos] Setting X/Y makes Stage maximization not work
 before show
Message-ID: 

When a window is visible the maximized, iconified, and fullscreen properties are two-way streets; changes made in Java are sent on to the platform window and changes in the platform window are sent back into Java.

When a window is hidden these properties (and others, like location and sizing information) are not sent on to the platform window until the window is made visible. In other words, the properties don't reflect the actual state of the window but the intended state after it's shown.

There's a period when the window is transitioning from hidden to shown where the core Stage code is using the stored properties to configure the platform window and the platform window is simultaneously calling back in to update the properties. This was causing the intended state to be wiped out before it could be sent on to the platform window.

The problem is specific to Mac because on that platform any change to the size or location of a window can cause it to enter or leave the maximized (zoomed) state. So just setting the location can cause the maximized flag to be altered.

The proposed solution is to copy the intended state bits to Stage local variables to be used later in the configuration.

-------------

Commit messages:
 - Stages on Mac now honor iconified and maximized flags set while the window is hidden.

Changes: https://git.openjdk.org/jfx/pull/1258/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1258&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316419
  Stats: 19 lines in 2 files changed: 10 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1258.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1258/head:pull/1258

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

From jvos at openjdk.org  Thu Oct 12 08:13:22 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 12 Oct 2023 08:13:22 GMT
Subject: RFR: 8314484: Update Gradle to 8.4
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 17:39:53 GMT, Ambarish Rapte  wrote:

> Upgrade gradle to version 8.4.
> It also includes a change for adding task dependency for windows platform that was missed in [JDK-8314486](https://bugs.openjdk.org/browse/JDK-8314486)

tested on Ubuntu 22.04: all good.

-------------

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1257#pullrequestreview-1673561143

From john.hendrikx at gmail.com  Thu Oct 12 08:33:14 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 12 Oct 2023 10:33:14 +0200
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>

Message-ID: <2c39bd6a-1cb1-7943-ea9b-6807e427cccc@gmail.com>

On 11/10/2023 19:44, Andy Goryachev wrote:
>
> Dear John:
>
> Seems like addEventFilter() was specifically designed to intercept 
> events before any other handlers, so I see no problem there.
>
This is a misunderstanding of what filters are for.? They're called in 
the capturing phase and they can prevent an event from reaching its 
intended target, but you want it to reach the intended target FIRST, as 
you still want to give the target the chance to be the first to act upon 
the event.? For example, let's say I want to attach a function to the 
SPACE key in some specialized HBox, it should only do something when 
something closer to the target doesn't need it first (like a nested HBox 
of the same type, or an active TextField that uses SPACE for input). Now 
if HBox had some FX default event handler that consumed SPACE, I have no 
options to override SPACE anymore; the filter is not a good spot, as its 
too early, and the handler is not a good spot because Behavior handlers 
were added before mine was.

> I somewhat disagree about the purpose of the key mapping system ? the 
> proposed solution solves two existing issues (the skin/behavior 
> mappings and the user mappings) in one neat package.? Every other 
> instrument such as addEventHandler/Filter is still there.
>
I'm saying that the need for this would be almost non-existent if user 
event handlers weren't considered less important than FX ones. You have 
to be careful that there aren't two ways of doing things here:

If the event you wish to give an alternative purpose to is unused by FX, 
you can use an event handler; otherwise you must disable it (so you can 
use an event handler!) or remap it (using an alternative system).? Note 
that if FX at some point decides to "claim" another mapping, that would 
be a breaking change as some user event handlers may cease to function.

This is why I think the input mapping system should stay hidden; its an 
implementation detail of the Event handlers added by FX so they don't 
need to write long if/else/switch chains, and so they can more easily 
switch out mappings depending on state.? Opening up the input map 
effectively is being able to influence those FX added event handlers to 
do something different, while there is a perfectly good way of doing 
that already: add your own event handler (with higher priority).

> And, if we look at the three bullet points
>
> - Ensure user event handlers have priority over behavior/inputmap 
> added ones
> - Ensure all behavior actions are available as methods on controls
> - Ensure that if a key is handled by the control, that it is ONLY 
> consumed when it actually triggers an action (navigation keys get 
> consumed regardless, even if no focus change results, that's wrong).
>
> I absolutely agree, and in fact the first three are indeed a part of 
> the proposal.? Well, the 3^rd one might unfortunately be a subject of 
> backward compatibility limitation since one of the requirements was no 
> behavior change w.r.t. the earlier versions.? We can always change the 
> behavior if we have a completing reason and go through the usual 
> process, nothing in the proposal precludes that.
>
I don't see how your proposal addresses the first point.

I've been reading the comments attached to 
https://bugs.openjdk.org/browse/JDK-8091189 and it has a lot of good 
information, and raises many good points (immutable input maps, keep 
input maps/behaviors as implementation details, use interfaces instead 
of base classes, what about controls that have no Skin, even the point I 
made about having the Control be in charge of registering the event 
handlers instead of letting InputMap do it requiring a Control 
field...).? There are several patches by Jonathan Giles, and there is 
even a library created by the author of ReactFX that allows for 
replacing key bindings with a much nicer API already (in so far that is 
possible without having inside FX support).

The general tone of the comments seems to be that Behaviors should be 
kept as implementation details -- they're not well defined (what is a 
Behavior, what should be in the Behavior, what should be in the Skin and 
what should be in the Control) and until that is absolutely clear, 
exposing any of that as API is premature.

> Making the behaviors completely independent with setBehavior() and 
> FXML, as you said, might be a future effort, perhaps we could attempt 
> opening up certain controls at some point.? On one hand, I am for 
> increasing the extensibility of FX, on the other hand the same 
> argument can be made against it (as in solidifying a particular way of 
> constructing skins and behaviors), but I feel it?s a separate issue 
> that is independent of this proposal.
>
I'm starting to lean towards keeping all of this as implementation 
details, at least until the current implementation is much cleaner than 
it is currently (the way InputMap and Behaviors currently are set up is 
more pragmatic than truly a good design), and just address the main 
issue: JavaFX stealing events that users want to override, note that I 
say events, key bindings are only part of it.

--John

> -andy
>
> *From: *openjfx-dev  on behalf of John 
> Hendrikx 
> *Date: *Wednesday, October 11, 2023 at 01:04
> *To: *openjfx-dev at openjdk.org 
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> I'm sorry, but that providing an arbitrary key mapping system seems 
> completely out of scope and not something that JavaFX should concern 
> itself with.? It's much too high level, when the key mappings involved 
> should only be for actions that the control can provide on its own.
>
> I think the problem we should be solving is that JavaFX control 
> behaviors shouldn't be first in line when it comes to consuming events 
> (which currently is only the case due to event handlers being added at 
> the earliest possible opportunity, and event handlers being called in 
> order). If something as trivial as:
>
> ?????? control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
> ????????????? if (e.getCode() == KeyCode.LEFT) {
> ??????????????????? e.consume();? // stop default behavior
> ????????????? }
> ?????? });
>
> ... actually worked, then there is much less need to redefine/disable 
> behavior key mappings, and no need for a secondary system that deals 
> with mappings (the first system, event handlers, can simply be used 
> for this).? If user event handlers had priority over behavior ones, 
> then everything you want can be achieved with the above, including:
>
> - Stopping default behavior
> - Triggering different behavior (just call something on control, of 
> course, make sure all behavior actions are available on the control in 
> the first place)
> - Remapping (a combination of the above two)
> - Adding an alternative key for the same behavior
>
> A system to remap keys can then be left squarely in the realm of user 
> space, and much nicer solutions can be build by users than whatever 
> JavaFX will provide out of the box.
>
> Changes to the Behavior system can then focus on replacing complete 
> behaviors (including their input map) and being able to use these by 
> default for a certain subset of controls (like -fx-skin provide in 
> CSS), as this is something users currently can't do.
>
> So in short, what I think this should be about is:
>
> - Ensure user event handlers have priority over behavior/inputmap 
> added ones
> - Ensure all behavior actions are available as methods on controls
> - Ensure that if a key is handled by the control, that it is ONLY 
> consumed when it actually triggers an action (navigation keys get 
> consumed regardless, even if no focus change results, that's wrong).
>
> Future:
>
> - Make behaviors public and allow Behaviors to be replaced with 
> -fx-behavior type CSS syntax / control.setBehavior calls
>
> --John
>
> The focus should be on being able to modify standard behavior of 
> controls (arrow-left, enter, ctrl-shift-right, etc.), specifically 
> also to be able to disable these when undesired, and, on top of that, 
> that they bubble up when NOT used even when they are configured (focus 
> navigation keys currently are always consumed, whether they actually 
> do something or not -- that's a big issue).? The other focus should be 
> on providing an alternative behavior (or at least mappings) for all 
> controls of a certain type -- I don't see the need for adding a 
> mapping to a specific control, that's already covered with event 
> handlers; the problem is mostly that behaviors currently steal certain 
> events before the user can get at them.
>
> Custom behaviors can then be constructed that provide more things that 
> may need mapping.? I'd expect those however to be limited in scope to 
> what the control offers, certainly not an arbitrary key/action mapping 
> system (that wouldn't even work, as most of these would be in the 
> scope of several controls or be global).? This kind of functionality 
> is much better provided by event handlers at the correct level for a 
> group of controls, and I wouldn't expect to find such an eloborate 
> system incorporated in behaviors.
>
> In fact, thinking about all of this a bit more,
>
> On 10/10/2023 19:54, Andy Goryachev wrote:
>
>     Re-sending with a smaller image (256kb limit, really?).
>
>     *From: *Andy Goryachev 
>     
>     *Date: *Tuesday, October 10, 2023 at 10:49
>     *To: *Michael Strau? 
>     
>     *Cc: *openjfx-dev at openjdk.org 
>     
>     *Subject: *Re: [Request for Comments] Behavior / InputMap
>
>     Dear Michael:
>
>     Here is a use case for (re-)mapping by the user at runtime:
>
>     (key mappings UI in Eclipse).
>
>     I can think of several other cases (mentioned in the proposal, I
>     think) so I think we can put the concept of immutable or global
>     InputMap to rest.
>
>     Whether the InputMap contains the reference to its control or not
>     is a minor implementation detail, I think.
>
>     -andy
>
>     *From: *openjfx-dev 
>      on behalf of Michael Strau?
>      
>     *Date: *Tuesday, October 10, 2023 at 10:36
>     *To: *
>     *Cc: *openjfx-dev at openjdk.org 
>     
>     *Subject: *Re: [Request for Comments] Behavior / InputMap
>
>     > Yes, one of the features the new design provides is ability to modify key
>     mappings by the user at runtime.? So yes, not only it needs to be
>     mutable, but it also adds some APIs for exactly that.
>     >
>
>     I struggle to see a use case for this feature. I can imagine that
>     there might be some use cases that call for customized input mappings,
>     but why would this translate to a _mutable_ input map? That's quite a
>     departure from the way other parts of JavaFX work.
>
>     For example, skins are also immutable. If you want to have a different
>     skin for a control, you don't somehow modify the existing skin
>     instance; instead, you'd create a new skin class (or -- somehow --
>     extend an existing skin class), and then install that new skin on your
>     control.
>
>     An input map shouldn't bind input events directly to instance methods
>     of a particular control instance. It should define the mapping of
>     events to methods symbolically:
>
>     Instead of mapping Event => instance.method(), it should map Event =>
>     Control::method. The input map could then be stateless and immutable,
>     and can be set on any control instance. If you want to change the
>     mappings, just set a different input map instance. There's no need
>     that an input map would retain a reference to any particular control,
>     since the control reference can be passed into the input map just as
>     easily.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: not available
URL: 

From arapte at openjdk.org  Thu Oct 12 09:11:28 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 12 Oct 2023 09:11:28 GMT
Subject: Integrated: 8314484: Update Gradle to 8.4
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 17:39:53 GMT, Ambarish Rapte  wrote:

> Upgrade gradle to version 8.4.
> It also includes a change for adding task dependency for windows platform that was missed in [JDK-8314486](https://bugs.openjdk.org/browse/JDK-8314486)

This pull request has now been integrated.

Changeset: e621d4b6
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/e621d4b65222ee99b29fb2709a830d8ad70ea44f
Stats:     261 lines in 7 files changed: 11 ins; 236 del; 14 mod

8314484: Update Gradle to 8.4

Reviewed-by: kcr, jvos

-------------

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

From fkirmaier at openjdk.org  Thu Oct 12 09:19:29 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 12 Oct 2023 09:19:29 GMT
Subject: RFR: JDK-8317308 JavaFX Developer build broken on Windows -
 NativeLibrary file contains invalid character ':'
In-Reply-To: <1ZUZluUKIQJhultCj_M33CNE3BoyP-ylWG1JP_3vBjo=.8de39edd-efda-48fc-aa11-97344fb5f1ec@github.com>
References: 
 <1ZUZluUKIQJhultCj_M33CNE3BoyP-ylWG1JP_3vBjo=.8de39edd-efda-48fc-aa11-97344fb5f1ec@github.com>
Message-ID: 

On Tue, 3 Oct 2023 15:35:40 GMT, John Neffenger  wrote:

>> The format of the timestamp has changed to ISO 8601. This contains the ?:? Character.
>> A copy of the dll is saved at /.openjfx/cache/" + jfxVersion + "/" + arch .
>> On Windows, the character ?:? is invalid in files, causing internal errors.
>> 
>> This only happens on developer/non-hudson builds, because on hudson-builds, the timestamp is omitted.
>> 
>> I just replaced the disallowed character when creating the native library.
>
> The follow-up pull request is [8317370: JavaFX runtime version is wrong at runtime][1]. I'll mark it ready for review when I finish running all of my test cases.
> 
>> On my fork, the code to add the "-internal" for non-hudson builds is removed.
> 
> @FlorianKirmaier You can remove "-internal" from the version string by overriding the `RELEASE_SUFFIX` property on the command line instead of modifying the build file. For example:
> 
> 
> # Sets the environment variable for reproducible builds
> SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
> export SOURCE_DATE_EPOCH
> 
> # Builds JavaFX
> bash gradlew --no-daemon \
>     -PPROMOTED_BUILD_NUMBER="31" \
>     -PRELEASE_SUFFIX="" \
>     -PJDK_DOCS="$JDK_DOCS" \
>     sdk jmods javadoc
> 
> 
> [1]:https://github.com/openjdk/jfx/pull/1253

@jgneff 
Thank you for the hint!
The next time, I'll use it, so I can reduce my changes in my fork.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1251#issuecomment-1759237842

From fkirmaier at openjdk.org  Thu Oct 12 09:23:19 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 12 Oct 2023 09:23:19 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 Oct 2023 16:24:42 GMT, John Neffenger  wrote:

>> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.
>
> John Neffenger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the documentation in UPDATING-VERSION.md

Based on the changes, it looks great - fewer variables, less code, more tests.
It's now also easier to follow, what the "no_hudson" flag does.

The ":" is now also removed from the version String - so my previous change would no longer be required.
But I guess it doesn't hurt either.

I tested making a build, and it works well!

So from my point of view, it looks quite great!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1253#issuecomment-1759244834

From kpk at openjdk.org  Thu Oct 12 09:40:18 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 12 Oct 2023 09:40:18 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v9]
In-Reply-To: 
References: 
Message-ID: 

> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
> 
> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
> 
> Added tests to validate the changes.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Fix repeating text node issue

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1157/files
  - new: https://git.openjdk.org/jfx/pull/1157/files/edb20ec5..34639797

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=07-08

  Stats: 195 lines in 6 files changed: 167 ins; 3 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1157.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157

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

From kpk at openjdk.org  Thu Oct 12 09:42:23 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 12 Oct 2023 09:42:23 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v8]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 3 Oct 2023 10:03:00 GMT, Karthik P K  wrote:

>> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
>> 
>> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
>> 
>> Added tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Fixed the issue when more than one text nodes with same text is present in text node. Added new test cases and improved current tests.
@andy-goryachev-oracle and @prrace please re-review.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1759276591

From gschmidj at qfs.de  Thu Oct 12 15:38:38 2023
From: gschmidj at qfs.de (Gregor Schmid)
Date: Thu, 12 Oct 2023 17:38:38 +0200
Subject: JavaFX, WebView and the WebP vulnerability
In-Reply-To: 
 (duke@openjdk.org's message of "Thu, 10 Aug 2023 07:53:36 GMT")
References: 

Message-ID: <4hmswnvojl.fsf_-_@qfs.de>

Hi Johan and all,

WebP vulnerabilty: https://nvd.nist.gov/vuln/detail/CVE-2023-4863

I guess we're not the only ones having been busy in the past weeks
recovering from that disaster, updating the WebP libraries in all the
various places.

What we haven't covered yet is WebView as part of JavaFX as part of
the JRE distributed with QF-Test. As I haven't seen anything on this
list, my questions are:

Is WebView affected? Given that WebKit supports WebP I would assume
yes.

If so, what are the plans? I see that, for example, JavaFX 17.0.9 from
Gluon is planned for release on October 17. Will it have a WebView
update with a clean WebP?

Thanks for any info and best regards,
    Greg

-- 
Gregor Schmid

Quality First Software GmbH
A company of mgm technology partners

B?rgermeister-Graf-Ring 10
82538 Geretsried

Phone: +49 8171 38648-11
Email: gregor.schmid at qfs.de | gregor.schmid at mgm-tp.com
Web:   www.qfs.de

Commercial Register: HRB M?nchen 140833
Managing Directors: Gregor Schmid, Karlheinz Kellerer

The data protection information in accordance with the EU General Data
Protection Regulation applies to authorized representatives /
authorized representatives of "legal persons" in accordance with Art.
12 ff. GDPR
https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf

From martin at martinfox.com  Thu Oct 12 16:30:56 2023
From: martin at martinfox.com (Martin Fox)
Date: Thu, 12 Oct 2023 09:30:56 -0700
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
 <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>

 <6C26F8E1-271E-466E-A63E-6801376D2EF3@martinfox.com>

Message-ID: <543E80E2-9418-47C5-BBE2-21A92C3D9C55@martinfox.com>

Andy,

> Speaking of the platform nuances ? this might be relevant to the ongoing platform API discussion.  Right now FX picks up nothing from the preferences set by the user within the OS.  You are right, macOS allows the user to change key modifiers (for example, switch control and command keys, Settings -> Keyboard -> Keyboard Shortcuts -> Modifier Keys) and FX remains oblivious to this change.

Those changes happen at a low level in the OS and are transparent to JavaFX. There?s nothing we need to do there.

We can?t directly query the OS to find a binding like, say, Shift + RIGHT => ?moveRight:?. The default mappings are well-established so just re-implementing them is fine. A super power user can alter these bindings by editing a text file and unless we go parse that text file we won?t honor those changes. But that file might contain bindings we can never map (like multi-character Emacs-style sequences) so there?s no guarantee that we can honor their bindings anyway.

A regular old power user (rather than a super power user) would probably use something like Karabiner which remaps things at a low level that?s transparent to us.

TL;DR not a bad idea to honor the platform key bindings but it would be nightmare to test and implement and benefit a very small number of super power users.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kpk at openjdk.org  Thu Oct 12 16:51:21 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 12 Oct 2023 16:51:21 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v10]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: 

On Fri, 6 Oct 2023 18:58:56 GMT, Andy Goryachev  wrote:

>> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
>> 
>> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
>> 
>> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
>> 
>> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
>> 
>> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - allowed characters
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - check
>  - test typing
>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>  - cleanup
>  - key modifier
>  - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test
>  - ... and 34 more: https://git.openjdk.org/jfx/compare/25862787...8b8112b8

The tests look good to me.
Left few minor comments inline.

doc-files/behavior/PasswordField.md line 3:

> 1: # PasswordField Behavior
> 2: 
> 3: ## Key Binginds

Minor: typo "Binginds"

doc-files/behavior/TextArea.md line 3:

> 1: # TextArea Behavior
> 2: 
> 3: ## Key Binginds

Minor: typo "Binginds"

doc-files/behavior/TextField.md line 3:

> 1: # TextField Behavior
> 2: 
> 3: ## Key Binginds

Minor: typo "Binginds"

doc-files/behavior/TextField.md line 72:

> 70: Notes:
> 71: 
> 72: 1. Base class mappings modified by the TextField class are highlighted in bold.

None of the key mappings are highlighted in bold in this file.

doc-files/behavior/TextInputControl.md line 3:

> 1: # TextInputControl Behavior
> 2: 
> 3: ## Key Binginds

Minor: typo "Binginds"

modules/javafx.controls/src/test/java/test/javafx/scene/control/behavior/BehaviorTestBase.java line 64:

> 62:      *     }
> 63:      * > 64:      * @param control the control being tested

Parameter can be renamed to control or comment can be updated.

-------------

Changes requested by kpk (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1221#pullrequestreview-1674243338
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1356864822
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1356866769
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1356872084
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1356883418
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1356872264
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1356936864

From angorya at openjdk.org  Thu Oct 12 17:01:16 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Oct 2023 17:01:16 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v10]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: 

On Thu, 12 Oct 2023 13:52:25 GMT, Karthik P K  wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
>> 
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>>  - allowed characters
>>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>>  - check
>>  - test typing
>>  - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
>>  - cleanup
>>  - key modifier
>>  - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test
>>  - ... and 34 more: https://git.openjdk.org/jfx/compare/25862787...8b8112b8
>
> doc-files/behavior/PasswordField.md line 3:
> 
>> 1: # PasswordField Behavior
>> 2: 
>> 3: ## Key Binginds
> 
> Minor: typo "Binginds"

The first rule of submitting scientific publications for a review: make an obvious spelling error in the title.
:-)

thanks!

> doc-files/behavior/TextField.md line 72:
> 
>> 70: Notes:
>> 71: 
>> 72: 1. Base class mappings modified by the TextField class are highlighted in bold.
> 
> None of the key mappings are highlighted in bold in this file.

none have been modified, so we are ok.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1357121963
PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1357124711

From angorya at openjdk.org  Thu Oct 12 17:08:39 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Oct 2023 17:08:39 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v11]
In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>
Message-ID: 

> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
> 
> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
> 
> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
> 
> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
> 
> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1221/files
  - new: https://git.openjdk.org/jfx/pull/1221/files/8b8112b8..4aac13a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=09-10

  Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1221.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221

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

From andy.goryachev at oracle.com  Thu Oct 12 17:26:47 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 12 Oct 2023 17:26:47 +0000
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: <543E80E2-9418-47C5-BBE2-21A92C3D9C55@martinfox.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>
 <82EEBF49-6652-45D2-B54C-4E6493122DF6@martinfox.com>

 <6C26F8E1-271E-466E-A63E-6801376D2EF3@martinfox.com>

 <543E80E2-9418-47C5-BBE2-21A92C3D9C55@martinfox.com>
Message-ID: 

I fully agree with you here, Martin.

-andy

From: Martin Fox 
Date: Thursday, October 12, 2023 at 09:31
To: Andy Goryachev 
Cc: John Hendrikx , openjfx-dev at openjdk.org 
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Andy,

Speaking of the platform nuances ? this might be relevant to the ongoing platform API discussion.  Right now FX picks up nothing from the preferences set by the user within the OS.  You are right, macOS allows the user to change key modifiers (for example, switch control and command keys, Settings -> Keyboard -> Keyboard Shortcuts -> Modifier Keys) and FX remains oblivious to this change.

Those changes happen at a low level in the OS and are transparent to JavaFX. There?s nothing we need to do there.

We can?t directly query the OS to find a binding like, say, Shift + RIGHT => ?moveRight:?. The default mappings are well-established so just re-implementing them is fine. A super power user can alter these bindings by editing a text file and unless we go parse that text file we won?t honor those changes. But that file might contain bindings we can never map (like multi-character Emacs-style sequences) so there?s no guarantee that we can honor their bindings anyway.

A regular old power user (rather than a super power user) would probably use something like Karabiner which remaps things at a low level that?s transparent to us.

TL;DR not a bad idea to honor the platform key bindings but it would be nightmare to test and implement and benefit a very small number of super power users.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Thu Oct 12 19:36:32 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Oct 2023 19:36:32 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v9]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 12 Oct 2023 09:40:18 GMT, Karthik P K  wrote:

>> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
>> 
>> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
>> 
>> Added tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeating text node issue

I think this looks good (with minor suggestions).  Tested with the MonkeyTester and with a rich text that contains multiple Text instances with exactly the same text.

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 213:

> 211:      * @return returns a {@link Hit} object containing character index, insertion index and position of cursor on the character.
> 212:      */
> 213:     public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart);

please add new `@param` blocks to javadoc

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 458:

> 456:                 for (int i = 0; i < lineIndex; i++) {
> 457:                     for (TextRun r: lines[i].runs) {
> 458:                         if (r.getTextSpan() != null && r.getTextSpan().getText().equals(text) && r.getStart() >= textRunStart) {

speedup: you may want to compute `>=textRunStart` condition before `.equals(text)` to save CPU cycles (basically, swap the two conditions here)

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 466:

> 464:                 boolean isPrevNodeExcluded = false;
> 465:                 for (TextRun r: runs) {
> 466:                     if (!r.getTextSpan().getText().equals(text) || (r.getTextSpan().getText().equals(text) && r.getStart() < textRunStart)) {

same suggestion about swapping conditions to save some CPU cycles

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 763:

> 761:             if (!textFound) {
> 762:                 for (TextRun r : lines[index].runs) {
> 763:                     if (r.getTextSpan() == null || (r.getTextSpan().getText().equals(text) && r.getStart() == runStart)) {

and definitely here `==` should go before `.equals()`

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1032:

> 1030:             while (runIndex < runs.length - 1) {
> 1031:                 if (ptInParent.getY() > runs[runIndex].getLocation().y
> 1032:                         && ptInParent.getY() < runs[runIndex + 1].getLocation().y) {

[minor]: the formatting looks off.  If we rename 'ptInParent` to `p` it will fit on one line.
Also, ptInParent.getY() gets called twice, may be use a local variable?  Also will make it shorter.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1039:

> 1037:         }
> 1038:         int textRunStart = runs.length == 0 ? 0 : ((TextRun) runs[0]).getStart();
> 1039:         int curRunStart = runs.length == 0 ? 0 : ((TextRun) runs[runIndex]).getStart();

very minor: we are computing run.length == 0 twice.  I know it might look neater than

int textRunStart;
int curRunStart;
if(runs.length == 0) {
  textRunStart = 0;
  curRunStart = 0;
} else {
 ...
}

-------------

PR Review: https://git.openjdk.org/jfx/pull/1157#pullrequestreview-1674985140
PR Review Comment: https://git.openjdk.org/jfx/pull/1157#discussion_r1357290999
PR Review Comment: https://git.openjdk.org/jfx/pull/1157#discussion_r1357293077
PR Review Comment: https://git.openjdk.org/jfx/pull/1157#discussion_r1357293685
PR Review Comment: https://git.openjdk.org/jfx/pull/1157#discussion_r1357294513
PR Review Comment: https://git.openjdk.org/jfx/pull/1157#discussion_r1357297816
PR Review Comment: https://git.openjdk.org/jfx/pull/1157#discussion_r1357301413

From angorya at openjdk.org  Thu Oct 12 19:40:23 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Oct 2023 19:40:23 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v9]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 12 Oct 2023 09:40:18 GMT, Karthik P K  wrote:

>> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
>> 
>> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
>> 
>> Added tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeating text node issue

Another observation, and it may be a different issue.  If i try to insert a Text instance with -fx-scale-x:200% into the flow, the scale affects the glyph rendering but neither caretShape, preferredWidth, nor hitInfo:

                t("BOLD ", f, "-fx-font-weight:bold;"),
                t("BOLD ", f, "-fx-font-weight:100; -fx-scale-x:200%;"),
                t("BOLD ", f, "-fx-font-weight:900;"),

![Screenshot 2023-10-12 at 12 33 36](https://github.com/openjdk/jfx/assets/107069028/6ad828af-fc24-4761-a798-dbb071d98e5e)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1760256042

From andy.goryachev at oracle.com  Thu Oct 12 19:56:52 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 12 Oct 2023 19:56:52 +0000
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: <2c39bd6a-1cb1-7943-ea9b-6807e427cccc@gmail.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>

 <2c39bd6a-1cb1-7943-ea9b-6807e427cccc@gmail.com>
Message-ID: 

Filters: are we talking about key bindings or event handlers?  With the key bindings, the user mappings take precedence over those registered through behavior.  There is no provision for adjusting priority of the event handlers ? that?s the FX reality, we don?t get to rearrange event handlers within the node.  That?s why I mentioned event filters added to the control.  I am not sure why you talk about HBoxes ? adding a filter on the control enables the user to intercept the event prior to skin/behavior.

So yes, this proposal does not address the event handlers (sorry for confusing key bindings with event handlers).  Unless we add addListenerBefore() API, we?d need to use event filters ? but this is out of scope for this proposal.

I do agree with you that we should keep the concrete Behaviors private for now.  In any case, public behaviors are outside of scope for this proposal.

One thing you mentioned several times is a ?truly good design?.  Let?s hear it!  Could you give us an outline, at the public API level at least, of such a design?

Thank you
-andy

From: John Hendrikx 
Date: Thursday, October 12, 2023 at 01:33
To: Andy Goryachev , openjfx-dev at openjdk.org 
Subject: [External] : Re: [Request for Comments] Behavior / InputMap

On 11/10/2023 19:44, Andy Goryachev wrote:
Dear John:

Seems like addEventFilter() was specifically designed to intercept events before any other handlers, so I see no problem there.

This is a misunderstanding of what filters are for.  They're called in the capturing phase and they can prevent an event from reaching its intended target, but you want it to reach the intended target FIRST, as you still want to give the target the chance to be the first to act upon the event.  For example, let's say I want to attach a function to the SPACE key in some specialized HBox, it should only do something when something closer to the target doesn't need it first (like a nested HBox of the same type, or an active TextField that uses SPACE for input).  Now if HBox had some FX default event handler that consumed SPACE, I have no options to override SPACE anymore; the filter is not a good spot, as its too early, and the handler is not a good spot because Behavior handlers were added before mine was.

I somewhat disagree about the purpose of the key mapping system ? the proposed solution solves two existing issues (the skin/behavior mappings and the user mappings) in one neat package.  Every other instrument such as addEventHandler/Filter is still there.

I'm saying that the need for this would be almost non-existent if user event handlers weren't considered less important than FX ones. You have to be careful that there aren't two ways of doing things here:

If the event you wish to give an alternative purpose to is unused by FX, you can use an event handler; otherwise you must disable it (so you can use an event handler!) or remap it (using an alternative system).  Note that if FX at some point decides to "claim" another mapping, that would be a breaking change as some user event handlers may cease to function.

This is why I think the input mapping system should stay hidden; its an implementation detail of the Event handlers added by FX so they don't need to write long if/else/switch chains, and so they can more easily switch out mappings depending on state.  Opening up the input map effectively is being able to influence those FX added event handlers to do something different, while there is a perfectly good way of doing that already: add your own event handler (with higher priority).

And, if we look at the three bullet points

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
- Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).
I absolutely agree, and in fact the first three are indeed a part of the proposal.  Well, the 3rd one might unfortunately be a subject of backward compatibility limitation since one of the requirements was no behavior change w.r.t. the earlier versions.  We can always change the behavior if we have a completing reason and go through the usual process, nothing in the proposal precludes that.

I don't see how your proposal addresses the first point.

I've been reading the comments attached to https://bugs.openjdk.org/browse/JDK-8091189 and it has a lot of good information, and raises many good points (immutable input maps, keep input maps/behaviors as implementation details, use interfaces instead of base classes, what about controls that have no Skin, even the point I made about having the Control be in charge of registering the event handlers instead of letting InputMap do it requiring a Control field...).  There are several patches by Jonathan Giles, and there is even a library created by the author of ReactFX that allows for replacing key bindings with a much nicer API already (in so far that is possible without having inside FX support).

The general tone of the comments seems to be that Behaviors should be kept as implementation details -- they're not well defined (what is a Behavior, what should be in the Behavior, what should be in the Skin and what should be in the Control) and until that is absolutely clear, exposing any of that as API is premature.

Making the behaviors completely independent with setBehavior() and FXML, as you said, might be a future effort, perhaps we could attempt opening up certain controls at some point.  On one hand, I am for increasing the extensibility of FX, on the other hand the same argument can be made against it (as in solidifying a particular way of constructing skins and behaviors), but I feel it?s a separate issue that is independent of this proposal.

I'm starting to lean towards keeping all of this as implementation details, at least until the current implementation is much cleaner than it is currently (the way InputMap and Behaviors currently are set up is more pragmatic than truly a good design), and just address the main issue: JavaFX stealing events that users want to override, note that I say events, key bindings are only part of it.

--John

-andy

From: openjfx-dev  on behalf of John Hendrikx 
Date: Wednesday, October 11, 2023 at 01:04
To: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap

I'm sorry, but that providing an arbitrary key mapping system seems completely out of scope and not something that JavaFX should concern itself with.  It's much too high level, when the key mappings involved should only be for actions that the control can provide on its own.
I think the problem we should be solving is that JavaFX control behaviors shouldn't be first in line when it comes to consuming events (which currently is only the case due to event handlers being added at the earliest possible opportunity, and event handlers being called in order).  If something as trivial as:

       control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
              if (e.getCode() == KeyCode.LEFT) {
                    e.consume();  // stop default behavior
              }
       });

... actually worked, then there is much less need to redefine/disable behavior key mappings, and no need for a secondary system that deals with mappings (the first system, event handlers, can simply be used for this).  If user event handlers had priority over behavior ones, then everything you want can be achieved with the above, including:

- Stopping default behavior
- Triggering different behavior (just call something on control, of course, make sure all behavior actions are available on the control in the first place)
- Remapping (a combination of the above two)
- Adding an alternative key for the same behavior

A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.

Changes to the Behavior system can then focus on replacing complete behaviors (including their input map) and being able to use these by default for a certain subset of controls (like -fx-skin provide in CSS), as this is something users currently can't do.

So in short, what I think this should be about is:

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
- Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).

Future:

- Make behaviors public and allow Behaviors to be replaced with -fx-behavior type CSS syntax / control.setBehavior calls

--John

The focus should be on being able to modify standard behavior of controls (arrow-left, enter, ctrl-shift-right, etc.), specifically also to be able to disable these when undesired, and, on top of that, that they bubble up when NOT used even when they are configured (focus navigation keys currently are always consumed, whether they actually do something or not -- that's a big issue).  The other focus should be on providing an alternative behavior (or at least mappings) for all controls of a certain type -- I don't see the need for adding a mapping to a specific control, that's already covered with event handlers; the problem is mostly that behaviors currently steal certain events before the user can get at them.

Custom behaviors can then be constructed that provide more things that may need mapping.  I'd expect those however to be limited in scope to what the control offers, certainly not an arbitrary key/action mapping system (that wouldn't even work, as most of these would be in the scope of several controls or be global).  This kind of functionality is much better provided by event handlers at the correct level for a group of controls, and I wouldn't expect to find such an eloborate system incorporated in behaviors.

In fact, thinking about all of this a bit more,

On 10/10/2023 19:54, Andy Goryachev wrote:
Re-sending with a smaller image (256kb limit, really?).

From: Andy Goryachev 
Date: Tuesday, October 10, 2023 at 10:49
To: Michael Strau? 
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
Dear Michael:

Here is a use case for (re-)mapping by the user at runtime:

[cid:part1.Mz2XogCD.DoK2QaIf at gmail.com]

(key mappings UI in Eclipse).

I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.

Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.

-andy

From: openjfx-dev  on behalf of Michael Strau? 
Date: Tuesday, October 10, 2023 at 10:36
To:
Cc: openjfx-dev at openjdk.org 
Subject: Re: [Request for Comments] Behavior / InputMap
> Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>

I struggle to see a use case for this feature. I can imagine that
there might be some use cases that call for customized input mappings,
but why would this translate to a _mutable_ input map? That's quite a
departure from the way other parts of JavaFX work.

For example, skins are also immutable. If you want to have a different
skin for a control, you don't somehow modify the existing skin
instance; instead, you'd create a new skin class (or -- somehow --
extend an existing skin class), and then install that new skin on your
control.

An input map shouldn't bind input events directly to instance methods
of a particular control instance. It should define the mapping of
events to methods symbolically:

Instead of mapping Event => instance.method(), it should map Event =>
Control::method. The input map could then be stateless and immutable,
and can be set on any control instance. If you want to change the
mappings, just set a different input map instance. There's no need
that an input map would retain a reference to any particular control,
since the control reference can be passed into the input map just as
easily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: image002.jpg
URL: 

From mhanl at openjdk.org  Thu Oct 12 20:06:22 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 12 Oct 2023 20:06:22 GMT
Subject: RFR: JDK-8187314: All Cells: must show backing data always
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 Oct 2023 18:11:44 GMT, Andy Goryachev  wrote:

> Do you have a SCCE for TreeTableView similar to the TreeView example in the ticket?

It should be the same as `TreeTableView` works basically the same as `TableView`.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1197#issuecomment-1760292078

From angorya at openjdk.org  Thu Oct 12 20:14:18 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Oct 2023 20:14:18 GMT
Subject: RFR: JDK-8187314: All Cells: must show backing data always
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Aug 2023 18:13:34 GMT, Marius Hanl  wrote:

> Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`.
> This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise).
> We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value.
> 
> Changed and added tests for all 4 cells.

could you please create one?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1197#issuecomment-1760301967

From mhanl at openjdk.org  Thu Oct 12 20:15:22 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 12 Oct 2023 20:15:22 GMT
Subject: RFR: JDK-8315569: Tests for the contract of
 SkinBase.layoutChildren(..) [v3]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 22 Sep 2023 17:14:30 GMT, Andy Goryachev  wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8315569: Improve test name and add 2.25 scale
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlLayoutTest.java line 44:
> 
>> 42: import static org.junit.jupiter.api.Assertions.assertTrue;
>> 43: 
>> 44: class ControlLayoutTest {
> 
> 1. should this class be public?
> 2. since no more tests are being planned here, perhaps we could rename it to be more specific (ControlLayoutTest still seems to be too generic to me), ControlLayoutChildrenContractTest or something like that?
> 3. could you please add a javadoc at the class level to explain what generate area this class tests?

1. No, JUnit5 classes can be package private as well and it is actually recommended
2. Well, we don't know. Maybe we will add some at one point, right now I don't have any idea what to add. Therefore I would keep the more generic name so we can reuse it at one point.
3. Same reason as 2., if we add more tests the Javadoc at class level may not be accurate anymore. 
+ There is Javadoc at method level already, which is more than 'necessary' as there is no policy that specifies that javadoc should be added to tests, I just do it voluntarily.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1357363874

From angorya at openjdk.org  Thu Oct 12 20:18:24 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Oct 2023 20:18:24 GMT
Subject: RFR: JDK-8315569: Tests for the contract of
 SkinBase.layoutChildren(..) [v3]
In-Reply-To: 
References: 

Message-ID: <0zgGwr1gt867LD2VGfhSmV9KMnya80_xrp161hHsVLI=.853eb8c8-6f0c-45c1-821f-6b71326327db@github.com>

On Fri, 22 Sep 2023 10:11:12 GMT, Marius Hanl  wrote:

>> This PR adds a test that verifies the `SkinBase.layoutChildren(..)` method with different scales.
>> While not explicitly documented, this method will receive the snapped and correctly calculated x, y, width and height values, so that children of the Control can be layouted correctly without requiring to do many more calculations regarding padding.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8315569: Improve test name and add 2.25 scale

? looking good

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1229#pullrequestreview-1675113019

From almatvee at openjdk.org  Fri Oct 13 01:33:23 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 13 Oct 2023 01:33:23 GMT
Subject: RFR: 8317508: Provide media support for libavcodec version 60
Message-ID: 

- Added support for libavcodec version 60.
- Tested on Ubuntu 23.10 with all possible media formats.
- Changed "--disable-yasm" to "--disable-asm". "--disable-asm" disables all assembler optimization and "--disable-yasm" only x86. Without "--disable-asm" I had issue building ffmpeg 6.0 on Ubuntu 23.10 most likely due to compiler version. Disabling assembler optimization fixed issue and we do not need this anyway for our stubs.

-------------

Commit messages:
 - 8317508: Provide media support for libavcodec version 60

Changes: https://git.openjdk.org/jfx/pull/1259/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1259&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317508
  Stats: 12 lines in 4 files changed: 7 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1259.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1259/head:pull/1259

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

From kpk at openjdk.org  Fri Oct 13 02:59:28 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 13 Oct 2023 02:59:28 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v11]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: 

On Thu, 12 Oct 2023 17:08:39 GMT, Andy Goryachev  wrote:

>> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
>> 
>> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
>> 
>> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
>> 
>> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
>> 
>> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

LGTM

-------------

Marked as reviewed by kpk (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1221#pullrequestreview-1675611628

From psadhukhan at openjdk.org  Fri Oct 13 03:29:10 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Oct 2023 03:29:10 GMT
Subject: RFR: 8318059: Typo is javafx.scene.Mode.usesMirroring comment
Message-ID: <_Dzm_yTGs9tFV06PCYbrxVcleexBIkFbc7XexUJSUpQ=.923df881-276c-4673-814e-b03ff6019b14@github.com>

Corrected the typo

-------------

Commit messages:
 - Typo fix

Changes: https://git.openjdk.org/jfx/pull/1260/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318059
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1260.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1260/head:pull/1260

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

From aghaisas at openjdk.org  Fri Oct 13 03:49:20 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 13 Oct 2023 03:49:20 GMT
Subject: RFR: 8318059: Typo is javafx.scene.Node.usesMirroring comment
In-Reply-To: <_Dzm_yTGs9tFV06PCYbrxVcleexBIkFbc7XexUJSUpQ=.923df881-276c-4673-814e-b03ff6019b14@github.com>
References: <_Dzm_yTGs9tFV06PCYbrxVcleexBIkFbc7XexUJSUpQ=.923df881-276c-4673-814e-b03ff6019b14@github.com>
Message-ID: <0NYMqWn6XCWXYoR0ii_n6_SeRuSmxVl7lMoAFOdf7h4=.976b208d-5740-4eb7-b544-1edd44dcdc01@github.com>

On Fri, 13 Oct 2023 03:23:42 GMT, Prasanta Sadhukhan  wrote:

> Corrected the typo

Looks good!

-------------

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1260#pullrequestreview-1675641812

From psadhukhan at openjdk.org  Fri Oct 13 03:52:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Oct 2023 03:52:19 GMT
Subject: Integrated: 8318059: Typo is javafx.scene.Node.usesMirroring comment
In-Reply-To: <_Dzm_yTGs9tFV06PCYbrxVcleexBIkFbc7XexUJSUpQ=.923df881-276c-4673-814e-b03ff6019b14@github.com>
References: <_Dzm_yTGs9tFV06PCYbrxVcleexBIkFbc7XexUJSUpQ=.923df881-276c-4673-814e-b03ff6019b14@github.com>
Message-ID: 

On Fri, 13 Oct 2023 03:23:42 GMT, Prasanta Sadhukhan  wrote:

> Corrected the typo

This pull request has now been integrated.

Changeset: 4604e873
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.org/jfx/commit/4604e87372adf3842529c1b3640bdb4424867e3d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8318059: Typo is javafx.scene.Node.usesMirroring comment

Reviewed-by: aghaisas

-------------

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

From kpk at openjdk.org  Fri Oct 13 07:01:51 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 13 Oct 2023 07:01:51 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v10]
In-Reply-To: 
References: 
Message-ID: 

> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
> 
> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
> 
> Added tests to validate the changes.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1157/files
  - new: https://git.openjdk.org/jfx/pull/1157/files/34639797..c0f1f9f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=08-09

  Stats: 14 lines in 3 files changed: 6 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1157.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157

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

From kpk at openjdk.org  Fri Oct 13 07:02:12 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 13 Oct 2023 07:02:12 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v9]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 12 Oct 2023 09:40:18 GMT, Karthik P K  wrote:

>> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
>> 
>> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
>> 
>> Added tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeating text node issue

Made changes in code as suggested above.

> Another observation, and it may be a different issue. If i try to insert a Text instance with -fx-scale-x:200% into the flow, the scale affects the glyph rendering but neither caretShape, preferredWidth, nor hitInfo:

This looks like a different issue. I will raise a new bug if it is not reported already.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1761005682

From aghaisas at openjdk.org  Fri Oct 13 07:21:25 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 13 Oct 2023 07:21:25 GMT
Subject: RFR: 8314906: [testbug] Create behavior tests for text input
 controls [v11]
In-Reply-To: 
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>

Message-ID: <9bfMf2zoEzTWbbwNIcyZHtNiaQyymVfbTC25Dee37Ww=.650199cb-06a7-47d1-8041-f28da0a1914b@github.com>

On Thu, 12 Oct 2023 17:08:39 GMT, Andy Goryachev  wrote:

>> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
>> 
>> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
>> 
>> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
>> 
>> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
>> 
>> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
>> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by aghaisas (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1221#pullrequestreview-1675865036

From kpk at openjdk.org  Fri Oct 13 09:28:31 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 13 Oct 2023 09:28:31 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v10]
In-Reply-To: 
References: 

Message-ID: <2XRoxLvTM-M7utBEaXBHDJSCuryQrUkYDUnlaVqBTOM=.134d8889-0022-45a5-b03f-df099801fd16@github.com>

On Fri, 13 Oct 2023 07:01:51 GMT, Karthik P K  wrote:

>> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
>> 
>> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
>> 
>> Added tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Created [JDK-8318079](https://bugs.openjdk.org/browse/JDK-8318079)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1761202644

From tsayao at openjdk.org  Fri Oct 13 12:26:51 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 13 Oct 2023 12:26:51 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v10]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 28 Sep 2023 01:05:20 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 incrementally with one additional commit since the last revision:
> 
>   Make it a default method for compatibility

Should I wait for feedback if it's working properly before doing the CSR?

I think it would be better to first stabilize it and see what need changes.

-------------

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

From angorya at openjdk.org  Fri Oct 13 14:39:20 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 13 Oct 2023 14:39:20 GMT
Subject: Integrated: 8314906: [testbug] Create behavior tests for text input
 controls
In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>
References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com>
Message-ID: 

On Wed, 23 Aug 2023 23:30:50 GMT, Andy Goryachev  wrote:

> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings.  The idea is to make writing such tests a simple process.  
> 
> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea).  Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like).
> 
> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once.
> 
> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)).
> 
> In addition, the key bindings are documented in /doc-files/behavior markdown documents:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md
> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md

This pull request has now been integrated.

Changeset: f76437da
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/f76437da86dbb6a2ad742c06f5818a2abac2d5eb
Stats:     2741 lines in 14 files changed: 2725 ins; 3 del; 13 mod

8314906: [testbug] Create behavior tests for text input controls

Reviewed-by: aghaisas, kpk

-------------

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

From angorya at openjdk.org  Fri Oct 13 15:53:09 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 13 Oct 2023 15:53:09 GMT
Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text [v3]
In-Reply-To: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
Message-ID: 

> The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
> 
> I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660
> 
> This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day).

Andy Goryachev 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8296266.navigation
 - naming changes only
 - Merge remote-tracking branch 'origin/master' into 8296266.navigation
 - added robot test
 - exposing cached break iterators
 - using break iterator

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1220/files
  - new: https://git.openjdk.org/jfx/pull/1220/files/94bba45e..36979b6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1220&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1220&range=01-02

  Stats: 3058 lines in 22 files changed: 2764 ins; 239 del; 55 mod
  Patch: https://git.openjdk.org/jfx/pull/1220.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1220/head:pull/1220

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

From angorya at openjdk.org  Fri Oct 13 16:17:09 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 13 Oct 2023 16:17:09 GMT
Subject: RFR: 8306083: Text.hitTest is incorrect when more than one Text
 node in TextFlow [v10]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 13 Oct 2023 07:01:51 GMT, Karthik P K  wrote:

>> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when hitTest was invoked for Text node in a TextFlow with more than one Text child. Hence wrong character index value was calculated.
>> 
>> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index.
>> 
>> Added tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

? looks good, thanks!

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1157#pullrequestreview-1676833750

From angorya at openjdk.org  Fri Oct 13 16:23:59 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 13 Oct 2023 16:23:59 GMT
Subject: RFR: 8314968: Public InputMap
Message-ID: 

Summary:
- public InputMap, KeyBinding, BehaviorBase in javafx.scene.control.behavior package
- InputMap allows for adding key mappings on control (user-defined) and behavior (defined by the skin) levels
- two stage mapping: key binding -> function tag -> function; enables a wide range of control customization (in some cases even without subclassing behavior classes)

For more detailed introduction, see
https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09

A number of Controls has been converted to use the new InputMap implementation:

- ColorPicker
- ComboBox
- DatePicker
- PasswordField
- TextArea
- TextField

This PR requires https://github.com/openjdk/jfx/pull/1221 to go in first.

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into 8314968.input.map
 - Merge branch '8314906.behavior.test' into 8314968.input.map
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314968.input.map
 - spelling
 - Merge branch '8314906.behavior.test' into 8314968.input.map
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test
 - whitespace
 - whitespace
 - ... and 128 more: https://git.openjdk.org/jfx/compare/f76437da...9df9b60f

Changes: https://git.openjdk.org/jfx/pull/1254/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1254&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314968
  Stats: 3165 lines in 33 files changed: 2369 ins; 358 del; 438 mod
  Patch: https://git.openjdk.org/jfx/pull/1254.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1254/head:pull/1254

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

From arapte at openjdk.org  Sat Oct 14 05:25:06 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Sat, 14 Oct 2023 05:25:06 GMT
Subject: RFR: 8318115: Webkit build fails after gradle 8.4
Message-ID: 

Few dependency were missed to be added for webkit build.
With this change webkit build completes successfully.
Please review

-------------

Commit messages:
 - webkit build fail fix

Changes: https://git.openjdk.org/jfx/pull/1261/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318115
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1261.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1261/head:pull/1261

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

From aghaisas at openjdk.org  Sat Oct 14 08:20:45 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Sat, 14 Oct 2023 08:20:45 GMT
Subject: RFR: 8318115: Webkit build fails after gradle 8.4
In-Reply-To: 
References: 
Message-ID: 

On Sat, 14 Oct 2023 05:17:44 GMT, Ambarish Rapte  wrote:

> Few dependency were missed to be added for webkit build.
> With this change webkit build completes successfully.
> Please review

Approving based on successful CI builds on all platforms.

-------------

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1261#pullrequestreview-1677901765

From arapte at openjdk.org  Sat Oct 14 08:53:45 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Sat, 14 Oct 2023 08:53:45 GMT
Subject: Integrated: 8318115: Webkit build fails after gradle 8.4
In-Reply-To: 
References: 
Message-ID: 

On Sat, 14 Oct 2023 05:17:44 GMT, Ambarish Rapte  wrote:

> Few dependency were missed to be added for webkit build.
> With this change webkit build completes successfully.
> Please review

This pull request has now been integrated.

Changeset: 6d2595a3
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/6d2595a3a3f5b0853de8ee61e99ecefc15345bf3
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8318115: Webkit build fails after gradle 8.4

Reviewed-by: aghaisas

-------------

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

From sykora at openjdk.org  Sat Oct 14 13:18:50 2023
From: sykora at openjdk.org (Joeri Sykora)
Date: Sat, 14 Oct 2023 13:18:50 GMT
Subject: RFR: 8317370: JavaFX runtime version is wrong at runtime [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 Oct 2023 16:24:42 GMT, John Neffenger  wrote:

>> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.
>
> John Neffenger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the documentation in UPDATING-VERSION.md

Tested on our build infrastructure and build and tests all worked fine.

-------------

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1253#pullrequestreview-1678081796

From jgneff at openjdk.org  Sat Oct 14 16:35:50 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Sat, 14 Oct 2023 16:35:50 GMT
Subject: Integrated: 8317370: JavaFX runtime version is wrong at runtime
In-Reply-To: 
References: 
Message-ID: <4Fepi9W7c8w6_0ymQcu5mxS2wiFLBi8ZCcZRSOkkwOA=.8fcfee1e-3564-442e-b9bf-f7baf1c7cdae@github.com>

On Mon, 2 Oct 2023 22:06:38 GMT, John Neffenger  wrote:

> Please review these changes to the build timestamp and to the JavaFX runtime version available in the system properties.

This pull request has now been integrated.

Changeset: 16169240
Author:    John Neffenger 
URL:       https://git.openjdk.org/jfx/commit/16169240667876633895b27464eb90033abb6166
Stats:     117 lines in 4 files changed: 66 ins; 39 del; 12 mod

8317370: JavaFX runtime version is wrong at runtime

Reviewed-by: kcr, sykora

-------------

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

From john.hendrikx at gmail.com  Sat Oct 14 17:19:49 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 14 Oct 2023 19:19:49 +0200
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>

 <2c39bd6a-1cb1-7943-ea9b-6807e427cccc@gmail.com>

Message-ID: <3c1f9b9d-1ed8-364d-975f-2d1f8c674c2d@gmail.com>

On 12/10/2023 21:56, Andy Goryachev wrote:
>
> Filters: are we talking about key bindings or event handlers?? With 
> the key bindings, the user mappings take precedence over those 
> registered through behavior. There is no provision for adjusting 
> priority of the event handlers ? that?s the FX reality, we don?t get 
> to rearrange event handlers within the node.? That?s why I mentioned 
> event filters added _to the control_.? I am not sure why you talk 
> about HBoxes ? adding a filter on the control enables the user to 
> intercept the event prior to skin/behavior.
>
On simple Controls yes, filters can be used there for this purpose, even 
though that's not their purpose.? It works because a Control (usually) 
is a leaf node.? It breaks down however when you want to change behavior 
of the View controls which have deeper control layers.? You may want to 
override something defined for ListView, but only if say a focused 
editable control isn't consuming that event for a different purpose.? A 
filter won't be able to do this.

> So yes, this proposal does not address the event handlers (sorry for 
> confusing key bindings with event handlers).? Unless we add 
> addListenerBefore() API, we?d need to use event filters ? but this is 
> out of scope for this proposal.
>
> I do agree with you that we should keep the concrete Behaviors private 
> for now.? In any case, public behaviors are outside of scope for this 
> proposal.
>
I see BehaviorBase moving to a public package though, and it is not 
package private, is that intended then?

> One thing you mentioned several times is a ?truly good design?.? Let?s 
> hear it!? Could you give us an outline, at the public API level at 
> least, of such a design?
>
Alright; these things take a lot of time, but I've taken a few hours to 
think about it today. First, a lot of things just triggered me with the 
current proposal;

- The mutable maps, immutability would allow making these static, saving 
many objects; when I have some time I can take a look at how many are in 
memory when a decent sized FX application is running; as even Labels are 
Controls, and Labels are the base class for any Cell, this number might 
be larger than expected and potentially could allow for some significant 
memory savings; making it public as-is closes that road down forever. 
Immutability does not mean things can't be changed, it just requires a 
slightly different mindset (ie. you combine a standard InputMap with a 
custom InputMap to form a new InputMap in which a binding is 
changed/overriden/disabled); this was also proposed on JDK-8091189

- The Control back reference; I firmly believe this is unnecessary, and 
also very undesirable.? Events already contain this reference, its 
superflous and requires a new instance for an (otherwise) similar 
instance; This is even done already in places, exactly to avoid having 
to create more instances (see #getNode in FocusTraversalInputMap for 
example, effectively allowing that class to be static while providing 
the focus traversal behavior).?? This was also raised on JDK-8091189

- Not designing this using interfaces (also raised on JDK-8091189).? 
With the addition of default methods, we should favor composable designs 
instead of being forced to inherit from a base class in order to provide 
a custom implementation.? Sure, you can still provide a default 
implementation, but public methods should be referring to the interface 
so it can be a completely different implementation.? Interfaces prevent 
using package private shortcuts where privileged classes can provide a 
functionality that users cannot.

- The public BehaviorBase and the new public behaviors for many 
controls; I'm not convinced behaviors (if we can't define exactly what 
their purpose is supposed to be vs the Control and Skin) are ready to 
become more than just an implementation detail.

As for high level design, it of course depends on what the goal here 
is.? The issues linked in the proposal all call out for a public 
behavior API, but your proposal narrows the scope rightfully down to 
influencing default reactions to (key?) events only.? Making behaviors 
public as they are now, and without a clear definition of what they are, 
seems definitely premature.? I think they first need to be re-evaluated 
to see if they are still a good design at all (after all they're 10+ 
years old), then rewritten internally (if the ideas behind them 
changed), and only then made public.

In your proposal I think the Summary and Motivation are quite good at 
outlining a problem to be solved.? I'd like to rephrase that as a goal: 
"To allow developers to remap, override or disable the standard behavior 
of JavaFX controls (note: behavior here is used in the general sense)".? 
I think there is no need to mention InputMap, Behaviors or key bindings 
here, those are merely possible means to achieve the goal.

I'd then first take a look how this could be achieved with current 
JavaFX, and where users are running into a wall.

Most obviously, the way to make controls do something you want is by 
using event handlers.? Even Behaviors use these internally, in which 
we'll later see lies a bit of the problem.

# Expectations

Just like when a developer sets a Control property directly to a 
specific value, when the developers adds an event handler or listener, 
he/she can rightfully expect that FX respects this and does not get in 
the way.? For the property case, CSS will not override such a property, 
for listeners, all listeners receive any callbacks, and for events, the 
user registered handlers should take priority over internal handlers 
(unlike listeners, event handlers can consume and act upon events before 
they reach the user handler, hence order plays an important role here).

CSS, Skins and Behaviors sharing the same properties, listeners and 
event handlers with application developers has always been a bit of a 
balancing act; CSS has an elaborate system to respect user property 
changes, and keeps track of these; Skins for the most part manage to 
stay out of the application developer's way, mostly because they 
primarily use listeners which inherently don't block listeners added by 
the application developer.? They also rarely override properties 
outright that are also modifiable by the developer.

With Behaviors the situation is very different.? Event handlers added by 
behaviors will consume events, effectively acting upon them before the 
application developer can (you may still see such events as "consumed", 
but they will not bubble up further). On top of that is the fact that 
EventHandlers are far more complicated than plain listeners or 
properties.? For example, a KeyEvent.KEY_PRESSED handler is called 
before a KeyEvent.KEY_ANY handler; attempting to override behavior in a 
KeyEvent.KEY_ANY handler is therefore impossible when the behavior to 
override is using a more specific event type.? Consumption of an event 
only blocks capturing/bubbling of the event; other event handlers at the 
same level do still see such events, but they're marked "consumed"; most 
event handlers should therefore probably start with a `if 
(e.isConsumed()) return` line, but often don't (users often don't do 
this because they expect their handlers to be the only ones present, or 
to be called first, even though for Controls with Behaviors this is not 
actually true).

# Problems

Some of the problems you can expect to see when you want to act upon an 
event that has a "default" behavior (versus ones that don't):

- Adding a more generic event handler than the one used internally will 
result in the events you are interested in being consumed already
- Adding the exact same event handler as one used internally AFTER the 
control was shown (or re-adding it in response to something) will result 
in events you are interested in being consumed already, or more 
generally, an event handler works differently whether they were added 
before or after the control was shown...
- Events for which there exist a default behavior are in some cases 
consumed even if the behavior could not be performed (navigation)

In all the above cases, for events WITHOUT default behavior, such a user 
installed handler works exactly as expected. IMHO there really should be 
no difference for the user whether there is a default behavior or not.

# Causes

Almost all of these problems are caused by the fact that JavaFX's 
internal handlers share the same lists/mechanisms as application 
developers to react to events; these internal handlers are mixed up with 
event handlers from application developers; often the internal ones run 
first, but it is very unpredictable:

- Is your event handler more generic than an internal handler? You 
always run last
- Is your event handler more specific than an internal handler? You 
always run first
- Is your event handler the exact same event type as an internal 
handler... then:
 ?? - Did you add handlers before the control was shown / skin was 
created? Yours run first (subject to change no doubt, we don't guarantee 
this)
 ?? - Did you add handlers after the control was shown? Yours run last 
(no guarantees)
 ?? - Did you add handlers after the control was shown, but then its 
skin was replaced?? Your event handlers that used to run last now run 
first... (undocumented)

An innocent change like listening for KeyEvent.ANY vs 
KeyEvent.KEY_PRESSED can have big repercussions.

# How to reach the goal?

There are many ways to reach the above stated goal.? Opening up some 
internal structures that are used by the internal event handlers is one 
way, but it effectively creates a 2nd mechanism to do the same thing.? I 
can change the internal event handler's internal structures to do X, or 
I can create an event handler that does X.? For some of these, both 
options work, and for others, only this new mechanism works.?? Not only 
is this mostly compensating for a flaw in the event handling system, but 
it also means that you need to be aware of which events need special 
treatment. It's even possible that some events require no special 
treatment now, but may in the future, or may need it if the platform 
changes certain defaults. In other words, this new mechanism would 
effectively need to be used in all cases or you risk your solution 
(using standard event handlers) breaking in the future (or JavaFX would 
have to freeze input maps and never change them again -- that's already 
sort of the case, but it is good to be aware of that).

# Alternative solution

I would look into seeing if the flaws in the event handling system can 
be resolved, so that this mechanism that is already available, and that 
users already know becomes powerful enough to cater to the stated goal.? 
Note that this doesn't preclude opening up behaviors later, but it does 
take away one of the fundamental reasons to do so, perhaps allowing for 
quite a different way of exposing these to users as the primary driver 
need no longer be focused on remapping bindings.? Perhaps the primary 
driver can then be how to design behaviors in such a way that they can 
be re-used and easily subclassed; perhaps behaviors are no longer needed 
at all, and they can remain an internal implementation detail, or 
perhaps they can be part of skins or controls.

I see a few problems that should be addressed if we want to be able to 
reach the goal with better event handlers:

1) Internal event handlers should NOT use the same mechanism as user 
event handlers; effectively, user event handlers (of any event type, 
even more general ones) run first, as if no internal event handlers 
existed at all.? This is already the case depending on the timing of 
when the user added the handlers; the timing is unpredictable (as stated 
above) and so I think we have enough leeway to change this, and enough 
reason to tighten up the specification here.

2) All internal event handlers run AFTER user ones (per EventTarget), 
regardless of when they were added. A separate list can be used, or the 
event type system could support this with some kind of internal flag.

3) Internal event handlers can be skipped completely if the user marks 
an event as such.? This is different from consuming the event; 
effectively, the event is not consumed (and can bubble up to other event 
targets) but internal event handlers are not allowed to act upon it.

4) All actions triggered by behaviors should be available as public 
methods (nested or direct) on their respective controls, allowing the 
user to call these as well.

The above changes should be enough to support the stated goal: "To allow 
developers to remap, override or disable the standard behavior of JavaFX 
controls (note: behavior here is used in the general sense)"

To override a standard behavior: install event handler (which will run 
first), react to an event, call a public method triggering the DIFFERENT 
behavior, consume the event
To disable a standard behavior: install event handler, react to an 
event, mark it as "not for internal use", effectively disallowing the 
internal handlers from acting on it
To remap a standard behavior: combine the above two solutions

# New API needed

A flag on `Event` that can be set/cleared whenever the user wants.? The 
flag effectively communicates that the given event is not to be 
processed by the "hidden" internal event handlers added by JavaFX.? It 
could be called "noDefault" or "skipDefaultBehavior".

Depending on the internal changes needed to separate user event handlers 
from internal ones, EventType may also need a small change.? For 
example, if the separation is implemented by introducing more event 
types, a convenient `EventType#toInternal` method could be added to 
convert a regular event type to an internal one that is always processed 
after standard ones.? It's possible such a method does not need to be 
public (but could be if users desire the old unpredictable behavior of 
mixing user and internal event handlers).

# Alternative alternative solution

Part of the problem can also be solved by disallowing internal handlers 
to listen on the most specific EventType (ie, don't listen to 
KeyEvent.KEY_PRESSED, but instead listen to KeyEvent.ANY).? This way a 
user can be the first to handle the event in all cases by using a more 
specific type (KeyEvent.KEY_PRESSED) or the last in all cases by using a 
less specific type (InputEvent.ANY).? This leaves much to be desired, 
and doesn't solve all of the above outlined problems, but I mention it 
to show that there is quite a lot possible here already by tweaking the 
event handling system.

--John

> Thank you
>
> -andy
>
> *From: *John Hendrikx 
> *Date: *Thursday, October 12, 2023 at 01:33
> *To: *Andy Goryachev , 
> openjfx-dev at openjdk.org 
> *Subject: *[External] : Re: [Request for Comments] Behavior / InputMap
>
> On 11/10/2023 19:44, Andy Goryachev wrote:
>
>     Dear John:
>
>     Seems like addEventFilter() was specifically designed to intercept
>     events before any other handlers, so I see no problem there.
>
> This is a misunderstanding of what filters are for. They're called in 
> the capturing phase and they can prevent an event from reaching its 
> intended target, but you want it to reach the intended target FIRST, 
> as you still want to give the target the chance to be the first to act 
> upon the event.? For example, let's say I want to attach a function to 
> the SPACE key in some specialized HBox, it should only do something 
> when something closer to the target doesn't need it first (like a 
> nested HBox of the same type, or an active TextField that uses SPACE 
> for input).? Now if HBox had some FX default event handler that 
> consumed SPACE, I have no options to override SPACE anymore; the 
> filter is not a good spot, as its too early, and the handler is not a 
> good spot because Behavior handlers were added before mine was.
>
>
>
>     I somewhat disagree about the purpose of the key mapping system ?
>     the proposed solution solves two existing issues (the
>     skin/behavior mappings and the user mappings) in one neat package.
>     Every other instrument such as addEventHandler/Filter is still there.
>
> I'm saying that the need for this would be almost non-existent if user 
> event handlers weren't considered less important than FX ones. You 
> have to be careful that there aren't two ways of doing things here:
>
> If the event you wish to give an alternative purpose to is unused by 
> FX, you can use an event handler; otherwise you must disable it (so 
> you can use an event handler!) or remap it (using an alternative 
> system).? Note that if FX at some point decides to "claim" another 
> mapping, that would be a breaking change as some user event handlers 
> may cease to function.
>
> This is why I think the input mapping system should stay hidden; its 
> an implementation detail of the Event handlers added by FX so they 
> don't need to write long if/else/switch chains, and so they can more 
> easily switch out mappings depending on state.? Opening up the input 
> map effectively is being able to influence those FX added event 
> handlers to do something different, while there is a perfectly good 
> way of doing that already: add your own event handler (with higher 
> priority).
>
>     And, if we look at the three bullet points
>
>     - Ensure user event handlers have priority over behavior/inputmap
>     added ones
>     - Ensure all behavior actions are available as methods on controls
>     - Ensure that if a key is handled by the control, that it is ONLY
>     consumed when it actually triggers an action (navigation keys get
>     consumed regardless, even if no focus change results, that's wrong).
>
>     I absolutely agree, and in fact the first three are indeed a part
>     of the proposal.? Well, the 3^rd one might unfortunately be a
>     subject of backward compatibility limitation since one of the
>     requirements was no behavior change w.r.t. the earlier versions.?
>     We can always change the behavior if we have a completing reason
>     and go through the usual process, nothing in the proposal
>     precludes that.
>
> I don't see how your proposal addresses the first point.
>
> I've been reading the comments attached to 
> https://bugs.openjdk.org/browse/JDK-8091189 and it has a lot of good 
> information, and raises many good points (immutable input maps, keep 
> input maps/behaviors as implementation details, use interfaces instead 
> of base classes, what about controls that have no Skin, even the point 
> I made about having the Control be in charge of registering the event 
> handlers instead of letting InputMap do it requiring a Control 
> field...).? There are several patches by Jonathan Giles, and there is 
> even a library created by the author of ReactFX that allows for 
> replacing key bindings with a much nicer API already (in so far that 
> is possible without having inside FX support).
>
> The general tone of the comments seems to be that Behaviors should be 
> kept as implementation details -- they're not well defined (what is a 
> Behavior, what should be in the Behavior, what should be in the Skin 
> and what should be in the Control) and until that is absolutely clear, 
> exposing any of that as API is premature.
>
>     Making the behaviors completely independent with setBehavior() and
>     FXML, as you said, might be a future effort, perhaps we could
>     attempt opening up certain controls at some point.? On one hand, I
>     am for increasing the extensibility of FX, on the other hand the
>     same argument can be made against it (as in solidifying a
>     particular way of constructing skins and behaviors), but I feel
>     it?s a separate issue that is independent of this proposal.
>
> I'm starting to lean towards keeping all of this as implementation 
> details, at least until the current implementation is much cleaner 
> than it is currently (the way InputMap and Behaviors currently are set 
> up is more pragmatic than truly a good design), and just address the 
> main issue: JavaFX stealing events that users want to override, note 
> that I say events, key bindings are only part of it.
>
> --John
>
>     -andy
>
>     *From: *openjfx-dev 
>      on behalf of John Hendrikx
>      
>     *Date: *Wednesday, October 11, 2023 at 01:04
>     *To: *openjfx-dev at openjdk.org 
>     
>     *Subject: *Re: [Request for Comments] Behavior / InputMap
>
>     I'm sorry, but that providing an arbitrary key mapping system
>     seems completely out of scope and not something that JavaFX should
>     concern itself with. It's much too high level, when the key
>     mappings involved should only be for actions that the control can
>     provide on its own.
>
>     I think the problem we should be solving is that JavaFX control
>     behaviors shouldn't be first in line when it comes to consuming
>     events (which currently is only the case due to event handlers
>     being added at the earliest possible opportunity, and event
>     handlers being called in order).? If something as trivial as:
>
>     control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
>     ????????????? if (e.getCode() == KeyCode.LEFT) {
>     ??????????????????? e.consume();? // stop default behavior
>     ????????????? }
>     ?????? });
>
>     ... actually worked, then there is much less need to
>     redefine/disable behavior key mappings, and no need for a
>     secondary system that deals with mappings (the first system, event
>     handlers, can simply be used for this).? If user event handlers
>     had priority over behavior ones, then everything you want can be
>     achieved with the above, including:
>
>     - Stopping default behavior
>     - Triggering different behavior (just call something on control,
>     of course, make sure all behavior actions are available on the
>     control in the first place)
>     - Remapping (a combination of the above two)
>     - Adding an alternative key for the same behavior
>
>     A system to remap keys can then be left squarely in the realm of
>     user space, and much nicer solutions can be build by users than
>     whatever JavaFX will provide out of the box.
>
>     Changes to the Behavior system can then focus on replacing
>     complete behaviors (including their input map) and being able to
>     use these by default for a certain subset of controls (like
>     -fx-skin provide in CSS), as this is something users currently
>     can't do.
>
>     So in short, what I think this should be about is:
>
>     - Ensure user event handlers have priority over behavior/inputmap
>     added ones
>     - Ensure all behavior actions are available as methods on controls
>     - Ensure that if a key is handled by the control, that it is ONLY
>     consumed when it actually triggers an action (navigation keys get
>     consumed regardless, even if no focus change results, that's wrong).
>
>     Future:
>
>     - Make behaviors public and allow Behaviors to be replaced with
>     -fx-behavior type CSS syntax / control.setBehavior calls
>
>     --John
>
>     The focus should be on being able to modify standard behavior of
>     controls (arrow-left, enter, ctrl-shift-right, etc.), specifically
>     also to be able to disable these when undesired, and, on top of
>     that, that they bubble up when NOT used even when they are
>     configured (focus navigation keys currently are always consumed,
>     whether they actually do something or not -- that's a big issue).?
>     The other focus should be on providing an alternative behavior (or
>     at least mappings) for all controls of a certain type -- I don't
>     see the need for adding a mapping to a specific control, that's
>     already covered with event handlers; the problem is mostly that
>     behaviors currently steal certain events before the user can get
>     at them.
>
>     Custom behaviors can then be constructed that provide more things
>     that may need mapping.? I'd expect those however to be limited in
>     scope to what the control offers, certainly not an arbitrary
>     key/action mapping system (that wouldn't even work, as most of
>     these would be in the scope of several controls or be global).?
>     This kind of functionality is much better provided by event
>     handlers at the correct level for a group of controls, and I
>     wouldn't expect to find such an eloborate system incorporated in
>     behaviors.
>
>     In fact, thinking about all of this a bit more,
>
>     On 10/10/2023 19:54, Andy Goryachev wrote:
>
>         Re-sending with a smaller image (256kb limit, really?).
>
>         *From: *Andy Goryachev 
>         
>         *Date: *Tuesday, October 10, 2023 at 10:49
>         *To: *Michael Strau? 
>         
>         *Cc: *openjfx-dev at openjdk.org 
>         
>         *Subject: *Re: [Request for Comments] Behavior / InputMap
>
>         Dear Michael:
>
>         Here is a use case for (re-)mapping by the user at runtime:
>
>         (key mappings UI in Eclipse).
>
>         I can think of several other cases (mentioned in the proposal,
>         I think) so I think we can put the concept of immutable or
>         global InputMap to rest.
>
>         Whether the InputMap contains the reference to its control or
>         not is a minor implementation detail, I think.
>
>         -andy
>
>         *From: *openjfx-dev 
>          on behalf of Michael
>         Strau?  
>         *Date: *Tuesday, October 10, 2023 at 10:36
>         *To: *
>         *Cc: *openjfx-dev at openjdk.org 
>         
>         *Subject: *Re: [Request for Comments] Behavior / InputMap
>
>         > Yes, one of the features the new design provides is ability to modify
>         key mappings by the user at runtime.? So yes, not only it
>         needs to be mutable, but it also adds some APIs for exactly that.
>         >
>
>         I struggle to see a use case for this feature. I can imagine that
>         there might be some use cases that call for customized input
>         mappings,
>         but why would this translate to a _mutable_ input map? That's
>         quite a
>         departure from the way other parts of JavaFX work.
>
>         For example, skins are also immutable. If you want to have a
>         different
>         skin for a control, you don't somehow modify the existing skin
>         instance; instead, you'd create a new skin class (or -- somehow --
>         extend an existing skin class), and then install that new skin
>         on your
>         control.
>
>         An input map shouldn't bind input events directly to instance
>         methods
>         of a particular control instance. It should define the mapping of
>         events to methods symbolically:
>
>         Instead of mapping Event => instance.method(), it should map
>         Event =>
>         Control::method. The input map could then be stateless and
>         immutable,
>         and can be set on any control instance. If you want to change the
>         mappings, just set a different input map instance. There's no need
>         that an input map would retain a reference to any particular
>         control,
>         since the control reference can be passed into the input map
>         just as
>         easily.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: not available
URL: 

From thiago.sayao at gmail.com  Sat Oct 14 17:44:23 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 14 Oct 2023 14:44:23 -0300
Subject: How to request javafx pixels rather than receiving it?
Message-ID: 

Hi,
I'm doing some experimenting on new ways to implement the gtk glass backend
(mainly targeting wayland support).

JavaFX View implementations receives the data to be drawn.
I want to be able to request it synchronously.

If JavaFX needs to paint I need it to request the glass backend without the
data.
So the backend would request back the data to be drawn when it's ready.

I could keep a buffer on GtkView.java. Would it be too ugly?

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tsayao at openjdk.org  Sat Oct 14 18:32:48 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 14 Oct 2023 18:32:48 GMT
Subject: RFR: 8316423: [linux] Secondary Stage does not respect Scene's
 dimensions when shown [v2]
In-Reply-To: 
References: 

Message-ID: 

On Sat, 30 Sep 2023 23:30:53 GMT, Thiago Milczarek Sayao  wrote:

>> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
>> 
>> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
>> 
>> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
>> 
>> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Re-enable tests
>  - Fix fullscreen position

I strongly suspect of what is happening:

`WindowContextTop` constructor calls `glass_gtk_configure_transparency_and_realize` which calls `gtk_widget_realize`.

This is probably creating the underlying gdk window before gtk expects and is messing things up.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1249#issuecomment-1763116193

From tsayao at openjdk.org  Sat Oct 14 18:39:36 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 14 Oct 2023 18:39:36 GMT
Subject: RFR: Draft: 8316423: [linux] Secondary Stage does not respect
 Scene's dimensions when shown [v3]
In-Reply-To: 
References: 
Message-ID: 

> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
> 
> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
> 
> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
> 
> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Experiment on not realizing the window

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1249/files
  - new: https://git.openjdk.org/jfx/pull/1249/files/c5b631d5..d5ef6de1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=01-02

  Stats: 75 lines in 5 files changed: 31 ins; 35 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1249.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1249/head:pull/1249

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

From tsayao at openjdk.org  Sat Oct 14 18:45:30 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 14 Oct 2023 18:45:30 GMT
Subject: RFR: Draft: 8316423: [linux] Secondary Stage does not respect
 Scene's dimensions when shown [v4]
In-Reply-To: 
References: 
Message-ID: 

> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
> 
> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
> 
> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
> 
> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Experiment on not realizing the window

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1249/files
  - new: https://git.openjdk.org/jfx/pull/1249/files/d5ef6de1..59fcf234

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=02-03

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

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

From martin at martinfox.com  Sat Oct 14 21:48:09 2023
From: martin at martinfox.com (Martin Fox)
Date: Sat, 14 Oct 2023 14:48:09 -0700
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
In-Reply-To: <3c1f9b9d-1ed8-364d-975f-2d1f8c674c2d@gmail.com>
References: 
 <6a1adf84-f196-d951-4278-8aa2cd17322d@gmail.com>

 <11da1132-d25c-39d1-8e6c-2e2230d954ea@gmail.com>

 <2c39bd6a-1cb1-7943-ea9b-6807e427cccc@gmail.com>

 <3c1f9b9d-1ed8-364d-975f-2d1f8c674c2d@gmail.com>
Message-ID: 

I?ve been digging around in the code to get some context on the existing machinery for ordering event handler execution. I haven?t had time to write up test cases so all of this is based on reading the spec and the code.

The current problem is that all handlers for a given Node are thrown into the same bucket and that bucket isn't delivering the execution order clients expect. Within the existing framework the minimal solution would be to (a) segregate handlers into separate buckets and (b) control the order in which the buckets are processed.

The second problem is solved. The order of execution is controlled by the EventDispatchChain and there are public API?s for manipulating it. Note that it?s possible for one Node to have multiple dispatchers in the chain and anyone can take a fully constructed Node and add an EventDispatcher to it (if you?re subclassing a node you would override buildEventDispatchChain).

Internally the first problem also has a solution. EventDispatchers which manage event handlers and filters are called EventHandlerManagers (the bucket I referred to earlier is the Node?s event handler manager). Again, a Node can have multiple dispatchers and any of them could be an EventHandlerManager. For example, the Control class could have an internal EventHandlerManager with its own collection of handlers and filters that is entirely separate from the Node?s. It would be up to the class to determine whether its manager executed before or after the Node?s.

(In the public API anyone can implement an EventDispatcher but if they want to support the existing calls for managing event handlers and filters they are on their own. Personally I think we should provide an EventHandlerManager for public use.)

Martin

> On Oct 14, 2023, at 10:19 AM, John Hendrikx  wrote:
> 
> On 12/10/2023 21:56, Andy Goryachev wrote:
>> Filters: are we talking about key bindings or event handlers?  With the key bindings, the user mappings take precedence over those registered through behavior.  There is no provision for adjusting priority of the event handlers ? that?s the FX reality, we don?t get to rearrange event handlers within the node.  That?s why I mentioned event filters added to the control.  I am not sure why you talk about HBoxes ? adding a filter on the control enables the user to intercept the event prior to skin/behavior.
> On simple Controls yes, filters can be used there for this purpose, even though that's not their purpose.  It works because a Control (usually) is a leaf node.  It breaks down however when you want to change behavior of the View controls which have deeper control layers.  You may want to override something defined for ListView, but only if say a focused editable control isn't consuming that event for a different purpose.  A filter won't be able to do this.
> 
>>  
>> So yes, this proposal does not address the event handlers (sorry for confusing key bindings with event handlers).  Unless we add addListenerBefore() API, we?d need to use event filters ? but this is out of scope for this proposal.
>>  
>> I do agree with you that we should keep the concrete Behaviors private for now.  In any case, public behaviors are outside of scope for this proposal.
> I see BehaviorBase moving to a public package though, and it is not package private, is that intended then?
> 
>>  
>> One thing you mentioned several times is a ?truly good design?.  Let?s hear it!  Could you give us an outline, at the public API level at least, of such a design?
>> 
> Alright; these things take a lot of time, but I've taken a few hours to think about it today. First, a lot of things just triggered me with the current proposal;
> 
> - The mutable maps, immutability would allow making these static, saving many objects; when I have some time I can take a look at how many are in memory when a decent sized FX application is running; as even Labels are Controls, and Labels are the base class for any Cell, this number might be larger than expected and potentially could allow for some significant memory savings; making it public as-is closes that road down forever.  Immutability does not mean things can't be changed, it just requires a slightly different mindset (ie. you combine a standard InputMap with a custom InputMap to form a new InputMap in which a binding is changed/overriden/disabled); this was also proposed on JDK-8091189
> 
> - The Control back reference; I firmly believe this is unnecessary, and also very undesirable.  Events already contain this reference, its superflous and requires a new instance for an (otherwise) similar instance; This is even done already in places, exactly to avoid having to create more instances (see #getNode in FocusTraversalInputMap for example, effectively allowing that class to be static while providing the focus traversal behavior).   This was also raised on JDK-8091189
> 
> - Not designing this using interfaces (also raised on JDK-8091189).  With the addition of default methods, we should favor composable designs instead of being forced to inherit from a base class in order to provide a custom implementation.  Sure, you can still provide a default implementation, but public methods should be referring to the interface so it can be a completely different implementation.  Interfaces prevent using package private shortcuts where privileged classes can provide a functionality that users cannot.
> 
> - The public BehaviorBase and the new public behaviors for many controls; I'm not convinced behaviors (if we can't define exactly what their purpose is supposed to be vs the Control and Skin) are ready to become more than just an implementation detail.
> 
> As for high level design, it of course depends on what the goal here is.  The issues linked in the proposal all call out for a public behavior API, but your proposal narrows the scope rightfully down to influencing default reactions to (key?) events only.  Making behaviors public as they are now, and without a clear definition of what they are, seems definitely premature.  I think they first need to be re-evaluated to see if they are still a good design at all (after all they're 10+ years old), then rewritten internally (if the ideas behind them changed), and only then made public.
> 
> In your proposal I think the Summary and Motivation are quite good at outlining a problem to be solved.  I'd like to rephrase that as a goal: "To allow developers to remap, override or disable the standard behavior of JavaFX controls (note: behavior here is used in the general sense)".  I think there is no need to mention InputMap, Behaviors or key bindings here, those are merely possible means to achieve the goal.
> 
> I'd then first take a look how this could be achieved with current JavaFX, and where users are running into a wall.
> 
> Most obviously, the way to make controls do something you want is by using event handlers.  Even Behaviors use these internally, in which we'll later see lies a bit of the problem.
> 
> # Expectations
> 
> Just like when a developer sets a Control property directly to a specific value, when the developers adds an event handler or listener, he/she can rightfully expect that FX respects this and does not get in the way.  For the property case, CSS will not override such a property, for listeners, all listeners receive any callbacks, and for events, the user registered handlers should take priority over internal handlers (unlike listeners, event handlers can consume and act upon events before they reach the user handler, hence order plays an important role here).
> 
> CSS, Skins and Behaviors sharing the same properties, listeners and event handlers with application developers has always been a bit of a balancing act; CSS has an elaborate system to respect user property changes, and keeps track of these; Skins for the most part manage to stay out of the application developer's way, mostly because they primarily use listeners which inherently don't block listeners added by the application developer.  They also rarely override properties outright that are also modifiable by the developer.
> 
> With Behaviors the situation is very different.  Event handlers added by behaviors will consume events, effectively acting upon them before the application developer can (you may still see such events as "consumed", but they will not bubble up further). On top of that is the fact that EventHandlers are far more complicated than plain listeners or properties.  For example, a KeyEvent.KEY_PRESSED handler is called before a KeyEvent.KEY_ANY handler; attempting to override behavior in a KeyEvent.KEY_ANY handler is therefore impossible when the behavior to override is using a more specific event type.  Consumption of an event only blocks capturing/bubbling of the event; other event handlers at the same level do still see such events, but they're marked "consumed"; most event handlers should therefore probably start with a `if (e.isConsumed()) return` line, but often don't (users often don't do this because they expect their handlers to be the only ones present, or to be called first, even though for Controls with Behaviors this is not actually true).
> 
> # Problems
> 
> Some of the problems you can expect to see when you want to act upon an event that has a "default" behavior (versus ones that don't):
> 
> - Adding a more generic event handler than the one used internally will result in the events you are interested in being consumed already
> - Adding the exact same event handler as one used internally AFTER the control was shown (or re-adding it in response to something) will result in events you are interested in being consumed already, or more generally, an event handler works differently whether they were added before or after the control was shown...
> - Events for which there exist a default behavior are in some cases consumed even if the behavior could not be performed (navigation)
> 
> In all the above cases, for events WITHOUT default behavior, such a user installed handler works exactly as expected. IMHO there really should be no difference for the user whether there is a default behavior or not.
> 
> # Causes
> 
> Almost all of these problems are caused by the fact that JavaFX's internal handlers share the same lists/mechanisms as application developers to react to events; these internal handlers are mixed up with event handlers from application developers; often the internal ones run first, but it is very unpredictable:
> 
> - Is your event handler more generic than an internal handler?  You always run last
> - Is your event handler more specific than an internal handler?  You always run first
> - Is your event handler the exact same event type as an internal handler... then:
>    - Did you add handlers before the control was shown / skin was created? Yours run first (subject to change no doubt, we don't guarantee this)
>    - Did you add handlers after the control was shown? Yours run last (no guarantees)
>    - Did you add handlers after the control was shown, but then its skin was replaced?  Your event handlers that used to run last now run first... (undocumented)
> 
> An innocent change like listening for KeyEvent.ANY vs KeyEvent.KEY_PRESSED can have big repercussions.
> 
> # How to reach the goal?
> 
> There are many ways to reach the above stated goal.  Opening up some internal structures that are used by the internal event handlers is one way, but it effectively creates a 2nd mechanism to do the same thing.  I can change the internal event handler's internal structures to do X, or I can create an event handler that does X.  For some of these, both options work, and for others, only this new mechanism works.   Not only is this mostly compensating for a flaw in the event handling system, but it also means that you need to be aware of which events need special treatment. It's even possible that some events require no special treatment now, but may in the future, or may need it if the platform changes certain defaults. In other words, this new mechanism would effectively need to be used in all cases or you risk your solution (using standard event handlers) breaking in the future (or JavaFX would have to freeze input maps and never change them again -- that's already sort of the case, but it is good to be aware of that).
> 
> # Alternative solution
> 
> I would look into seeing if the flaws in the event handling system can be resolved, so that this mechanism that is already available, and that users already know becomes powerful enough to cater to the stated goal.  Note that this doesn't preclude opening up behaviors later, but it does take away one of the fundamental reasons to do so, perhaps allowing for quite a different way of exposing these to users as the primary driver need no longer be focused on remapping bindings.  Perhaps the primary driver can then be how to design behaviors in such a way that they can be re-used and easily subclassed; perhaps behaviors are no longer needed at all, and they can remain an internal implementation detail, or perhaps they can be part of skins or controls.
> 
> I see a few problems that should be addressed if we want to be able to reach the goal with better event handlers:
> 
> 1) Internal event handlers should NOT use the same mechanism as user event handlers; effectively, user event handlers (of any event type, even more general ones) run first, as if no internal event handlers existed at all.  This is already the case depending on the timing of when the user added the handlers; the timing is unpredictable (as stated above) and so I think we have enough leeway to change this, and enough reason to tighten up the specification here.
> 
> 2) All internal event handlers run AFTER user ones (per EventTarget), regardless of when they were added. A separate list can be used, or the event type system could support this with some kind of internal flag.
> 
> 3) Internal event handlers can be skipped completely if the user marks an event as such.  This is different from consuming the event; effectively, the event is not consumed (and can bubble up to other event targets) but internal event handlers are not allowed to act upon it.
> 
> 4) All actions triggered by behaviors should be available as public methods (nested or direct) on their respective controls, allowing the user to call these as well.
> 
> The above changes should be enough to support the stated goal: "To allow developers to remap, override or disable the standard behavior of JavaFX controls (note: behavior here is used in the general sense)"
> 
> To override a standard behavior: install event handler (which will run first), react to an event, call a public method triggering the DIFFERENT behavior, consume the event
> To disable a standard behavior: install event handler, react to an event, mark it as "not for internal use", effectively disallowing the internal handlers from acting on it
> To remap a standard behavior: combine the above two solutions
> 
> # New API needed
> 
> A flag on `Event` that can be set/cleared whenever the user wants.  The flag effectively communicates that the given event is not to be processed by the "hidden" internal event handlers added by JavaFX.  It could be called "noDefault" or "skipDefaultBehavior".
> 
> Depending on the internal changes needed to separate user event handlers from internal ones, EventType may also need a small change.  For example, if the separation is implemented by introducing more event types, a convenient `EventType#toInternal` method could be added to convert a regular event type to an internal one that is always processed after standard ones.  It's possible such a method does not need to be public (but could be if users desire the old unpredictable behavior of mixing user and internal event handlers).
> 
> # Alternative alternative solution
> 
> Part of the problem can also be solved by disallowing internal handlers to listen on the most specific EventType (ie, don't listen to KeyEvent.KEY_PRESSED, but instead listen to KeyEvent.ANY).  This way a user can be the first to handle the event in all cases by using a more specific type (KeyEvent.KEY_PRESSED) or the last in all cases by using a less specific type (InputEvent.ANY).  This leaves much to be desired, and doesn't solve all of the above outlined problems, but I mention it to show that there is quite a lot possible here already by tweaking the event handling system.
> 
> --John
> 
> 
> 
>>  
>> Thank you
>> -andy
>>  
>>  
>>  
>> From: John Hendrikx  
>> Date: Thursday, October 12, 2023 at 01:33
>> To: Andy Goryachev  , openjfx-dev at openjdk.org   
>> Subject: [External] : Re: [Request for Comments] Behavior / InputMap
>> 
>>  
>> 
>> On 11/10/2023 19:44, Andy Goryachev wrote:
>> Dear John:
>>  
>> Seems like addEventFilter() was specifically designed to intercept events before any other handlers, so I see no problem there.
>> This is a misunderstanding of what filters are for.  They're called in the capturing phase and they can prevent an event from reaching its intended target, but you want it to reach the intended target FIRST, as you still want to give the target the chance to be the first to act upon the event.  For example, let's say I want to attach a function to the SPACE key in some specialized HBox, it should only do something when something closer to the target doesn't need it first (like a nested HBox of the same type, or an active TextField that uses SPACE for input).  Now if HBox had some FX default event handler that consumed SPACE, I have no options to override SPACE anymore; the filter is not a good spot, as its too early, and the handler is not a good spot because Behavior handlers were added before mine was.
>> 
>> 
>> 
>>  
>> I somewhat disagree about the purpose of the key mapping system ? the proposed solution solves two existing issues (the skin/behavior mappings and the user mappings) in one neat package.  Every other instrument such as addEventHandler/Filter is still there.
>> I'm saying that the need for this would be almost non-existent if user event handlers weren't considered less important than FX ones. You have to be careful that there aren't two ways of doing things here:
>> 
>> If the event you wish to give an alternative purpose to is unused by FX, you can use an event handler; otherwise you must disable it (so you can use an event handler!) or remap it (using an alternative system).  Note that if FX at some point decides to "claim" another mapping, that would be a breaking change as some user event handlers may cease to function.
>> 
>> This is why I think the input mapping system should stay hidden; its an implementation detail of the Event handlers added by FX so they don't need to write long if/else/switch chains, and so they can more easily switch out mappings depending on state.  Opening up the input map effectively is being able to influence those FX added event handlers to do something different, while there is a perfectly good way of doing that already: add your own event handler (with higher priority).
>> 
>>  
>> And, if we look at the three bullet points
>>  
>> - Ensure user event handlers have priority over behavior/inputmap added ones
>> - Ensure all behavior actions are available as methods on controls
>> - Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).
>> 
>> I absolutely agree, and in fact the first three are indeed a part of the proposal.  Well, the 3rd one might unfortunately be a subject of backward compatibility limitation since one of the requirements was no behavior change w.r.t. the earlier versions.  We can always change the behavior if we have a completing reason and go through the usual process, nothing in the proposal precludes that.
>> I don't see how your proposal addresses the first point. 
>> 
>> I've been reading the comments attached to https://bugs.openjdk.org/browse/JDK-8091189 and it has a lot of good information, and raises many good points (immutable input maps, keep input maps/behaviors as implementation details, use interfaces instead of base classes, what about controls that have no Skin, even the point I made about having the Control be in charge of registering the event handlers instead of letting InputMap do it requiring a Control field...).  There are several patches by Jonathan Giles, and there is even a library created by the author of ReactFX that allows for replacing key bindings with a much nicer API already (in so far that is possible without having inside FX support). 
>> 
>> The general tone of the comments seems to be that Behaviors should be kept as implementation details -- they're not well defined (what is a Behavior, what should be in the Behavior, what should be in the Skin and what should be in the Control) and until that is absolutely clear, exposing any of that as API is premature.  
>> 
>>  
>> Making the behaviors completely independent with setBehavior() and FXML, as you said, might be a future effort, perhaps we could attempt opening up certain controls at some point.  On one hand, I am for increasing the extensibility of FX, on the other hand the same argument can be made against it (as in solidifying a particular way of constructing skins and behaviors), but I feel it?s a separate issue that is independent of this proposal.
>> I'm starting to lean towards keeping all of this as implementation details, at least until the current implementation is much cleaner than it is currently (the way InputMap and Behaviors currently are set up is more pragmatic than truly a good design), and just address the main issue: JavaFX stealing events that users want to override, note that I say events, key bindings are only part of it.
>> 
>> --John
>> 
>>  
>>  
>> -andy
>>  
>>  
>>  
>> From: openjfx-dev   on behalf of John Hendrikx  
>> Date: Wednesday, October 11, 2023 at 01:04
>> To: openjfx-dev at openjdk.org   
>> Subject: Re: [Request for Comments] Behavior / InputMap
>> 
>> I'm sorry, but that providing an arbitrary key mapping system seems completely out of scope and not something that JavaFX should concern itself with.  It's much too high level, when the key mappings involved should only be for actions that the control can provide on its own.
>> 
>> I think the problem we should be solving is that JavaFX control behaviors shouldn't be first in line when it comes to consuming events (which currently is only the case due to event handlers being added at the earliest possible opportunity, and event handlers being called in order).  If something as trivial as:
>>        control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
>>               if (e.getCode() == KeyCode.LEFT) {
>>                     e.consume();  // stop default behavior
>>               }
>>        });
>> 
>> ... actually worked, then there is much less need to redefine/disable behavior key mappings, and no need for a secondary system that deals with mappings (the first system, event handlers, can simply be used for this).  If user event handlers had priority over behavior ones, then everything you want can be achieved with the above, including:
>> 
>> - Stopping default behavior
>> - Triggering different behavior (just call something on control, of course, make sure all behavior actions are available on the control in the first place)
>> - Remapping (a combination of the above two)
>> - Adding an alternative key for the same behavior
>> 
>> A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box.
>> 
>> Changes to the Behavior system can then focus on replacing complete behaviors (including their input map) and being able to use these by default for a certain subset of controls (like -fx-skin provide in CSS), as this is something users currently can't do.
>> 
>> So in short, what I think this should be about is:
>> 
>> - Ensure user event handlers have priority over behavior/inputmap added ones
>> - Ensure all behavior actions are available as methods on controls
>> - Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong).
>> 
>> Future:
>> 
>> - Make behaviors public and allow Behaviors to be replaced with -fx-behavior type CSS syntax / control.setBehavior calls
>> 
>> --John
>> 
>>  
>> 
>> The focus should be on being able to modify standard behavior of controls (arrow-left, enter, ctrl-shift-right, etc.), specifically also to be able to disable these when undesired, and, on top of that, that they bubble up when NOT used even when they are configured (focus navigation keys currently are always consumed, whether they actually do something or not -- that's a big issue).  The other focus should be on providing an alternative behavior (or at least mappings) for all controls of a certain type -- I don't see the need for adding a mapping to a specific control, that's already covered with event handlers; the problem is mostly that behaviors currently steal certain events before the user can get at them.
>> 
>> Custom behaviors can then be constructed that provide more things that may need mapping.  I'd expect those however to be limited in scope to what the control offers, certainly not an arbitrary key/action mapping system (that wouldn't even work, as most of these would be in the scope of several controls or be global).  This kind of functionality is much better provided by event handlers at the correct level for a group of controls, and I wouldn't expect to find such an eloborate system incorporated in behaviors.
>> 
>> In fact, thinking about all of this a bit more, 
>> 
>>  
>> 
>> On 10/10/2023 19:54, Andy Goryachev wrote:
>> 
>> Re-sending with a smaller image (256kb limit, really?).
>>  
>> From: Andy Goryachev  
>> Date: Tuesday, October 10, 2023 at 10:49
>> To: Michael Strau?  
>> Cc: openjfx-dev at openjdk.org   
>> Subject: Re: [Request for Comments] Behavior / InputMap
>> 
>> Dear Michael:
>>  
>> Here is a use case for (re-)mapping by the user at runtime:
>>  
>> 
>>  
>> (key mappings UI in Eclipse).
>>  
>> I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest.
>>  
>> Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think.
>>  
>> -andy
>>  
>>  
>> From: openjfx-dev   on behalf of Michael Strau?  
>> Date: Tuesday, October 10, 2023 at 10:36
>> To: 
>> Cc: openjfx-dev at openjdk.org   
>> Subject: Re: [Request for Comments] Behavior / InputMap
>> 
>> > Yes, one of the features the new design provides is ability to modify key mappings by the user at runtime.  So yes, not only it needs to be mutable, but it also adds some APIs for exactly that.
>> >
>> 
>> I struggle to see a use case for this feature. I can imagine that
>> there might be some use cases that call for customized input mappings,
>> but why would this translate to a _mutable_ input map? That's quite a
>> departure from the way other parts of JavaFX work.
>> 
>> For example, skins are also immutable. If you want to have a different
>> skin for a control, you don't somehow modify the existing skin
>> instance; instead, you'd create a new skin class (or -- somehow --
>> extend an existing skin class), and then install that new skin on your
>> control.
>> 
>> An input map shouldn't bind input events directly to instance methods
>> of a particular control instance. It should define the mapping of
>> events to methods symbolically:
>> 
>> Instead of mapping Event => instance.method(), it should map Event =>
>> Control::method. The input map could then be stateless and immutable,
>> and can be set on any control instance. If you want to change the
>> mappings, just set a different input map instance. There's no need
>> that an input map would retain a reference to any particular control,
>> since the control reference can be passed into the input map just as
>> easily.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From thiago.sayao at gmail.com  Sun Oct 15 00:16:31 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 14 Oct 2023 21:16:31 -0300
Subject: How to request javafx pixels rather than receiving it?
In-Reply-To: 
References: 
Message-ID: 

Hi,

Please, ignore. I've found a solution with the existing flow.

Em s?b., 14 de out. de 2023 ?s 14:44, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> Hi,
> I'm doing some experimenting on new ways to implement the gtk glass
> backend (mainly targeting wayland support).
>
> JavaFX View implementations receives the data to be drawn.
> I want to be able to request it synchronously.
>
> If JavaFX needs to paint I need it to request the glass backend without
> the data.
> So the backend would request back the data to be drawn when it's ready.
>
> I could keep a buffer on GtkView.java. Would it be too ugly?
>
> -- Thiago.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tsayao at openjdk.org  Sun Oct 15 00:27:50 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 15 Oct 2023 00:27:50 GMT
Subject: RFR: Draft: 8316423: [linux] Secondary Stage does not respect
 Scene's dimensions when shown [v5]
In-Reply-To: 
References: 
Message-ID: 

> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
> 
> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
> 
> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
> 
> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Test

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1249/files
  - new: https://git.openjdk.org/jfx/pull/1249/files/59fcf234..ac7b4da7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=03-04

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

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

From tsayao at openjdk.org  Sun Oct 15 00:32:47 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 15 Oct 2023 00:32:47 GMT
Subject: RFR: Draft: 8316423: [linux] Secondary Stage does not respect
 Scene's dimensions when shown [v6]
In-Reply-To: 
References: 
Message-ID: 

> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
> 
> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
> 
> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
> 
> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Test"

  This reverts commit ac7b4da75b9690c42aecd484bb3990866a004074.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1249/files
  - new: https://git.openjdk.org/jfx/pull/1249/files/ac7b4da7..e5ab28b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=04-05

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

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

From rahman.usta.88 at gmail.com  Sun Oct 15 08:50:27 2023
From: rahman.usta.88 at gmail.com (Rahman USTA)
Date: Sun, 15 Oct 2023 11:50:27 +0300
Subject: JVM Crash due to libjfxwebkit.dylib
Message-ID: 

Hi,

I reported a JVM crash in here
https://github.com/adoptium/adoptium-support/issues/919

It seems related to webkit. Can you help me with this ?

Thank you,
Rahman Usta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pedro.duquevieira at gmail.com  Sun Oct 15 12:11:11 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sun, 15 Oct 2023 13:11:11 +0100
Subject: [Request for Comments] Behavior / InputMap
In-Reply-To: 
References: 

Message-ID: 

Hi Andy,

Sorry for the late reply but unfortunately I didn't have time to respond to
you earlier.

Yes, you're right, Swing did allow for easier extension of controls' themes
and you did see people coming up with new theme libraries that overwrote
Controls appearance/behavior through code.

I think the main issue with Skins being difficult to extend is that they're
taking on too much responsibility. They do both the View and Controller
part of the Controls (the model being the part that developers interact
with). When I talk about MVC here I mean it in a loose way, I'm
referring to any and all the MVC like patterns. If for instance there was a
clear class, in the Skin architecture, that just took care of how a Control
is displayed, and nothing else, it would be easier to overwrite, for
example, how the Control is displayed and hence override Skins.

   - What are the missing APIs in Skins that we can add to simplify
   extension of skins?

I think, as I said above, Skins would have to have a different
architecture. IMHO, their responsibilities would likely have to be split
into different classes each with a smaller set of concerns. I'm not talking
about changing the whole Control architecture, just the Skin part. This
would likely be a big effort but perhaps it could be split into smaller
tasks till the end goal is achieved.

   - Would this proposal (BehaviorBase + InputMap) prevent us from moving
   forward?

Likely no.

BTW, in the past I already had the need for this API (InputMap) for an
application I was developing that's now in production. To do what I needed
I had to call on private methods using reflection, etc, since there's no
public API to achieve this yet.
My use case was that I was creating a custom control, "inside" that control
I used a ScrollPane but ScrollPane has a bunch of default key mappings,
like SPACE, PAGE_UP, PAGE_DOWN, HOME that when pressed already do
predefined things. I needed to remove those key mappings as in this
application those keys were already meant to do something else other than
what the default JavaFX ScrollPane does with them.

Thnaks. Kind regards,

On Mon, Oct 9, 2023 at 7:38?PM Andy Goryachev 
wrote:

> Thank you for the feedback!
>
>
>
> You are right: even though Skins are public classes now, they are very
> difficult to extend ? at least, much more difficult that Swing UIs.  It?s a
> source of constant discussions within the team ? how much of it should be
> made public (protected) to allow for extension vs. how much of it should be
> hidden as implementation detail to minimize the API surface and allow for
> evolution.  While opening it all up might alleviate developers? pain when
> extending, it poses a great(er) danger of introducing of all sorts of
> compatibility issues with respect to bug fixes and other changes.
>
>
>
> If we speak about extending skins specifically, a good question might be:
> what exactly is missing?  Which APIs do we need to enable easier extension
> of skins?
>
>
>
> One thing I would like to clarify is that the Behavior / InputMap proposal
> is not about extending skins.  It is also not about making the concrete
> behaviors public (a task which is probably as large as adding missing
> public APIs to skins).
>
>
>
> The main goal is to allow for extending and slightly modifying the
> behavior ? like altering the way navigation works in a text control, or
> adding a new key binding.  As a result, the overall proposal is smaller
> than it could be.
>
>
>
> Having said that, nothing prevents us from exploring options to open up
> skins, or making behaviors public.
>
>
>
> To summarize:
>
>    - What are the missing APIs in Skins that we can add to simplify
>    extension of skins?
>    - Would this proposal (BehaviorBase + InputMap) prevent us from moving
>    forward?
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev  on behalf of Pedro
> Duque Vieira 
> *Date: *Saturday, October 7, 2023 at 14:05
> *To: *openjfx-dev at openjdk.org 
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> I second the opinions of others that JavaFX is too closed which, I think,
> hinders the work of library and app developers.
>
>
>
> I wonder if the reasons that were used to make this design decision back
> when JavaFX was being created still hold true. Back in the beginning there
> were more developers involved in developing JavaFX, significant features
> were added at a fast pace so the fact that it was closed wasn't such a big
> drawback as things were changing quickly and missing features that were
> spotted could be added relatively quick.
>
>
>
> Commenting more specifically on your question... I think Skins could
> benefit generally from being easier to extend. The promise of skins is that
> you could easily replace a control behavior and visuals without changing
> its model (the model being the part of the control that developers usually
> interact with) but the problem is that the JavaFX SDK control's skins are
> very difficult to extend. Say, if you only want to add a specific visual
> feature (something that CSS can't do) it takes a significant effort.
>
> What you usually see is that developers opt to create completely new
> controls rather than just new skins.
>
> My attempt at providing new skins for existing javafx sdk controls is
> here: https://github.com/dukke/FXSkins
>
> Still it required quite a bit of effort.. at least more than it could
> ideally take (I think).
>
> The advantage of this kind of approach (providing new Skins) and the
> library I created "FXSkins" is that you can enhance the controls of your
> existing app very easily by setting new skins in the CSS stylesheet. You
> won't need to change anything directly in the code.
>
>
>
> Regarding the current state of the JavaFX SDK Skins, there isn't a clear
> MVC separation, the skin does the Controller and View part at the same
> time. Perhaps ideally there would be a clear View part that could easily be
> extended to add different advanced visuals to the control (by advanced I
> mean, anything that can't be done with CSS). And then perhaps also the
> Behavior part where you can easily change the control's functionality. I
> remember at some point Richard Bair saying that it was a goal to make
> Behaviors public.
>
>
>
> Thanks!
>
> --
>
> Pedro Duque Vieira - https://www.pixelduke.com
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tsayao at openjdk.org  Sun Oct 15 13:13:23 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 15 Oct 2023 13:13:23 GMT
Subject: RFR: Draft: 8316423: [linux] Secondary Stage does not respect
 Scene's dimensions when shown [v6]
In-Reply-To: 
References: 

Message-ID: <1fwAyTdFFEOaVztFs2RqRJhsxUyM0SBOqIzB6FJKypU=.e9d94eb1-7113-4391-989b-8821d9cd4955@github.com>

On Sun, 15 Oct 2023 00:32:47 GMT, Thiago Milczarek Sayao  wrote:

>> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
>> 
>> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
>> 
>> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
>> 
>> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Test"
>   
>   This reverts commit ac7b4da75b9690c42aecd484bb3990866a004074.

Filed a bug on Mutter [here](https://gitlab.gnome.org/GNOME/mutter/-/issues/3092).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1249#issuecomment-1763385062

From tsayao at openjdk.org  Sun Oct 15 13:25:15 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 15 Oct 2023 13:25:15 GMT
Subject: RFR: Draft: 8316423: [linux] Secondary Stage does not respect
 Scene's dimensions when shown [v7]
In-Reply-To: 
References: 
Message-ID: 

> It looks like a condition between calls from `set_visible` to `request_focus`. When `request_focus` is called, the window is not yet mapped (map is requested on `set_visible`). 
> 
> 200x200 is the default gtk window size if none is specified. Since the window is presented at the requested size and then changes to 200x200 I would guess the size request on `gtk_window_present` (which is called on `request_focus`) is being queued and released later. But I'm not really sure.
> 
> With this change immediate `request_focus` after the window is created will be ignored. But the default is to request focus on map, so it will work. `request_focus` will only be useful when called after the window is mapped (presented on the screen).
> 
> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix background

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1249/files
  - new: https://git.openjdk.org/jfx/pull/1249/files/e5ab28b3..891d9407

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1249&range=05-06

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

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

From tsayao at openjdk.org  Sun Oct 15 13:34:23 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 15 Oct 2023 13:34:23 GMT
Subject: RFR: 8316423: [linux] Secondary Stage does not respect Scene's
 dimensions when shown [v7]
In-Reply-To: 
References: 

Message-ID: 

On Sun, 15 Oct 2023 13:25:15 GMT, Thiago Milczarek Sayao  wrote:

>> The bug on the title happens because `gtk_widget_realize()` was called on the constructor. It creates the internal underlying window  `GdkWindow` and `XWindow` messing the Gtk expected order. It actually it's probably a Mutter change rather than Gtk. But makes sense to not realize it before expected on the gtk/mutter flow.
>> 
>> I moved the code to get the `GdkWindow` to the realize event.
>> 
>> Had to change the background function because it's called before realize.
>> 
>> The initial **Maximized** and **FullScreen** situations are probably a bug on Mutter [filed here](https://gitlab.gnome.org/GNOME/mutter/-/issues/3092).
>> 
>> I could work-around it on this situation, but it would still happen on later focus request.
>> 
>> 
>> This also fixes [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix background

Updated the original description.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1249#issuecomment-1763391088

From thiago.sayao at gmail.com  Sun Oct 15 13:49:03 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 15 Oct 2023 10:49:03 -0300
Subject: Wayland
Message-ID: 

Hi,

https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland

I did some experiments here. So far, so good.

1) Replaced GDK events for Gtk Signals - It's the way to go for newer gtk.
2) Replaced drawing directly in the window and added a GtkDrawingArea with
a GtkHeaderBar which allows control over the whole window
size and allows to get rid of extents* calls - this cleans up a lot.
3) Unified the WindowContext to clean it up.

I also integrated the IME replacement proposed here:
https://github.com/openjdk/jfx/pull/1080

It almost runs with software rendering on Wayland, but something still
touches X11.

To finally make it work on Wayland it requires to implement it on prism
es2. I see that there's a EGL part of Monocle. I still don't completely
understand it, but wouldn't it work as a drop-in replacement?

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From thiago.sayao at gmail.com  Sun Oct 15 19:06:23 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 15 Oct 2023 16:06:23 -0300
Subject: Wayland
In-Reply-To: 
References: 
Message-ID: 

Hi,

Update: It now works on wayland with -Dprism.order=sw

Em dom., 15 de out. de 2023 ?s 10:49, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> Hi,
>
> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>
> I did some experiments here. So far, so good.
>
> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer gtk.
> 2) Replaced drawing directly in the window and added a GtkDrawingArea with
> a GtkHeaderBar which allows control over the whole window
> size and allows to get rid of extents* calls - this cleans up a lot.
> 3) Unified the WindowContext to clean it up.
>
> I also integrated the IME replacement proposed here:
> https://github.com/openjdk/jfx/pull/1080
>
> It almost runs with software rendering on Wayland, but something still
> touches X11.
>
> To finally make it work on Wayland it requires to implement it on prism
> es2. I see that there's a EGL part of Monocle. I still don't completely
> understand it, but wouldn't it work as a drop-in replacement?
>
> -- Thiago.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.hendrikx at gmail.com  Mon Oct 16 11:51:18 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 16 Oct 2023 13:51:18 +0200
Subject: Alternative approach for behaviors, leveraging existing event system
Message-ID: <5221ff0a-3bba-1efd-7d38-adc6bbb4bd03@gmail.com>

Hi Andy, hi list,

I've had the weekend to think about the proposal made by Andy Goryachev 
to make some of the API's surrounding InputMap / Behaviors public.

I'm having some nagging doubts if that proposal is really the way 
forward, and I'd like to explore a different approach which leverages 
more of FX's existing event infrastructure.

First, let me repeat an earlier observation; I think event handlers 
installed by users should always have priority over handlers installed 
by FX behaviors. The reasoning here is that the user (the developer in 
this case) should be in control.? Just like CSS will back off when the 
user changes values directly, so should default behaviors.? For this 
proposal to have merit, this needs to be addressed.

One thing that I think Andy's proposal addresses very nicely is the need 
for an indirection between low level key and mouse events and their 
associated behavior. Depending on the platform, or even platform 
configuration, certain keys and mouse events will result in certain high 
level actions.? Which keys and mouse events is platform specific.? A 
user wishing to change this behavior should not need to be aware of how 
these key and mouse events are mapped to a behavior.

I however think this can be addressed in a different way, and I will use 
the Button control to illustrate this, as it is already doing something 
similar out of the box.

The Button control will trigger itself when a specific combination of 
key/mouse events occurs.? In theory, a user could install event handlers 
to check if the mouse was released over the button, and then perform 
some kind of action that the button is supposed to perform.? In practice 
however, this is tricky, and would require mimicing the whole process to 
ensure the mouse was also first **pressed** on that button, if it wasn't 
moved outside the clickable area, etc.

Obviously expecting a user to install the necessary event handlers to 
detect button presses based on key and mouse events is a ridiculous 
expectation, and so Button offers a much simpler alternative: the 
ActionEvent; this is a high level event that encapsulates several other 
events, and translates it to a new concept.? It is triggered when all 
the criteria to fire the button have been met without the user needing 
to be aware of what those are.

I think the strategy of translating low level events to high level 
events, is a really good one, and suitable for reusing for other purposes.

One such purpose is converting platform dependent events into platform 
independent ones. Instead of needing to know the exact key press that 
would fire a Button, there can be an event that can fire a button.? Such 
a specific event can be filtered and listened for as usual, it can be 
redirected, blocked and it can be triggered by anyone for any reason.

For a Button, the sequence of events is normally this:

- User presses SPACE, resulting in a KeyEvent
- Behavior receives KeyEvent and arms the button
- User releases SPACE, resulting in a KeyEvent
- Behavior receives KeyEvent, disarms and fires the button
- Control fires an ActionEvent

What I'm proposing is to change it to:

- User presses SPACE, resulting in a KeyEvent
- Behavior receives KeyEvent, and sends out ButtonEvent.BUTTON_ARM
- Control receives BUTTON_ARM, and arms the button
- User releases SPACE, resulting in a KeyEvent
- Behavior receives KeyEvent and sends out ButtonEvent.BUTTON_FIRE
- Control receives BUTTON_FIRE, disarms the button and fires an ActionEvent

The above basically adds an event based indirection.? Normally it is 
KeyEvent -> ActionEvent, but now it would be KeyEvent -> ButtonEvent -> 
ActionEvent. The user now has the option of hooking into the mechanics 
of a Button at several different levels:

- The "raw" level, listening for raw key/mouse events, useful for 
creating custom behavior that can be platform specific
- The "interpreted" level, listening for things like ARM, DISARM, FIRE, 
SELECT_NEXT_WORD, SELECT_ALL, etc...; these are platform independent
- The "application" level, primarily action type events

There is sufficient precedence for such a system.? Action events are a 
good example, but another example are the DnD events which are created 
by looking at raw mouse events, effectively interpreting magic mouse 
movements and presses into more useful DnD events.

The event based indirection here is very similar to the FunctionTag 
indirection in Andy's proposal.? Instead of FunctionTags, there would be 
new events defined:

 ??? ButtonEvent {
 ??????? public static final EventType ANY = ... ;
 ??????? public static final EventType BUTTON_ARM = ... ;
 ??????? public static final EventType BUTTON_DISARM = ... ;
 ??????? public static final EventType BUTTON_FIRE = ... ;
 ??? }

 ??? TextFieldEvent {
 ??????? public static final EventType ANY = ... ;
 ??????? public static final EventType SELECT_ALL = ... ;
 ??????? public static final EventType SELECT_NEXT_WORD 
= ... ;
 ??? }

These events are similarly publically accessible and static as 
FunctionTags would be.

The internal Behavior classes would shift from translating + executing a 
behavior to only translating it.? The Control would be actually 
executing the behavior.

This also simplifies the role of Behaviors, and maybe even clarifies it; 
a Behavior's purpose is to translate platform dependent to platform 
independent events, but not to act on those events.? Acting upon the 
events will be squarely the domain of the control.? As this pinpoints 
better what Behavior's purpose it, and as it simplifies their 
implementation (event translation only) it may be the way that leads to 
them becoming public as well.

---

I've used a similar mechanism as described above in one of my FX 
Applications; key bindings are defined in a configuration file:

 ? ? BACKSPACE: navigateBack
 ? ? LEFT: player.position:subtract(10000)
 ? ? RIGHT: player.position:add(10000)
 ? ? P: player.paused:toggle
 ? ? SPACE: player.paused:toggle
 ? ? I:
 ? ? ??? - overlayVisible:toggle
 ?? ???? - showInfo:trigger

When the right key is pressed (and it is not consumed by anything), it 
is translated to a new higher level event by a generic key binding 
system.? This event is fired to the same target (the focused node).? If 
the high level event is consumed, the action was succesfully triggered; 
if not, and a key has more than one mapping, another event is sent out 
that may get consumed or not.? If none of the high level events were 
consumed, the low level event that triggered it is allowed to propogate 
as usual.

The advantage of this system is obvious; the controls involved can keep 
the action that needs to be performed separate from the exact key (or 
something else) that may trigger it.? For "navigateBack" for example, it 
is also an option to use the mouse; controls need not be aware of this 
at all.? These events also bubble up; a nested control that has several 
states may consume "navigateBack" until it has reached its local "top 
level", and only then let it bubble up for one of its parents to act on.

--John

From nlisker at gmail.com  Mon Oct 16 11:52:21 2023
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 16 Oct 2023 14:52:21 +0300
Subject: Question: bidi navigation
In-Reply-To: 
References: 
Message-ID: 

This is a tricky one. All applications I have seen, and I think that's what
people expect, is that the cursor changes direction during traversal.

A key point is where the paragraph is aligned to (in Windows adjusted with
left CTRL+SHIFT and right CTRL+SHIFT). This sets the forward and backward
direction: if the paragraph is left-aligned, pressing the right arrow moves
the cursor forward, and for a right aligned, the right arrow moves the
cursor backward. Then the actual movement of the cursor is relative to the
paragraph alignment: in RTL alignment, traversing RTL text moves the
cursor forward, while traversing LTR moves the cursor backward.

To help with navigation, the cursor has a line attached to its top showing
which direction it's facing.

Hope this helps.

On Thu, Oct 12, 2023 at 3:42?AM Andy Goryachev 
wrote:

> Hi.
>
>
>
> I have a question for people who routinely use right-to-left RTL languages
> (Arabic, Hebrew, etc.):
>
>
>
> *What is your expectation for navigating text using left/right arrow keys
> when the text contains a mixture of RTL and LTR?*
>
>
>
> It looks like there is no standard when it comes to modern applications ?
> see a small sample:
>
>
> https://gist.github.com/andy-goryachev-oracle/4802f9380fb03ec2be7ac36bd98a2059
>
>
>
> In javafx, the navigation of bidirectional (bidi) text might have been
> broken sometime after jfx8, and even jfx8 might have issues, see
>
> https://bugs.openjdk.org/browse/JDK-8296266
>
>
>
> It looks like the most modern applications use logical navigation and
> logical selection (that is, when navigating using left/right arrow keys,
> the cursor position reflects previous/next insertion indexes in the text,
> rather than visual position).  This causes the cursor to change the
> direction of movement when it crosses the bidi boundary.  Would you say
> this is the expected behavior?
>
>
>
> Thank you
>
> -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Mon Oct 16 15:16:18 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 16 Oct 2023 15:16:18 +0000
Subject: [External] : Re: Question: bidi navigation
In-Reply-To: 
References: 

Message-ID: 

Nir, thank you for responding!

The behavior you describe (?logical? navigation) is what can be seen in many, but not all applications, and that is what puzzles me.  What?s more interesting, the applications that use a ?visual? kind of navigation, that is the RIGHT ARROW key always moving the cursor right regardless of the text, is used by javafx8 (it?s totally broken in jfx17, but it looks from the code that it is supposed to be the same as in javafx8), java swing, MS Word 2007 on Windows 10, macOS Notes app, macOS TextEdit, and Mozilla Thunderbird.  Also, this is the kind of navigation that some users prefer (based on a very, very limited sample I was able to contact).

What puzzles me is that there is no apparent standard even among the modern applications (bundled macOS apps), although the transition from visual to logical navigation in MS Word might indicate that the logical navigation is winning.

The appearance of caret is another aspect that seem to have no standard.  In many apps the caret does not change at all, very rarely we see a flag indicating direction (java swing), and only javafx8 and some obsolete mac Carbon reference doc shows a split caret.