Re: RFR: 8185831: Psuedo selectors do not appear to work in Node.lookupAll() [v2]

[Sai Pradeep Dandem]

> **Issue:**
> Using pseudo classes in programmatic query using Node.lookupAll() or 
> Node.lookup() gives unexpected results.
> 
> **Cause:**
> There is no check for checking the psuedo states matching in the applies() 
> method of SimpleSelector.java.
> 
> **Fix:**
> Included the check for the states for matching.

Sai Pradeep Dandem has updated the pull request incrementally with one 
additional commit since the last revision:

  8185831: Fixed test failing issues and code review comments

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1245/files
  - new: https://git.openjdk.org/jfx/pull/1245/files/524db831..75323661

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

  Stats: 69 lines in 3 files changed: 30 ins; 7 del; 32 mod
  Patch: https://git.openjdk.org/jfx/pull/1245.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1245/head:pull/1245

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

Re: [External] : Re: [Request for Comments] Behavior / InputMap

[Andy Goryachev]

Dear John:

Based on what I understand about your proposal now, I think it’s a variant of 
the same thing, not fully developed and in some places based on the incorrect 
assumptions (S/B separation, stateless B).  But you know I am biased :-)

A more detailed proposal - up to you; there are literally thousands of bugs in 
FX that I’d rather focus on instead, but it’s an open source and nobody can 
tell you what to do :-)  May be a more detailed proposal at least outlining 
public APIs might help.

Looking at your Carousel TreeViewSkin demo (nice work, by the way!) I fully 
agree - there is no way we can reasonably create a base skin for that.  It is a 
new skin, or maybe even a new control altogether.

The separation between skins and behaviors are fuzzy, but we do have an 
established and well know pattern: MVC.  Behavior is the controller in this 
paradigm - a stateful logic which translates input events into changes in 
model.  You are proposing for B to translate the input events to another set of 
events which I think is unnecessary.  “Everything should be made as simple as 
possible, but not simpler”, to paraphrase Herr Einstein.  May be I don’t see a 
clear use case (for new events)?

A behavior listens for events (coming from control or elements of skin), 
maintains its state, translates these events into direct actions on the model 
or the control (control being a façade).  I think there is no need for an extra 
layer of events, especially if they bubble up.

Most use case I think are limited to developers changing a minor aspect of the 
skin/behavior - adding a corner node between horizontal and vertical scroll bar 
for example, or modifying the way currently selected item is highlighted vs. 
the mouse hover highlight, remap a key binding, or something like that.  Go 
beyond that - it’s a new thing altogether, as you rightfully said earlier.

Also, when looking at sufficiently complex control such as (Rich)TextArea or 
TreeTableView - I don’t think the behavior can be composited from a bunch of 
simple things - there is too much interaction.  So B ends up being a complex, 
stateful beast that tightly coupled with the particular implementation of the 
skin (so in some sense you are right, saying we have only skins).  Just like 
ComponentUI in swing.  It simply cannot be an interface or a singleton.

I am sorry, John, for my negative reaction to your proposal.  I am very 
grateful for the discussion, and I think we should discuss/develop some ideas 
in it further - like prioritization of event handlers.

What do you think we ought to do to move forward?

Thank you
-andy


From: John Hendrikx 
Date: Tuesday, October 17, 2023 at 15:04
To: Andy Goryachev , openjfx-dev@openjdk.org 

Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap

Hi Andy,
On 17/10/2023 20:07, Andy Goryachev wrote:
Dear John:

It looks like we have different views on the subject, so perhaps we should 
invite other people to weigh in.

I would be interested to hear from others on this subject as well.

I feel however that I may need to make a more formal proposal to show more 
clearly what is possible.  I'd still be interested in hearing your views on the 
alternative proposal after I addressed your initial questions.  Do you need 
more information?

My goal is to move forward adding missing features without making any drastic 
changes, and avoid regressions as much as possible.  We also have to be mindful 
of the fact that we are dealing with constrained resources, so any major 
development is very likely out of question.  That’s why

I don't think my proposal is that drastic, nor do I think it will be the cause 
of any major regressions.  Nor do I agree that my alternative is that much 
harder to implement.  It may require a bit more work upfront, but it also 
offers more in the end.  It still can be implemented one control at a time.


My problem here is that by making this class public (which IMHO is not a good 
design) will lock us out of improving this later.
If nobody uses FX there will be no “later”.  If customers’ code breaks too 
often they will switch to some [unnamed] alternative.

That's conditional on if we're breaking code, who said anything about that?  
Are you saying we can't change internals too much?

Nothing Behavior related should be made public without a full design of how 
Behaviors should work, what their responsibilities are, how they interact with 
Skins (if at all, IMHO they shouldn't), etc.  Once a design is known and agreed 
upon, then we can work on step-by-step improvements by making parts public, and 
leaving parts hidden.
We kind of know what behaviors do - they handle user input, modifying the 
appearance or internal state of the control.

I just want to mention again that behaviors must interact with skins - not all 
the behaviors, but some.  For example, TextArea “MOVE_LINE_END” needs to know 
how the text is laid out in order to determine the target caret position, this 

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Martin Fox]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

Adding a comment to keeper the robot away.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1767332449

Re: [External] : Re: [Request for Comments] Behavior / InputMap

[Michael Strauß]

Hi Andy,

I mean this in the most respectful way possible, but my feeling is that
most of the arguments presented in favor of this enhancement seem to be
driven by an existing implementation, and not a "first-principles" analysis.

I've seen many proposals on this mailing list shot down with exactly this
justification: don't simply propose to make an existing internal
implementation public; instead, think of it in terms of the problem and API
first. Is the (existing) InputMap idea really so good that it would emerge
as the winner in an open competition of ideas? Maybe it is, but I'm not
convinced.

In an earlier mail, you wrote the following:
> BehaviorBase (or an interface with default methods) is an important
addition and a pre-requisite for effective use of the new input map (it’s
already being used and is a blocker for RichTextArea, and I have one more
control that needs it).

This puts us in a difficult situation. You're proposing a (controversial)
addition to the core JavaFX API, and justify it at least in part with being
a blocker for another feature that is presumably already under development.
Again, this is not how feature proposals should be justified according to
the guidelines of this project.
Can't you use the existing internal implementation for RichTextArea, at
least for the time being? That would give us a bit more time to let the
pieces settle. You've put out the first proposal, which is great! But now
there's at least one other proposal, which is also a great thing.

Kevin has rightfully indicated time and time again that we shouldn't rush a
new feature into JavaFX, especially if the community hasn't come to a clear
agreement. And even if there is an agreement, new features of this
magnitude usually take many months (sometimes years) to go in. Why the
urgence for this particular feature? At the same time, other useful
features like nested change notifications, CSS transitions, or the whole
platform preferences / style themes saga sit idly by and wait for their
time to shine.

I acknowledge that the InputMap proposal does add value to JavaFX, but it
does so at the cost of a pretty large API surface (InputMap has 12 public
methods, and BehaviorBase adds another 13 public methods, and that's before
going into all of the FunctionTags defined on controls). My feeling is that
at last some of that complexity is a result of working around limitations
of JavaFX internals (method names like "addHandlerLast" also seem to
suggest that).

In an earlier mail, I asked you for clarification what this new API enables
developers to do. You suggested a customized shortcut feature as seen in
Eclipse and other IDEs. John and Martin observed that an application-level
key binding feature most likely wouldn't be implemented using "simple"
out-of-the-box tools that JavaFX can offer. In this example, when a
shortcut is changed in the IDE, the application wouldn't traverse the whole
scene graph, looking for controls, and then directly manipulating their
InputMap in some fashion to enable application-level shortcuts.

Since you hinted at RichTextArea, maybe you can talk about how the proposed
InputMap is necessary for the new control, and why it can't just use the
existing internal impementation like all other built-in controls.

You also talk about adding missing features. However, I don't see people
requesting key remapping very often (either here on the mailing list, or on
other channels like Reddit or StackOverflow). From my observation, these
are the features requested most often:

1. SVG images!!!
2. I want some XYZ control.
3. By the way, how can I extend and/or modify existing controls and skins?
4. Make JavaFX look more modern.

That doesn't mean that key remapping shouldn't be on the list of features
we want to implement, but all things considered, I question whether it
really is such a forced move to get this feature in ASAP.


On Tue, Oct 17, 2023 at 8:07 PM Andy Goryachev 
wrote:

> Dear John:
>
>
>
> It looks like we have different views on the subject, so perhaps we should
> invite other people to weigh in.
>
>
>
> My goal is to move forward adding missing features without making any
> drastic changes, and avoid regressions as much as possible.  We also have
> to be mindful of the fact that we are dealing with constrained resources,
> so any major development is very likely out of question.  That’s why
>
>
>
> My problem here is that by making this class public (which IMHO is not a
> good design) will lock us out of improving this later.
>
> If nobody uses FX there will be no “later”.  If customers’ code breaks too
> often they will switch to some [unnamed] alternative.
>
>
>
> Nothing Behavior related should be made public without a full design of
> how Behaviors should work, what their responsibilities are, how they
> interact with Skins (if at all, IMHO they shouldn't), etc.  Once a design
> is known and agreed upon, then we can work on step-by-step improvements by
> making parts public, and 

Re: [External] : Re: [Request for Comments] Behavior / InputMap

[John Hendrikx]

Hi Andy,

On 17/10/2023 20:07, Andy Goryachev wrote:


Dear John:

It looks like we have different views on the subject, so perhaps we 
should invite other people to weigh in.



I would be interested to hear from others on this subject as well.

I feel however that I may need to make a more formal proposal to show 
more clearly what is possible.  I'd still be interested in hearing your 
views on the alternative proposal after I addressed your initial 
questions.  Do you need more information?


My goal is to move forward adding missing features without making any 
drastic changes, and avoid regressions as much as possible.  We also 
have to be mindful of the fact that we are dealing with constrained 
resources, so any major development is very likely out of question. 
That’s why


I don't think my proposal is that drastic, nor do I think it will be the 
cause of any major regressions.  Nor do I agree that my alternative is 
that much harder to implement.  It may require a bit more work upfront, 
but it also offers more in the end.  It still can be implemented one 
control at a time.


My problem here is that by making this class public (which IMHO is not 
a good design) will lock us out of improving this later.


If nobody uses FX there will be no “later”.  If customers’ code breaks 
too often they will switch to some [unnamed] alternative.


That's conditional on if we're breaking code, who said anything about 
that?  Are you saying we can't change internals too much?


Nothing Behavior related should be made public without a full design 
of how Behaviors should work, what their responsibilities are, how 
they interact with Skins (if at all, IMHO they shouldn't), etc.  Once 
a design is known and agreed upon, then we can work on step-by-step 
improvements by making parts public, and leaving parts hidden.


We kind of know what behaviors do - they handle user input, modifying 
the appearance or internal state of the control.


I just want to mention again that behaviors must interact with skins - 
not all the behaviors, but some.  For example, TextArea 
“MOVE_LINE_END” needs to know how the text is laid out in order to 
determine the target caret position, this function cannot be 
implemented without the skin and the laid out text.  I think we need 
to take into account this constraint.


This is a technical issue that can be resolved.  Tying Behaviors and 
Skins together just means we only have one thing: Skins.  In that case, 
why pretend there even are behaviors?  If Skins need to provide 
functionality, this can be achieved differently.  TextArea could provide 
overridable hooks for this, Skins could install an event handler for 
TextAreaEvent.MOVE_LINE_END; just the fact that the TextArea skin is 
doing it this way is a red flag that clearly shows this class may need 
some adjustments as it was clearly not well separated -- it's normal for 
such problems to appear when trying to introduce something new; you 
don't work around them, you solve them.


Another point is that behavior is sometimes stateful, so let’s take 
this into account as well.


I've taken it into account now, and state can be associated with 
behaviors easily enough, without having a behavior be both the state 
class and the factory.  It's a minor separation, but makes it much 
easier to reason about.


I think BehaviorBase is just a convenient way to access the new input 
map (the subject of the new proposal). If someone does not want or 
does not need to use the input map - fine, nothing in the proposed 
design requires them to use it.  I don’t think it should be an 
interface either - the methods in BehaviorBase are protected because 
they are offered for subclasses only, and making BB an interface will 
turn these public which isn’t right.


I have a better solution for this, allowing Behavior to be an interface, 
with easy subclassing and composition options to manipulate the 
contained inputmap (without actually needing to expose an inputmap).


I do acknowledge that the issue of ordering of calls to added handlers 
might be undefined/unexpected, especially after a skin change.  This 
is the existing condition, and we probably should try to solve it in a 
separate thread.  I think that for skins the expectation is that the 
handlers added by the user are orthogonal to those added by the 
skin/behavior, and if they are not - use event filter, or let’s talk 
about adding prioritization in a separate discussion.


I always expected such a fix to be a separate change.  It could even be 
delayed somewhat, but not forever.  As the current implementation does 
not specify any ordering, there is sufficient freedom to make minor 
adjustments here.  Again, event filters are not intended and 
insufficient for this purpose.


I also acknowledge that the input map proposal does not address the 
issue of creating alternative custom skins and extending behaviors 
beyond modifying the key mappings and some limited manipulations of 

RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards

[Martin Fox]

After finding the Window virtual key code for a character getKeyCodeForChar was 
using a mapping table that only works correctly for U.S. English to retrieve 
the Java key code. This caused getKeyCodeForChar to encode keys differently 
than the original key event handling machinery.

With this fix the Robot, getKeyCodeForChar, and the code that handles platform 
key events all agree on how Windows VK codes should map to Java codes.

The manual KeyboardTest app can be used to test this (tests/manual/events). Run 
the tests by selecting "without keypad combinations" in the second dropdown. 
This will use a Robot to test KeyCharacterCombinations excluding the numeric 
keypad (which is a separate issue).

-

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into wincharcombo2
 - Fixing KeyCharacterCombinations on Windows

Changes: https://git.openjdk.org/jfx/pull/1264/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1264=00
  Issue: https://bugs.openjdk.org/browse/JDK-8274967
  Stats: 18 lines in 1 file changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1264.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1264/head:pull/1264

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

Re: RFR: 8205067: Resizing window with TextField hides text value

[Andy Goryachev]

On Tue, 17 Oct 2023 12:15:14 GMT, Karthik P K  wrote:

> Because of a missing conditional check in the `updateTextPos()`,  the 
> `textTranslateX` value was not getting updated when TextField size was 
> changed as a result of resizing window.
> 
> Updated the CENTER and LEFT cases in the `updateTextPos()` method to fix the 
> issue.
> 
> The fix can be validated using MonkeyTester.
> Steps to select TextField option in Monkey Tester.
> 
> - Open the MonkeyTester app and select TextField from the left option pane.
> - Select Long from Text selection option and TOP_LEFT from Alignment dropdown.
> - After above step, follow the steps given in the bug to validate the fix in 
> monkey tester.

@karthikpandelu there seems to much flicker.  Try placing the caret not at the 
end of the text, but a few characters before the end.
Could we make it more like JTextField behavior which tries to position the text 
such that it occupies all the available space?

-

PR Comment: https://git.openjdk.org/jfx/pull/1263#issuecomment-1767011394

Re: [External] : Re: [Request for Comments] Behavior / InputMap

[Andy Goryachev]

Thank you!

We probably should extract the skinning discussion into a separate thread.

-andy



From: Pedro Duque Vieira 
Date: Tuesday, October 17, 2023 at 05:57
To: Andy Goryachev 
Cc: openjfx-dev@openjdk.org 
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Yes Input Map would be a welcome addition.

--

Talking about the Skin discussion:
Right now, I think Skins do both the Controller and View part of a Control, 
making it really difficult to replace, extend, etc a Control's Skin...

I would have to think much more about this but I could see some kind of View 
class that Skin references. In this View class, we would define just how the 
control represents itself visually, that is, visual nodes, layout and 
animations. The Skin would take care of handling events from the View and 
updating the Model appropriately (the Model being the part that developers 
already interact with in a JavaFX Control - the class that extends Control), 
that is, just being a kind of Controller.

Main purpose would be to make it as easy as possible for developers to update a 
Control's visuals (layout, animation, etc). Right now it's a really hard task 
and 99% of developers just prefer to create a whole new control altogether 
rather than replace its Skin (even if they just want to slightly tweak an 
existing control's visuals).
In this case developers would replace the "View" class with their own 
implementation, adding new animations, new visuals, etc... This would allow for 
a much easier customization of visuals while still maintaining about the same 
code in the application (the application code being everything else except the 
Skins' code).
This would also allow a new echo system of Skin libraries to start to appear. 
These libraries would be interchangeable and would allow developers to easily 
update and enhance the visuals of their apps by setting a skin library.
This is what the library I've created FXSkins does 
(https://github.com/dukke/FXSkins),
 that is, it allows a developer to enhance their app's visuals very easily 
without changing one line of code in their app. The difference is that if 
JavaFX Skins architecture were defined as I mentioned above it would be much 
easier for me to develop FXSkins and there would probably be more libraries 
like this, created by other developers.

Thanks Andy! Kind regards,


On Mon, Oct 16, 2023 at 6:51 PM Andy Goryachev 
mailto:andy.goryac...@oracle.com>> wrote:
Thank you for clarification!

I just want to mention that here we are straying into what looks like a 
parallel discussion about skins (nothing wrong about it!).

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.

Could you please expand upon this?  What parts should skins be split into?

As it currently stands, Skins have two responsibilities - visual representation 
(the View in MVC paradigm) and handling of events, currently represented by the 
private behavior implementation.  In some sense, behaviors and skins are 
tightly coupled - it would be hard, in my opinion, to separate them without 
introducing large public API surface and consequently solidifying certain 
aspects of one particular implementation.

As far as I can tell, the input map proposal addresses the low hanging fruit of 
simple customization like your case of unregistering all key mappings from the 
ScrollPane.  It is certainly not a call to a major redesign.

Cheers,
-andy

From: Pedro Duque Vieira 
mailto:pedro.duquevie...@gmail.com>>
Date: Sunday, October 15, 2023 at 05:11
To: Andy Goryachev mailto:andy.goryac...@oracle.com>>
Cc: openjfx-dev@openjdk.org 
mailto:openjfx-dev@openjdk.org>>
Subject: [External] : Re: [Request for Comments] Behavior / InputMap
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, 

Skin Extension

[Andy Goryachev]

From: Pedro Duque Vieira
Talking about the Skin discussion:
Right now, I think Skins do both the Controller and View part of a Control, 
making it really difficult to replace, extend, etc a Control's Skin...

I would have to think much more about this but I could see some kind of View 
class that Skin references. In this View class, we would define just how the 
control represents itself visually, that is, visual nodes, layout and 
animations. The Skin would take care of handling events from the View and 
updating the Model appropriately (the Model being the part that developers 
already interact with in a JavaFX Control - the class that extends Control), 
that is, just being a kind of Controller.

Main purpose would be to make it as easy as possible for developers to update a 
Control's visuals (layout, animation, etc). Right now it's a really hard task 
and 99% of developers just prefer to create a whole new control altogether 
rather than replace its Skin (even if they just want to slightly tweak an 
existing control's visuals).
In this case developers would replace the "View" class with their own 
implementation, adding new animations, new visuals, etc... This would allow for 
a much easier customization of visuals while still maintaining about the same 
code in the application (the application code being everything else except the 
Skins' code).
This would also allow a new echo system of Skin libraries to start to appear. 
These libraries would be interchangeable and would allow developers to easily 
update and enhance the visuals of their apps by setting a skin library.
This is what the library I've created FXSkins does 
(https://github.com/dukke/FXSkins),
 that is, it allows a developer to enhance their app's visuals very easily 
without changing one line of code in their app. The difference is that if 
JavaFX Skins architecture were defined as I mentioned above it would be much 
easier for me to develop FXSkins and there would probably be more libraries 
like this, created by other developers.


With your permission, I’ve extracted this topic into a separate discussion.

First I’d start with outlining the problem we are trying to solve.  What do we 
want to achieve?  Do we want to change a certain aspect of the existing skin, 
or do we want to provide a drastically differently looking thing with a 
different behavior?  Could we list some examples?

Assuming we do need to touch the skins in some way, we have one major problem: 
skins are currently public, but extremely opaque.  My understanding is that the 
original intent in FX was to hide everything from the developer under the 
premise of “future development” or “evolving implementation without introducing 
compatibility issues”.  It’s a good idea, provided such processes were indeed 
ongoing.

We have at least two choices:

1. Simple: make skins and behaviors less opaque (protected methods, non-final 
classes etc.) similarly to what Swing does.  In Swing it is often possible to 
extend the component UI without much trouble.  The price: any code that depends 
on particular implementation detail will break after a new feature or a bug 
fix.  There is much resistance within this team to this choice, even though 
Swing has enormous success in delivering quality apps for more than two decades.

2. Not so simple: identify missing APIs that will make skin extension possible 
and easy.  Designing the APIs in such a way that hides internal detains and yet 
provides enough flexibility is not an easy task.  Personally, I don’t think 
it’s even possible without opening up the skin implementation, but perhaps I am 
wrong.

Did I miss anything?  What do you think?

-andy

Integrated: 8318204: Use new EventTarget methods in ListenerHelper

[Michael Strauß]

On Tue, 17 Oct 2023 04:46:12 GMT, Michael Strauß  wrote:

> As of OpenJFX 21, `EventTarget` has methods to add and remove event listeners.
> The `instanceof` checks in `com.sun.javafx.scene.control.ListenerHelper` 
> should be removed and replaced by a simple call to the respective interface 
> method.

This pull request has now been integrated.

Changeset: cd7383ae
Author:Michael Strauß 
URL:   
https://git.openjdk.org/jfx/commit/cd7383aefcb15804bce1ba8541bf41137fb880cb
Stats: 87 lines in 2 files changed: 1 ins; 78 del; 8 mod

8318204: Use new EventTarget methods in ListenerHelper

Reviewed-by: jhendrikx, nlisker, angorya

-

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

[jfx21u] Integrated: 8317842: Create release notes for JavaFX 21.0.1

[Kevin Rushforth]

On Tue, 10 Oct 2023 23:24:05 GMT, Kevin Rushforth  wrote:

> Release notes for JavaFX 21.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=44663
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=44662
> 
> As usual, I excluded test bugs, cleanup bugs, etc. I manually excludes 4 
> additional bugs, one of which was a README change (does not affect the 
> product), and the other three were introduced and fixed in the same release.

This pull request has now been integrated.

Changeset: e7ad06f7
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx21u/commit/e7ad06f70f18050ae2ab6b1fb471f4b4eacbc435
Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod

8317842: Create release notes for JavaFX 21.0.1

Reviewed-by: jvos

-

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

Re: [External] : Re: Question: bidi navigation

[Andy Goryachev]

Dear Nir:

Thank you so much for the information.  I spoke to several people none of whom, 
unfortunately, use an environment configured for RTL mode (but who have 
keyboard settings for RTL languages).  Based on the very small sample, it 
appears that logical navigation is a way to go - which means the FX behavior 
(or rather lack thereof due to https://bugs.openjdk.org/browse/JDK-8296266) 
needs to change relative to jfx8.

Regarding the direction indicator - FX implements a dual caret the logic of 
which I am still trying to decipher:


[cid:image001.png@01DA00D4.548303B0]


(sliptCaret in PrismTextLayout:354)

The closest description I was able to find is in Apple ATSUI Programming guide
http://developer.apple.com/legacy/mac/library/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui.pdf
on page 35, though I am not sure FX works as described in that document.

The expectation is that the primary (high) caret is where the character having 
the same directionality as the “primary line direction” is inserted.  It is 
possible that the text layout determines the primary line direction based on 
the text as opposed to taking a hint from NodeOrientation.

Since this behavior is baked into FX prism text layout, I think it’s unlikely 
to change.

To summarize, I think we should switch FX TextInputControl hierarchy to logical 
navigation.  What do you think?

-andy



From: Nir Lisker 
Date: Tuesday, October 17, 2023 at 03:44
To: Andy Goryachev 
Cc: openjfx-dev@openjdk.org 
Subject: Re: [External] : Re: Question: bidi navigation
I have just tested on Win10: Notepad, Wordpad, MSWord 2021, Discord desktop, 
WhatsApp desktop, Opera, Eclipse, Gimp 2, Audacity 2.1.3, and MS VisualStudio 
2022 all use logical. Edge uses logical in text areas and text fields, but 
visual in the address bar (seems like a bug, but you can't have spaces in web 
addresses anyway). I don't remember ever using a visual navigation application, 
maybe it was very long ago. If there ever was a decision there, it was made 
long ago, at least on Windows.

It's very important to show the cursor direction because it resolves 
ambiguities. It's available in most applications.

My Windows UI is in standard English LTR. I just have an RTL language installed.

Logical navigation is a bit easier to work with I think. The behavior at the 
edge of a word that changes the direction can be surprising (see the 
ambiguities above), but that can be helped with the cursor direction 
indication. If we can do a custom implementation, I would go a step further and 
actually resolve the position ambiguities by positioning the cursor in 
accordance with the selected insertion method (RTL or LTR). This means that the 
cursor will jump when switching the language, but it will make life easier 
because you will easily know in which direction you're about to type.

On Mon, Oct 16, 2023 at 6:16 PM Andy Goryachev 
mailto:andy.goryac...@oracle.com>> wrote:
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.

More questions for you:

  1.  it looks like you are on Windows, and are you using (or have you seen) a 
fully localized version of Windows with all the UI set to RTL mode?
  2.  Have you seen any native applications that use the visual navigation 
model?

Getting back to the problem at hand: if we were to retain the backward 
compatibility in FX, we would need to fix the “visual” navigation.  FX uses the 
split caret which some users find confusing but we probably are stuck with it.  
If we were to assume that the “logical” navigation is a standard everyone is 
slowly converging to, then my fix for 
https://bugs.openjdk.org/browse/JDK-8296266 is the right one and we should 
declare a change in behavior.

What do you think?

P.S. I wonder if the logical navigation was chosen because of ease of 
implementation, or is there a deeper reason?

Re: [External] : Re: [jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Kevin Rushforth]

Thanks. To answer the one outstanding question from your earlier reply:

It would be a great future feature if we can somehow automatically 
remove the issues that are introduced in the same version.


Yes, it would. As of now, we don't have a robust way to do it,  but I'll 
give it some thought.


-- Kevin




On 10/17/2023 7:53 AM, Johan Vos wrote:

No, you are right.
All good, I approved.

- Johan

On Tue, Oct 17, 2023 at 4:50 PM Kevin Rushforth 
 wrote:


We need to exclude from the release notes any backport with a fix
version of 21.0.1 and an hgupdate-sync label. Those bugs were
fixed in 21 and are already in the release notes for 21.

Do you have an example where you think the JBS filter excluded
something it should not have?

-- Kevin


On 10/17/2023 7:43 AM, Johan Vos wrote:

Hi Kevin,

After a second look, I'm not sure about excluding the issues with
a hgupdate-sync label. From a previous mail, I understood that
those have to be removed in the release notes of jfx22, but from
the backports?

- Johan

On Tue, Oct 17, 2023 at 4:10 PM Kevin Rushforth 
wrote:

Release notes for JavaFX 21.0.1.

Notes to reviewers:

I used the following filter to pick the issues:

https://bugs.openjdk.org/issues/?filter=44663

The original filter, with the backport IDs, is here:

https://bugs.openjdk.org/issues/?filter=44662

As usual, I excluded test bugs, cleanup bugs, etc. I manually
excludes 4 additional bugs, one of which was a README change
(does not affect the product), and the other three were
introduced and fixed in the same release.

-

Commit messages:
 - 8317842: Create release notes for JavaFX 21.0.1

Changes: https://git.openjdk.org/jfx21u/pull/19/files
 Webrev:
https://webrevs.openjdk.org/?repo=jfx21u=19=00

  Issue: https://bugs.openjdk.org/browse/JDK-8317842
  Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx21u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git
pull/19/head:pull/19

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

Re: [jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Johan Vos]

No, you are right.
All good, I approved.

- Johan

On Tue, Oct 17, 2023 at 4:50 PM Kevin Rushforth 
wrote:

> We need to exclude from the release notes any backport with a fix version
> of 21.0.1 and an hgupdate-sync label. Those bugs were fixed in 21 and are
> already in the release notes for 21.
>
> Do you have an example where you think the JBS filter excluded something
> it should not have?
>
> -- Kevin
>
>
> On 10/17/2023 7:43 AM, Johan Vos wrote:
>
> Hi Kevin,
>
> After a second look, I'm not sure about excluding the issues with a
> hgupdate-sync label. From a previous mail, I understood that those have to
> be removed in the release notes of jfx22, but from the backports?
>
> - Johan
>
> On Tue, Oct 17, 2023 at 4:10 PM Kevin Rushforth  wrote:
>
>> Release notes for JavaFX 21.0.1.
>>
>> Notes to reviewers:
>>
>> I used the following filter to pick the issues:
>>
>> https://bugs.openjdk.org/issues/?filter=44663
>>
>> The original filter, with the backport IDs, is here:
>>
>> https://bugs.openjdk.org/issues/?filter=44662
>>
>> As usual, I excluded test bugs, cleanup bugs, etc. I manually excludes 4
>> additional bugs, one of which was a README change (does not affect the
>> product), and the other three were introduced and fixed in the same release.
>>
>> -
>>
>> Commit messages:
>>  - 8317842: Create release notes for JavaFX 21.0.1
>>
>> Changes: https://git.openjdk.org/jfx21u/pull/19/files
>>  Webrev: https://webrevs.openjdk.org/?repo=jfx21u=19=00
>>   Issue: https://bugs.openjdk.org/browse/JDK-8317842
>>   Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
>>   Patch: https://git.openjdk.org/jfx21u/pull/19.diff
>>   Fetch: git fetch https://git.openjdk.org/jfx21u.git
>> pull/19/head:pull/19
>>
>> PR: https://git.openjdk.org/jfx21u/pull/19
>>
>
>

Re: [jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Kevin Rushforth]

We need to exclude from the release notes any backport with a fix 
version of 21.0.1 and an hgupdate-sync label. Those bugs were fixed in 
21 and are already in the release notes for 21.


Do you have an example where you think the JBS filter excluded something 
it should not have?


-- Kevin


On 10/17/2023 7:43 AM, Johan Vos wrote:

Hi Kevin,

After a second look, I'm not sure about excluding the issues with a 
hgupdate-sync label. From a previous mail, I understood that those 
have to be removed in the release notes of jfx22, but from the backports?


- Johan

On Tue, Oct 17, 2023 at 4:10 PM Kevin Rushforth  wrote:

Release notes for JavaFX 21.0.1.

Notes to reviewers:

I used the following filter to pick the issues:

https://bugs.openjdk.org/issues/?filter=44663

The original filter, with the backport IDs, is here:

https://bugs.openjdk.org/issues/?filter=44662

As usual, I excluded test bugs, cleanup bugs, etc. I manually
excludes 4 additional bugs, one of which was a README change (does
not affect the product), and the other three were introduced and
fixed in the same release.

-

Commit messages:
 - 8317842: Create release notes for JavaFX 21.0.1

Changes: https://git.openjdk.org/jfx21u/pull/19/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx21u=19=00

  Issue: https://bugs.openjdk.org/browse/JDK-8317842
  Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx21u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git
pull/19/head:pull/19

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

JavaFX 21.0.1 tags pushed

[Kevin Rushforth]

There were no security fixes for the just-released October CPU, 
including JavaFX 21.0.1. I pushed the 21.0.1 tags to openjdk/jfx21u, 
including the 21.0.1-ga tag.


-- Kevin

Re: [jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Johan Vos]

Hi Kevin,

After a second look, I'm not sure about excluding the issues with a
hgupdate-sync label. From a previous mail, I understood that those have to
be removed in the release notes of jfx22, but from the backports?

- Johan

On Tue, Oct 17, 2023 at 4:10 PM Kevin Rushforth  wrote:

> Release notes for JavaFX 21.0.1.
>
> Notes to reviewers:
>
> I used the following filter to pick the issues:
>
> https://bugs.openjdk.org/issues/?filter=44663
>
> The original filter, with the backport IDs, is here:
>
> https://bugs.openjdk.org/issues/?filter=44662
>
> As usual, I excluded test bugs, cleanup bugs, etc. I manually excludes 4
> additional bugs, one of which was a README change (does not affect the
> product), and the other three were introduced and fixed in the same release.
>
> -
>
> Commit messages:
>  - 8317842: Create release notes for JavaFX 21.0.1
>
> Changes: https://git.openjdk.org/jfx21u/pull/19/files
>  Webrev: https://webrevs.openjdk.org/?repo=jfx21u=19=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8317842
>   Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.org/jfx21u/pull/19.diff
>   Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/19/head:pull/19
>
> PR: https://git.openjdk.org/jfx21u/pull/19
>

Re: RFR: 8316518 javafx.print.Paper getWidth / getHeight rounds values, causing errors.

[Andy Goryachev]

On Tue, 19 Sep 2023 11:56:39 GMT, Florian Kirmaier  
wrote:

> The Method javafx.print.getWidth and getHeight returns a double of points.
> But the values are always rounded to full integers. This causes especially 
> problems,
> with mm based Papers.
> 
> I asked in the mailing list, with the conclusion (me and John Hendrix) that 
> is best to just fix this behavior by removing the rounding.

I agree with John.  I can't think of the use case for the rounding.

-

PR Comment: https://git.openjdk.org/jfx/pull/1244#issuecomment-1766557869

Re: [jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Johan Vos]

Looks good, I'm double checking and will approve.
It would be a great future feature if we can somehow automatically remove
the issues that are introduced in the same version.

- Johan

Op di 17 okt 2023 om 16:10 schreef Kevin Rushforth :

> Release notes for JavaFX 21.0.1.
>
> Notes to reviewers:
>
> I used the following filter to pick the issues:
>
> https://bugs.openjdk.org/issues/?filter=44663
>
> The original filter, with the backport IDs, is here:
>
> https://bugs.openjdk.org/issues/?filter=44662
>
> As usual, I excluded test bugs, cleanup bugs, etc. I manually excludes 4
> additional bugs, one of which was a README change (does not affect the
> product), and the other three were introduced and fixed in the same release.
>
> -
>
> Commit messages:
>  - 8317842: Create release notes for JavaFX 21.0.1
>
> Changes: https://git.openjdk.org/jfx21u/pull/19/files
>  Webrev: https://webrevs.openjdk.org/?repo=jfx21u=19=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8317842
>   Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.org/jfx21u/pull/19.diff
>   Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/19/head:pull/19
>
> PR: https://git.openjdk.org/jfx21u/pull/19
>

Re: RFR: 8318204: Use new EventTarget methods in ListenerHelper

[Andy Goryachev]

On Tue, 17 Oct 2023 04:46:12 GMT, Michael Strauß  wrote:

> As of OpenJFX 21, `EventTarget` has methods to add and remove event listeners.
> The `instanceof` checks in `com.sun.javafx.scene.control.ListenerHelper` 
> should be removed and replaced by a simple call to the respective interface 
> method.

 looks good, thanks!

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1262#pullrequestreview-1682519588

Re: RFR: 8318204: Use new EventTarget methods in ListenerHelper

[Andy Goryachev]

On Tue, 17 Oct 2023 11:04:03 GMT, Nir Lisker  wrote:

> By the way, isn't `IDisconnectable` just a `Subscription` with less gadgets?

it's a functional interface, so no gadgets at all.

-

PR Comment: https://git.openjdk.org/jfx/pull/1262#issuecomment-1766533941

[jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Kevin Rushforth]

Release notes for JavaFX 21.0.1.

Notes to reviewers:

I used the following filter to pick the issues:

https://bugs.openjdk.org/issues/?filter=44663

The original filter, with the backport IDs, is here:

https://bugs.openjdk.org/issues/?filter=44662

As usual, I excluded test bugs, cleanup bugs, etc. I manually excludes 4 
additional bugs, one of which was a README change (does not affect the 
product), and the other three were introduced and fixed in the same release.

-

Commit messages:
 - 8317842: Create release notes for JavaFX 21.0.1

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

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

Re: [jfx21u] RFR: 8317842: Create release notes for JavaFX 21.0.1

[Kevin Rushforth]

On Tue, 10 Oct 2023 23:24:05 GMT, Kevin Rushforth  wrote:

> Release notes for JavaFX 21.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=44663
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=44662
> 
> As usual, I excluded test bugs, cleanup bugs, etc. I manually excludes 4 
> additional bugs, one of which was a README change (does not affect the 
> product), and the other three were introduced and fixed in the same release.

Reviewers: @johanvos @abhinayagarwal

There are no security fixes this time, so this PR is ready for final review.

-

PR Comment: https://git.openjdk.org/jfx21u/pull/19#issuecomment-1756458351
PR Comment: https://git.openjdk.org/jfx21u/pull/19#issuecomment-1766462373

Re: RFR: 8313321 : Set minimum python version in WebKit cmake scripts [v2]

[Kevin Rushforth]

On Tue, 5 Sep 2023 07:17:57 GMT, Johan Vos  wrote:

>> Hima Bindu Meda has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   change minimum version for mac to 3.6
>
> I think that should be ok for now, and I don't want to make the PR more 
> complex as this is a good step, but I believe we need more strict checks:
> * also check the maximum version for python
> * check versions of perl,ruby
> Unfortunately, building webkit is extremely brittle and requiring exact 
> versions is decreasing the chances on failures at build or runtime.

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

-

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

Re: [External] : Re: [Request for Comments] Behavior / InputMap

[Pedro Duque Vieira]

Yes Input Map would be a welcome addition.

--

Talking about the Skin discussion:
Right now, I think Skins do both the Controller and View part of a Control,
making it really difficult to replace, extend, etc a Control's Skin...

I would have to think much more about this but I could see some kind of
View class that Skin references. In this View class, we would define just
how the control represents itself visually, that is, visual nodes, layout
and animations. The Skin would take care of handling events from the View
and updating the Model appropriately (the Model being the part that
developers already interact with in a JavaFX Control - the class that
extends Control), that is, just being a kind of Controller.

Main purpose would be to make it as easy as possible for developers to
update a Control's visuals (layout, animation, etc). Right now it's a
really hard task and 99% of developers just prefer to create a whole new
control altogether rather than replace its Skin (even if they just want to
slightly tweak an existing control's visuals).
In this case developers would replace the "View" class with their own
implementation, adding new animations, new visuals, etc... This would allow
for a much easier customization of visuals while still maintaining about
the same code in the application (the application code being everything
else except the Skins' code).
This would also allow a new echo system of Skin libraries to start to
appear. These libraries would be interchangeable and would allow developers
to easily update and enhance the visuals of their apps by setting a skin
library.
This is what the library I've created FXSkins does (
https://github.com/dukke/FXSkins), that is, it allows a developer to
enhance their app's visuals very easily without changing one line of code
in their app. The difference is that if JavaFX Skins architecture were
defined as I mentioned above it would be much easier for me to develop
FXSkins and there would probably be more libraries like this, created by
other developers.

Thanks Andy! Kind regards,


On Mon, Oct 16, 2023 at 6:51 PM Andy Goryachev 
wrote:

> Thank you for clarification!
>
>
>
> I just want to mention that here we are straying into what looks like a
> parallel discussion about skins (nothing wrong about it!).
>
>
>
> 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.
>
>
>
> Could you please expand upon this?  What parts should skins be split into?
>
>
>
> As it currently stands, Skins have two responsibilities - visual
> representation (the View in MVC paradigm) and handling of events, currently
> represented by the private behavior implementation.  In some sense,
> behaviors and skins are tightly coupled - it would be hard, in my opinion,
> to separate them without introducing large public API surface and
> consequently solidifying certain aspects of one particular implementation.
>
>
>
> As far as I can tell, the input map proposal addresses the low hanging
> fruit of simple customization like your case of unregistering all key
> mappings from the ScrollPane.  It is certainly not a call to a major
> redesign.
>
>
>
> Cheers,
>
> -andy
>
>
>
> *From: *Pedro Duque Vieira 
> *Date: *Sunday, October 15, 2023 at 05:11
> *To: *Andy Goryachev 
> *Cc: *openjfx-dev@openjdk.org 
> *Subject: *[External] : Re: [Request for Comments] Behavior / InputMap
>
> 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 

Re: RFR: 8301302: Platform preferences API [v15]

[Pedro Duque Vieira]

Yes please keep this open.

Having adequate Theme development support would be great and I think
wouldn't require much effort (right now custom theme support in JavaFX is
faulty IMO).
Looking forward to the StyleTheme API so you can define multiple
stylesheets as user agent stylesheets.

(sorry to be annoying about this but as a long time custom theme developer
I've been looking forward to this for ages)



> >> Please read [this document](
> https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an
> introduction to the Platform Preferences API, and how it interacts with the
> proposed style theme and stage appearance features.
> >
> > Michael Strau? has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> >   Handle key removals


Let's keep this open.


-- 
Pedro Duque Vieira - https://www.pixelduke.com

RFR: 8205067: Resizing window with TextField hides text value

[Karthik P K]

Because of a missing conditional check in the `updateTextPos()`,  the 
`textTranslateX` value was not getting updated when TextField size was changed 
as a result of resizing window.

Updated the CENTER and LEFT cases in the `updateTextPos()` method to fix the 
issue.

The fix can be validated using MonkeyTester.
Steps to select TextField option in Monkey Tester.

- Open the MonkeyTester app and select TextField from the left option pane.
- Select Long from Text selection option and TOP_LEFT from Alignment dropdown.
- After above step, follow the steps given in the bug to validate the fix in 
monkey tester.

-

Commit messages:
 - Fix textfield resizing issue

Changes: https://git.openjdk.org/jfx/pull/1263/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1263=00
  Issue: https://bugs.openjdk.org/browse/JDK-8205067
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1263.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1263/head:pull/1263

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

Re: RFR: 8316419: [macos] Setting X/Y makes Stage maximization not work before show

[Lukasz Kostyra]

On Thu, 12 Oct 2023 05:52:04 GMT, Martin Fox  wrote:

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

Looks good on first sight. I'll verify it soon on all platforms.

-

PR Review: https://git.openjdk.org/jfx/pull/1258#pullrequestreview-1682078641

Re: RFR: 8318204: Use new EventTarget methods in ListenerHelper

[Nir Lisker]

On Tue, 17 Oct 2023 04:46:12 GMT, Michael Strauß  wrote:

> As of OpenJFX 21, `EventTarget` has methods to add and remove event listeners.
> The `instanceof` checks in `com.sun.javafx.scene.control.ListenerHelper` 
> should be removed and replaced by a simple call to the respective interface 
> method.

Looks good.

By the way, isn't `IDisconnectable` just a `Subscription` with less gadgets?

-

Marked as reviewed by nlisker (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1262#pullrequestreview-1682025487

Re: [External] : Re: Question: bidi navigation

[Nir Lisker]

I have just tested on Win10: Notepad, Wordpad, MSWord 2021, Discord
desktop, WhatsApp desktop, Opera, Eclipse, Gimp 2, Audacity 2.1.3, and MS
VisualStudio 2022 all use logical. Edge uses logical in text areas and text
fields, but visual in the address bar (seems like a bug, but you can't have
spaces in web addresses anyway). I don't remember ever using a visual
navigation application, maybe it was very long ago. If there ever was a
decision there, it was made long ago, at least on Windows.

It's very important to show the cursor direction because it resolves
ambiguities. It's available in most applications.

My Windows UI is in standard English LTR. I just have an RTL language
installed.

Logical navigation is a bit easier to work with I think. The behavior at
the edge of a word that changes the direction can be surprising (see the
ambiguities above), but that can be helped with the cursor direction
indication. If we can do a custom implementation, I would go a step further
and actually resolve the position ambiguities by positioning the cursor in
accordance with the selected insertion method (RTL or LTR). This means that
the cursor will jump when switching the language, but it will make life
easier because you will easily know in which direction you're about to type.

On Mon, Oct 16, 2023 at 6:16 PM Andy Goryachev 
wrote:

> 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.
>
>
>
> More questions for you:
>
>1. it looks like you are on Windows, and are you using (or have you
>seen) a fully localized version of Windows with all the UI set to RTL mode?
>2. Have you seen any native applications that use the visual
>navigation model?
>
>
>
> Getting back to the problem at hand: if we were to retain the backward
> compatibility in FX, we would need to fix the “visual” navigation.  FX uses
> the split caret which some users find confusing but we probably are stuck
> with it.  If we were to assume that the “logical” navigation is a standard
> everyone is slowly converging to, then my fix for
> https://bugs.openjdk.org/browse/JDK-8296266 is the right one and we
> should declare a change in behavior.
>
>
>
> What do you think?
>
>
>
> P.S. I wonder if the logical navigation was chosen because of ease of
> implementation, or is there a deeper reason?
>
>
>
>
>
>
>
>
>
> *From: *Nir Lisker 
> *Date: *Monday, October 16, 2023 at 04:52
> *To: *Andy Goryachev 
> *Cc: *openjfx-dev@openjdk.org 
> *Subject: *[External] : Re: Question: bidi navigation
>
> 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.
>
>
>
> Examples
>
> In a left-aligned paragraph, pressing the right arrow will move the cursor
> (|) like this:
>
> |ab אבג cd
>
> a|b אבג cd
>
> ab| אבג cd
>
> ab |אבג cd  OR ab אבג| cd(there is ambiguity because the space
> character can be both RTL or LTR)
>
> ab א|בג cd
>
> ab אב|ג cd
>
> ab אבג| cd  OR ab |אבג cd
>
> ab אבג |cd
>
> ab אבג c|d
>
> ab אבג cd|
>
>
>
> 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 

Re: RFR: 8316518 javafx.print.Paper getWidth / getHeight rounds values, causing errors.

[Florian Kirmaier]

On Tue, 19 Sep 2023 11:56:39 GMT, Florian Kirmaier  
wrote:

> The Method javafx.print.getWidth and getHeight returns a double of points.
> But the values are always rounded to full integers. This causes especially 
> problems,
> with mm based Papers.
> 
> I asked in the mailing list, with the conclusion (me and John Hendrix) that 
> is best to just fix this behavior by removing the rounding.

It would be nice if something could be decided here.

Another option would be, to rename the current method to something like 
getWidthInPoints() which then can be used internally. But the old - now correct 
methods - can be exposed to applications, returning correct values.

But I would still prefer to just fix it, returning the correct values. And if 
it turns out, at some part we need it in points, then we just have to convert 
it to this location. I still don't see how the current state doesn't lead to 
various incorrect behaviors.

-

PR Comment: https://git.openjdk.org/jfx/pull/1244#issuecomment-1766021174

CDI into Custom Controls

[Dirk Lemmermann]

Hi all,

As mentioned to Kevin and Johan at Devoxx: I was wondering how hard it would be 
to add CDI support for custom controls that are added via FXML. At the moment 
we always have to set various fields on custom controls inside the controller 
class. It would be great if this could be streamlined so that a context can be 
used for the controls. 

Dirk

Re: [External] : Re: [Request for Comments] Behavior / InputMap

[John Hendrikx]

Replying here, for some reason I did not receive your original message 
Martin.


In reply to Martin's comments:

Thanks for looking into the event handling system already; I'm certain 
there are some solutions here that can keep internals and user event 
handlers seperated, and you found a few alternatives that I overlooked 
(I admittedly did not look that deep, just assumed it would be possible 
or could be changed to make it possible).


I'm not sure about making EventHandlerManager public, although that 
could certainly help to address the problem; I think the API we have 
(addEventHandler/removeEventHandler) ought to be sufficient for users to 
manage their handlers; it's just that FX handlers need to be called last 
so the user has a decent change of overriding behavior.


As event handlers can get added/removed at any time by changing the Skin 
or Behavior, even then the order of whether internal FX handlers run 
first or last should not change (and I think we shouldn't burden the 
user with having to manage the order if it changes).


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.


I also like that; only Control's would need it, so it wouldn't be a 
burden for all Nodes.


--

In reply to Andy's question:

The problem we're trying to address is that user event handlers are 
currently somewhat unpredictable as to when they get executed; if added 
before the Skin is installed, they will be first and will be more 
powerful as they can consume events before the behavior handlers can get 
to them. If installed after the skin (or if they're ever need to be 
refreshed by adding/removing them during operation of your control) then 
they will end up AFTER the skin event handlers and things that worked 
before now don't anymore.


On top of that, even if you do install your event handler first, but it 
is of a more general type (ie. KeyEvent.ANY vs KeyEvent.KEY_PRESSED), 
then the PRESSED handler gets executed first regardless; the ANY handler 
will only receive a consumed event...  What we're saying is that user 
handlers should be considered more important than the default FX 
internal behaviorial handlers; those should be triggered if no user 
handler is interested in the event.


The problems that this addresses are:

- It will be possible to do a lot of the things that people would like 
to change the Behavior for
- Event handler order will no longer depend on circumstances like when 
was the Skin/Behavior installed or changed; having a predictable and 
explainable system is very important


As I said before, the fact that the Skins/Behaviors are mixing their 
concerns directly with user concerns (by manipulating the same Control 
the user is manipulating) is a bit iffy; for listeners (primarily used 
by Skins) this is fairly safe as they always all get called and no 
"state" changes (although see bugs in the old value handling for change 
listeners), but for event handlers installed by behaviors, once an event 
is consumed, a user event handler can't do anything anymore...


--John


On 16/10/2023 20:31, Andy Goryachev wrote:


Martin:

What would be the use case for creating a public EventHandlerManager?

In general, what is the problem we are trying to address that is 
impossible to solve using the existing machinery?


Thank you

-andy

*From: *Martin Fox 
*Date: *Saturday, October 14, 2023 at 14:48
*To: *John Hendrikx 
*Cc: *Andy Goryachev , 
openjfx-dev@openjdk.org 

*Subject: *Re: [External] : Re: [Request for Comments] Behavior / InputMap

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 

Re: RFR: 8318204: Use new EventTarget methods in ListenerHelper

[John Hendrikx]

On Tue, 17 Oct 2023 04:46:12 GMT, Michael Strauß  wrote:

> As of OpenJFX 21, `EventTarget` has methods to add and remove event listeners.
> The `instanceof` checks in `com.sun.javafx.scene.control.ListenerHelper` 
> should be removed and replaced by a simple call to the respective interface 
> method.

Nice little clean-up!

-

Marked as reviewed by jhendrikx (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1262#pullrequestreview-1681546795

Withdrawn: 8090267: JFXPanel Input Problem

[duke]

On Tue, 4 Jul 2023 05:54:54 GMT, Prasanta Sadhukhan  
wrote:

> When Japanse (IME on) is inputted to the TextFIeld, which is on JFXPanel, 
> small window for inputting appears on top-left side of screen
> 
> ![image](https://github.com/openjdk/jfx/assets/43534309/65833d59-528e-4087-9992-9f86b8b8c47f)
> 
> For swing-interop case, WmImeStartComposition starts composition in native 
> ImmSetCompositionWindow window as "m_useNativeCompWindow" below is true for FX
> https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3957
> 
> m_useNativeCompWindow is true because during 
> sun.awt.im.InputContext#focusGained() calls activateInputMethod which calls 
> WInputMethod.activate() which calls haveActiveClient() which checks for
> clientComponent.getInputMethodRequests().
> Now, in JFXPanel, getInputMethodRequests() returns null as setEmbeddedScene() 
> is not called yet.
> Since getInputMethodRequests() returns null, haveActiveClient() is false 
> which calls enableNativeIME() with 1 [thereby native composition window is 
> enabled]
> https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java#L316
> 
> Proposed fix is to ensure there is an active client "initially" so that 
> enableNativeIME() is called with 0 and no native compostion window is shown.
> getInputMethodRequests() is called in setEmbeddedScene() so as to make sure 
> getInputMethodRequest() is initialised to correct 
> "InputMethodSupport.InputMethodRequestsAdapter.fxRequests" object and not 
> NULL.
> 
> AFter fix
> ![image](https://github.com/openjdk/jfx/assets/43534309/ec3d8343-9295-4950-885b-f9983b9b017a)

This pull request has been closed without being integrated.

-

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