From john.hendrikx at gmail.com Thu Feb 1 00:27:28 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Feb 2024 01:27:28 +0100 Subject: Binding properties to constant values In-Reply-To: References: <1bed200c-e286-d9a1-397a-66a0abbfd63e@gmail.com> Message-ID: <677138a2-f597-8823-8777-2e6cc9ad6fcc@gmail.com> Hi Nir, On 31/01/2024 22:36, Nir Lisker wrote: > > I would wait with the ramifications of setting competing values from > different origins until the question of precedence is answered. > Perhaps emitting warnings is better, though I can see some scenarios > in which they will be annoying. > > The way I see the order: > 1. Setting from code should always take precedence (including the > current bindings over setter order of course). > 2. INLINE origin (via setStyle). > 3. Stylesheets according to their StyleOrigin as specified by the > non-javafx css specifications [3]: AUTHOR > USER > USER_AGENT (see > below for INLINE). > > 2 and 3 are already (more or less) specified in JavaFX's?css as far as > I can see. However, 1 is not css, hence I don't think StyleOrigin > should be applicable here even. Even more, 2 isn't really css either, > it mimics html tags and shouldn't count as a css StyleOrigin in my > opinion. StyleOrigin is more of an internal thing that got exposed, so I wouldn't worry too much about what is CSS and what isn't.? I agree that the above order would make more sense. I suspect the reasoning why it wasn't done is that setters are getting called to set up defaults, which if they by default override all, would conflict with style sheets set by the user. > Note also that a Stylesheet can set its origin [4], even to INLINE, so > it takes precedence over java property setters and conflicts with > 'setStyle' "real" INLINE. I'm not sure if this is a bug because the > javafx css specs say that "Inline styles are specified via the Node > setStyle AP". The CSS API is weird. It has many seemingly useful and public bits, but they are isolated from the rest of FX. Take StyleSheet for example.? You can convert them (using File to File) from regular to binary, then load a binary file and get a StyleSheet reference with a public API.? You can then change its origin.? However, it stops there.? You can't feed such a modified StyleSheet to FX via any public API. It almost looks like a lot of the CSS public API is there for a possibly previously integrated Scene Builder type application, which was later split off. > > So, if I were to able to do anything I wanted, I would have restricted > Stylesheets to the options in 3, remove INLINE from a public > perspective and apply it only behind the scenes to 'setStyle' calls, > and stop treating java settings in the css hierarchy (which means > removing the USER StyleOrigin from them). Obviously that breaks a lot > of code, but this behavior would be my general goal. As for how to > represent it, maybe a constant can be added to StyleOrigin to > represent java code settings, but that's not a real css origin. I > guess we could call INLINE and the hypothetical JAVA constants > "pseudo-origins", because they don't apply to stylesheets, and are > only used internally. Or just don't check StyleOrigin when the value > is set from java. There are probably more ways. StyleOrigin really is only there for the CSS engine to distinguish if it can replace a value or not with something else depending on precedence. It probably shouldn't have been public at all, aside from the fact that StyleableProperty being an interface forced it to be public. Oddly enough, the StyleableProperty interface is public, but it is again never returned anywhere (didn't check extensively). So you can't actually do "label.textAlignment().applyStyle( ... )" even though text alignment is a styleable property. If `textAlignment()` did return a StyleableProperty, then you could do `label.textAlignment().applyStyle(StyleOrigin.CODE, value)` for a permanent override of the value which the CSS engine will respect. > > I also wonder if StyleOrigin should implement Comparable for > the?precedence calculations of stylesheets. It sort of already does, they are defined in the order of least to highest precedence, so an integer comparator on its ordinal can be used. --John From mfox at openjdk.org Thu Feb 1 00:53:05 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 1 Feb 2024 00:53:05 GMT Subject: RFR: 8320912: IME should commit on focus change In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 21:49:32 GMT, Andy Goryachev wrote: >>> notice how the underline under ? is still there in the first text field. >> >> That behavior surprised me the first time I saw it but I eventually figured out that it's a feature, not a bug. If you switch back to the original window by clicking on the title bar you should pick up composition exactly where you left off e.g. the IM window should appear showing the same candidates it was showing earlier. That's the way native Mac apps like TextEdit work (most of the time, every now and then clicking on the title bar commits the text). >> >> On a technical level the focusOwner for the Scene isn't changing so JavaFX doesn't think there's any reason to finish composition. And apparently the OS agrees and relies on Glass to retain enough state that it can pick up where it left off. > >> e.g. the IM window should appear showing the same candidates it was showing earlier. > > Thank you for clarification! > The behavior is different, let me explain: > > using the MonkeyTester, open TextField page and the Native-to-ascii tool (Tools -> Native-to-ascii). > 1. switch to Japanese input > 2. type "su" into the text field in the main window > 3. click on a "native" text area in the other window > 4. type "zu" in the native window > 5. **unexpectedly**, the text field in the main window shows the symbol still underlined > 6. click on the main window title to focus back on the original text field. type "zuki" > EXPECTED: > - the text field should contain ?? > ACTUAL: > - the text is ???, the last two symbols underlined: > > ![Screenshot 2024-01-31 at 13 43 41](https://github.com/openjdk/jfx/assets/107069028/60eac972-252d-40b0-b8ed-76dcb6672bac) > > It looks like the text was indeed committed (despite it being displayed underlined at step 5), and getting back to it from another window does not restore the IME to the state expected at the step 2. > > Interestingly, if instead of going to a different window of the same javafx application, the user clicks elsewhere on some other application window and then goes back to javafx by clicking on the title bar, the IME window is indeed gets back to the expected state. @andy-goryachev-oracle You're right, I missed a detail and ended up testing something else. I did some more testing and it looks like the JavaFX behavior is consistent with other apps like TextEdit. If you move focus away from a window in the middle of IM composition the composed text is left underlined. If you restore focus to that window *before* typing anything the IM will pick up where it left off. But if you type something in another window before restoring focus the IM will commit the text the moment focus returns. This seems to be driven by the OS since TextEdit behaves the same way. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1920268535 From aoqi at openjdk.org Thu Feb 1 06:40:19 2024 From: aoqi at openjdk.org (Ao Qi) Date: Thu, 1 Feb 2024 06:40:19 GMT Subject: RFR: 8325093: Update CONTRIBUTING.md for build jdk version Message-ID: [JDK-8297068](https://bugs.openjdk.org/browse/JDK-8297068) updated boot JDK to 19.0.1 from 18.0.2, and [JDK-8321434](https://bugs.openjdk.org/browse/JDK-8321434) updated boot JDK to 21.0.1. `CONTRIBUTING.md` should be updated correspondingly. ------------- Commit messages: - 8325093: Update CONTRIBUTING.md for build jdk version Changes: https://git.openjdk.org/jfx/pull/1357/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325093 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1357.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1357/head:pull/1357 PR: https://git.openjdk.org/jfx/pull/1357 From kpk at openjdk.org Thu Feb 1 08:11:09 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 1 Feb 2024 08:11:09 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v7] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 10:24:20 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix issue with multiline text I will work on the inline node issue and the issue in Rich text area. The rich text area issue is basically because of the repeated text node BOLD. Im not really sure if the increased scale is causing any issue, I will get into it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1920730601 From kpk at openjdk.org Thu Feb 1 08:11:10 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 1 Feb 2024 08:11:10 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v7] In-Reply-To: References: Message-ID: <70JX8j7Wilm1DI1efl7Sb5Yowxqi3kFHX5wMk_rPVcI=.ac3534ce-b235-4fcf-acac-5c57d6a37187@github.com> On Wed, 31 Jan 2024 21:09:53 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix issue with multiline text > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 513: > >> 511: if ((x > run.getWidth() && (!isMultiRunText || run.getStart() == curRunStart)) || textWidthPrevLine > 0) { >> 512: getBounds(run.getTextSpan(), textBounds); >> 513: x -= (runs[0].getLocation().x - textBounds.getMinX()); > > suggestion: we are still in the for loop, so perhaps it makes sense to extract > `(runs[0].getLocation().x - textBounds.getMinX());` > to a variable outside of the loop The idea is that outside the loop we don't know if we need to subtract the textBound min x value and the starting location of the first run or not. That is why this is present inside the loop. Once this is done we are breaking out of the loop so this will not get called multiple times. Let me know if you have any suggestions. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1473962144 From javafx at ivoryemr.co.za Thu Feb 1 08:42:37 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Thu, 01 Feb 2024 10:42:37 +0200 Subject: Integrated: 8324658: Allow animation play/start/stop/pause methods to be called on any thread In-Reply-To: References: Message-ID: A big THANK YOU to everybody that was part of this process. It's very much appreciated ! Regards Jurgen On Tue, 30 Jan 2024 11:27:44 +0200, Nir Lisker wrote: > On Fri, 26 Jan 2024 23:59:50 GMT, Nir Lisker wrote: > >> Added a utility method to run code on the FX thread if it's not >> already, and changed the animation methods to use it. > > This pull request has now been integrated. > > Changeset: c5ab220b > Author: Nir Lisker > URL: > https://git.openjdk.org/jfx/commit/c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f > Stats: 422 lines in 7 files changed: 225 ins; 148 del; 49 mod > > 8324658: Allow animation play/start/stop/pause methods to be called on > any thread > > Reviewed-by: kcr, jpereda > > ------------- > > PR: https://git.openjdk.org/jfx/pull/1352 From kpk at openjdk.org Thu Feb 1 09:20:35 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 1 Feb 2024 09:20:35 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v8] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Code review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/52ee61cc..3012fae8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=06-07 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From arapte at openjdk.org Thu Feb 1 10:24:07 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Feb 2024 10:24:07 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3] In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 21:29:31 GMT, Laurent Bourg?s wrote: >> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright years of modified files + fixed comments in DMarlinPrismUtils tests/system/src/test/java/test/com/sun/marlin/Scale0Test.java line 253: > 251: } > 252: > 253: } I had few comments about the test like: 1. MyApp class can be removed 2. if (button instanceof Labeled) can be removed 3. preparePane() method could be shortened. 4. Variables leftPane and slider could be local 5. final keyword could be removed from some local variables. 6. Rename the test file and test function. I made these changes locally and sharing the file as attached. [ScaleX0Test.zip](https://github.com/openjdk/jfx/files/14123536/ScaleX0Test.zip) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1474190840 From arapte at openjdk.org Thu Feb 1 10:36:12 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Feb 2024 10:36:12 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v2] In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 09:44:04 GMT, Karthik P K wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed test package > > modules/javafx.graphics/src/main/java/com/sun/marlin/DPathConsumer2D.java line 2: > >> 1: /* >> 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved. > > Shouldn't it be 2007, 2024? In general it is not required to update the copyright year along with the fix, though it is not a hard rule. We update the years for all files before release. But as you are modifying please change this one to 24. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1474210526 From arapte at openjdk.org Thu Feb 1 10:39:08 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Feb 2024 10:39:08 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3] In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 21:29:31 GMT, Laurent Bourg?s wrote: >> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright years of modified files + fixed comments in DMarlinPrismUtils - Provided a few comments in test, and - Copyright year needs to be updated in [modules/javafx.graphics/src/main/java/com/sun/marlin/DPathConsumer2D.java](https://github.com/openjdk/jfx/pull/1348/files/251d1d61534eafbfa59165a348aa02e47a0242bd#diff-5b6489e7b2e4a135ca5aa33367dd1cc7e704feb12cabed7259256603be13488c) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1921014234 From r.lichtenberger at gmail.com Thu Feb 1 12:00:32 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 1 Feb 2024 13:00:32 +0100 Subject: CSS Performance regression inTableColumnHeader.resizeColumnToFitContent Message-ID: Hi, We are seeing degraded performance in our production application concerning the "fit to content" function of TableViews. I've developed a little benchmark program that can be found at https://gist.github.com/effad/9eebee0c1e86a8e605cb55ced9485dd4 Here's the last lines of data from runs against different JavaFX versions: JFX 17.0.10+2 average run time: 848 JFX 18.0.1+2 average run time: 839 JFX 19.0.2+1 average run time: 1113 JFX 20.0.2+3 average run time: 1656 JFX 21.0.2+5 average run time: 2460 17 and 18 are almost the same. The performance penalty of 19 most likely is due to (my own) PR in https://github.com/openjdk/jfx/pull/757, which put's the cell used to measure the needed width of the column into a row. The penalties from 19 to 20 and 20 to 21 however are worse than that. To investigate further I let the benchmark run (with no warmup, just 3 iterations and only 5000 rows) in the profiler Visual VM 2.1.7. Looking at _the_ hotspot of the execution I can see that javafx.scene.CssStyleHelper.transitionToState is consuming most of the time. And I can see that this method is called: ~ 30.000 times in JFX 18 ~ 45.000 times in JFX 19 (which is 3 iterations * 5000 rows more than in JFX 18, as expected since we have an additional row whose css needs to be applied) ~ 105.000 times in JFX 20 ~ 105.000 times in JFX 21 In looking at my changes for PR 757, I noticed that there are calls to cell.updateTableColumn(tc) and cell.updateTableView(tv) that need not be within the loop iterating over the rows. When putting these two lines before the loop, I was able to measure: JFX 23-internal+0-2024-02-01-061822 average run time: 1119 which would be roughly at the performance lebel of JFX 19 again. Interestingly, when profiling with this optimization I still get 105k calls to transitionToState, but they seem to be much faster. So I see two issues here: a) A general CSS-related performance degradation b) A potential to optimize resizeColumnToFitContent() Is it ok to open two issues for that and provide a PR for b)? I have no idea what to do about a), maybe someone with more experience in the CSS stuff can look at it? Thanks, Robert From arapte at openjdk.org Thu Feb 1 12:12:11 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Feb 2024 12:12:11 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:13:09 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint > -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomSkin extends Skin { > public MyCustomSkin(C skinnable, boolean someFlag) { ... } > } > > Now if we would change the skin of the `PopupControl` two times like this: > > popup.setSkin(new MyCustomSkin(popup, true)); > popup.setSkin(new MyCustomSkin(popup, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. > > This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) @Maran23 This is ready for integration. If you were waiting for me. Thanks, It looks good, I don't have any comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1331#issuecomment-1921183306 From mhanl at openjdk.org Thu Feb 1 14:13:11 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 1 Feb 2024 14:13:11 GMT Subject: Integrated: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:13:09 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin when it is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install listener but is then rejected when setting it due to the `skinProperty` class constraint > -> `PopupControl` is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomSkin extends Skin { > public MyCustomSkin(C skinnable, boolean someFlag) { ... } > } > > Now if we would change the skin of the `PopupControl` two times like this: > > popup.setSkin(new MyCustomSkin(popup, true)); > popup.setSkin(new MyCustomSkin(popup, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. > > This is the same issue and fix as done for `Control` in [JDK-8276056](https://bugs.openjdk.org/browse/JDK-8276056) (PR: https://github.com/openjdk/jfx/pull/806) This pull request has now been integrated. Changeset: aac2df16 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/aac2df168d524f97d663de6776962773702b360c Stats: 42 lines in 2 files changed: 28 ins; 12 del; 2 mod 8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1331 From mhanl at openjdk.org Thu Feb 1 14:13:10 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 1 Feb 2024 14:13:10 GMT Subject: RFR: JDK-8323615: PopupControl.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 12:09:36 GMT, Ambarish Rapte wrote: > @Maran23 This is ready for integration. If you were waiting for me. Thanks, It looks good, I don't have any comments. Thank you for checking as well! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1331#issuecomment-1921417204 From john.hendrikx at gmail.com Thu Feb 1 15:53:05 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Feb 2024 16:53:05 +0100 Subject: CSS Performance regression inTableColumnHeader.resizeColumnToFitContent In-Reply-To: References: Message-ID: On 01/02/2024 13:00, Robert Lichtenberger wrote: > Hi, > > We are seeing degraded performance in our production application > concerning the "fit to content" function of TableViews. > > I've developed a little benchmark program that can be found at > https://gist.github.com/effad/9eebee0c1e86a8e605cb55ced9485dd4 > > Here's the last lines of data from runs against different JavaFX > versions: > > JFX 17.0.10+2 average run time: 848 > JFX 18.0.1+2 average run time: 839 > JFX 19.0.2+1 average run time: 1113 > JFX 20.0.2+3 average run time: 1656 > JFX 21.0.2+5 average run time: 2460 > > 17 and 18 are almost the same. > > The performance penalty of 19 most likely is due to (my own) PR in > https://github.com/openjdk/jfx/pull/757, which put's the cell used to > measure the needed width of the column into a row. > > The penalties from 19 to 20 and 20 to 21 however are worse than that. > > > To investigate further I let the benchmark run (with no warmup, just 3 > iterations and only 5000 rows) in the profiler Visual VM 2.1.7. > Looking at _the_ hotspot of the execution I can see that > javafx.scene.CssStyleHelper.transitionToState is consuming most of the > time. And I can see that this method is called: > > ~ 30.000 times in JFX 18 > ~ 45.000 times in JFX 19 (which is 3 iterations * 5000 rows more than > in JFX 18, as expected since we have an additional row whose css needs > to be applied) > ~ 105.000 times in JFX 20 > ~ 105.000 times in JFX 21 > > > In looking at my changes for PR 757, I noticed that there are calls to > cell.updateTableColumn(tc) and cell.updateTableView(tv) that need not > be within the loop iterating over the rows. When putting these two > lines before the loop, I was able to measure: > > JFX 23-internal+0-2024-02-01-061822 average run time: 1119 > > which would be roughly at the performance lebel of JFX 19 again. > > Interestingly, when profiling with this optimization I still get 105k > calls to transitionToState, but they seem to be much faster. Is it still a CSS performance degradation then?? I mean, it's the same speed, and the number of calls should be irrelevant? However, if you want to narrow it down further (perhaps there is more performance to be gained), you could run your tests against the early access builds.? You may be able to find a set of 10-20 isolated commits that could have led to the introduction of the extra 60.000 calls.? For example, check if the problem is present in 20-ea+1 up to 20-ea-19, 20, 20.0.1 and 20.0.2 (early access versions available are 1, 2, 3, 4, 6, 7, 9, 11, 19), see here: https://mvnrepository.com/artifact/org.openjfx/javafx-base I checked the recent changes I did for CSS: * CSS performance regression up to 10x (https://bugs.openjdk.org/browse/JDK-8322795) * Quadratic layout time with nested nodes and pseudo-class in style sheet (https://bugs.openjdk.org/browse/JDK-8199216) * Public API in javafx.css.Match should not return private API class PseudoClassState (https://bugs.openjdk.org/browse/JDK-8304959) * Region#padding property rendering error (https://bugs.openjdk.org/browse/JDK-8245919) However, none of those were present in JavaFX 20. --John From kevin.rushforth at oracle.com Thu Feb 1 16:05:31 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 1 Feb 2024 08:05:31 -0800 Subject: JavaFX 22 is in Rampdown Phase Two (RDP2) Message-ID: <25f4bc24-4d7b-4487-8d94-ef37fa885410@oracle.com> To: JavaFX Developers As a reminder, JavaFX 22 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed during RDP2. Explicit approval is needed for all bug fixes and enhancements (except for doc and test fixes) to go in to the jfx22 branch [2]. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in JavaFX 22. We need to be extremely careful about including anything that introduces risk. We will use the same rules for RDP2 that the JDK uses [3], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 22 release. As an obvious choice, derived from the JBS fix version, we will use "jfx22-fix-request", "jfx22-fix-yes", "jfx22-fix-no" and "jfx22-fix-nmi", "jfx22-enhancement-request", "jfx22-enhancement-yes", "jfx22-enhancement-no" and "jfx22-enhancement-nmi" as corresponding labels. REMINDER: In this release we will integrate almost all stabilization changes via backports from the master branch [4]. ? * Almost all fixes intended for the jfx22 stabilization branch will also be applicable to the master branch. Integrate such a change into the master branch first. Then, after you have obtained any required approvals, backport it to the stabilization branch using the Skara `/backport` command or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash.? (The JDK Developers? Guide contains more information on working with backports [5].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 23 as of today). This is usually what we want. A backport PR should be targeted to `jfx22` if, and only if, it is intended for JavaFX 22 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx22`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 23 (or withdrawn if it is a backport of a fix already in `master`). Reviewers also need to be extra careful when reviewing PRs targeted to jfx22 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. This should be less of a problem for this release, since almost all PRs for jfx22 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042703.html [2] https://github.com/openjdk/jfx/tree/jfx22 [3] http://openjdk.org/jeps/3 [4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [5] https://openjdk.org/guide/#working-with-backports-in-jbs From angorya at openjdk.org Thu Feb 1 16:30:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Feb 2024 16:30:10 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v7] In-Reply-To: <70JX8j7Wilm1DI1efl7Sb5Yowxqi3kFHX5wMk_rPVcI=.ac3534ce-b235-4fcf-acac-5c57d6a37187@github.com> References: <70JX8j7Wilm1DI1efl7Sb5Yowxqi3kFHX5wMk_rPVcI=.ac3534ce-b235-4fcf-acac-5c57d6a37187@github.com> Message-ID: <29G3Bn_iyS2iETGE7HpQndKNNWuj_YtP6vuMAj4kkOc=.a7668382-c24a-4506-acd9-47aa9638f505@github.com> On Thu, 1 Feb 2024 08:06:18 GMT, Karthik P K wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 513: >> >>> 511: if ((x > run.getWidth() && (!isMultiRunText || run.getStart() == curRunStart)) || textWidthPrevLine > 0) { >>> 512: getBounds(run.getTextSpan(), textBounds); >>> 513: x -= (runs[0].getLocation().x - textBounds.getMinX()); >> >> suggestion: we are still in the for loop, so perhaps it makes sense to extract >> `(runs[0].getLocation().x - textBounds.getMinX());` >> to a variable outside of the loop > > The idea is that outside the loop we don't know if we need to subtract the textBound min x value and the starting location of the first run or not. That is why this is present inside the loop. Once this is done we are breaking out of the loop so this will not get called multiple times. > Let me know if you have any suggestions. you are right: I missed the `break` in line 520 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1474745002 From nlisker at gmail.com Thu Feb 1 16:38:19 2024 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Feb 2024 18:38:19 +0200 Subject: Binding properties to constant values In-Reply-To: <677138a2-f597-8823-8777-2e6cc9ad6fcc@gmail.com> References: <1bed200c-e286-d9a1-397a-66a0abbfd63e@gmail.com> <677138a2-f597-8823-8777-2e6cc9ad6fcc@gmail.com> Message-ID: Hi John, If the issues with StyleOrigin are not as problematic as I presented, it comes out to the behavioral flexibility we have. Can we change the precedence order at this point? Do users rely on it or are surprised by it (I see the latter, but those who think it works correctly are not going to say that)? Perhaps Kevin can weigh in. The question of how to do it is simpler, and can be done with or without breaking changes to StyleOrigin. On Thu, Feb 1, 2024 at 2:27?AM John Hendrikx wrote: > Hi Nir, > > On 31/01/2024 22:36, Nir Lisker wrote: > > > > I would wait with the ramifications of setting competing values from > > different origins until the question of precedence is answered. > > Perhaps emitting warnings is better, though I can see some scenarios > > in which they will be annoying. > > > > The way I see the order: > > 1. Setting from code should always take precedence (including the > > current bindings over setter order of course). > > 2. INLINE origin (via setStyle). > > 3. Stylesheets according to their StyleOrigin as specified by the > > non-javafx css specifications [3]: AUTHOR > USER > USER_AGENT (see > > below for INLINE). > > > > 2 and 3 are already (more or less) specified in JavaFX's css as far as > > I can see. However, 1 is not css, hence I don't think StyleOrigin > > should be applicable here even. Even more, 2 isn't really css either, > > it mimics html tags and shouldn't count as a css StyleOrigin in my > > opinion. > StyleOrigin is more of an internal thing that got exposed, so I wouldn't > worry too much about what is CSS and what isn't. I agree that the above > order would make more sense. I suspect the reasoning why it wasn't done > is that setters are getting called to set up defaults, which if they by > default override all, would conflict with style sheets set by the user. > > Note also that a Stylesheet can set its origin [4], even to INLINE, so > > it takes precedence over java property setters and conflicts with > > 'setStyle' "real" INLINE. I'm not sure if this is a bug because the > > javafx css specs say that "Inline styles are specified via the Node > > setStyle AP". > > The CSS API is weird. It has many seemingly useful and public bits, but > they are isolated from the rest of FX. > > Take StyleSheet for example. You can convert them (using File to File) > from regular to binary, then load a binary file and get a StyleSheet > reference with a public API. You can then change its origin. However, > it stops there. You can't feed such a modified StyleSheet to FX via any > public API. > > It almost looks like a lot of the CSS public API is there for a possibly > previously integrated Scene Builder type application, which was later > split off. > > > > > So, if I were to able to do anything I wanted, I would have restricted > > Stylesheets to the options in 3, remove INLINE from a public > > perspective and apply it only behind the scenes to 'setStyle' calls, > > and stop treating java settings in the css hierarchy (which means > > removing the USER StyleOrigin from them). Obviously that breaks a lot > > of code, but this behavior would be my general goal. As for how to > > represent it, maybe a constant can be added to StyleOrigin to > > represent java code settings, but that's not a real css origin. I > > guess we could call INLINE and the hypothetical JAVA constants > > "pseudo-origins", because they don't apply to stylesheets, and are > > only used internally. Or just don't check StyleOrigin when the value > > is set from java. There are probably more ways. > > StyleOrigin really is only there for the CSS engine to distinguish if it > can replace a value or not with something else depending on precedence. > It probably shouldn't have been public at all, aside from the fact that > StyleableProperty being an interface forced it to be public. > > Oddly enough, the StyleableProperty interface is public, but it is again > never returned anywhere (didn't check extensively). So you can't > actually do "label.textAlignment().applyStyle( ... )" even though text > alignment is a styleable property. > > If `textAlignment()` did return a StyleableProperty, then you could do > `label.textAlignment().applyStyle(StyleOrigin.CODE, value)` for a > permanent override of the value which the CSS engine will respect. > > > > > I also wonder if StyleOrigin should implement Comparable for > > the precedence calculations of stylesheets. > > It sort of already does, they are defined in the order of least to > highest precedence, so an integer comparator on its ordinal can be used. > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Feb 1 16:51:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Feb 2024 16:51:10 GMT Subject: RFR: 8320912: IME should commit on focus change In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 20:32:36 GMT, Martin Fox wrote: > This is a Mac only bug. If the user was in the middle of IM text composition and clicked on a different node the partially composed text was left in the old node and the IM window wasn't dismissed. This PR implements the existing finishInputMethodComposition call so it can commit the text and dismiss the IM window before focus moves away from the node where composition was taking place. > > This PR changes the implementation of `unmarkText` to match what we want and what Apple says it should do ("The text view should accept the marked text as if it had been inserted normally"). With that said I haven't found an IME that calls this routine. You are right - I should have checked a native app. It works as expected then. Thank you for fixing this bug! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1356#pullrequestreview-1856993847 From kevin.rushforth at oracle.com Thu Feb 1 23:33:15 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 1 Feb 2024 15:33:15 -0800 Subject: Integrated: 8324658: Allow animation play/start/stop/pause methods to be called on any thread In-Reply-To: References: Message-ID: <38a5560c-eca9-4f59-8eea-7ffd742f53f0@oracle.com> And thank you for raising the issue and answering the questions we had concerning the use case. This will be in the next promoted build, JavaFX 22+28 (as well as JavaFX 23+3). -- Kevin On 2/1/2024 12:42 AM, Jurgen Doll wrote: > > A big THANK YOU to everybody that was part of this process. > It's very much appreciated ! > > Regards > Jurgen > > > On Tue, 30 Jan 2024 11:27:44 +0200, Nir Lisker > wrote: > >> On Fri, 26 Jan 2024 23:59:50 GMT, Nir Lisker >> wrote: >> >>> Added a utility method to run code on the FX thread if it's not >>> already, and changed the animation methods to use it. >> >> This pull request has now been integrated. >> >> Changeset: c5ab220b >> Author:??? Nir Lisker >> URL: >> https://git.openjdk.org/jfx/commit/c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f >> Stats:???? 422 lines in 7 files changed: 225 ins; 148 del; 49 mod >> >> 8324658: Allow animation play/start/stop/pause methods to be called >> on any thread >> >> Reviewed-by: kcr, jpereda >> >> ------------- >> >> PR: https://git.openjdk.org/jfx/pull/1352 From r.lichtenberger at gmail.com Fri Feb 2 06:10:51 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Fri, 2 Feb 2024 07:10:51 +0100 Subject: CSS Performance regression inTableColumnHeader.resizeColumnToFitContent In-Reply-To: References: Message-ID: <2fd68042-4582-1bc6-cbce-b694a568ead4@gmail.com> Am 01.02.24 um 16:53 schrieb John Hendrikx: > > Is it still a CSS performance degradation then?? I mean, it's the same > speed, and the number of calls should be irrelevant? A performance degradation must be present, since after the expected deterioration of JFX 19 it has become twice as slow since. The assumption that is has something to do with CSS is based on the fact that we also have rendering performance problems in TableView in our production application where a column with a cell factory exists that has lots of nodes in a cell. > > However, if you want to narrow it down further (perhaps there is more > performance to be gained), you could run your tests against the early > access builds.? You may be able to find a set of 10-20 isolated > commits that could have led to the introduction of the extra 60.000 > calls.? For example, check if the problem is present in 20-ea+1 up to > 20-ea-19, 20, 20.0.1 and 20.0.2 (early access versions available are > 1, 2, 3, 4, 6, 7, 9, 11, 19), see here: > https://mvnrepository.com/artifact/org.openjfx/javafx-base Good idea, I will try that. And I will also create an issue / PR for the "low hanging fruits" in resizeColumnToFitContent. Robert From rlichten at openjdk.org Fri Feb 2 06:59:16 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Fri, 2 Feb 2024 06:59:16 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be Message-ID: The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. ------------- Commit messages: - 8325154: resizeColumnToFitContent is slower than it needs to be Changes: https://git.openjdk.org/jfx/pull/1358/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1358&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325154 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1358.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1358/head:pull/1358 PR: https://git.openjdk.org/jfx/pull/1358 From mhanl at openjdk.org Fri Feb 2 08:08:14 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 2 Feb 2024 08:08:14 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 668: > 666: tableRow.updateIndex(row); > 667: > 668: cell.updateTableRow(tableRow); can this also be moved out? `cell.updateTableRow(tableRow);` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1475699942 From rlichten at openjdk.org Fri Feb 2 08:23:07 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Fri, 2 Feb 2024 08:23:07 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> References: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> Message-ID: On Fri, 2 Feb 2024 08:05:12 GMT, Marius Hanl wrote: > can this also be moved out? `cell.updateTableRow(tableRow);` I don't think so. Since tableRow gets an updated index above, the cell's style could change (e.g. odd / even styling). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1475714044 From mhanl at openjdk.org Fri Feb 2 08:47:04 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 2 Feb 2024 08:47:04 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> Message-ID: On Fri, 2 Feb 2024 08:20:09 GMT, Robert Lichtenberger wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 668: >> >>> 666: tableRow.updateIndex(row); >>> 667: >>> 668: cell.updateTableRow(tableRow); >> >> can this also be moved out? `cell.updateTableRow(tableRow);` > >> can this also be moved out? `cell.updateTableRow(tableRow);` > > I don't think so. Since tableRow gets an updated index above, the cell's style could change (e.g. odd / even styling). Well, the `tableRow` is still set (but before the loop), we just update the index in this loop. It looks like setting the table row in this loop is not needed, just once above. I also don't see that `setTableRow` has any side effects. So maybe worth a try. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1475740214 From mariushanl at web.de Fri Feb 2 08:50:27 2024 From: mariushanl at web.de (Marius Hanl) Date: Fri, 2 Feb 2024 09:50:27 +0100 Subject: Aw: Headless glass platform In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From r.lichtenberger at gmail.com Fri Feb 2 09:49:56 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Fri, 2 Feb 2024 10:49:56 +0100 Subject: CSS Performance regression inTableColumnHeader.resizeColumnToFitContent In-Reply-To: <2fd68042-4582-1bc6-cbce-b694a568ead4@gmail.com> References: <2fd68042-4582-1bc6-cbce-b694a568ead4@gmail.com> Message-ID: <1a0f1ff3-655a-cab6-1e08-fc1e53288c02@gmail.com> Am 02.02.24 um 07:10 schrieb Robert Lichtenberger: > >> >> However, if you want to narrow it down further (perhaps there is more >> performance to be gained), you could run your tests against the early >> access builds.? You may be able to find a set of 10-20 isolated >> commits that could have led to the introduction of the extra 60.000 >> calls.? For example, check if the problem is present in 20-ea+1 up to >> 20-ea-19, 20, 20.0.1 and 20.0.2 (early access versions available are >> 1, 2, 3, 4, 6, 7, 9, 11, 19), see here: >> https://mvnrepository.com/artifact/org.openjfx/javafx-base > > Good idea, I will try that. Okay, using prebuilt ea-Versions I was able to narrow the problem down: JFX 19.0.2+1 average run time: 1113 JFX 20-ea+1 average run time: 1110 JFX 20-ea+7 average run time: 1211 JFX 20-ea+9 average run time: 1115 JFX 20-ea+11 average run time: 1646 JFX 20.0.2+3 average run time: 1656 => Something has happened between ea+9 and ea+11. I've then let the benchmark run against self-built sdks that are based on the git tags. git checkout tags/20+9: JFX 20-internal+0-2024-02-02-095926 average run time: 1098 git checkout tags/20+11: JFX 20-internal+0-2024-02-02-095926 average run time: 1576 So this confirms the data of the prebuilt sdks. There's also a 20+10 tag, which is still fast: JFX 20-internal+0-2024-02-02-095926 average run time: 1078 So now I've looked at the commits betweeen 20+10 and 20+11. git checkout c2af0c31b70df238769bd0eb1b7fd04eb7241446: JFX 20-internal+0-2024-02-02-095926 average run time: 1093 git checkout bb98d886b01d5d1c6117303f40d43eab9f7ac504: JFX 20-internal+0-2024-02-02-095926 average run time: 1072 => So it wasn't the "8295806: TableViewSkin: memory leak when changing skin" commit git checkout 6abbe0803456ad648117b8e72deeeeced7cb5231: JFX 20-internal+0-2024-02-02-095926 average run time: 1086 git checkout c900a00c7527f290e8047792fef4b45002930892: JFX 20-internal+0-2024-02-02-095926 average run time: 1608 => So the "culprit" seems to be the "8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize" commit by Marius Hanl. Looking into the commit, I see that the "tableSkin.getChildren().remove(tableRow);" hast been moved out of the for-loop. I've put it back into the loop, which should make things slower, but: JFX 20-internal+0-2024-02-02-095926 average run time: 161 Looks like things are _ten times_ faster this way. Tests in javafx.controls still pass. Sounds almost too good to be true, so I will investigate a bit further... Robert From mariushanl at web.de Fri Feb 2 10:15:53 2024 From: mariushanl at web.de (Marius Hanl) Date: Fri, 2 Feb 2024 11:15:53 +0100 Subject: Aw: Re: CSS Performance regression inTableColumnHeader.resizeColumnToFitContent In-Reply-To: <1a0f1ff3-655a-cab6-1e08-fc1e53288c02@gmail.com> References: <2fd68042-4582-1bc6-cbce-b694a568ead4@gmail.com> <1a0f1ff3-655a-cab6-1e08-fc1e53288c02@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From rlichten at openjdk.org Fri Feb 2 10:42:06 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Fri, 2 Feb 2024 10:42:06 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> Message-ID: On Fri, 2 Feb 2024 08:44:45 GMT, Marius Hanl wrote: >>> can this also be moved out? `cell.updateTableRow(tableRow);` >> >> I don't think so. Since tableRow gets an updated index above, the cell's style could change (e.g. odd / even styling). > > Well, the `tableRow` is still set (but before the loop), we just update the index in this loop. > It looks like setting the table row in this loop is not needed, just once above. I also don't see that `setTableRow` has any side effects. So maybe worth a try. You're right. I tried it out and it seems to work. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1475877054 From lbourges at openjdk.org Fri Feb 2 13:14:26 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 2 Feb 2024 13:14:26 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v4] In-Reply-To: References: Message-ID: > Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: fixed tests thanks to + copyright years ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1348/files - new: https://git.openjdk.org/jfx/pull/1348/files/19189e07..51e55efe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=02-03 Stats: 467 lines in 3 files changed: 213 ins; 253 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1348.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1348/head:pull/1348 PR: https://git.openjdk.org/jfx/pull/1348 From jhendrikx at openjdk.org Fri Feb 2 13:30:19 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Feb 2024 13:30:19 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v3] In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Deprecate for 23 and add new method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1340/files - new: https://git.openjdk.org/jfx/pull/1340/files/31088037..382ef218 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=01-02 Stats: 28 lines in 3 files changed: 26 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1340.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1340/head:pull/1340 PR: https://git.openjdk.org/jfx/pull/1340 From jhendrikx at openjdk.org Fri Feb 2 13:30:19 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Feb 2024 13:30:19 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since parameter to deprecation annotation Okay, so I added the method `Set getClasses()`: The reasoning is as follows: - The ideal name `getStyleClasses` is currently in use by `List getStyleClasses()` - Internally (for selectors), style classes are not a `List`, duplicates are removed, and the order is lost. Exposing it as a `List` seems to offer guarantees we can't offer - Perhaps the next best name `getStyleClassSet` is taken up by the old `Set getStyleClassSet()` -- I can't use this as `StyleClass` is about to be phased out for performance reasons - Mirroring what `Styleable` does with `ObservableList getStyleClass()` is less than ideal (it is a `List`), however it does set some precedence for using a name like `getStyleClass` even though that is not a best practice for collections (it should be plural) - CSS reference never really uses the term "style classes", just classes: https://www.w3schools.com/cssref/css_selectors.php My conclusion is that we either need two rounds to get this right (to first free up our first choice `getStyleClasses`), or we can settle on one of: `getStyleClassNames`, `getStyles`, `getStyleNames`, `getClasses`, `getClassNames`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1923809524 From kcr at openjdk.org Fri Feb 2 13:40:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 13:40:06 GMT Subject: RFR: 8325093: Update CONTRIBUTING.md for build jdk version In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 06:36:51 GMT, Ao Qi wrote: > [JDK-8297068](https://bugs.openjdk.org/browse/JDK-8297068) updated boot JDK to 19.0.1 from 18.0.2, and [JDK-8321434](https://bugs.openjdk.org/browse/JDK-8321434) updated boot JDK to 21.0.1. `CONTRIBUTING.md` should be updated correspondingly. Looks good. Thanks. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1357#pullrequestreview-1859268381 From kcr at openjdk.org Fri Feb 2 13:40:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 13:40:07 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. @andy-goryachev-oracle Can you review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1923824237 From aoqi at openjdk.org Fri Feb 2 14:42:08 2024 From: aoqi at openjdk.org (Ao Qi) Date: Fri, 2 Feb 2024 14:42:08 GMT Subject: RFR: 8325093: Update CONTRIBUTING.md for build jdk version In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 13:37:15 GMT, Kevin Rushforth wrote: >> [JDK-8297068](https://bugs.openjdk.org/browse/JDK-8297068) updated boot JDK to 19.0.1 from 18.0.2, and [JDK-8321434](https://bugs.openjdk.org/browse/JDK-8321434) updated boot JDK to 21.0.1. `CONTRIBUTING.md` should be updated correspondingly. > > Looks good. Thanks. @kevinrushforth, thanks for the review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1357#issuecomment-1924017692 From aoqi at openjdk.org Fri Feb 2 15:02:10 2024 From: aoqi at openjdk.org (Ao Qi) Date: Fri, 2 Feb 2024 15:02:10 GMT Subject: Integrated: 8325093: Update CONTRIBUTING.md for build jdk version In-Reply-To: References: Message-ID: <2-zIH4BW1ly9K3GM0pphIhpy9Pww9IPWX_SngCGdL5s=.b4d0b519-d4ae-4ab7-aa3e-62c08afe2d44@github.com> On Thu, 1 Feb 2024 06:36:51 GMT, Ao Qi wrote: > [JDK-8297068](https://bugs.openjdk.org/browse/JDK-8297068) updated boot JDK to 19.0.1 from 18.0.2, and [JDK-8321434](https://bugs.openjdk.org/browse/JDK-8321434) updated boot JDK to 21.0.1. `CONTRIBUTING.md` should be updated correspondingly. This pull request has now been integrated. Changeset: 12816b57 Author: Ao Qi Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/12816b57ffd1ffad57d008f7195666ad4e9400bb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8325093: Update CONTRIBUTING.md for build jdk version Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1357 From mfox at openjdk.org Fri Feb 2 15:40:35 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 15:40:35 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v3] In-Reply-To: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: > Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. > > The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Fixed ambiguous comment - Merge remote-tracking branch 'upstream/master' into macerrors - Merge remote-tracking branch 'upstream/master' into macerrors - Remove reference to non-existent generic Java app icon - Fixed umatched pragma push - Remove unnecessary comment - Simpler handling of temporary NSNotification - Fixed leaked object. Removed unnecessary pragma. - Consistency in dealing with path to app icon. Updated default image name. - Turning off deprecation warnings on a per-file basis. Fixes for some warnings. - ... and 3 more: https://git.openjdk.org/jfx/compare/12816b57...1c4c4e96 ------------- Changes: https://git.openjdk.org/jfx/pull/687/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=687&range=02 Stats: 51 lines in 17 files changed: 33 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/687.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/687/head:pull/687 PR: https://git.openjdk.org/jfx/pull/687 From kcr at openjdk.org Fri Feb 2 16:03:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 16:03:13 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> Message-ID: <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> On Fri, 2 Feb 2024 13:27:50 GMT, John Hendrikx wrote: > My conclusion is that we either need two rounds to get this right (to first free up our first choice getStyleClasses), or we can settle on one of: getStyleClassNames, getStyles, getStyleNames, getClasses, getClassNames. Let's settle on one of these names. I think `getClasses` is fine. My second choice would be `getClassNames`. There is one other method used by SceneBuilder's `CssInternal` class, `CompoundSelector::getSelectors`. I think you need to add a method to the `Selector` base class that returns a `List` instead of the `List` returned by the existing `CompoundSelector` method. Maybe `getChildSelectors` or similar? That method would be overridden in the subclasses with `CompoundSelector` wrapping the existing selectors list in an unmodifiable list and `SimpleSelectors` returning an empty List. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1924164069 From mfox at openjdk.org Fri Feb 2 16:14:07 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 16:14:07 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v3] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 15:40:35 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Fixed ambiguous comment > - Merge remote-tracking branch 'upstream/master' into macerrors > - Merge remote-tracking branch 'upstream/master' into macerrors > - Remove reference to non-existent generic Java app icon > - Fixed umatched pragma push > - Remove unnecessary comment > - Simpler handling of temporary NSNotification > - Fixed leaked object. Removed unnecessary pragma. > - Consistency in dealing with path to app icon. Updated default image name. > - Turning off deprecation warnings on a per-file basis. Fixes for some warnings. > - ... and 3 more: https://git.openjdk.org/jfx/compare/12816b57...1c4c4e96 Re-opening this PR. Instead of disabling deprecation warnings globally I added pragmas to the relevant files. This will make it easier to continue the clean-up; someone can file a bug against a specific file, remove the pragma, and fix it up without having to wade through the warnings generated by the other files. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924185627 From angorya at openjdk.org Fri Feb 2 16:18:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Feb 2024 16:18:12 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. I see it working right in macOS 14.2.1, by double-clicking on the column divider in the table header. Question to @effad : could you provide the measurements for this fix (before/after) please? A side comment: the default implementation of resizeColumnToFitContent() is to iterate over all the rows, and I think this is not right. The UI locks up if the table has, let's say, 10,000,000 rows. I think in this case it should instead pick a reasonable limited range (maybe a max 1000 rows or so) of rows based on what's currently visible, so as not to lock up the UI. This might be a separate improvement. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1358#pullrequestreview-1859623785 From mfox at openjdk.org Fri Feb 2 16:24:11 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 16:24:11 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v3] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 15:40:35 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Fixed ambiguous comment > - Merge remote-tracking branch 'upstream/master' into macerrors > - Merge remote-tracking branch 'upstream/master' into macerrors > - Remove reference to non-existent generic Java app icon > - Fixed umatched pragma push > - Remove unnecessary comment > - Simpler handling of temporary NSNotification > - Fixed leaked object. Removed unnecessary pragma. > - Consistency in dealing with path to app icon. Updated default image name. > - Turning off deprecation warnings on a per-file basis. Fixes for some warnings. > - ... and 3 more: https://git.openjdk.org/jfx/compare/12816b57...1c4c4e96 The pre-submit error is due to a call to `[NSApp activate]` which is only available in macOS 14.0 and up. My local builds use a 14.x SDK but the pre-submit tests are built with 13.3. It's an easy fix but I first need to find out why the SDK matters; the minimum target is 11.0 so I should have seen a warning. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924201479 From kcr at openjdk.org Fri Feb 2 16:28:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 16:28:06 GMT Subject: RFR: 8320912: IME should commit on focus change In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 20:32:36 GMT, Martin Fox wrote: > This is a Mac only bug. If the user was in the middle of IM text composition and clicked on a different node the partially composed text was left in the old node and the IM window wasn't dismissed. This PR implements the existing finishInputMethodComposition call so it can commit the text and dismiss the IM window before focus moves away from the node where composition was taking place. > > This PR changes the implementation of `unmarkText` to match what we want and what Apple says it should do ("The text view should accept the marked text as if it had been inserted normally"). With that said I haven't found an IME that calls this routine. The code changes look good. I did some cursory testing (since both you and Andy did extensive testing) and it fixes the bug. I left one minor comment. If you choose to fix it, I'll reapprove. modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacView.java line 81: > 79: @Override native protected void _exitFullscreen(long ptr, boolean animate); > 80: @Override native protected void _enableInputMethodEvents(long ptr, boolean enable); > 81: @Override native protected void _finishInputMethodComposition(long ptr); Now that you override this method on Mac, I recommend changing the comment in the base class from `... needed only on Windows` to `... needed only on some platforms`. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1356#pullrequestreview-1859616385 PR Review Comment: https://git.openjdk.org/jfx/pull/1356#discussion_r1476258024 From kcr at openjdk.org Fri Feb 2 16:29:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 16:29:09 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2] In-Reply-To: References: Message-ID: On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > When IM enabled state changes we dismiss the IM window. Once #1356 is integrated I'll re-review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924212261 From mfox at openjdk.org Fri Feb 2 16:46:05 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 16:46:05 GMT Subject: RFR: 8320912: IME should commit on focus change In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 16:11:52 GMT, Kevin Rushforth wrote: >> This is a Mac only bug. If the user was in the middle of IM text composition and clicked on a different node the partially composed text was left in the old node and the IM window wasn't dismissed. This PR implements the existing finishInputMethodComposition call so it can commit the text and dismiss the IM window before focus moves away from the node where composition was taking place. >> >> This PR changes the implementation of `unmarkText` to match what we want and what Apple says it should do ("The text view should accept the marked text as if it had been inserted normally"). With that said I haven't found an IME that calls this routine. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacView.java line 81: > >> 79: @Override native protected void _exitFullscreen(long ptr, boolean animate); >> 80: @Override native protected void _enableInputMethodEvents(long ptr, boolean enable); >> 81: @Override native protected void _finishInputMethodComposition(long ptr); > > Now that you override this method on Mac, I recommend changing the comment in the base class from `... needed only on Windows` to `... needed only on some platforms`. I'll pick up the comment change in the PR #1351. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1356#discussion_r1476296254 From mfox at openjdk.org Fri Feb 2 16:46:06 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 16:46:06 GMT Subject: Integrated: 8320912: IME should commit on focus change In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 20:32:36 GMT, Martin Fox wrote: > This is a Mac only bug. If the user was in the middle of IM text composition and clicked on a different node the partially composed text was left in the old node and the IM window wasn't dismissed. This PR implements the existing finishInputMethodComposition call so it can commit the text and dismiss the IM window before focus moves away from the node where composition was taking place. > > This PR changes the implementation of `unmarkText` to match what we want and what Apple says it should do ("The text view should accept the marked text as if it had been inserted normally"). With that said I haven't found an IME that calls this routine. This pull request has now been integrated. Changeset: 17dfab06 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/17dfab066b1f5db3d34b130cade3acd09ee21a70 Stats: 40 lines in 4 files changed: 36 ins; 0 del; 4 mod 8320912: IME should commit on focus change Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1356 From angorya at openjdk.org Fri Feb 2 17:15:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Feb 2024 17:15:08 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2] In-Reply-To: <6pYLwWIj95-eNoJeyU_5ZV3PluCogsLQPJiAGx3Qv4s=.3bc73d43-3683-4491-8600-8bc405844394@github.com> References: <6pYLwWIj95-eNoJeyU_5ZV3PluCogsLQPJiAGx3Qv4s=.3bc73d43-3683-4491-8600-8bc405844394@github.com> Message-ID: On Tue, 30 Jan 2024 20:43:33 GMT, Martin Fox wrote: >>> The order in which they get resolved doesn't matter. >> >> would it be possible to get [JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912) integrated first then? It seems the scenario it addresses is narrower, and it will be easier to review this bug. > > @andy-goryachev-oracle I submitted PR #1356. @beldenfox could you sync up with the latest master branch please? Eclipse reports a conflict in GlassView3D.m around lines 722, I am surprised there are no conflicts in github... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924302579 From angorya at openjdk.org Fri Feb 2 17:15:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Feb 2024 17:15:09 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2] In-Reply-To: References: Message-ID: On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > When IM enabled state changes we dismiss the IM window. Even though it says "This branch has conflicts that must be resolved" there is a green checkmark next to it in the Pull Requests view: https://github.com/openjdk/jfx/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Arfr ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924307063 From kcr at openjdk.org Fri Feb 2 17:25:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 17:25:09 GMT Subject: RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 10:21:05 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add since tags This PR should probably be moved to draft. Now that the deprecation for removal is targeted for 23, this won't happen until JavaFX 24. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1924338633 From kcr at openjdk.org Fri Feb 2 17:30:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 17:30:07 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2] In-Reply-To: References: Message-ID: On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > When IM enabled state changes we dismiss the IM window. I'm surprised Skara hasn't noticed that there is a merge conflict -- when it does, it should add a `merge-conflict` label. Maybe it needs something other than a PR comment to wake it up? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924354933 From mfox at openjdk.org Fri Feb 2 17:52:08 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 17:52:08 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2] In-Reply-To: References: Message-ID: <1ijWtHSmorlkc0polo7jZx_n_71r7yucAH0HMQ4kYmM=.3fb27566-e297-4c9d-b576-b45e0416ffb6@github.com> On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > When IM enabled state changes we dismiss the IM window. Skara has noted the merge conflict. I'll get that patched up. I also need to tweak the implementation of setEnabled, it's trying to handle focus moving from node to node but the logic is wrong. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924398536 From kcr at openjdk.org Fri Feb 2 17:52:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 17:52:08 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2] In-Reply-To: References: Message-ID: On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > When IM enabled state changes we dismiss the IM window. Skara hasn't labeled it, so I'm restating the requirement of 2 reviewers to see if that wakes up the bot to check for the merge conflict. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924401376 From kcr at openjdk.org Fri Feb 2 18:14:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 18:14:13 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v8] In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 20:35:15 GMT, Johan Vos wrote: > Thanks for the additional test. There was already a test in the SystemMenuBarTest, but it's really good to have an additional test for this -- I added it. @johanvos [8323787](https://bugs.openjdk.org/browse/JDK-8323787) seems like a distinct bug, so I recommend adding it to this PR with `/issue add 8323787`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1924431871 From mfox at openjdk.org Fri Feb 2 18:43:19 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 18:43:19 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v3] In-Reply-To: References: Message-ID: <7xm2HROW5-_pmBRTqAFDYxXHutUSvnqijEke8rWcpz4=.7781ad2e-eeb0-4f74-aa67-bab40e93ed4d@github.com> > In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. > > In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. > > The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. > > I also updated a few deprecated constants so this file no longer generates compiler warnings. Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Now handling ESC ending the composition state. Minor setEnabled cleanup. - Merge remote-tracking branch 'upstream/master' into macimefixes - When IM enabled state changes we dismiss the IM window. - Merge remote-tracking branch 'upstream/master' into macimefixes - Comment tweaks - Merge remote-tracking branch 'upstream/master' into macimefixes - Modified method of determing which keyDowns are sent as KeyEvents. ------------- Changes: https://git.openjdk.org/jfx/pull/1351/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1351&range=02 Stats: 60 lines in 3 files changed: 35 ins; 10 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1351.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1351/head:pull/1351 PR: https://git.openjdk.org/jfx/pull/1351 From mfox at openjdk.org Fri Feb 2 18:50:07 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 18:50:07 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v3] In-Reply-To: <7xm2HROW5-_pmBRTqAFDYxXHutUSvnqijEke8rWcpz4=.7781ad2e-eeb0-4f74-aa67-bab40e93ed4d@github.com> References: <7xm2HROW5-_pmBRTqAFDYxXHutUSvnqijEke8rWcpz4=.7781ad2e-eeb0-4f74-aa67-bab40e93ed4d@github.com> Message-ID: On Fri, 2 Feb 2024 18:43:19 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Now handling ESC ending the composition state. Minor setEnabled cleanup. > - Merge remote-tracking branch 'upstream/master' into macimefixes > - When IM enabled state changes we dismiss the IM window. > - Merge remote-tracking branch 'upstream/master' into macimefixes > - Comment tweaks > - Merge remote-tracking branch 'upstream/master' into macimefixes > - Modified method of determing which keyDowns are sent as KeyEvents. Two additions to the code. I was not handling the case where the keystroke didn't commit text but did clear the marked text (getting us out of composition mode). You can do this by repeatedly pressing ESC. When the enabled state changes we shouldn't have any marked text but if we do it should just be discarded. The old code was trying to deal with focusOwner changes but that cleanup has to happen before the enabled state changes instead of after (which is why finishInputMethodComposition exists). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1924483704 From kcr at openjdk.org Fri Feb 2 19:02:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 19:02:08 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 Message-ID: Periodic sync of `jfx:jfx22` into `jfx22u:master`. ------------- Commit messages: - Merge jfx:jfx22 - 8324879: Platform-specific preferences keys are incorrect for Windows toolkit - 8324658: Allow animation play/start/stop/pause methods to be called on any thread The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx22u/pull/9/files Stats: 462 lines in 10 files changed: 258 ins; 148 del; 56 mod Patch: https://git.openjdk.org/jfx22u/pull/9.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/9/head:pull/9 PR: https://git.openjdk.org/jfx22u/pull/9 From kcr at openjdk.org Fri Feb 2 19:02:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 19:02:09 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 18:55:49 GMT, Kevin Rushforth wrote: > Periodic sync of `jfx:jfx22` into `jfx22u:master`. This pull request has now been integrated. Changeset: 3980a726 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/3980a7260ab1711a92c19d136161a7f8fe42ed0a Stats: 462 lines in 10 files changed: 258 ins; 148 del; 56 mod Merge ------------- PR: https://git.openjdk.org/jfx22u/pull/9 From jhendrikx at openjdk.org Fri Feb 2 19:07:07 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Feb 2024 19:07:07 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> Message-ID: On Fri, 2 Feb 2024 16:00:28 GMT, Kevin Rushforth wrote: > There is one other method used by SceneBuilder's `CssInternal` class, `CompoundSelector::getSelectors`. I think you need to add a method to the `Selector` base class that returns a `List` instead of the `List` returned by the existing `CompoundSelector` method. Maybe `getChildSelectors` or similar? That method would be overridden in the subclasses with `CompoundSelector` wrapping the existing selectors list in an unmodifiable list and `SimpleSelectors` returning an empty List. @kevinrushforth if I'm correct, SceneBuilder won't need that anymore. Since it shouldn't need to do an `instanceof` check (which will break once they're moved to internal packages), the fragment that gets all the selectors should be changed to: for (Rule r : s.getRules()) { for (Selector ss : r.getSelectors()) { styleClasses.addAll(ss.getClasses()); // provisional name getClasses } } Old SceneBuilder code fragment: for (Rule r : s.getRules()) { for (Selector ss : r.getSelectors()) { if (ss instanceof SimpleSelector) { SimpleSelector simple = (SimpleSelector) ss; styleClasses.addAll(simple.getStyleClasses()); } else { if (ss instanceof CompoundSelector) { CompoundSelector cs = (CompoundSelector) ss; for (Selector selector : cs.getSelectors()) { if (selector instanceof SimpleSelector) { SimpleSelector simple = (SimpleSelector) selector; styleClasses.addAll(simple.getStyleClasses()); } } } } } } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1924508539 From kcr at openjdk.org Fri Feb 2 19:30:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 19:30:11 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> Message-ID: On Fri, 2 Feb 2024 19:04:33 GMT, John Hendrikx wrote: >>> My conclusion is that we either need two rounds to get this right (to first free up our first choice getStyleClasses), or we can settle on one of: getStyleClassNames, getStyles, getStyleNames, getClasses, getClassNames. >> >> Let's settle on one of these names. I think `getClasses` is fine. My second choice would be `getClassNames`. >> >> There is one other method used by SceneBuilder's `CssInternal` class, `CompoundSelector::getSelectors`. I think you need to add a method to the `Selector` base class that returns a `List` instead of the `List` returned by the existing `CompoundSelector` method. Maybe `getChildSelectors` or similar? That method would be overridden in the subclasses with `CompoundSelector` wrapping the existing selectors list in an unmodifiable list and `SimpleSelectors` returning an empty List. > >> There is one other method used by SceneBuilder's `CssInternal` class, `CompoundSelector::getSelectors`. I think you need to add a method to the `Selector` base class that returns a `List` instead of the `List` returned by the existing `CompoundSelector` method. Maybe `getChildSelectors` or similar? That method would be overridden in the subclasses with `CompoundSelector` wrapping the existing selectors list in an unmodifiable list and `SimpleSelectors` returning an empty List. > > @kevinrushforth if I'm correct, SceneBuilder won't need that anymore. Since it shouldn't need to do an `instanceof` check (which will break once they're moved to internal packages), the fragment that gets all the selectors should be changed to: > > for (Rule r : s.getRules()) { > for (Selector ss : r.getSelectors()) { > styleClasses.addAll(ss.getClasses()); // provisional name getClasses > } > } > > Old SceneBuilder code fragment: > > for (Rule r : s.getRules()) { > for (Selector ss : r.getSelectors()) { > if (ss instanceof SimpleSelector) { > SimpleSelector simple = (SimpleSelector) ss; > styleClasses.addAll(simple.getStyleClasses()); > } else { > if (ss instanceof CompoundSelector) { > CompoundSelector cs = (CompoundSelector) ss; > for (Selector selector : cs.getSelectors()) { > if (selector instanceof SimpleSelector) { > SimpleSelector simple = (SimpleSelector) selector; > styleClasses.addAll(simple.getStyleClasses()); > } > } > } > } > } > } > > Note that in this old code, there is some unnecessary casting going on (`cs.getSelectors()` already returns `SimpleSelector`s, which makes it seem like `CompoundSelector` could contain something other than `SimpleSelector`s, which is not the case (they can't be nested or anything). @hjohn since the implementation of `getClasses` in `CompoundSelector` aggregates the style classes for all of its `SimpleSelectors`, then I think you are right that a `getChildSelectors` is unnecessary. @jperedadnr Will this work for you? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1924543785 From jpereda at openjdk.org Fri Feb 2 19:37:06 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 2 Feb 2024 19:37:06 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v3] In-Reply-To: <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> Message-ID: On Fri, 2 Feb 2024 13:30:19 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Deprecate for 23 and add new method Yes, I think so, simplifying the code without breaking the existing functionality should be fine. I guess it should be easy to do a build with this PR and test Scene Builder before and after the proposed change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1924554466 From mfox at openjdk.org Fri Feb 2 19:47:17 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 19:47:17 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: > Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. > > The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Added OS version guard for NSApp activate call ------------- Changes: - all: https://git.openjdk.org/jfx/pull/687/files - new: https://git.openjdk.org/jfx/pull/687/files/1c4c4e96..862067d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=687&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=687&range=02-03 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/687.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/687/head:pull/687 PR: https://git.openjdk.org/jfx/pull/687 From mfox at openjdk.org Fri Feb 2 20:14:07 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 20:14:07 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 19:47:17 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Added OS version guard for NSApp activate call Ouch. We're targeting a minimum macOS version of 11.0 but `[NSApp activate]` is only available on 14.0 and above. Xcode 15 should issue a warning about this but doesn't *if this is the only version warning in the file*. I've tried this with a standalone app and also tweaked the Glass code and the result is the same; I get no warning unless I add some other 14.0-specific call in the same file. At that point I'll get a warning about the other violation in addition to the `[NSApp activate]` call. Adding an `@available` check around this is the right thing to do but not enough to appease the pre-submit bot which is building with the 13.3 SDK. To clean this up either the bot needs to be upgraded or I need to add a localized pragma to disable this check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924616685 From kcr at openjdk.org Fri Feb 2 20:55:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 20:55:05 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v3] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> Message-ID: On Fri, 2 Feb 2024 19:34:02 GMT, Jose Pereda wrote: > Yes, I think so, simplifying the code without breaking the existing functionality should be fine. I guess it should be easy to do a build with this PR and test Scene Builder before and after the proposed change. In order to fully test it, you would need to locally make the change to `SceneBuilder` that John suggested. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1924681177 From kcr at openjdk.org Fri Feb 2 21:07:20 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 21:07:20 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 19:47:17 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Added OS version guard for NSApp activate call > We're targeting a minimum macOS version of 11.0 but `[NSApp activate]` is only available on 14.0 and above. Xcode 15 should issue a warning about this but doesn't _if this is the only version warning in the file_. Sigh. I'm not much a fan of how Apple handles runtime version checks, and this seems like one more indication of that. > Adding an `@available` check around this is the right thing to do but not enough to appease the pre-submit bot which is building with the 13.3 SDK. Technically the `@available` check is redundant (the only place that `requiresActivation` is set to `YES` is already in an `@available` check), but I can see how the compiler wouldn't know that. Adding it around the use site seems fine; too bad it is insufficient. > To clean this up either the bot needs to be upgraded Definitely not. This matches our production build environment. We use Xcode 14.3.1, which includes `MacOSX13.sdk`. > or I need to add a localized pragma to disable this check. So basically, a pragma to workaround a limitation of Xcode. This might be the best option if it isn't too ugly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924693909 From kcr at openjdk.org Fri Feb 2 21:24:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 21:24:09 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 19:47:17 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Added OS version guard for NSApp activate call Btw, I ran this PR through our CI and got the expected error: Starting process 'command 'jfx/buildSrc/build/build-tools/devkit-macosx-Xcode14.3.1+1.0.tar/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang''. Working directory: jfx/modules/javafx.graphics Command: jfx/buildSrc/build/build-tools/devkit-macosx-Xcode14.3.1+1.0.tar/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-macos-11 -mmacosx-version-min=11.0 -isysroot jfx/buildSrc/build/build-tools/devkit-macosx-Xcode14.3.1+1.0.tar/Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk -iframeworkjfx/buildSrc/build/build-tools/devkit-macosx-Xcode14.3.1+1.0.tar/Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks -arch x86_64 -I/Users/java_re/jenkins/workspace/jfx-submit/label/mac-13-x64/jfx/bootjdk/jdk-21.0.2.jdk/Contents/Home/include -I/Users/java_re/jenkins/workspace/jfx-submit/label/mac-13-x64/jfx/bootjdk/jdk-21.0.2.jdk/Contents/Home/include/darw in -std=c99 -c -O3 -DNDEBUG -DGL_SILENCE_DEPRECATION -DMACOS_MIN_VERSION_MAJOR=11 -DMACOS_MIN_VERSION_MINOR=0 -Werror -Ijfx/modules/javafx.graphics/build/gensrc/headers/javafx.graphics -Ijfx/modules/javafx.graphics/src/main/native-glass/mac -Ijfx/modules/javafx.graphics/src/main/native-glass/mac/a11y -o jfx/modules/javafx.graphics/build/native/glass/mac/GlassApplication.obj jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m Successfully started process 'command 'jfx/buildSrc/build/build-tools/devkit-macosx-Xcode14.3.1+1.0.tar/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang'' jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m:304:24: error: instance method '-activate' not found (return type defaults to 'id') [-Werror,-Wobjc-method-access] [NSApp activate]; ^~~~~~~~ jfx/buildSrc/build/build-tools/devkit-macosx-Xcode14.3.1+1.0.tar/Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSApplication.h:158:12: note: receiver is instance of class declared here @interface NSApplication : NSResponder ^ 1 error generated. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924718099 From jpereda at openjdk.org Fri Feb 2 21:26:08 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 2 Feb 2024 21:26:08 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v3] In-Reply-To: <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> Message-ID: On Fri, 2 Feb 2024 13:30:19 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Deprecate for 23 and add new method Sure, that was what I meant. I'll give it a try over the weekend. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1924719862 From mfox at openjdk.org Fri Feb 2 22:09:19 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 22:09:19 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 21:04:13 GMT, Kevin Rushforth wrote: > So basically, a pragma to workaround a limitation of Xcode. I wouldn't describe this as a limitation of Xcode. After all, the glass code is trying to access a 14.0 API using a 13.3 SDK. If the language was C++ the call wouldn't be in the headers and the code wouldn't compile. If we launch a jfx22 app on macOS 13 in theory we're sending NSApp an `activate` selector that it doesn't recognize. Or maybe it does? It's possible that this is an old internal call that Apple finally documented in 14.0. That would explain why they would be lenient about issuing a warning. I'll run some tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924772957 From kcr at openjdk.org Fri Feb 2 22:20:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Feb 2024 22:20:07 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 22:06:41 GMT, Martin Fox wrote: > > So basically, a pragma to workaround a limitation of Xcode. > > I wouldn't describe this as a limitation of Xcode. After all, the glass code is trying to access a 14.0 API using a 13.3 SDK. If the language was C++ the call wouldn't be in the headers and the code wouldn't compile. In C++ we would need to use reflection (dlsym), so I can see your point. > If we launch a jfx22 app on macOS 13 in theory we're sending NSApp an `activate` selector that it doesn't recognize. Or maybe it does? It's possible that this is an old internal call that Apple finally documented in 14.0. That would explain why they would be lenient about issuing a warning. I'll run some tests. No, we're not. The `@available` generates a runtime check so that code is executed only if the runtime platform is macOS 14.x or later. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924782232 From mfox at openjdk.org Fri Feb 2 22:26:06 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 2 Feb 2024 22:26:06 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v4] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Fri, 2 Feb 2024 22:17:15 GMT, Kevin Rushforth wrote: > No, we're not. The `@available` generates a runtime check so that code is executed only if the runtime platform is macOS 14.x or later. Right, forgot about the other `@available` check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924791132 From perini.davide at dpsoftware.org Sun Feb 4 01:49:42 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 4 Feb 2024 02:49:42 +0100 Subject: Can't restart my app with the latest JDK, regression. Message-ID: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> Hi there, my JavaFX 21.0.2 app experienced a very weird regression when switching from Temurin OpenJDK21U-jdk_x64_windows_hotspot_21.0.1_12 to OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13 I use this method to restart my app. public void restart() { // path to my exe app plus one string argument String[] cmdToRunUsingArgs = {"C:\Users\sblantipodi\AppData\Local\Firefly Luciferin\Firefly Luciferin.exe","string argument"}; try { Runtime.getRuntime().exec(cmdToRunUsingArgs); }catch (SecurityException | IOException e) { log.error(e.getMessage()); } javafx.application.Platform.exit(); System.exit(0); } It worked well since years until JDK 21.0.2_13. If I revert back to 21.0.1_12 it works well. That method should start a new instance of the app, and close the "old instance". With JDK 21.0.2_13, it closed the running instance but does not open a new instance. I don't know if open a bugreport to JDK but before opening the bug report I would like to ask you if that method to restart the app is correct or if you think that I can use a better way. Thanks Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From perini.davide at dpsoftware.org Sun Feb 4 11:09:06 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 4 Feb 2024 12:09:06 +0100 Subject: Can't restart my app with the latest JDK, regression. In-Reply-To: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> References: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> Message-ID: <4fb52e46-4379-4d52-b810-fa1236a47684@dpsoftware.org> Wrong list sorry, this is a message for the users one... Il 04/02/2024 02:49, Davide Perini ha scritto: > Hi there, > my JavaFX 21.0.2 app experienced a very weird regression when > switching from Temurin > OpenJDK21U-jdk_x64_windows_hotspot_21.0.1_12 > to > OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13 > > I use this method to restart my app. > > public void restart() { > // path to my exe app plus one string argument > String[] cmdToRunUsingArgs = {"C:\Users\sblantipodi\AppData\Local\Firefly Luciferin\Firefly > Luciferin.exe","string argument"}; > try { > Runtime.getRuntime().exec(cmdToRunUsingArgs); > }catch (SecurityException | IOException e) { > log.error(e.getMessage()); > } > javafx.application.Platform.exit(); > System.exit(0); > } > > It worked well since years until JDK 21.0.2_13. > If I revert back to 21.0.1_12 it works well. > > That method should start a new instance of the app, and close the "old > instance". > > With JDK 21.0.2_13, it closed the running instance but does not open a > new instance. > > I don't know if open a bugreport to JDK but before opening the bug > report I would like to ask you if that method to restart the app is > correct or if you think that I can use a better way. > > Thanks > Davide > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Sun Feb 4 17:17:31 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 4 Feb 2024 18:17:31 +0100 Subject: Can't restart my app with the latest JDK, regression. In-Reply-To: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> References: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> Message-ID: <56bf5b6a-f76d-5a0b-1c21-ba1ed693eb9d@gmail.com> Hi, Does that Temurin build contain JavaFX, or is it just a new Temurin build?? Did you change anything else besides the JDK used?? You could try other JDK's (openjdk, corretto, etc) as well. Is there anything being logged that may indicate what went wrong? That all said, it seems really unlikely this is related to JavaFX. If System.exit(0) is killing both the new and old application, then it wasn't really spawned independently, so you can look into that (you could put a delay there, and see with a tool like `top` or Task Manager says, and see whether the restarted app is a child process or not). It's also possible the problem is in the tools/settings used to create the ".exe", so see if you changed anything there. For more info, tips or other ways of doing restarts: https://stackoverflow.com/questions/4159802/how-can-i-restart-a-java-application --John On 04/02/2024 02:49, Davide Perini wrote: > Hi there, > my JavaFX 21.0.2 app experienced a very weird regression when > switching from Temurin > OpenJDK21U-jdk_x64_windows_hotspot_21.0.1_12 > to > OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13 > > I use this method to restart my app. > > public void restart() { > // path to my exe app plus one string argument > String[] cmdToRunUsingArgs = {"C:\Users\sblantipodi\AppData\Local\Firefly Luciferin\Firefly > Luciferin.exe","string argument"}; > try { > Runtime.getRuntime().exec(cmdToRunUsingArgs); > }catch (SecurityException | IOException e) { > log.error(e.getMessage()); > } > javafx.application.Platform.exit(); > System.exit(0); > } > > It worked well since years until JDK 21.0.2_13. > If I revert back to 21.0.1_12 it works well. > > That method should start a new instance of the app, and close the "old > instance". > > With JDK 21.0.2_13, it closed the running instance but does not open a > new instance. > > I don't know if open a bugreport to JDK but before opening the bug > report I would like to ask you if that method to restart the app is > correct or if you think that I can use a better way. > > Thanks > Davide > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Mon Feb 5 00:20:06 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 5 Feb 2024 00:20:06 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v3] In-Reply-To: <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> Message-ID: On Fri, 2 Feb 2024 13:30:19 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Deprecate for 23 and add new method I've tested the change proposed in https://github.com/openjdk/jfx/pull/1340#issuecomment-1924508539 successfully: I've built locally this PR and Scene Builder with the proposed change. Then, showing the CSS analyzer, it calls `CSSInternal::getStyleClasses` using `Selector::getClasses`, which produces the same result as using the old implementation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1926007302 From swpalmer at gmail.com Mon Feb 5 00:48:43 2024 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 4 Feb 2024 19:48:43 -0500 Subject: Binding properties to constant values In-Reply-To: References: <1bed200c-e286-d9a1-397a-66a0abbfd63e@gmail.com> <677138a2-f597-8823-8777-2e6cc9ad6fcc@gmail.com> Message-ID: I think we could (easily?) introduce a new layer for style sheets that sits at the right spot in the precedence order. The issue that makes things difficult is that the scene can have only one user agent stylesheet, so it is a pain to layer on changes to the defaults with the desired precedence. If we had a list of style sheets at that level then we could simply use it instead of scene.getStylesheets(). It would be a backwards compatible change so developers could add or remove style sheets at the precedence level that makes sense for them. I may be over-simplifying, as it has been a while since I went down the rabbit hole of trying to get JavaFX css to do what I wanted. But I see a disconnect between bindings overriding the stylesheet and setProperty not. To me setProperty should be effectively like binding the property to a constant - they are both cases of explicitly setting the property to a value from code. It came as a mild shock to discover that things weren't working as I expected them to, because things were designed not to work as I expected them to :-). It was a "why would you do that to us?" moment. Scott On Thu, Feb 1, 2024 at 12:05?PM Nir Lisker wrote: > Hi John, > > If the issues with StyleOrigin are not as problematic as I presented, it > comes out to the behavioral flexibility we have. Can we change the > precedence order at this point? Do users rely on it or are surprised by it > (I see the latter, but those who think it works correctly are not going to > say that)? > Perhaps Kevin can weigh in. > > The question of how to do it is simpler, and can be done with or without > breaking changes to StyleOrigin. > > On Thu, Feb 1, 2024 at 2:27?AM John Hendrikx > wrote: > >> Hi Nir, >> >> On 31/01/2024 22:36, Nir Lisker wrote: >> > >> > I would wait with the ramifications of setting competing values from >> > different origins until the question of precedence is answered. >> > Perhaps emitting warnings is better, though I can see some scenarios >> > in which they will be annoying. >> > >> > The way I see the order: >> > 1. Setting from code should always take precedence (including the >> > current bindings over setter order of course). >> > 2. INLINE origin (via setStyle). >> > 3. Stylesheets according to their StyleOrigin as specified by the >> > non-javafx css specifications [3]: AUTHOR > USER > USER_AGENT (see >> > below for INLINE). >> > >> > 2 and 3 are already (more or less) specified in JavaFX's css as far as >> > I can see. However, 1 is not css, hence I don't think StyleOrigin >> > should be applicable here even. Even more, 2 isn't really css either, >> > it mimics html tags and shouldn't count as a css StyleOrigin in my >> > opinion. >> StyleOrigin is more of an internal thing that got exposed, so I wouldn't >> worry too much about what is CSS and what isn't. I agree that the above >> order would make more sense. I suspect the reasoning why it wasn't done >> is that setters are getting called to set up defaults, which if they by >> default override all, would conflict with style sheets set by the user. >> > Note also that a Stylesheet can set its origin [4], even to INLINE, so >> > it takes precedence over java property setters and conflicts with >> > 'setStyle' "real" INLINE. I'm not sure if this is a bug because the >> > javafx css specs say that "Inline styles are specified via the Node >> > setStyle AP". >> >> The CSS API is weird. It has many seemingly useful and public bits, but >> they are isolated from the rest of FX. >> >> Take StyleSheet for example. You can convert them (using File to File) >> from regular to binary, then load a binary file and get a StyleSheet >> reference with a public API. You can then change its origin. However, >> it stops there. You can't feed such a modified StyleSheet to FX via any >> public API. >> >> It almost looks like a lot of the CSS public API is there for a possibly >> previously integrated Scene Builder type application, which was later >> split off. >> >> > >> > So, if I were to able to do anything I wanted, I would have restricted >> > Stylesheets to the options in 3, remove INLINE from a public >> > perspective and apply it only behind the scenes to 'setStyle' calls, >> > and stop treating java settings in the css hierarchy (which means >> > removing the USER StyleOrigin from them). Obviously that breaks a lot >> > of code, but this behavior would be my general goal. As for how to >> > represent it, maybe a constant can be added to StyleOrigin to >> > represent java code settings, but that's not a real css origin. I >> > guess we could call INLINE and the hypothetical JAVA constants >> > "pseudo-origins", because they don't apply to stylesheets, and are >> > only used internally. Or just don't check StyleOrigin when the value >> > is set from java. There are probably more ways. >> >> StyleOrigin really is only there for the CSS engine to distinguish if it >> can replace a value or not with something else depending on precedence. >> It probably shouldn't have been public at all, aside from the fact that >> StyleableProperty being an interface forced it to be public. >> >> Oddly enough, the StyleableProperty interface is public, but it is again >> never returned anywhere (didn't check extensively). So you can't >> actually do "label.textAlignment().applyStyle( ... )" even though text >> alignment is a styleable property. >> >> If `textAlignment()` did return a StyleableProperty, then you could do >> `label.textAlignment().applyStyle(StyleOrigin.CODE, value)` for a >> permanent override of the value which the CSS engine will respect. >> >> > >> > I also wonder if StyleOrigin should implement Comparable for >> > the precedence calculations of stylesheets. >> >> It sort of already does, they are defined in the order of least to >> highest precedence, so an integer comparator on its ordinal can be used. >> >> --John >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Feb 5 07:34:12 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 5 Feb 2024 07:34:12 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v4] In-Reply-To: References: Message-ID: <0QU_mFRskI_zOA6DKY5ebWfgf14n4QyK4feLgH30ma0=.5a9e2eea-939c-4a6c-a290-6dcd6e18a76e@github.com> On Fri, 2 Feb 2024 13:14:26 GMT, Laurent Bourg?s wrote: >> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed tests thanks to + copyright years tests/system/src/test/java/test/com/sun/marlin/ScaleX0Test.java line 113: > 111: > 112: // Restore stderr: > 113: System.setErr(defaultErrorStream); I missed one more thing earlier. The sleep of 2 seconds is an uncertain time, which can be made little more specific. - Add an onShown latch for Stage - Capture the stderr after stage is shown and keep the sleep of 2 seconds as is This makes it little clearer that the issue occurs after stage is shown. Here is the change to replace above code: CountDownLatch showLatch = new CountDownLatch(1); Platform.runLater(() -> { Stage stage = new Stage(); stage.setScene(scene); stage.setOnShown(s -> showLatch.countDown()); stage.show(); }); Util.waitForLatch(showLatch, 5, "Failed to show the stage."); // Capture stderr: System.setErr(new PrintStream(out, true)); try { Thread.sleep(2000L); } catch (InterruptedException ie) { Logger.getLogger(ScaleX0Test.class.getName()).log(Level.SEVERE, "interrupted", ie); } // Restore stderr: System.setErr(defaultErrorStream); Please check if this is a correct understanding. I tested it several times with and without the fix: Always Failed without fix and always passed with fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1477764299 From rlichten at openjdk.org Mon Feb 5 09:34:07 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Mon, 5 Feb 2024 09:34:07 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> On Fri, 2 Feb 2024 16:15:43 GMT, Andy Goryachev wrote: > I see it working right in macOS 14.2.1, by double-clicking on the column divider in the table header. > > Question to @effad : could you provide the measurements for this fix (before/after) please? Applying the patch improves performance (on my Threadripper 2950X)from: JFX 21.0.2+5 average run time: 2460 to: JFX 23-internal+0-2024-02-01-061822 average run time: 1119 so the speedup is quite remarkable and will probably be even better, if I follow @Maran23 advise to also pull `cell.updateTableRow(tableRow);` out of the loop. I will hopefully be able to provide an improved PR tomorrow. > A side comment: the default implementation of resizeColumnToFitContent() is to iterate over all the rows, and I think this is not right. The UI locks up if the table has, let's say, 10,000,000 rows. I think in this case it should instead pick a reasonable limited range (maybe a max 1000 rows or so) of rows based on what's currently visible, so as not to lock up the UI. This might be a separate improvement. I agree. However, in order to "not break things" we would have to introduce an API to users to be able to control the number of rows they want to be taken into account. Definitely a separate improvement. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1926559011 From mhanl at openjdk.org Mon Feb 5 09:48:06 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 5 Feb 2024 09:48:06 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> Message-ID: On Mon, 5 Feb 2024 09:31:37 GMT, Robert Lichtenberger wrote: > A side comment: the default implementation of resizeColumnToFitContent() is to iterate over all the rows, and I think this is not right. The UI locks up if the table has, let's say, 10,000,000 rows. I think in this case it should instead pick a reasonable limited range (maybe a max 1000 rows or so) of rows based on what's currently visible, so as not to lock up the UI. This might be a separate improvement. I agree as well. This is on my todo list for quite a while. The default auto size is done with 30 rows. If you double click the edge of the header, it will take ALL rows, which can be very slow. So +1 here. Also another idea I had is to take 15 top rows and 15 bttom rows into account. In case the table is sorted. We can disuss this more in a seperate issue. I will review this PR soon as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1926583385 From mhanl at openjdk.org Mon Feb 5 09:56:08 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 5 Feb 2024 09:56:08 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511 > reverted accidental indentation chang modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1556: > 1554: if (targetCell != null) { > 1555: if (targetIndex < 0) { > 1556: T cell = getCell(targetIndex); Is there a reason you call `getCell` here, but `getAvailableCell` below? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1477922425 From perini.davide at dpsoftware.org Mon Feb 5 10:01:45 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 5 Feb 2024 11:01:45 +0100 Subject: Can't restart my app with the latest JDK, regression. In-Reply-To: <56bf5b6a-f76d-5a0b-1c21-ba1ed693eb9d@gmail.com> References: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> <56bf5b6a-f76d-5a0b-1c21-ba1ed693eb9d@gmail.com> Message-ID: <0649af16-338d-4d62-817a-3fcc4c40dccd@dpsoftware.org> Hi John, thanks for the answer. The problem happen even with other JDKs like the Azul, corretto... The weird thing is that to reproduce it you need to package the program with jpackage and then execute the program using the generated exe. This is the only code needed to reproduce the issue. public static void main(String... args) throws IOException { String[] cmdToRunUsingArgs = {"cmd.exe", "/C", "C:\\Program Files\\Notepad++\\notepad++.exe"}; Runtime.getRuntime().exec(cmdToRunUsingArgs); Executors.newSingleThreadScheduledExecutor().schedule(() -> { System.exit(0); }, 30, TimeUnit.SECONDS); } It's very weird because the problem does not happen with the previous minor version of the JDK21, the JDK 21.01_12. I'm pretty sure now that this isn't related to JavaFX since the problem can be reproduced even without JavaFX. Problem must be in the JPackage. Thanks Davide Il 04/02/2024 18:17, John Hendrikx ha scritto: > > Hi, > > Does that Temurin build contain JavaFX, or is it just a new Temurin > build?? Did you change anything else besides the JDK used?? You could > try other JDK's (openjdk, corretto, etc) as well. > > Is there anything being logged that may indicate what went wrong? > > That all said, it seems really unlikely this is related to JavaFX. > > If System.exit(0) is killing both the new and old application, then it > wasn't really spawned independently, so you can look into that (you > could put a delay there, and see with a tool like `top` or Task > Manager says, and see whether the restarted app is a child process or > not). > > It's also possible the problem is in the tools/settings used to create > the ".exe", so see if you changed anything there. > > For more info, tips or other ways of doing restarts: > https://stackoverflow.com/questions/4159802/how-can-i-restart-a-java-application > > --John > > > On 04/02/2024 02:49, Davide Perini wrote: >> Hi there, >> my JavaFX 21.0.2 app experienced a very weird regression when >> switching from Temurin >> OpenJDK21U-jdk_x64_windows_hotspot_21.0.1_12 >> to >> OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13 >> >> I use this method to restart my app. >> >> public void restart() { >> // path to my exe app plus one string argument >> String[] cmdToRunUsingArgs = {"C:\Users\sblantipodi\AppData\Local\Firefly Luciferin\Firefly >> Luciferin.exe","string argument"}; >> try { >> Runtime.getRuntime().exec(cmdToRunUsingArgs); >> }catch (SecurityException | IOException e) { >> log.error(e.getMessage()); >> } >> javafx.application.Platform.exit(); >> System.exit(0); >> } >> >> It worked well since years until JDK 21.0.2_13. >> If I revert back to 21.0.1_12 it works well. >> >> That method should start a new instance of the app, and close the >> "old instance". >> >> With JDK 21.0.2_13, it closed the running instance but does not open >> a new instance. >> >> I don't know if open a bugreport to JDK but before opening the bug >> report I would like to ask you if that method to restart the app is >> correct or if you think that I can use a better way. >> >> Thanks >> Davide >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Mon Feb 5 10:37:22 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 5 Feb 2024 11:37:22 +0100 Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> Message-ID: Hi, just wanted to add my 2 cents, In my opinion, no operation in List/Table/TreeTable should be doing such measurements on all rows or columns (where cells need to be loaded, CSS aplied, etc) -- it just won't scale.? In my application many of my lists contain images, and pre-loading all of these to do measurements is just not possible (luckily I can use fixed size cells). So, I think that by default it should work on *visible* cells only, and use estimates for the rest of the cells.? This is how browsers deal with huge tables (they for example won't preload every image in a table to "measure" the size of cells).? The estimates can be adjusted as more cells have become visible (or nothing happens at all if the user is not interacting with the control). As I think there are wildly different requirements for each view, I think it may be a good idea to implement size estimations using a Strategy pattern (like the FocusModel and SelectionModel), where the default strategy is based on visible cells, and can be replaced with other strategies that measure or estimate differently.? Already there are implementations and ideas for: - Fixed size - Visible cells only + estimates - All cells - First 15, bottom 15 - First 1000 rows I don't think there will be a one size fits all, so I think externalizing this problem and having the user choose or even implement their own would be a more tenable solution.? I feel this problem has gone back and forth several times now during the life time of TableView :) --John On 05/02/2024 10:48, Marius Hanl wrote: > On Mon, 5 Feb 2024 09:31:37 GMT, Robert Lichtenberger wrote: > >> A side comment: the default implementation of resizeColumnToFitContent() is to iterate over all the rows, and I think this is not right. The UI locks up if the table has, let's say, 10,000,000 rows. I think in this case it should instead pick a reasonable limited range (maybe a max 1000 rows or so) of rows based on what's currently visible, so as not to lock up the UI. This might be a separate improvement. > I agree as well. This is on my todo list for quite a while. > The default auto size is done with 30 rows. If you double click the edge of the header, it will take ALL rows, which can be very slow. > So +1 here. Also another idea I had is to take 15 top rows and 15 bttom rows into account. In case the table is sorted. > We can disuss this more in a seperate issue. > > I will review this PR soon as well. > > ------------- > > PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1926583385 From rlichten at openjdk.org Mon Feb 5 12:54:06 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Mon, 5 Feb 2024 12:54:06 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> Message-ID: On Fri, 2 Feb 2024 10:39:49 GMT, Robert Lichtenberger wrote: >> Well, the `tableRow` is still set (but before the loop), we just update the index in this loop. >> It looks like setting the table row in this loop is not needed, just once above. I also don't see that `setTableRow` has any side effects. So maybe worth a try. > > You're right. I tried it out and it seems to work. I've tried out an improved version of the patch with cell.updateTableRow(tableRow) moved out of the loop. However, this makes overall performance a bit slower. This patch: > Warmup #0 > Warmup #1 > Warmup #2 > Warmup #3 > Warmup #4 > Run #0: 978 ms. > Run #1: 972 ms. > Run #2: 983 ms. > Run #3: 984 ms. > Run #4: 978 ms. > Run #5: 977 ms. > Run #6: 996 ms. > Run #7: 982 ms. > Run #8: 996 ms. > Run #9: 1044 ms. > Run #10: 1018 ms. > Run #11: 1058 ms. > Run #12: 1016 ms. > Run #13: 1006 ms. > Run #14: 1026 ms. > Run #15: 1029 ms. > Run #16: 1049 ms. > Run #17: 988 ms. > Run #18: 974 ms. > Run #19: 975 ms. > JFX 23-internal+0-2024-02-05-114532 average run time: 1001 vs. "improved version": > Warmup #0 > Warmup #1 > Warmup #2 > Warmup #3 > Warmup #4 > Run #0: 1037 ms. > Run #1: 1030 ms. > Run #2: 1034 ms. > Run #3: 1031 ms. > Run #4: 1033 ms. > Run #5: 1031 ms. > Run #6: 1015 ms. > Run #7: 1015 ms. > Run #8: 1013 ms. > Run #9: 1020 ms. > Run #10: 1013 ms. > Run #11: 1017 ms. > Run #12: 1019 ms. > Run #13: 1022 ms. > Run #14: 1025 ms. > Run #15: 1023 ms. > Run #16: 1024 ms. > Run #17: 1017 ms. > Run #18: 1025 ms. > Run #19: 1023 ms. > JFX 23-internal+0-2024-02-05-114532 average run time: 1023 Since the difference between the two is so small I reran the test with 500_000 rows. This patch: average run time: 9628 "Improved" patch: average run time: 10412 To that end, I'd leave it as is (although the performance differences are admittedly small). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1478182155 From angorya at openjdk.org Mon Feb 5 16:05:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Feb 2024 16:05:11 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> Message-ID: On Mon, 5 Feb 2024 09:31:37 GMT, Robert Lichtenberger wrote: > , in order to "not break things" we would have to introduce an API to users to be able to control the number of rows they want to be taken into account. I think the UI "breaking itself" is much worse than us changing the (buggy) behavior. The user gains very little if the UI locks up for several seconds (or minutes) trying to size every row. At the same time the user might simply double click on the header again (or better, just resize the offending column like they used to do since time immemorial) once a wide cell comes into view. Basically, I don't think the new API is required in this particular case; I think it's a bug and it should either size the visible rows or (visible + some margin). Of course, there is one more operation which guarantees a lock up with large models - sorting. There is no easy solution for sorting, and that's where we *might* need new APIs. And it is a totally separate issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1927330194 From mfox at openjdk.org Mon Feb 5 16:46:40 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 5 Feb 2024 16:46:40 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5] In-Reply-To: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> > Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. > > The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. Martin Fox has updated the pull request incrementally with two additional commits since the last revision: - Work-around for using a call not present in the Xcode 13.3 SDK. - Need correctly formed NSNotification when running tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/687/files - new: https://git.openjdk.org/jfx/pull/687/files/862067d8..ee8877d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=687&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=687&range=03-04 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/687.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/687/head:pull/687 PR: https://git.openjdk.org/jfx/pull/687 From kevin.rushforth at oracle.com Mon Feb 5 19:03:48 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 5 Feb 2024 11:03:48 -0800 Subject: Can't restart my app with the latest JDK, regression. In-Reply-To: <0649af16-338d-4d62-817a-3fcc4c40dccd@dpsoftware.org> References: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> <56bf5b6a-f76d-5a0b-1c21-ba1ed693eb9d@gmail.com> <0649af16-338d-4d62-817a-3fcc4c40dccd@dpsoftware.org> Message-ID: <85729ac3-8a2a-4af8-81bb-03372117b9d6@oracle.com> For others who might be curious, Davide filed a bug via bugreport.java.com and it is now available here: https://bugs.openjdk.org/browse/JDK-8325203 It is almost certainly a bug in jpackage. -- Kevin On 2/5/2024 2:01 AM, Davide Perini wrote: > Hi John, > thanks for the answer. > > The problem happen even with other JDKs like the Azul, corretto... > > The weird thing is that to reproduce it you need to package the > program with jpackage and then execute the program using the generated > exe. > > This is the only code needed to reproduce the issue. > > public static void main(String... args) throws IOException { > String[] cmdToRunUsingArgs = {"cmd.exe", "/C", "C:\\Program Files\\Notepad++\\notepad++.exe"}; > Runtime.getRuntime().exec(cmdToRunUsingArgs); > Executors.newSingleThreadScheduledExecutor().schedule(() -> { > System.exit(0); > }, 30, TimeUnit.SECONDS); > } > > It's very weird because the problem does not happen with the previous > minor version of the JDK21, the JDK 21.01_12. > > I'm pretty sure now that this isn't related to JavaFX since the > problem can be reproduced even without JavaFX. > > Problem must be in the JPackage. > > Thanks > Davide > > > > Il 04/02/2024 18:17, John Hendrikx ha scritto: >> >> Hi, >> >> Does that Temurin build contain JavaFX, or is it just a new Temurin >> build?? Did you change anything else besides the JDK used?? You could >> try other JDK's (openjdk, corretto, etc) as well. >> >> Is there anything being logged that may indicate what went wrong? >> >> That all said, it seems really unlikely this is related to JavaFX. >> >> If System.exit(0) is killing both the new and old application, then >> it wasn't really spawned independently, so you can look into that >> (you could put a delay there, and see with a tool like `top` or Task >> Manager says, and see whether the restarted app is a child process or >> not). >> >> It's also possible the problem is in the tools/settings used to >> create the ".exe", so see if you changed anything there. >> >> For more info, tips or other ways of doing restarts: >> https://stackoverflow.com/questions/4159802/how-can-i-restart-a-java-application >> >> --John >> >> >> On 04/02/2024 02:49, Davide Perini wrote: >>> Hi there, >>> my JavaFX 21.0.2 app experienced a very weird regression when >>> switching from Temurin >>> OpenJDK21U-jdk_x64_windows_hotspot_21.0.1_12 >>> to >>> OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13 >>> >>> I use this method to restart my app. >>> >>> public void restart() { >>> // path to my exe app plus one string argument >>> String[] cmdToRunUsingArgs = {"C:\Users\sblantipodi\AppData\Local\Firefly Luciferin\Firefly >>> Luciferin.exe","string argument"}; >>> try { >>> Runtime.getRuntime().exec(cmdToRunUsingArgs); >>> }catch (SecurityException | IOException e) { >>> log.error(e.getMessage()); >>> } >>> javafx.application.Platform.exit(); >>> System.exit(0); >>> } >>> >>> It worked well since years until JDK 21.0.2_13. >>> If I revert back to 21.0.1_12 it works well. >>> >>> That method should start a new instance of the app, and close the >>> "old instance". >>> >>> With JDK 21.0.2_13, it closed the running instance but does not open >>> a new instance. >>> >>> I don't know if open a bugreport to JDK but before opening the bug >>> report I would like to ask you if that method to restart the app is >>> correct or if you think that I can use a better way. >>> >>> Thanks >>> Davide >>> >>> >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From credmond at certak.com Mon Feb 5 20:31:04 2024 From: credmond at certak.com (Cormac Redmond) Date: Mon, 5 Feb 2024 20:31:04 +0000 Subject: TreeTableView / FilteredList momentary incorrect selection bug Message-ID: Hi folks, I have noticed an issue when combining TreeTableView and FilteredLists, where a wrong node is "selected" (I believe during some shift selection functionality in TreeTableView). Currently using JavaFX 21-ea+5 on Windows, but occurs in later builds too. First noticed in a much more complex scenario with many components, I narrowed it down quite a bit, and created the simplest example I could, to demonstrate what I think is a bug. Let's say you have a tree (TableTreeView) displayed like this (as per code below): root (invisible) | ggg1 | ggg1.1 | xxx1.2 | ggg1.3 | bbb2 | bbb2.1 | bbb2.2 | bbb2.3 | aaa3 | aaa3.1 | aaa3.2 | aaa3.3 If you select leaf node "aaa3.2", for example, and then filter using a string "ggg", the node "bbb2", is being selected unexpectedly/incorrectly in the process, where it shouldn't. This is the bug. Here's a simple way to reproduce the issue. Run the code, and look at the tree first. Observe that a leaf node "aaa3.2" is selected for you (the code selects this as a shortcut for you). Hit the button to filter with string "ggg", and notice the logging showing that "bbb2" -- the leaf node's parent's sibling, is incorrectly momentarily selected, before "null" is settled as the final selected value (null being correct). Why is this happening? Sample output of running the below code: Value of aaa3.2 from tree (for verification): aaa3.2 <---- printed to show the node about to be selected is the correct node Selecting item: aaa3.2 <---- printed to show the code is about to select it Selected item (as per listener): aaa3.2 <---- printed by the listener, showing it was selected About to filter on "ggg" <---- printed to show you hit the button, now the list is filtering which will change the tree Selected item (as per listener): bbb2 <---- printed by the listener, showing bbb2 is selected , why is this happening along the way? This seems like a bug. Maybe it's part of some "let's select the closest sibling" logic, but...why? And if so, it's not a consistent pattern/logic that I can understand. Selected item (as per listener): null <---- printed by the listener, showing null is "selected", which is fine / expected, as the *real* selected item has been filtered out Runnable code: import javafx.application.Application; import javafx.beans.binding.Bindings; import javafx.beans.property.ObjectProperty; import javafx.beans.property.SimpleObjectProperty; import javafx.beans.value.ObservableValue; import javafx.collections.FXCollections; import javafx.collections.transformation.FilteredList; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.VBox; import javafx.stage.Stage; import java.util.ArrayList; import java.util.List; import java.util.function.Predicate; public class TreeTableSelectBug extends Application { private final TreeTableView tree = new TreeTableView<>(); private final ObjectProperty> filterPredicate = new SimpleObjectProperty<>(); @Override public void start(Stage primaryStage) throws Exception { final VBox outer = new VBox(); tree.setShowRoot(false); tree.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); tree.setRoot(createTree()); addColumn(); // Print selection changes: there should only be two (initial selection, then final selection to "null" when nodes are filtered), but there is an extra one ("bbb2") in the middle. tree.getSelectionModel().selectedItemProperty().addListener((observable, oldValue, newValue) -> System.out.println("Selected item (as per listener): " + (tree.getSelectionModel().getSelectedItem() == null ? "null" : tree.getSelectionModel().getSelectedItem().getValue()))); final Button filterButton = new Button("Filter on \"ggg\""); outer.getChildren().addAll(filterButton, tree); final Scene scene = new Scene(outer, 640, 480); primaryStage.setScene(scene); primaryStage.show(); // Select a lead node: aaa3 -> aaa3.2 (as an example) final TreeItem aaa32 = tree.getRoot().getChildren().get(2).getChildren().get(1); System.out.println("Value of aaa3.2 from tree (for verification): " + aaa32.getValue()); // Expand it -- without expanding it, the bug won't occur aaa32.getParent().setExpanded(true); System.out.println("Selecting item: " + aaa32.getValue()); // Select an item, note it is printed. Same as a user clicking the row. tree.getSelectionModel().select(aaa32); filterButton.setOnAction(event -> { System.out.println("About to filter on \"ggg\""); // Filter based on "ggg" (the top parent node) filterPredicate.set(string -> string.toLowerCase().trim().contains("ggg")); // BUG: The output is the below. Note that "bbb2" gets selected along the way, for some reason. This is the bug. // // Output: // Value of aaa3.2 from tree (for verification): aaa3.2 // Selecting item: aaa3.2 // Selected item (as per listener): aaa3.2 // About to filter on "ggg": aaa3.2 // Selected item (as per listener): bbb2 // Selected item (as per listener): null }); } private SimpleTreeItem createTree() { // So, we have a tree like this: // ggg1 // | ggg1.1 // | xxx1.2 // | ggg1.3 // bbb2 // | bbb2.1 // | bbb2.2 // | bbb2.3 // aaa3 // | children // | aaa3.1 // | aaa3.2 // | aaa3.3 final List> gggChildren = new ArrayList<>(); gggChildren.add(new SimpleTreeItem<>("ggg1.1", null, filterPredicate)); gggChildren.add(new SimpleTreeItem<>("xxx1.2", null, filterPredicate)); gggChildren.add(new SimpleTreeItem<>("ggg1.3", null, filterPredicate)); final SimpleTreeItem gggTree = new SimpleTreeItem<>("ggg1", gggChildren, filterPredicate); final List> bbbChildren = new ArrayList<>(); bbbChildren.add(new SimpleTreeItem<>("bbb2.1", null, filterPredicate)); bbbChildren.add(new SimpleTreeItem<>("bbb2.2", null, filterPredicate)); bbbChildren.add(new SimpleTreeItem<>("bbb2.3", null, filterPredicate)); final SimpleTreeItem bbbTree = new SimpleTreeItem<>("bbb2", bbbChildren, filterPredicate); final List> aaaChildren = new ArrayList<>(); aaaChildren.add(new SimpleTreeItem<>("aaa3.1", null, filterPredicate)); aaaChildren.add(new SimpleTreeItem<>("aaa3.2", null, filterPredicate)); aaaChildren.add(new SimpleTreeItem<>("aaa3.3", null, filterPredicate)); final SimpleTreeItem aaaTree = new SimpleTreeItem<>("aaa3", aaaChildren, filterPredicate); final List> rootChildren = new ArrayList<>(); rootChildren.add(gggTree); rootChildren.add(bbbTree); rootChildren.add(aaaTree); return new SimpleTreeItem<>("root", rootChildren, filterPredicate); } static class SimpleTreeItem extends TreeItem { private final ObjectProperty> filter = new SimpleObjectProperty<>(); private FilteredList> children; public SimpleTreeItem(final T value, List> children, ObservableValue> filter) { super(value, null); if (filter != null) { this.filter.bind(filter); } if (children != null) { addChildren(children); } } private void addChildren(List> childrenParam) { children = new FilteredList<>(FXCollections.observableArrayList(childrenParam)); children.predicateProperty().bind(Bindings.createObjectBinding(() -> SimpleTreeItem.this::showNode, filter)); Bindings.bindContent(getChildren(), children); } private boolean showNode(SimpleTreeItem node) { if (filter.get() == null) { return true; } if (filter.get().test(node.getValue())) { // Node is directly matched -> so show it return true; } if (node.children != null) { // Are there children (or children of children...) that are matched? If yes we also need to show this node return node.children.getSource().stream().anyMatch(this::showNode); } return false; } } protected void addColumn() { TreeTableColumn column = new TreeTableColumn<>("Some column"); column.setPrefWidth(150); column.setCellFactory(param -> new TreeTableCell<>() { @Override protected void updateItem(String item, boolean empty) { super.updateItem(item, empty); if (empty || item == null) { setText(null); } else { setText(item); } } }); column.setCellValueFactory( param -> param.getValue().valueProperty() ); tree.getColumns().add(column); } public static void main(String[] args) { launch(args); } } Kind Regards, Cormac -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Mon Feb 5 21:56:36 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Mon, 5 Feb 2024 22:56:36 +0100 Subject: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> Message-ID: <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> I finally found some time to test the latest ea build and can confirm that it works now on Windows as expected. Next, I moved to Linux, more specifically Ubuntu 23.04, and encountered some issues: - The accent color detection does not work, i.e. it does not initially detect the value set in the settings and also does not change when I modify the accent color in the Ubuntu Settings. I can see some values changing in the map, however the end result is still the same - When opening the Ubuntu Settings application, the entire platform preferences map is updated with weird values but somehow changes back immediately after. Maybe it reports the default light mode colors for a split second when opening the settings? Once again I do not know whether this is intended or not as there is no definitive list of which operating systems are supported. Here is the obligatory preferences map on that system: On 1/30/2024 2:09 PM, Nir Lisker wrote: > > ?I'm under the impression that the last available 22+ea maven > release, which is now almost 3 months old, does not contain the > platform preferences API > > > You are correct, the new API was added a month after the latest ea > build. Versions 11-21 all had at least 1 ea release per month on > average. Not sure why 22 doesn't. > > Johan, do you do these releases or are they part of OpenJFX? > > On Tue, Jan 30, 2024 at 2:39?PM Christopher Schnick > wrote: > > Hello Nir, > > I'm not entirely familiar with every ea build, but I'm under the > impression that the last available 22+ea maven release, which is > now almost 3 months old, does not contain the platform preferences > API and also does not contain the kinda important css performance > regression fixes. > > On 1/30/2024 1:33 PM, Nir Lisker wrote: >> Hi Christopher, >> >> Looking at Maven Central, >> https://mvnrepository.com/artifact/org.openjfx/javafx, JavaFX >> releases ea builds there, which I sometimes use myself from >> Maven/Gradle. Version 21 had 6 ea versions, and 22 has 3. The >> release?cycle is 6 months per final version (aligned with OpenJDK). >> >> - Nir >> >> On Tue, Jan 30, 2024 at 2:18?PM Christopher Schnick >> wrote: >> >> Alright I will try out the new ea release once the fix is >> integrated. Other than that, everything works fine for me so >> far with observing colors using the platform-specific strings. >> >> As a side note, I think the community would have caught this >> issue earlier if there were more frequent maven releases of >> ea builds. As of right now, the only way to properly use >> recent ea features is downloading the jars and jmods manually >> from the jdk.java.net site, which is >> cumbersome. I don't know how much of the maven release >> pipeline is automated and how much work more frequent ea >> releases would be, but it would definitely help with early >> testing and adoption. >> >> On 1/29/2024 11:09 PM, Michael Strau? wrote: >>> I see that the names of the platform mappings defined in >>> WinApplication::getPlatformKeyMappings() are simply wrong >>> ("Windows.UIColor.ForegroundColor" instead of >>> "Windows.UIColor.Foreground"), so the platform mappings are >>> not applied to the properties. >>> >>> That's quite surprising, and it's a change that must have >>> slipped into the feature at a very late stage during >>> development, so that it went unnoticed by all reviewers. >>> I'll file a bug and prepare a fix for this issue. >>> >>> >>> On Mon, Jan 29, 2024 at 10:45?PM Christopher Schnick >>> wrote: >>> >>> Hello Michael, >>> >>> I took a look at the implementation and tried to find >>> the issue. From what I can see, the mappings returned >>> are correct: >>> >>> >>> >>> but it seems like they are somehow not applied the >>> PreferencesProperties: >>> >>> Let me know whether I can help with anything to debug >>> this issue. >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img.png Type: image/png Size: 97121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img1.png Type: image/png Size: 39755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img2.png Type: image/png Size: 36000 bytes Desc: not available URL: From lbourges at openjdk.org Tue Feb 6 00:03:50 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 6 Feb 2024 00:03:50 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> Message-ID: On Mon, 5 Feb 2024 09:45:25 GMT, Marius Hanl wrote: > A side comment: the default implementation of resizeColumnToFitContent() is to iterate over all the rows, and I think this is not right. The UI locks up if the table has, let's say, 10,000,000 rows. I think in this case it should instead pick a reasonable limited range (maybe a max 1000 rows or so) of rows based on what's currently visible, so as not to lock up the UI. This might be a separate improvement. Here is my jtable autofit column that uses sampling to avoid processing all rows: https://github.com/JMMC-OpenDev/jmcs/blob/61db740407dce5b38301ff67a8a3d77aa84ad3fe/src/main/java/fr/jmmc/jmcs/gui/util/AutofitTableColumns.java#L199 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1927600809 From angorya at openjdk.org Tue Feb 6 00:03:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 00:03:52 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <-lcMKtabvOPkX8SX0Oq6q2ax7NmBNqre1WdTDv2fsd0=.d93b56ba-03fe-4df1-b524-b774c4a31c8b@github.com> Message-ID: On Mon, 5 Feb 2024 12:51:15 GMT, Robert Lichtenberger wrote: >> You're right. I tried it out and it seems to work. > > I've tried out an improved version of the patch with cell.updateTableRow(tableRow) moved out of the loop. However, this makes overall performance a bit slower. > This patch: > >> Warmup #0 >> Warmup #1 >> Warmup #2 >> Warmup #3 >> Warmup #4 >> Run #0: 978 ms. >> Run #1: 972 ms. >> Run #2: 983 ms. >> Run #3: 984 ms. >> Run #4: 978 ms. >> Run #5: 977 ms. >> Run #6: 996 ms. >> Run #7: 982 ms. >> Run #8: 996 ms. >> Run #9: 1044 ms. >> Run #10: 1018 ms. >> Run #11: 1058 ms. >> Run #12: 1016 ms. >> Run #13: 1006 ms. >> Run #14: 1026 ms. >> Run #15: 1029 ms. >> Run #16: 1049 ms. >> Run #17: 988 ms. >> Run #18: 974 ms. >> Run #19: 975 ms. >> JFX 23-internal+0-2024-02-05-114532 average run time: 1001 > > vs. "improved version": > >> Warmup #0 >> Warmup #1 >> Warmup #2 >> Warmup #3 >> Warmup #4 >> Run #0: 1037 ms. >> Run #1: 1030 ms. >> Run #2: 1034 ms. >> Run #3: 1031 ms. >> Run #4: 1033 ms. >> Run #5: 1031 ms. >> Run #6: 1015 ms. >> Run #7: 1015 ms. >> Run #8: 1013 ms. >> Run #9: 1020 ms. >> Run #10: 1013 ms. >> Run #11: 1017 ms. >> Run #12: 1019 ms. >> Run #13: 1022 ms. >> Run #14: 1025 ms. >> Run #15: 1023 ms. >> Run #16: 1024 ms. >> Run #17: 1017 ms. >> Run #18: 1025 ms. >> Run #19: 1023 ms. >> JFX 23-internal+0-2024-02-05-114532 average run time: 1023 > > Since the difference between the two is so small I reran the test with 500_000 rows. > This patch: average run time: 9628 > "Improved" patch: average run time: 10412 > > To that end, I'd leave it as is (although the performance differences are admittedly small). thank you for the measurements! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1478601228 From angorya at openjdk.org Tue Feb 6 00:04:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 00:04:27 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> Message-ID: On Fri, 2 Feb 2024 16:00:28 GMT, Kevin Rushforth wrote: > I think `getClasses` is fine. My second choice would be `getClassNames`. Perhaps it might be `getStyleClasses()` to parallel one in `Node`? (I don't know why Node's method is called `getStyleClass` (singular) when it clearly returns multiple Strings.) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1927515960 From jhendrikx at openjdk.org Tue Feb 6 00:04:34 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Feb 2024 00:04:34 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> Message-ID: <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> On Mon, 5 Feb 2024 17:19:35 GMT, Andy Goryachev wrote: > > I think `getClasses` is fine. My second choice would be `getClassNames`. > > Perhaps it might be `getStyleClasses()` to parallel one in `Node`? (I don't know why Node's method is called `getStyleClass` (singular) when it clearly returns multiple Strings.) The problem with that choice is that it would need 2 passes, because there already is a method named like that: List getStyleClasses() We'd first need to get rid of it, then replace it with `Set getStyleClasses()`. Keeping it as a `List` I would not recommend, since selectors don't keep duplicates, and don't keep the order (they never did). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1928218068 From angorya at openjdk.org Tue Feb 6 00:04:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 00:04:40 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> Message-ID: On Mon, 5 Feb 2024 22:14:06 GMT, John Hendrikx wrote: > need 2 passes, because there already is a method named like that: oh yeah, sorry. `getStyleClassesSet()` ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1928264474 From jhendrikx at openjdk.org Tue Feb 6 00:04:45 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Feb 2024 00:04:45 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> Message-ID: <-xrX5h4pIZS8H5RfX7vzgdsxLaj0TsS9IF2UUkZft3U=.be5518f3-8647-4834-8ffe-2529953c4c25@github.com> On Mon, 5 Feb 2024 22:22:25 GMT, Andy Goryachev wrote: > > need 2 passes, because there already is a method named like that: > > oh yeah, sorry. `getStyleClassesSet()` ? That one is still available yes :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1928279865 From lbourges at openjdk.org Tue Feb 6 00:06:58 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 6 Feb 2024 00:06:58 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v5] In-Reply-To: References: Message-ID: > Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: improved rendez-vous to collect stderr ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1348/files - new: https://git.openjdk.org/jfx/pull/1348/files/51e55efe..20c22c91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=03-04 Stats: 26 lines in 1 file changed: 18 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1348.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1348/head:pull/1348 PR: https://git.openjdk.org/jfx/pull/1348 From angorya at openjdk.org Tue Feb 6 00:13:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 00:13:49 GMT Subject: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v3] In-Reply-To: <7xm2HROW5-_pmBRTqAFDYxXHutUSvnqijEke8rWcpz4=.7781ad2e-eeb0-4f74-aa67-bab40e93ed4d@github.com> References: <7xm2HROW5-_pmBRTqAFDYxXHutUSvnqijEke8rWcpz4=.7781ad2e-eeb0-4f74-aa67-bab40e93ed4d@github.com> Message-ID: On Fri, 2 Feb 2024 18:43:19 GMT, Martin Fox wrote: >> In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all. >> >> In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. >> >> The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. >> >> I also updated a few deprecated constants so this file no longer generates compiler warnings. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Now handling ESC ending the composition state. Minor setEnabled cleanup. > - Merge remote-tracking branch 'upstream/master' into macimefixes > - When IM enabled state changes we dismiss the IM window. > - Merge remote-tracking branch 'upstream/master' into macimefixes > - Comment tweaks > - Merge remote-tracking branch 'upstream/master' into macimefixes > - Modified method of determing which keyDowns are sent as KeyEvents. As far as I can tell, the new behavior matches the native app one. ??? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1351#pullrequestreview-1864065082 From michaelstrau2 at gmail.com Tue Feb 6 00:26:02 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 6 Feb 2024 01:26:02 +0100 Subject: Platform preferences theme detection In-Reply-To: <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> Message-ID: Hi Christopher! 1) Accent color detection is not yet implemented for Linux/GTK. I think this is a fairly recent addition for Ubuntu, probably in version 22. 2) I don't see this behavior on my Ubuntu 20.04 system (need to upgrade to 23 and test again). If you have acess to JBS, feel free to open a bug ticket to track this issue. On Mon, Feb 5, 2024 at 10:56?PM Christopher Schnick wrote: > I finally found some time to test the latest ea build and can confirm that > it works now on Windows as expected. > > Next, I moved to Linux, more specifically Ubuntu 23.04, and encountered > some issues: > - The accent color detection does not work, i.e. it does not initially > detect the value set in the settings and also does not change when I modify > the accent color in the Ubuntu Settings. I can see some values changing in > the map, however the end result is still the same > - When opening the Ubuntu Settings application, the entire platform > preferences map is updated with weird values but somehow changes back > immediately after. Maybe it reports the default light mode colors for a > split second when opening the settings? > > Once again I do not know whether this is intended or not as there is no > definitive list of which operating systems are supported. Here is the > obligatory preferences map on that system: > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img.png Type: image/png Size: 97121 bytes Desc: not available URL: From crschnick at xpipe.io Tue Feb 6 00:57:02 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Tue, 6 Feb 2024 01:57:02 +0100 Subject: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> Message-ID: <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> Alright, if the accent is not supported yet then almost everything is fine I guess. The settings issue is not noticeable as all the updates happen very fast. I want to open my previous question about detecting unsupported colors again here. So I assume that for example accent detection is not supported on any Linux system and I have not tested yet how widespread the support for color scheme detection is on other desktop environments. >From an application developer's point of view, the platform preferences feature loses some appeal if there is no way of enabling a control flow like: If the system color is supported use that one, else use the color that I manually define somehow. So it would be nice to either have a relatively simple way of detecting which basic color property foreground, background, accent, color scheme is actually supported or allow application developers to set the default value for that property manually. In this case, I could just set a good looking default accent color, which would then be returned on Linux systems as that property is not supported yet. I don't have access to the JBS, I'm not even sure how you get that. On 2/6/2024 1:26 AM, Michael Strau? wrote: > Hi Christopher! > > 1) Accent color detection is not yet implemented for Linux/GTK. I > think this is a fairly recent addition for Ubuntu, probably in version 22. > > 2) I don't see this behavior on my Ubuntu 20.04 system (need to > upgrade to 23 and test again). If you have acess to JBS, feel free to > open a bug ticket to track this issue. > > > On Mon, Feb 5, 2024 at 10:56?PM Christopher Schnick > wrote: > > I finally found some time to test the latest ea build and can > confirm that it works now on Windows as expected. > > Next, I moved to Linux, more specifically Ubuntu 23.04, and > encountered some issues: > - The accent color detection does not work, i.e. it does not > initially detect the value set in the settings and also does not > change when I modify the accent color in the Ubuntu Settings. I > can see some values changing in the map, however the end result is > still the same > - When opening the Ubuntu Settings application, the entire > platform preferences map is updated with weird values but somehow > changes back immediately after. Maybe it reports the default light > mode colors for a split second when opening the settings? > > Once again I do not know whether this is intended or not as there > is no definitive list of which operating systems are supported. > Here is the obligatory preferences map on that system: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img.png Type: image/png Size: 97121 bytes Desc: not available URL: From michaelstrau2 at gmail.com Tue Feb 6 03:19:33 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 6 Feb 2024 04:19:33 +0100 Subject: Preview features for JavaFX Message-ID: The discussion around the new Platform Preferences API has brought up a potential area where the API may lack a way to detect whether a particular preference is supported on a particular operating system [0]. Discussions like these will invariably come up when new API is released, and some of the real-world insights may prove to be very valuable. However, with the current development process, we specify and implement new features largely without feedback from application developers. I know that, in principle, developers can join in on the discussion on this mailing list. But the reality is that GA is the first time that a new feature gets wider exposure. All of this makes it very hard for us to ship new features, since we must be extremely careful to get it right the first time. The JDK uses incubator modules and preview features to address these challenges. It seems that OpenJFX will also potentially use an incubator module to introduce new controls [1]. This is great for modular features, but not so great for new API that is added to existing infrastructure. Maybe we could add something akin to preview features to OpenJFX: this could be as easy as documenting the new API to be in preview, or decorate the new API with a @PreviewFeature annotation. I don't think that it is necessary to go beyond simple documentation; in particular, we don't need this to be integrated with the Java compiler. Documenting new features to be preview features will enable us to ship features quicker, and ensure that what we're building is actually useful in the real world because we can actually go back and improve aspects of a feature without worrying as much about backwards compatibility. In particular, my suggestion is to ship the new Platform Preferences API as a preview feature for jfx22. [0] https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html [1] https://bugs.openjdk.org/browse/JDK-8309381 From rlichten at openjdk.org Tue Feb 6 06:27:00 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Tue, 6 Feb 2024 06:27:00 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> Message-ID: <3CeUNp7-Efme2w7qnjx0ERbdMLylZg4Sw3kqibZBD-0=.9dd5965f-2367-461c-b4b9-e782ca1cbad4@github.com> On Mon, 5 Feb 2024 16:02:46 GMT, Andy Goryachev wrote: > > , in order to "not break things" we would have to introduce an API to users to be able to control the number of rows they want to be taken into account. > > I think the UI "breaking itself" is much worse than us changing the (buggy) behavior. The user gains very little if the UI locks up for several seconds (or minutes) trying to size every row. I don't agree. Our production application usually loads 200 rows and lets the user load as many more rows as they see fit. It also provides a "fit all columns" function which will fit all columns of the table. Users are fine with a few seconds of blockage if they have loaded thousands of rows. But if the "fit all columns" function will no longer work, they will report a bug which I will not be able to fix, if JavaFX suddenly refuses to iterate over all the rows as it does now. So maybe we should: * Provide an API that let's the client specify how many rows should be taken into account * Make resizeColumnToFitContent available for clients > > At the same time the user might simply double click on the header again (or better, just resize the offending column like they used to do since time immemorial) once a wide cell comes into view. > > Basically, I don't think the new API is required in this particular case; I think it's a bug and it should either size the visible rows or (visible + some margin). Of course, there is one more operation which guarantees a lock up with large models - sorting. There is no easy solution for sorting, and that's where we _might_ need new APIs. And it is a totally separate issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1928861769 From r.lichtenberger at gmail.com Tue Feb 6 07:32:41 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Tue, 6 Feb 2024 08:32:41 +0100 Subject: Preview features for JavaFX In-Reply-To: References: Message-ID: <059e4e78-1c92-4251-aa96-d60fb1b3bac6@gmail.com> Seems like a good idea to me. From an application developer point of view I don't care if new parts are super-stable (they never really are). If they are marked as preview I'll take that as an additional caveat to not rely on API stability, etc. Robert Am 06.02.24 um 04:19 schrieb Michael Strau?: > The discussion around the new Platform Preferences API has brought up > a potential area where the API may lack a way to detect whether a > particular preference is supported on a particular operating system > [0]. > > Discussions like these will invariably come up when new API is > released, and some of the real-world insights may prove to be very > valuable. However, with the current development process, we specify > and implement new features largely without feedback from application > developers. I know that, in principle, developers can join in on the > discussion on this mailing list. But the reality is that GA is the > first time that a new feature gets wider exposure. > > All of this makes it very hard for us to ship new features, since we > must be extremely careful to get it right the first time. The JDK uses > incubator modules and preview features to address these challenges. It > seems that OpenJFX will also potentially use an incubator module to > introduce new controls [1]. > > This is great for modular features, but not so great for new API that > is added to existing infrastructure. Maybe we could add something akin > to preview features to OpenJFX: this could be as easy as documenting > the new API to be in preview, or decorate the new API with a > @PreviewFeature annotation. I don't think that it is necessary to go > beyond simple documentation; in particular, we don't need this to be > integrated with the Java compiler. > > Documenting new features to be preview features will enable us to ship > features quicker, and ensure that what we're building is actually > useful in the real world because we can actually go back and improve > aspects of a feature without worrying as much about backwards > compatibility. > > In particular, my suggestion is to ship the new Platform Preferences > API as a preview feature for jfx22. > > > [0] https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html > [1] https://bugs.openjdk.org/browse/JDK-8309381 From perini.davide at dpsoftware.org Tue Feb 6 09:33:48 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 6 Feb 2024 10:33:48 +0100 Subject: Can't restart my app with the latest JDK, regression. In-Reply-To: <85729ac3-8a2a-4af8-81bb-03372117b9d6@oracle.com> References: <25283849-f1ec-4036-b857-21f75e6bfafd@dpsoftware.org> <56bf5b6a-f76d-5a0b-1c21-ba1ed693eb9d@gmail.com> <0649af16-338d-4d62-817a-3fcc4c40dccd@dpsoftware.org> <85729ac3-8a2a-4af8-81bb-03372117b9d6@oracle.com> Message-ID: Thank you for sharing this info, I think it can be very interesting for the JavaFX community since most of us use JPackage to bundle our JavaFX apps :) Regards, Davide Il 05/02/2024 20:03, Kevin Rushforth ha scritto: > For others who might be curious, Davide filed a bug via > bugreport.java.com and it is now available here: > > https://bugs.openjdk.org/browse/JDK-8325203 > > It is almost certainly a bug in jpackage. > > -- Kevin > > > On 2/5/2024 2:01 AM, Davide Perini wrote: >> Hi John, >> thanks for the answer. >> >> The problem happen even with other JDKs like the Azul, corretto... >> >> The weird thing is that to reproduce it you need to package the >> program with jpackage and then execute the program using the >> generated exe. >> >> This is the only code needed to reproduce the issue. >> >> public static void main(String... args) throws IOException { >> String[] cmdToRunUsingArgs = {"cmd.exe", "/C", "C:\\Program Files\\Notepad++\\notepad++.exe"}; >> Runtime.getRuntime().exec(cmdToRunUsingArgs); >> Executors.newSingleThreadScheduledExecutor().schedule(() -> { >> System.exit(0); >> }, 30, TimeUnit.SECONDS); >> } >> >> It's very weird because the problem does not happen with the previous >> minor version of the JDK21, the JDK 21.01_12. >> >> I'm pretty sure now that this isn't related to JavaFX since the >> problem can be reproduced even without JavaFX. >> >> Problem must be in the JPackage. >> >> Thanks >> Davide >> >> >> >> Il 04/02/2024 18:17, John Hendrikx ha scritto: >>> >>> Hi, >>> >>> Does that Temurin build contain JavaFX, or is it just a new Temurin >>> build?? Did you change anything else besides the JDK used?? You >>> could try other JDK's (openjdk, corretto, etc) as well. >>> >>> Is there anything being logged that may indicate what went wrong? >>> >>> That all said, it seems really unlikely this is related to JavaFX. >>> >>> If System.exit(0) is killing both the new and old application, then >>> it wasn't really spawned independently, so you can look into that >>> (you could put a delay there, and see with a tool like `top` or Task >>> Manager says, and see whether the restarted app is a child process >>> or not). >>> >>> It's also possible the problem is in the tools/settings used to >>> create the ".exe", so see if you changed anything there. >>> >>> For more info, tips or other ways of doing restarts: >>> https://stackoverflow.com/questions/4159802/how-can-i-restart-a-java-application >>> >>> --John >>> >>> >>> On 04/02/2024 02:49, Davide Perini wrote: >>>> Hi there, >>>> my JavaFX 21.0.2 app experienced a very weird regression when >>>> switching from Temurin >>>> OpenJDK21U-jdk_x64_windows_hotspot_21.0.1_12 >>>> to >>>> OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13 >>>> >>>> I use this method to restart my app. >>>> >>>> public void restart() { >>>> // path to my exe app plus one string argument >>>> String[] cmdToRunUsingArgs = {"C:\Users\sblantipodi\AppData\Local\Firefly Luciferin\Firefly >>>> Luciferin.exe","string argument"}; >>>> try { >>>> Runtime.getRuntime().exec(cmdToRunUsingArgs); >>>> }catch (SecurityException | IOException e) { >>>> log.error(e.getMessage()); >>>> } >>>> javafx.application.Platform.exit(); >>>> System.exit(0); >>>> } >>>> >>>> It worked well since years until JDK 21.0.2_13. >>>> If I revert back to 21.0.1_12 it works well. >>>> >>>> That method should start a new instance of the app, and close the >>>> "old instance". >>>> >>>> With JDK 21.0.2_13, it closed the running instance but does not >>>> open a new instance. >>>> >>>> I don't know if open a bugreport to JDK but before opening the bug >>>> report I would like to ask you if that method to restart the app is >>>> correct or if you think that I can use a better way. >>>> >>>> Thanks >>>> Davide >>>> >>>> >>>> >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Tue Feb 6 10:31:18 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Feb 2024 10:31:18 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v9] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Inline node issue fix ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/3012fae8..cc89f12a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=07-08 Stats: 33 lines in 1 file changed: 13 ins; 5 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Tue Feb 6 10:34:03 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Feb 2024 10:34:03 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v8] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 09:20:35 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Code review changes Fixed the above issues. I have simplified the logic little bit so that it doesn't get confusing as I add more conditions. I tested using the monkey tester and automated tests. Please let me know if you find issue in any scenario. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1929218388 From arapte at openjdk.org Tue Feb 6 11:32:02 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Feb 2024 11:32:02 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v5] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 00:06:58 GMT, Laurent Bourg?s wrote: >> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > improved rendez-vous to collect stderr Provided two minor comments. Otherwise ready to approve. tests/system/src/test/java/test/com/sun/marlin/ScaleX0Test.java line 109: > 107: Stage stage = new Stage(); > 108: stage.setScene(scene); > 109: stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e -> Platform.runLater(launchLatch::countDown)); Not mandatory, but can be changed to `stage.setOnShown(e -> Platform.runLater(launchLatch::countDown));` The import `import javafx.stage.WindowEvent;` can be removed with this change. tests/system/src/test/java/test/com/sun/marlin/ScaleX0Test.java line 116: > 114: if (!launchLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)) { > 115: Assert.fail("Timeout waiting for stage to show"); > 116: } The Util class contains helper methods to bring consistency in tests that use such common calls, So would recommend to use: `Util.waitForLatch(launchLatch, TIMEOUT, "Failed to show the stage");` The error message gets prefixed with `Timeout:` in `Util.waitForLatch()` the import `import java.util.concurrent.TimeUnit;` can be removed with this change ------------- PR Review: https://git.openjdk.org/jfx/pull/1348#pullrequestreview-1864882224 PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1479602847 PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1479621791 From kpk at openjdk.org Tue Feb 6 11:43:00 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Feb 2024 11:43:00 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v2] In-Reply-To: References: Message-ID: <7geuBdPqjG9SQP0OeTJXpJbZIfUV7GdVEct3OumlHIE=.34058685-0de1-4086-9c1b-28f490bfe252@github.com> On Mon, 29 Jan 2024 09:09:40 GMT, Karthik P K wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed test package > > modules/javafx.graphics/src/main/java/com/sun/marlin/ArrayCacheDouble.java line 168: > >> 166: if (DO_CLEAN_DIRTY && (toIndex != 0)) { >> 167: // clean-up array of dirty part[fromIndex; toIndex[ >> 168: fill(array, fromIndex, toIndex, /*(double)*/ 0.0); > > Do you think /*(double)*/ will be helpful? In my opinion, it is not required. @bourgesl are planning to remove these comments? Wanted to check since the comment was resolved without change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1479636490 From lbourges at openjdk.org Tue Feb 6 13:49:13 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 6 Feb 2024 13:49:13 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v6] In-Reply-To: References: Message-ID: <5ZQGP8F7JyjcIZhHuaNvq3yUoGavPTYRpqtuDuKbM8U=.ce4fc632-b963-4082-9ae3-f28b4faf1e31@github.com> > Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: minor cleanup to simplify test and fixed imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1348/files - new: https://git.openjdk.org/jfx/pull/1348/files/20c22c91..45e786f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1348&range=04-05 Stats: 14 lines in 1 file changed: 3 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1348.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1348/head:pull/1348 PR: https://git.openjdk.org/jfx/pull/1348 From crschnick at xpipe.io Tue Feb 6 14:54:02 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Tue, 6 Feb 2024 15:54:02 +0100 Subject: Preview features for JavaFX In-Reply-To: <059e4e78-1c92-4251-aa96-d60fb1b3bac6@gmail.com> References: <059e4e78-1c92-4251-aa96-d60fb1b3bac6@gmail.com> Message-ID: I would add that during the 6 month release cycle, there is usually some time to get new features out in an ea release and receive early feedback that way. Maybe even in time that it can be incorporated into the next release if it is reasonable. In this concrete case there was no ea build available in maven central for 3 months that contained this new feature, so barely anyone used it. As an application developer that likes to try out new features, I would like to see more frequent maven releases, although I'm not sure how much work that is and if it is automated. Even if it is not possible to publish every early access release to maven, maybe push a maven release out on important points during development of the current release rather than in fixed intervals. One such important point would have been the release of the platform preferences. I see now that there is another ea release available on maven after a gap of 3 months, but that one does not contain the fix for Windows color schemes, so any Windows ea user will get a nonfunctional feature. Plus making maybe a small announcement when a new larger feature has been released for the first time in early access and linking to the appropriate maven release would result in a good real world test coverage and discussions with other developers. Best Christopher On 2/6/2024 8:32 AM, Robert Lichtenberger wrote: > Seems like a good idea to me. From an application developer point of > view I don't care if new parts are super-stable (they never really > are). If they are marked as preview I'll take that as an additional > caveat to not rely on API stability, etc. > > > Robert > > Am 06.02.24 um 04:19 schrieb Michael Strau?: >> The discussion around the new Platform Preferences API has brought up >> a potential area where the API may lack a way to detect whether a >> particular preference is supported on a particular operating system >> [0]. >> >> Discussions like these will invariably come up when new API is >> released, and some of the real-world insights may prove to be very >> valuable. However, with the current development process, we specify >> and implement new features largely without feedback from application >> developers. I know that, in principle, developers can join in on the >> discussion on this mailing list. But the reality is that GA is the >> first time that a new feature gets wider exposure. >> >> All of this makes it very hard for us to ship new features, since we >> must be extremely careful to get it right the first time. The JDK uses >> incubator modules and preview features to address these challenges. It >> seems that OpenJFX will also potentially use an incubator module to >> introduce new controls [1]. >> >> This is great for modular features, but not so great for new API that >> is added to existing infrastructure. Maybe we could add something akin >> to preview features to OpenJFX: this could be as easy as documenting >> the new API to be in preview, or decorate the new API with a >> @PreviewFeature annotation. I don't think that it is necessary to go >> beyond simple documentation; in particular, we don't need this to be >> integrated with the Java compiler. >> >> Documenting new features to be preview features will enable us to ship >> features quicker, and ensure that what we're building is actually >> useful in the real world because we can actually go back and improve >> aspects of a feature without worrying as much about backwards >> compatibility. >> >> In particular, my suggestion is to ship the new Platform Preferences >> API as a preview feature for jfx22. >> >> >> [0] >> https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html >> [1] https://bugs.openjdk.org/browse/JDK-8309381 From angorya at openjdk.org Tue Feb 6 15:56:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 15:56:01 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: <3CeUNp7-Efme2w7qnjx0ERbdMLylZg4Sw3kqibZBD-0=.9dd5965f-2367-461c-b4b9-e782ca1cbad4@github.com> References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> <3CeUNp7-Efme2w7qnjx0ERbdMLylZg4Sw3kqibZBD-0=.9dd5965f-2367-461c-b4b9-e782ca1cbad4@github.com> Message-ID: On Tue, 6 Feb 2024 06:24:18 GMT, Robert Lichtenberger wrote: > So maybe we should: > > * Provide an API that let's the client specify how many rows should be taken into account > * Make resizeColumnToFitContent available for clients Let's create an RFE. What would be your recommendation for the specific API? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1930102012 From angorya at openjdk.org Tue Feb 6 16:08:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 16:08:03 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v3] In-Reply-To: <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <9a4dEzutfDhNpDUoIwSFrwHrqTKTP4OSwzp0JV3chQ4=.36f68eaf-5a7a-4bf5-b6b2-aeadd5dbd53d@github.com> Message-ID: On Fri, 2 Feb 2024 13:30:19 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Deprecate for 23 and add new method Looks good, with minor changes. This also needs a CSR (which has already been requested). I'll re-approve once we all agree on the new method name. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 95: > 93: > 94: /** > 95: * Gets the set of style class names of this Selector. The returned set Maybe just "Gets the immutable set of style class names of this Selector." ? modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102: > 100: * @since 23 > 101: */ > 102: public abstract Set getClasses(); suggestion: `getStyleClassesSet()` getClasses() creates expectation of returning `Class<>`es. modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 200: > 198: @Override > 199: public Set getClasses() { > 200: return styleClassSet.stream().map(StyleClass::getStyleClassName).collect(Collectors.toUnmodifiableSet()); minor: could we reformat this on multiple lines, like the other? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1340#pullrequestreview-1865631005 PR Review Comment: https://git.openjdk.org/jfx/pull/1340#discussion_r1480084573 PR Review Comment: https://git.openjdk.org/jfx/pull/1340#discussion_r1480083671 PR Review Comment: https://git.openjdk.org/jfx/pull/1340#discussion_r1480081109 From andy.goryachev at oracle.com Tue Feb 6 16:11:45 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 6 Feb 2024 16:11:45 +0000 Subject: TreeTableView / FilteredList momentary incorrect selection bug In-Reply-To: References: Message-ID: Thank you for reporting the issue! Is this the same scenario as described in https://bugs.openjdk.org/browse/JDK-8321323 ? -andy From: openjfx-dev on behalf of Cormac Redmond Date: Monday, February 5, 2024 at 12:31 To: openjfx-dev at openjdk.org Subject: TreeTableView / FilteredList momentary incorrect selection bug Hi folks, I have noticed an issue when combining TreeTableView and FilteredLists, where a wrong node is "selected" (I believe during some shift selection functionality in TreeTableView). Currently using JavaFX 21-ea+5 on Windows, but occurs in later builds too. First noticed in a much more complex scenario with many components, I narrowed it down quite a bit, and created the simplest example I could, to demonstrate what I think is a bug. Let's say you have a tree (TableTreeView) displayed like this (as per code below): root (invisible) | ggg1 | ggg1.1 | xxx1.2 | ggg1.3 | bbb2 | bbb2.1 | bbb2.2 | bbb2.3 | aaa3 | aaa3.1 | aaa3.2 | aaa3.3 If you select leaf node "aaa3.2", for example, and then filter using a string "ggg", the node "bbb2", is being selected unexpectedly/incorrectly in the process, where it shouldn't. This is the bug. Here's a simple way to reproduce the issue. Run the code, and look at the tree first. Observe that a leaf node "aaa3.2" is selected for you (the code selects this as a shortcut for you). Hit the button to filter with string "ggg", and notice the logging showing that "bbb2" -- the leaf node's parent's sibling, is incorrectly momentarily selected, before "null" is settled as the final selected value (null being correct). Why is this happening? Sample output of running the below code: Value of aaa3.2 from tree (for verification): aaa3.2 <---- printed to show the node about to be selected is the correct node Selecting item: aaa3.2 <---- printed to show the code is about to select it Selected item (as per listener): aaa3.2 <---- printed by the listener, showing it was selected About to filter on "ggg" <---- printed to show you hit the button, now the list is filtering which will change the tree Selected item (as per listener): bbb2 <---- printed by the listener, showing bbb2 is selected , why is this happening along the way? This seems like a bug. Maybe it's part of some "let's select the closest sibling" logic, but...why? And if so, it's not a consistent pattern/logic that I can understand. Selected item (as per listener): null <---- printed by the listener, showing null is "selected", which is fine / expected, as the *real* selected item has been filtered out Runnable code: import javafx.application.Application; import javafx.beans.binding.Bindings; import javafx.beans.property.ObjectProperty; import javafx.beans.property.SimpleObjectProperty; import javafx.beans.value.ObservableValue; import javafx.collections.FXCollections; import javafx.collections.transformation.FilteredList; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.VBox; import javafx.stage.Stage; import java.util.ArrayList; import java.util.List; import java.util.function.Predicate; public class TreeTableSelectBug extends Application { private final TreeTableView tree = new TreeTableView<>(); private final ObjectProperty> filterPredicate = new SimpleObjectProperty<>(); @Override public void start(Stage primaryStage) throws Exception { final VBox outer = new VBox(); tree.setShowRoot(false); tree.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); tree.setRoot(createTree()); addColumn(); // Print selection changes: there should only be two (initial selection, then final selection to "null" when nodes are filtered), but there is an extra one ("bbb2") in the middle. tree.getSelectionModel().selectedItemProperty().addListener((observable, oldValue, newValue) -> System.out.println("Selected item (as per listener): " + (tree.getSelectionModel().getSelectedItem() == null ? "null" : tree.getSelectionModel().getSelectedItem().getValue()))); final Button filterButton = new Button("Filter on \"ggg\""); outer.getChildren().addAll(filterButton, tree); final Scene scene = new Scene(outer, 640, 480); primaryStage.setScene(scene); primaryStage.show(); // Select a lead node: aaa3 -> aaa3.2 (as an example) final TreeItem aaa32 = tree.getRoot().getChildren().get(2).getChildren().get(1); System.out.println("Value of aaa3.2 from tree (for verification): " + aaa32.getValue()); // Expand it -- without expanding it, the bug won't occur aaa32.getParent().setExpanded(true); System.out.println("Selecting item: " + aaa32.getValue()); // Select an item, note it is printed. Same as a user clicking the row. tree.getSelectionModel().select(aaa32); filterButton.setOnAction(event -> { System.out.println("About to filter on \"ggg\""); // Filter based on "ggg" (the top parent node) filterPredicate.set(string -> string.toLowerCase().trim().contains("ggg")); // BUG: The output is the below. Note that "bbb2" gets selected along the way, for some reason. This is the bug. // // Output: // Value of aaa3.2 from tree (for verification): aaa3.2 // Selecting item: aaa3.2 // Selected item (as per listener): aaa3.2 // About to filter on "ggg": aaa3.2 // Selected item (as per listener): bbb2 // Selected item (as per listener): null }); } private SimpleTreeItem createTree() { // So, we have a tree like this: // ggg1 // | ggg1.1 // | xxx1.2 // | ggg1.3 // bbb2 // | bbb2.1 // | bbb2.2 // | bbb2.3 // aaa3 // | children // | aaa3.1 // | aaa3.2 // | aaa3.3 final List> gggChildren = new ArrayList<>(); gggChildren.add(new SimpleTreeItem<>("ggg1.1", null, filterPredicate)); gggChildren.add(new SimpleTreeItem<>("xxx1.2", null, filterPredicate)); gggChildren.add(new SimpleTreeItem<>("ggg1.3", null, filterPredicate)); final SimpleTreeItem gggTree = new SimpleTreeItem<>("ggg1", gggChildren, filterPredicate); final List> bbbChildren = new ArrayList<>(); bbbChildren.add(new SimpleTreeItem<>("bbb2.1", null, filterPredicate)); bbbChildren.add(new SimpleTreeItem<>("bbb2.2", null, filterPredicate)); bbbChildren.add(new SimpleTreeItem<>("bbb2.3", null, filterPredicate)); final SimpleTreeItem bbbTree = new SimpleTreeItem<>("bbb2", bbbChildren, filterPredicate); final List> aaaChildren = new ArrayList<>(); aaaChildren.add(new SimpleTreeItem<>("aaa3.1", null, filterPredicate)); aaaChildren.add(new SimpleTreeItem<>("aaa3.2", null, filterPredicate)); aaaChildren.add(new SimpleTreeItem<>("aaa3.3", null, filterPredicate)); final SimpleTreeItem aaaTree = new SimpleTreeItem<>("aaa3", aaaChildren, filterPredicate); final List> rootChildren = new ArrayList<>(); rootChildren.add(gggTree); rootChildren.add(bbbTree); rootChildren.add(aaaTree); return new SimpleTreeItem<>("root", rootChildren, filterPredicate); } static class SimpleTreeItem extends TreeItem { private final ObjectProperty> filter = new SimpleObjectProperty<>(); private FilteredList> children; public SimpleTreeItem(final T value, List> children, ObservableValue> filter) { super(value, null); if (filter != null) { this.filter.bind(filter); } if (children != null) { addChildren(children); } } private void addChildren(List> childrenParam) { children = new FilteredList<>(FXCollections.observableArrayList(childrenParam)); children.predicateProperty().bind(Bindings.createObjectBinding(() -> SimpleTreeItem.this::showNode, filter)); Bindings.bindContent(getChildren(), children); } private boolean showNode(SimpleTreeItem node) { if (filter.get() == null) { return true; } if (filter.get().test(node.getValue())) { // Node is directly matched -> so show it return true; } if (node.children != null) { // Are there children (or children of children...) that are matched? If yes we also need to show this node return node.children.getSource().stream().anyMatch(this::showNode); } return false; } } protected void addColumn() { TreeTableColumn column = new TreeTableColumn<>("Some column"); column.setPrefWidth(150); column.setCellFactory(param -> new TreeTableCell<>() { @Override protected void updateItem(String item, boolean empty) { super.updateItem(item, empty); if (empty || item == null) { setText(null); } else { setText(item); } } }); column.setCellValueFactory( param -> param.getValue().valueProperty() ); tree.getColumns().add(column); } public static void main(String[] args) { launch(args); } } Kind Regards, Cormac -------------- next part -------------- An HTML attachment was scrubbed... URL: From credmond at certak.com Tue Feb 6 16:20:58 2024 From: credmond at certak.com (Cormac Redmond) Date: Tue, 6 Feb 2024 16:20:58 +0000 Subject: TreeTableView / FilteredList momentary incorrect selection bug In-Reply-To: References: Message-ID: Hi Andy, Thank you; yes, that report was also myself via bugreport.java.com, I think -- I didn't actually realise it ended up anywhere. The mail I dropped here though is somewhat easier to digest / has less typos (for anyone interested)! Kind Regards, Cormac On Tue, 6 Feb 2024 at 16:11, Andy Goryachev wrote: > Thank you for reporting the issue! > > > > Is this the same scenario as described in > https://bugs.openjdk.org/browse/JDK-8321323 ? > > > > -andy > > > > > > *From: *openjfx-dev on behalf of Cormac > Redmond > *Date: *Monday, February 5, 2024 at 12:31 > *To: *openjfx-dev at openjdk.org > *Subject: *TreeTableView / FilteredList momentary incorrect selection bug > > Hi folks, > > > > I have noticed an issue when combining TreeTableView and FilteredLists, > where a wrong node is "selected" (I believe during some shift selection > functionality in TreeTableView). Currently using JavaFX 21-ea+5 on Windows, > but occurs in later builds too. > > > > First noticed in a much more complex scenario with many components, I > narrowed it down quite a bit, and created the simplest example I could, to > demonstrate what I think is a bug. > > > > Let's say you have a tree (TableTreeView) displayed like this (as per code > below): > > > > root (invisible) > > | ggg1 > > | ggg1.1 > | xxx1.2 > | ggg1.3 > | bbb2 > | bbb2.1 > | bbb2.2 > | bbb2.3 > | aaa3 > | aaa3.1 > | aaa3.2 > | aaa3.3 > > > > If you select leaf node "aaa3.2", for example, and then filter using a > string "ggg", the node "bbb2", is being selected unexpectedly/incorrectly > in the process, where it shouldn't. This is the bug. > > > > Here's a simple way to reproduce the issue. Run the code, and look at the > tree first. Observe that a leaf node "aaa3.2" is selected for you (the code > selects this as a shortcut for you). > > > > Hit the button to filter with string "ggg", and notice the logging showing > that "bbb2" -- the leaf node's parent's sibling, is incorrectly momentarily > selected, before "null" is settled as the final selected value (null being > correct). Why is this happening? > > Sample output of running the below code: > > > Value of aaa3.2 from tree (for verification): aaa3.2 <---- printed to > show the node about to be selected is the correct node > Selecting item: aaa3.2 <---- printed to show the code is about to > select it > Selected item (as per listener): aaa3.2 <---- printed by the > listener, showing it was selected > About to filter on "ggg" <---- printed to show you hit the > button, now the list is filtering which will change the tree > Selected item (as per listener): bbb2 <---- printed by the > listener, showing bbb2 is selected , why is this happening along the way? > This seems like a bug. Maybe it's part of some "let's select the closest > sibling" logic, but...why? And if so, it's not a consistent pattern/logic > that I can understand. > Selected item (as per listener): null <---- printed by the > listener, showing null is "selected", which is fine / expected, as the > *real* selected item has been filtered out > > > > Runnable code: > > > > import javafx.application.Application; > import javafx.beans.binding.Bindings; > import javafx.beans.property.ObjectProperty; > import javafx.beans.property.SimpleObjectProperty; > import javafx.beans.value.ObservableValue; > import javafx.collections.FXCollections; > import javafx.collections.transformation.FilteredList; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > import java.util.ArrayList; > import java.util.List; > import java.util.function.Predicate; > > public class TreeTableSelectBug extends Application { > private final TreeTableView tree = new TreeTableView<>(); > private final ObjectProperty> filterPredicate = new > SimpleObjectProperty<>(); > > @Override > public void start(Stage primaryStage) throws Exception { > final VBox outer = new VBox(); > > tree.setShowRoot(false); > tree.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > tree.setRoot(createTree()); > addColumn(); > > // Print selection changes: there should only be two (initial > selection, then final selection to "null" when nodes are filtered), but > there is an extra one ("bbb2") in the middle. > > tree.getSelectionModel().selectedItemProperty().addListener((observable, > oldValue, newValue) > -> System.out.println("Selected item (as per listener): " > + (tree.getSelectionModel().getSelectedItem() == null ? "null" : > tree.getSelectionModel().getSelectedItem().getValue()))); > > final Button filterButton = new Button("Filter on \"ggg\""); > > outer.getChildren().addAll(filterButton, tree); > final Scene scene = new Scene(outer, 640, 480); > primaryStage.setScene(scene); > primaryStage.show(); > > // Select a lead node: aaa3 -> aaa3.2 (as an example) > final TreeItem aaa32 = > tree.getRoot().getChildren().get(2).getChildren().get(1); > System.out.println("Value of aaa3.2 from tree (for verification): > " + aaa32.getValue()); > > // Expand it -- without expanding it, the bug won't occur > aaa32.getParent().setExpanded(true); > > System.out.println("Selecting item: " + aaa32.getValue()); > // Select an item, note it is printed. Same as a user clicking the > row. > tree.getSelectionModel().select(aaa32); > > filterButton.setOnAction(event -> { > System.out.println("About to filter on \"ggg\""); > > // Filter based on "ggg" (the top parent node) > filterPredicate.set(string -> > string.toLowerCase().trim().contains("ggg")); > > // BUG: The output is the below. Note that "bbb2" gets > selected along the way, for some reason. This is the bug. > // > // Output: > // Value of aaa3.2 from tree (for verification): aaa3.2 > // Selecting item: aaa3.2 > // Selected item (as per listener): aaa3.2 > // About to filter on "ggg": aaa3.2 > // Selected item (as per listener): bbb2 > // Selected item (as per listener): null > }); > } > > private SimpleTreeItem createTree() { > > // So, we have a tree like this: > // ggg1 > // | ggg1.1 > // | xxx1.2 > // | ggg1.3 > // bbb2 > // | bbb2.1 > // | bbb2.2 > // | bbb2.3 > // aaa3 > // | children > // | aaa3.1 > // | aaa3.2 > // | aaa3.3 > > final List> gggChildren = new ArrayList<>(); > gggChildren.add(new SimpleTreeItem<>("ggg1.1", null, > filterPredicate)); > gggChildren.add(new SimpleTreeItem<>("xxx1.2", null, > filterPredicate)); > gggChildren.add(new SimpleTreeItem<>("ggg1.3", null, > filterPredicate)); > final SimpleTreeItem gggTree = new > SimpleTreeItem<>("ggg1", gggChildren, filterPredicate); > > final List> bbbChildren = new ArrayList<>(); > bbbChildren.add(new SimpleTreeItem<>("bbb2.1", null, > filterPredicate)); > bbbChildren.add(new SimpleTreeItem<>("bbb2.2", null, > filterPredicate)); > bbbChildren.add(new SimpleTreeItem<>("bbb2.3", null, > filterPredicate)); > final SimpleTreeItem bbbTree = new > SimpleTreeItem<>("bbb2", bbbChildren, filterPredicate); > > final List> aaaChildren = new ArrayList<>(); > aaaChildren.add(new SimpleTreeItem<>("aaa3.1", null, > filterPredicate)); > aaaChildren.add(new SimpleTreeItem<>("aaa3.2", null, > filterPredicate)); > aaaChildren.add(new SimpleTreeItem<>("aaa3.3", null, > filterPredicate)); > final SimpleTreeItem aaaTree = new > SimpleTreeItem<>("aaa3", aaaChildren, filterPredicate); > > final List> rootChildren = new > ArrayList<>(); > rootChildren.add(gggTree); > rootChildren.add(bbbTree); > rootChildren.add(aaaTree); > > return new SimpleTreeItem<>("root", > rootChildren, > filterPredicate); > } > > static class SimpleTreeItem extends TreeItem { > > private final ObjectProperty> filter = new > SimpleObjectProperty<>(); > private FilteredList> children; > > public SimpleTreeItem(final T value, List> > children, ObservableValue> filter) { > super(value, null); > > if (filter != null) { > this.filter.bind(filter); > } > > if (children != null) { > addChildren(children); > } > } > > private void addChildren(List> childrenParam) { > children = new > FilteredList<>(FXCollections.observableArrayList(childrenParam)); > > children.predicateProperty().bind(Bindings.createObjectBinding(() -> > SimpleTreeItem.this::showNode, filter)); > > Bindings.bindContent(getChildren(), children); > } > > private boolean showNode(SimpleTreeItem node) { > if (filter.get() == null) { > return true; > } > > if (filter.get().test(node.getValue())) { > // Node is directly matched -> so show it > return true; > } > > if (node.children != null) { > // Are there children (or children of children...) that > are matched? If yes we also need to show this node > return > node.children.getSource().stream().anyMatch(this::showNode); > > } > return false; > } > } > > protected void addColumn() { > TreeTableColumn column = new > TreeTableColumn<>("Some column"); > column.setPrefWidth(150); > > column.setCellFactory(param -> new TreeTableCell<>() { > @Override > protected void updateItem(String item, boolean empty) { > super.updateItem(item, empty); > if (empty || item == null) { > setText(null); > } else { > setText(item); > } > } > }); > > column.setCellValueFactory( > param -> param.getValue().valueProperty() > ); > tree.getColumns().add(column); > } > > public static void main(String[] args) { > launch(args); > } > } > > > > > > > > Kind Regards, > > Cormac > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Feb 6 16:37:02 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Feb 2024 16:37:02 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v6] In-Reply-To: <5ZQGP8F7JyjcIZhHuaNvq3yUoGavPTYRpqtuDuKbM8U=.ce4fc632-b963-4082-9ae3-f28b4faf1e31@github.com> References: <5ZQGP8F7JyjcIZhHuaNvq3yUoGavPTYRpqtuDuKbM8U=.ce4fc632-b963-4082-9ae3-f28b4faf1e31@github.com> Message-ID: On Tue, 6 Feb 2024 13:49:13 GMT, Laurent Bourg?s wrote: >> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup to simplify test and fixed imports Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1348#pullrequestreview-1865792652 From angorya at openjdk.org Tue Feb 6 18:12:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 18:12:00 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 10:31:18 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Inline node issue fix Fails with "Emojis" data set (magenta line indicates where): ![Screenshot 2024-02-06 at 10 07 45](https://github.com/openjdk/jfx/assets/107069028/357628f5-cf08-4694-a2a6-ac4ed1532126) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1930497240 From angorya at openjdk.org Tue Feb 6 18:19:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 18:19:00 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 10:31:18 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Inline node issue fix Also fails with "Tabs": ![Screenshot 2024-02-06 at 10 14 34](https://github.com/openjdk/jfx/assets/107069028/bd0c5f62-22be-4403-82a4-3d0a8d5e8751) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1930506784 From angorya at openjdk.org Tue Feb 6 18:54:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 18:54:03 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Wed, 31 Jan 2024 00:34:57 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix test comment ... and with RIGHT alignment: ![Screenshot 2024-02-06 at 10 49 59](https://github.com/openjdk/jfx/assets/107069028/033d8fb5-e8b6-401e-b679-0389bccc9525) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1930559657 From angorya at openjdk.org Tue Feb 6 18:54:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 18:54:02 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v7] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Tue, 30 Jan 2024 00:35:24 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bug which confused char index with glyph index > > I think that it may be wise to do some clean-up of the code surrounding `TextRun` in some future PR. It's a mish-mash of things currently: > > - TextRun seems to be used in two ways. > - The "normal" way where multiple runs are constructed from a character array, and it retains references to the start/end in that array (although not a reference to the array itself). Because it has no reference to the chars from which it was created, a lot of functionality which could be encapsulated is externalized, and many internals of `TextRun` need to be exposed to feed those external functions. > - For javafx-web, which just wants to render a bunch of glyphs, unrelated to any text (so there is no character array it is based on, and its start/end values are bogus) > - There is a lot of code that pretends there is a difference between a `GlyphList` (clearly intended for rendering pure glyphs only) and `TextRun`, but there is only one implementation of `GlyphList` (`TextRun`). The code that does the actual rendering in `NGText` bluntly always casts a `GlyphList` to a `TextRun`. It does this for the sole purpose of finding out the start character position of the original characters the `TextRun` was created from (needed for selection rendering), yet, for `TextRun`s created by javafx-web this is irrelevant (it just always returns `0` for the start character position). > - It would have been better to do a conditional cast to `TextRun` in `NGText` so that javafx-web can use a much simpler implementation of `GlyphList` not based on `TextRun`. > - In a lot of places in this code and surrounding code, fields have been failed to be marked `private` or `final` even though they can be; this may have implications for what JIT can do. > - There are unused fields (`isCanonical` always returns `false`, `TextLine` is only stored to get its `RectBounds`, could just store that directly, it's `final`) > > A clean-up would entail: > - Include a reference to the characters it was created from in `TextRun` > - Encapsulate a lot of code into `TextRun` (moved from `PrismTextLayout`) that does calculations that needed both internal information of `TextRun` (that no longer needs to be exposed) and the original characters. > - Have javafx-web just implement `GlyphList` and change `NGText` to work with `GlyphList`. This class would be much smaller (`TextRun` has over a dozen fields). > - In `NGText` do an `instanceof` check to see if it is a `TextRun`, in which case its start offset can be used, oth... @hjohn are these screenshots show expected layout (with the CENTER alignment and regular spaces 0x20)? Shouldn't the leading/trailing whitespace be ignored? ![Screenshot 2024-02-06 at 10 47 18](https://github.com/openjdk/jfx/assets/107069028/b52c2b2c-06ba-4d23-a9bf-7cffa93d5f1d) ![Screenshot 2024-02-06 at 10 47 32](https://github.com/openjdk/jfx/assets/107069028/ab999606-5b0e-446b-a3fd-ac3fa45449fa) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1930558059 From duke at openjdk.org Tue Feb 6 19:56:05 2024 From: duke at openjdk.org (duke) Date: Tue, 6 Feb 2024 19:56:05 GMT Subject: Withdrawn: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <1uT4xxZuYjTXHmH_bH32b66orzAFI6ujcL0j_53T8hg=.ca77a6a0-d0a3-444d-886d-fb5353495328@github.com> On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1156 From angorya at openjdk.org Tue Feb 6 21:27:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 21:27:18 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v9] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). 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 28 additional commits since the last revision: - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - Merge remote-tracking branch 'origin/master' into 8299753.resize - undo merge - no new api - Merge remote-tracking branch 'origin/master' into 8299753.resize - cleanup - using snap inner space api - ... and 18 more: https://git.openjdk.org/jfx/compare/1b970fdc...9105b009 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/80286f26..9105b009 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=07-08 Stats: 294533 lines in 6591 files changed: 173273 ins; 84720 del; 36540 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From jhendrikx at openjdk.org Tue Feb 6 21:35:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Feb 2024 21:35:12 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v4] In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <_doivqwg2WlNtKD-kmJxPEaRLYnaP8LBbdjjjI1G6Sk=.262c50fc-5f65-480c-973c-329e184e75cf@github.com> > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Resolve review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1340/files - new: https://git.openjdk.org/jfx/pull/1340/files/382ef218..631ca587 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=02-03 Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1340.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1340/head:pull/1340 PR: https://git.openjdk.org/jfx/pull/1340 From jhendrikx at openjdk.org Tue Feb 6 21:38:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Feb 2024 21:38:02 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Wed, 31 Jan 2024 00:34:57 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix test comment Is this something specific to strike though? I've been testing with underline (because it conveniently shows you where the spaces are), but I haven't seen anything like the above. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1930790225 From angorya at openjdk.org Tue Feb 6 21:40:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 21:40:59 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Tue, 6 Feb 2024 21:35:43 GMT, John Hendrikx wrote: > specific to strike though I don't think so. I can turn it off and nothing changes, same for underline. I am not sure why it all suddenly started to fail - I did a clean build twice... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1930793983 From jhendrikx at openjdk.org Tue Feb 6 22:18:00 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Feb 2024 22:18:00 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Tue, 6 Feb 2024 21:38:41 GMT, Andy Goryachev wrote: > > specific to strike though > > I don't think so. I can turn it off and nothing changes, same for underline. I am not sure why it all suddenly started to fail - I did a clean build twice... Can you see if the new `TextLayoutTest` system test ran (with all my new tests) during the build, it should already be catching this problem? This seems to have regressed to the "before" situation. I'm not able to find the problem on my end at the moment, but I'll do a clean build and see if that gets anything. All the files I have locally are pushed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1930840916 From angorya at openjdk.org Tue Feb 6 22:18:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 22:18:24 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font Message-ID: Requesting content layout when font changes. This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. ------------- Commit messages: - Merge branch 'master' into 8307117.wrap - request layout when changing font Changes: https://git.openjdk.org/jfx/pull/1217/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307117 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1217.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1217/head:pull/1217 PR: https://git.openjdk.org/jfx/pull/1217 From angorya at openjdk.org Tue Feb 6 22:18:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 22:18:24 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: <54ZySvpcJLh8utUNu_cmQTW-oZ2BHEId2XYVith3xVs=.992854f2-05d3-475d-b81b-a5519731c7fc@github.com> On Mon, 21 Aug 2023 21:44:12 GMT, Andy Goryachev wrote: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. keep alive keep alive on second thought, let's address this independently of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1765372038 PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1852327075 PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1930780284 From angorya at openjdk.org Tue Feb 6 23:34:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Feb 2024 23:34:58 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Wed, 31 Jan 2024 00:34:57 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix test comment one thing: you may sync up with the latest master branch, that's the configuration I am testing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1930945346 From kevin.rushforth at oracle.com Tue Feb 6 23:58:28 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 6 Feb 2024 15:58:28 -0800 Subject: Preview features for JavaFX In-Reply-To: References: Message-ID: <96c2ffb3-b744-4066-91e5-95c58a7172c5@oracle.com> In order for preview features and incubating features to not cause more problems than they solve, there needs to be a robust way to ensure that applications and libraries don't use them without knowing that they are doing so. We know how to do that for a feature that lives in its own module (an incubating feature), but not how to do that for something like a preview feature. For incubating?features, this is relatively straight-forward, since they are delivered in a separate module that has "incubator" in the name, isn't resolved by default, and warns you at runtime when those modules are resolved. Adapting what the JDK does for JavaFX should be pretty easy, and retain the benefit that an app knows when they are using incubating features. I don't think it is feasible to do the same thing for preview features. The way the JDK preview features work is that a command line option is needed both at compile time and at runtime to opt into preview features for a specific release. This prevents using a preview API from an existing module and package without knowing that it is subject to change. Without a clear "opt in" mechanism to be able to use an API, an app would be able to accidentally use a feature whose API is unstable and quite possible might change. An annotation isn't good enough (and documentation certainly isn't sufficient). IDEs will still autocomplete and show the API, and once an app uses it -- accidentally or otherwise -- there is no indication at runtime that you are using a feature that will likely stop working without any notice in the next version. I don't see a good way to do this for JavaFX given the limitations. -- Kevin On 2/5/2024 7:19 PM, Michael Strau? wrote: > The discussion around the new Platform Preferences API has brought up > a potential area where the API may lack a way to detect whether a > particular preference is supported on a particular operating system > [0]. > > Discussions like these will invariably come up when new API is > released, and some of the real-world insights may prove to be very > valuable. However, with the current development process, we specify > and implement new features largely without feedback from application > developers. I know that, in principle, developers can join in on the > discussion on this mailing list. But the reality is that GA is the > first time that a new feature gets wider exposure. > > All of this makes it very hard for us to ship new features, since we > must be extremely careful to get it right the first time. The JDK uses > incubator modules and preview features to address these challenges. It > seems that OpenJFX will also potentially use an incubator module to > introduce new controls [1]. > > This is great for modular features, but not so great for new API that > is added to existing infrastructure. Maybe we could add something akin > to preview features to OpenJFX: this could be as easy as documenting > the new API to be in preview, or decorate the new API with a > @PreviewFeature annotation. I don't think that it is necessary to go > beyond simple documentation; in particular, we don't need this to be > integrated with the Java compiler. > > Documenting new features to be preview features will enable us to ship > features quicker, and ensure that what we're building is actually > useful in the real world because we can actually go back and improve > aspects of a feature without worrying as much about backwards > compatibility. > > In particular, my suggestion is to ship the new Platform Preferences > API as a preview feature for jfx22. > > > [0] https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html > [1] https://bugs.openjdk.org/browse/JDK-8309381 From kevin.rushforth at oracle.com Wed Feb 7 00:03:23 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 6 Feb 2024 16:03:23 -0800 Subject: Preview features for JavaFX In-Reply-To: References: <059e4e78-1c92-4251-aa96-d60fb1b3bac6@gmail.com> Message-ID: <4f8afeb6-74fb-4481-b0ef-969dc00d5a63@oracle.com> Announcing new features and encouraging testing of those features is a good idea. We should do that more often, especially in cases where feedback on the API is important. Developers who are willing to download the ea builds (SDK or JMODs) can do so right away, since builds are published weekly. Gluon produces the maven releases, so Johan can probably answer the question about the frequency of EA snapshots in maven central. -- Kevin On 2/6/2024 6:54 AM, Christopher Schnick wrote: > I would add that during the 6 month release cycle, there is usually > some time to get new features out in an ea release and receive early > feedback that way. Maybe even in time that it can be incorporated into > the next release if it is reasonable. > > In this concrete case there was no ea build available in maven central > for 3 months that contained this new feature, so barely anyone used > it. As an application developer that likes to try out new features, I > would like to see more frequent maven releases, although I'm not sure > how much work that is and if it is automated. Even if it is not > possible to publish every early access release to maven, maybe push a > maven release out on important points during development of the > current release rather than in fixed intervals. One such important > point would have been the release of the platform preferences. I see > now that there is another ea release available on maven after a gap of > 3 months, but that one does not contain the fix for Windows color > schemes, so any Windows ea user will get a nonfunctional feature. > > Plus making maybe a small announcement when a new larger feature has > been released for the first time in early access and linking to the > appropriate maven release would result in a good real world test > coverage and discussions with other developers. > > Best > Christopher > > On 2/6/2024 8:32 AM, Robert Lichtenberger wrote: >> Seems like a good idea to me. From an application developer point of >> view I don't care if new parts are super-stable (they never really >> are). If they are marked as preview I'll take that as an additional >> caveat to not rely on API stability, etc. >> >> >> Robert >> >> Am 06.02.24 um 04:19 schrieb Michael Strau?: >>> The discussion around the new Platform Preferences API has brought up >>> a potential area where the API may lack a way to detect whether a >>> particular preference is supported on a particular operating system >>> [0]. >>> >>> Discussions like these will invariably come up when new API is >>> released, and some of the real-world insights may prove to be very >>> valuable. However, with the current development process, we specify >>> and implement new features largely without feedback from application >>> developers. I know that, in principle, developers can join in on the >>> discussion on this mailing list. But the reality is that GA is the >>> first time that a new feature gets wider exposure. >>> >>> All of this makes it very hard for us to ship new features, since we >>> must be extremely careful to get it right the first time. The JDK uses >>> incubator modules and preview features to address these challenges. It >>> seems that OpenJFX will also potentially use an incubator module to >>> introduce new controls [1]. >>> >>> This is great for modular features, but not so great for new API that >>> is added to existing infrastructure. Maybe we could add something akin >>> to preview features to OpenJFX: this could be as easy as documenting >>> the new API to be in preview, or decorate the new API with a >>> @PreviewFeature annotation. I don't think that it is necessary to go >>> beyond simple documentation; in particular, we don't need this to be >>> integrated with the Java compiler. >>> >>> Documenting new features to be preview features will enable us to ship >>> features quicker, and ensure that what we're building is actually >>> useful in the real world because we can actually go back and improve >>> aspects of a feature without worrying as much about backwards >>> compatibility. >>> >>> In particular, my suggestion is to ship the new Platform Preferences >>> API as a preview feature for jfx22. >>> >>> >>> [0] >>> https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html >>> >>> [1] https://bugs.openjdk.org/browse/JDK-8309381 From kcr at openjdk.org Wed Feb 7 00:08:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Feb 2024 00:08:59 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v4] In-Reply-To: <_doivqwg2WlNtKD-kmJxPEaRLYnaP8LBbdjjjI1G6Sk=.262c50fc-5f65-480c-973c-329e184e75cf@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <_doivqwg2WlNtKD-kmJxPEaRLYnaP8LBbdjjjI1G6Sk=.262c50fc-5f65-480c-973c-329e184e75cf@github.com> Message-ID: <6V5YW8KPT_jKKrVuIqFn7DKuLc70fQ16jzJRl0AH1Dc=.a37d2697-64e2-42a4-b2be-1a675cac645e@github.com> On Tue, 6 Feb 2024 21:35:12 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Resolve review comments So we can add `getStyleClassesSet` to the list of possible method names. I think the word "class" should be in the name of the method, which excludes `getStyles` and `getStyleNames`, leaving the following: getStyleClassNames getClasses getClassNames getStyleClassesSet Any of them seem OK to me. I don't have a strong preference. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1930988290 From kcr at openjdk.org Wed Feb 7 00:10:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Feb 2024 00:10:58 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:44:12 GMT, Andy Goryachev wrote: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. Reviewers: @arapte @karthikpandelu This seems reasonable, but I'll let Ambarish and Karthik review. My only question is whether it would it be possible to create an automated test for this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1930991665 From michaelstrau2 at gmail.com Wed Feb 7 01:06:00 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 7 Feb 2024 02:06:00 +0100 Subject: Preview features for JavaFX In-Reply-To: <96c2ffb3-b744-4066-91e5-95c58a7172c5@oracle.com> References: <96c2ffb3-b744-4066-91e5-95c58a7172c5@oracle.com> Message-ID: Hi Kevin, my suggestion would be to annotate and document the preview API (at least annotations do show up by default in most IDEs), and emit a one-time runtime warning when the API is used (this works for methods and constructors). This would make it quite visible to developers that they are using a preview feature, or that a third-party library uses a preview feature. The runtime warning can be suppressed with a command line parameter such as "javafx.enablePreviewFeatures". A more drastic approach would be to throw an exception from new APIs when the parameter is not specified. Given that there are very tangible benefits to previewing new API, this would seem to me like a good enough solution. On Wed, Feb 7, 2024 at 12:59?AM Kevin Rushforth wrote: > > In order for preview features and incubating features to not cause more > problems than they solve, there needs to be a robust way to ensure that > applications and libraries don't use them without knowing that they are > doing so. We know how to do that for a feature that lives in its own > module (an incubating feature), but not how to do that for something > like a preview feature. > > For incubating features, this is relatively straight-forward, since they > are delivered in a separate module that has "incubator" in the name, > isn't resolved by default, and warns you at runtime when those modules > are resolved. Adapting what the JDK does for JavaFX should be pretty > easy, and retain the benefit that an app knows when they are using > incubating features. > > I don't think it is feasible to do the same thing for preview features. > The way the JDK preview features work is that a command line option is > needed both at compile time and at runtime to opt into preview features > for a specific release. This prevents using a preview API from an > existing module and package without knowing that it is subject to > change. Without a clear "opt in" mechanism to be able to use an API, an > app would be able to accidentally use a feature whose API is unstable > and quite possible might change. An annotation isn't good enough (and > documentation certainly isn't sufficient). IDEs will still autocomplete > and show the API, and once an app uses it -- accidentally or otherwise > -- there is no indication at runtime that you are using a feature that > will likely stop working without any notice in the next version. > > I don't see a good way to do this for JavaFX given the limitations. > > -- Kevin From kpk at openjdk.org Wed Feb 7 05:27:00 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Feb 2024 05:27:00 GMT Subject: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v6] In-Reply-To: <5ZQGP8F7JyjcIZhHuaNvq3yUoGavPTYRpqtuDuKbM8U=.ce4fc632-b963-4082-9ae3-f28b4faf1e31@github.com> References: <5ZQGP8F7JyjcIZhHuaNvq3yUoGavPTYRpqtuDuKbM8U=.ce4fc632-b963-4082-9ae3-f28b4faf1e31@github.com> Message-ID: On Tue, 6 Feb 2024 13:49:13 GMT, Laurent Bourg?s wrote: >> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > minor cleanup to simplify test and fixed imports Marked as reviewed by kpk (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1348#pullrequestreview-1866929656 From kpk at openjdk.org Wed Feb 7 05:28:57 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Feb 2024 05:28:57 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 18:09:40 GMT, Andy Goryachev wrote: > Fails with "Emojis" data set (magenta line indicates where): > I forgot to mention that I didn't test with emojis. I wanted to make it work with text with all scenario and then move to emojis. Now that we have text related issues fixed, I will check this. With tabs it works properly on the text and on the tab spaces it fails now. I will look into this as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1931312819 From lbourges at openjdk.org Wed Feb 7 06:58:59 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 7 Feb 2024 06:58:59 GMT Subject: Integrated: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 In-Reply-To: References: Message-ID: On Wed, 24 Jan 2024 14:55:21 GMT, Laurent Bourg?s wrote: > Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java This pull request has now been integrated. Changeset: 172c491d Author: Laurent Bourg?s URL: https://git.openjdk.org/jfx/commit/172c491dae4b774012589d991c898f12ccb44a4c Stats: 340 lines in 14 files changed: 276 ins; 10 del; 54 mod 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 Reviewed-by: kpk, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1348 From rlichten at openjdk.org Wed Feb 7 07:42:59 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 7 Feb 2024 07:42:59 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> <3CeUNp7-Efme2w7qnjx0ERbdMLylZg4Sw3kqibZBD-0=.9dd5965f-2367-461c-b4b9-e782ca1cbad4@github.com> Message-ID: On Tue, 6 Feb 2024 15:53:07 GMT, Andy Goryachev wrote: > > So maybe we should: > > > > * Provide an API that let's the client specify how many rows should be taken into account > > * Make resizeColumnToFitContent available for clients > > Let's create an RFE. What would be your recommendation for the specific API? At first I had only thought about a simple "setColumnFitSamplSize(int sampleSize)" method. However, @hjohn s suggestion of a strategy pattern seems convincing to me: It allows the client to specify how the required column width is calculated. I'm not quite sure how to approach this however. If we have a "ColumnFitStrategy" interface/baseclass with just a simple "calculateColumnWidth(int column)" this would not help clients since they don't have access to a lot of the stuff that's happening inside resizeColumnToFitContent. If, on the other hand, we only allow a "ColumnFitRowSelection" interface/baseclass that will return the rows to be used for measuring, the client code will not be able to optimize in some cases (e.g. you have graphics in your table; loading them is expensive; but you know the size of the graphics and could thus give a "correct" required size without really loading/applying css). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1931449204 From rlichten at openjdk.org Wed Feb 7 07:43:00 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 7 Feb 2024 07:43:00 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: <1Z3lcTst6eo84_ywHqCq978D8IkbmD1Cc-u8gL8efHg=.e16d9481-6241-4e5e-8865-1486e50d110d@github.com> Message-ID: On Mon, 5 Feb 2024 09:45:25 GMT, Marius Hanl wrote: > I will review this PR soon as well. The discussion about a "bigger" solution aside I think the PR is still of value to improve performance, so I look forward to your review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1931452084 From rlichten at openjdk.org Wed Feb 7 08:16:58 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 7 Feb 2024 08:16:58 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. I've filed https://bugs.openjdk.org/browse/JDK-8325390 to prevent this PR from getting too much clutter. I hope this is the right approach for an RFE ... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1931496944 From mhanl at openjdk.org Wed Feb 7 08:54:58 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 7 Feb 2024 08:54:58 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 670: > 668: cell.updateTableRow(tableRow); > 669: cell.updateIndex(row); > 670: we could also check if we need/can call `tableRow.applyCss();` just only one time (below) (e.g. at first?), May works and improve performance, or may not work ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1481111741 From arapte at openjdk.org Wed Feb 7 09:15:58 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 7 Feb 2024 09:15:58 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:44:12 GMT, Andy Goryachev wrote: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved. minor: year should be 2024. We update copyright years in bulk before releases/new year, so in general one can avoid changing copyright year along with fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1217#discussion_r1481144684 From john.hendrikx at gmail.com Wed Feb 7 09:22:59 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 7 Feb 2024 10:22:59 +0100 Subject: Preview features for JavaFX In-Reply-To: References: <96c2ffb3-b744-4066-91e5-95c58a7172c5@oracle.com> Message-ID: <830a320a-2867-97d1-ebf0-1905170f0adc@gmail.com> Hi Kevin, Michael, I think throwing an exception when using features that are preview without a prerequisite property being present or set to some value would be a good idea.? JavaFX has quite a few properties already, and a special one for previews would make it possible to ensure that such a feature is not being used without being aware of it. I would suggest making the property consists of keys (comma separated) so you must opt-in to each preview feature separately, or having multiple properties that follow a specific pattern. A preview check can be as simple as: ???? if (!Boolean.getProperty("javafx.enablePreview.platformPrefs") ) throw new UnsupportedOperationException(STANDARD_DISCLAIMER + "preview feature, please enable: xyz"); The disclaimer can be a standard piece of text explaining what a preview feature is, what it means, and what guarantees we offer (as limited as they might be).? For example, I think preview features are still guaranteed to be maintained for the release version they target, but that may be altered or completely removed in a next major release. I think a warning line is insufficient, especially when preview feature use may be inherited via a dependency. --John On 07/02/2024 02:06, Michael Strau? wrote: > Hi Kevin, > > my suggestion would be to annotate and document the preview API (at > least annotations do show up by default in most IDEs), and emit a > one-time runtime warning when the API is used (this works for methods > and constructors). This would make it quite visible to developers that > they are using a preview feature, or that a third-party library uses a > preview feature. > > The runtime warning can be suppressed with a command line parameter > such as "javafx.enablePreviewFeatures". A more drastic approach would > be to throw an exception from new APIs when the parameter is not > specified. > > Given that there are very tangible benefits to previewing new API, > this would seem to me like a good enough solution. > > > On Wed, Feb 7, 2024 at 12:59?AM Kevin Rushforth > wrote: >> In order for preview features and incubating features to not cause more >> problems than they solve, there needs to be a robust way to ensure that >> applications and libraries don't use them without knowing that they are >> doing so. We know how to do that for a feature that lives in its own >> module (an incubating feature), but not how to do that for something >> like a preview feature. >> >> For incubating features, this is relatively straight-forward, since they >> are delivered in a separate module that has "incubator" in the name, >> isn't resolved by default, and warns you at runtime when those modules >> are resolved. Adapting what the JDK does for JavaFX should be pretty >> easy, and retain the benefit that an app knows when they are using >> incubating features. >> >> I don't think it is feasible to do the same thing for preview features. >> The way the JDK preview features work is that a command line option is >> needed both at compile time and at runtime to opt into preview features >> for a specific release. This prevents using a preview API from an >> existing module and package without knowing that it is subject to >> change. Without a clear "opt in" mechanism to be able to use an API, an >> app would be able to accidentally use a feature whose API is unstable >> and quite possible might change. An annotation isn't good enough (and >> documentation certainly isn't sufficient). IDEs will still autocomplete >> and show the API, and once an app uses it -- accidentally or otherwise >> -- there is no indication at runtime that you are using a feature that >> will likely stop working without any notice in the next version. >> >> I don't see a good way to do this for JavaFX given the limitations. >> >> -- Kevin From rlichten at openjdk.org Wed Feb 7 10:02:02 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 7 Feb 2024 10:02:02 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 08:52:32 GMT, Marius Hanl wrote: >> The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 670: > >> 668: cell.updateTableRow(tableRow); >> 669: cell.updateIndex(row); >> 670: > > we could also check if we need/can call `tableRow.applyCss();` just only one time (below) (e.g. at first?), > May works and improve performance, or may not work That doesn't work unfortunately. I tried this: boolean tableRowHasCss = false; for (int row = 0; row < rows; row++) { tableRow.updateIndex(row); cell.updateIndex(row); if ((cell.getText() != null && !cell.getText().isEmpty()) || cell.getGraphic() != null) { if (!tableRowHasCss) { tableRow.applyCss(); tableRowHasCss = true; } maxWidth = Math.max(maxWidth, cell.prefWidth(-1)); } } but if you have a table with this css: .oddbig .table-row-cell:odd{ -fx-font-size: 36; } Then only the css of the first row will be taken into account, i.e. the column wont size correctly. I've recorded a little video of the effect at https://youtu.be/-p0pv-i4K2s ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1481219613 From arapte at openjdk.org Wed Feb 7 10:25:57 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 7 Feb 2024 10:25:57 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:44:12 GMT, Andy Goryachev wrote: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. With this change observed a behavior that: When changing font size from smaller size to larger size, text is first layouted vertically and then layouted horizontally. Sharing screen capture: https://github.com/openjdk/jfx/assets/11330676/5cd3a70a-7aac-4339-9947-5f3817802377 I tried adding few more calls to the listener as below, but it did not change the behavior: registerChangeListener(control.fontProperty(), e -> { invalidateMetrics(); updateFontMetrics(); control.requestLayout(); contentView.requestLayout(); }); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1931729793 From johan.vos at gluonhq.com Wed Feb 7 10:33:26 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 7 Feb 2024 11:33:26 +0100 Subject: Preview features for JavaFX In-Reply-To: <4f8afeb6-74fb-4481-b0ef-969dc00d5a63@oracle.com> References: <059e4e78-1c92-4251-aa96-d60fb1b3bac6@gmail.com> <4f8afeb6-74fb-4481-b0ef-969dc00d5a63@oracle.com> Message-ID: As for the maven releases for EA snapshots: you're right, we're not building/publishing them weekly. We have an increasing number of requests for builds for particular configurations, and with the more frequent LTS versions, the total build processes are taking more time. All those builds are free, and where we used to get AWS credits for this, we don't have that any longer so it's all paid for by us (Gluon). Having said that, the automation in our build systems has improved considerably over the last months, so I hope we can increase the cadence of EA-snapshots again. Sorry about the delays. - Johan On Wed, Feb 7, 2024 at 1:04?AM Kevin Rushforth wrote: > Announcing new features and encouraging testing of those features is a > good idea. We should do that more often, especially in cases where > feedback on the API is important. Developers who are willing to download > the ea builds (SDK or JMODs) can do so right away, since builds are > published weekly. > > Gluon produces the maven releases, so Johan can probably answer the > question about the frequency of EA snapshots in maven central. > > -- Kevin > > On 2/6/2024 6:54 AM, Christopher Schnick wrote: > > I would add that during the 6 month release cycle, there is usually > > some time to get new features out in an ea release and receive early > > feedback that way. Maybe even in time that it can be incorporated into > > the next release if it is reasonable. > > > > In this concrete case there was no ea build available in maven central > > for 3 months that contained this new feature, so barely anyone used > > it. As an application developer that likes to try out new features, I > > would like to see more frequent maven releases, although I'm not sure > > how much work that is and if it is automated. Even if it is not > > possible to publish every early access release to maven, maybe push a > > maven release out on important points during development of the > > current release rather than in fixed intervals. One such important > > point would have been the release of the platform preferences. I see > > now that there is another ea release available on maven after a gap of > > 3 months, but that one does not contain the fix for Windows color > > schemes, so any Windows ea user will get a nonfunctional feature. > > > > Plus making maybe a small announcement when a new larger feature has > > been released for the first time in early access and linking to the > > appropriate maven release would result in a good real world test > > coverage and discussions with other developers. > > > > Best > > Christopher > > > > On 2/6/2024 8:32 AM, Robert Lichtenberger wrote: > >> Seems like a good idea to me. From an application developer point of > >> view I don't care if new parts are super-stable (they never really > >> are). If they are marked as preview I'll take that as an additional > >> caveat to not rely on API stability, etc. > >> > >> > >> Robert > >> > >> Am 06.02.24 um 04:19 schrieb Michael Strau?: > >>> The discussion around the new Platform Preferences API has brought up > >>> a potential area where the API may lack a way to detect whether a > >>> particular preference is supported on a particular operating system > >>> [0]. > >>> > >>> Discussions like these will invariably come up when new API is > >>> released, and some of the real-world insights may prove to be very > >>> valuable. However, with the current development process, we specify > >>> and implement new features largely without feedback from application > >>> developers. I know that, in principle, developers can join in on the > >>> discussion on this mailing list. But the reality is that GA is the > >>> first time that a new feature gets wider exposure. > >>> > >>> All of this makes it very hard for us to ship new features, since we > >>> must be extremely careful to get it right the first time. The JDK uses > >>> incubator modules and preview features to address these challenges. It > >>> seems that OpenJFX will also potentially use an incubator module to > >>> introduce new controls [1]. > >>> > >>> This is great for modular features, but not so great for new API that > >>> is added to existing infrastructure. Maybe we could add something akin > >>> to preview features to OpenJFX: this could be as easy as documenting > >>> the new API to be in preview, or decorate the new API with a > >>> @PreviewFeature annotation. I don't think that it is necessary to go > >>> beyond simple documentation; in particular, we don't need this to be > >>> integrated with the Java compiler. > >>> > >>> Documenting new features to be preview features will enable us to ship > >>> features quicker, and ensure that what we're building is actually > >>> useful in the real world because we can actually go back and improve > >>> aspects of a feature without worrying as much about backwards > >>> compatibility. > >>> > >>> In particular, my suggestion is to ship the new Platform Preferences > >>> API as a preview feature for jfx22. > >>> > >>> > >>> [0] > >>> > https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html > >>> > >>> [1] https://bugs.openjdk.org/browse/JDK-8309381 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Wed Feb 7 10:43:12 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Feb 2024 10:43:12 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix emoji issue ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/cc89f12a..43f1f186 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=08-09 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Wed Feb 7 10:47:08 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Feb 2024 10:47:08 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 10:43:12 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix emoji issue The issue with emojis and tabs are fixed. In Monkey tester with RichText option selected, I see issue in the last line shown in the screenshot below. ![Screenshot 2024-02-07 at 3 53 02?PM](https://github.com/openjdk/jfx/assets/26969459/0a900679-ad85-4949-bdec-8e9b7b25a6a5) Since the emoji itself is not rendered properly I don't think it is an issue relevant to this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1931769144 From mhanl at openjdk.org Wed Feb 7 10:48:04 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 7 Feb 2024 10:48:04 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 09:59:45 GMT, Robert Lichtenberger wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 670: >> >>> 668: cell.updateTableRow(tableRow); >>> 669: cell.updateIndex(row); >>> 670: >> >> we could also check if we need/can call `tableRow.applyCss();` just only one time (below) (e.g. at first?), >> May works and improve performance, or may not work > > That doesn't work unfortunately. I tried this: > > boolean tableRowHasCss = false; > for (int row = 0; row < rows; row++) { > tableRow.updateIndex(row); > cell.updateIndex(row); > > if ((cell.getText() != null && !cell.getText().isEmpty()) || cell.getGraphic() != null) { > if (!tableRowHasCss) { > tableRow.applyCss(); > tableRowHasCss = true; > } > maxWidth = Math.max(maxWidth, cell.prefWidth(-1)); > } > } > > but if you have a table with this css: > > .oddbig .table-row-cell:odd{ > -fx-font-size: 36; > } > > > Then only the css of the first row will be taken into account, i.e. the column wont size correctly. > I've recorded a little video of the effect at https://youtu.be/-p0pv-i4K2s Thanks for checking! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1358#discussion_r1481278071 From mhanl at openjdk.org Wed Feb 7 10:54:58 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 7 Feb 2024 10:54:58 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. Looks good to me. Checking `updateTableColumn` and `updateTableView`, I can see that those operation will clean up and register a lot of properties and listener, so it is a good thing to do that just once (since we never change the column or table inbetween). ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1358#pullrequestreview-1867503900 From kpk at openjdk.org Wed Feb 7 12:18:02 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Feb 2024 12:18:02 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 10:23:20 GMT, Ambarish Rapte wrote: >> Requesting content layout when font changes. >> >> This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. > > With this change observed a behavior that: When changing font size from smaller size to larger size, text is first layouted vertically and then layouted horizontally. > Sharing screen capture: > > https://github.com/openjdk/jfx/assets/11330676/5cd3a70a-7aac-4339-9947-5f3817802377 > > I tried adding few more calls to the listener as below, but it did not change the behavior: > > registerChangeListener(control.fontProperty(), e -> { > invalidateMetrics(); > updateFontMetrics(); > control.requestLayout(); > contentView.requestLayout(); > }); I can also see the same behaviour which @arapte mentioned above. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1931924252 From kevin.rushforth at oracle.com Wed Feb 7 12:21:58 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 7 Feb 2024 04:21:58 -0800 Subject: Preview features for JavaFX In-Reply-To: <830a320a-2867-97d1-ebf0-1905170f0adc@gmail.com> References: <96c2ffb3-b744-4066-91e5-95c58a7172c5@oracle.com> <830a320a-2867-97d1-ebf0-1905170f0adc@gmail.com> Message-ID: <010b221f-e06c-42eb-87c4-17a7584d4cae@oracle.com> Yes, something like an opt-in property might be workable and is worth considering. We would also want to explore ideas for producing a compile-time warning along with with a pattern to document them. I'm not familiar enough with what you can do with annotations, but maybe there is something there that could help. We should explore this further for JavaFX 23. -- Kevin On 2/7/2024 1:22 AM, John Hendrikx wrote: > Hi Kevin, Michael, > > I think throwing an exception when using features that are preview > without a prerequisite property being present or set to some value > would be a good idea.? JavaFX has quite a few properties already, and > a special one for previews would make it possible to ensure that such > a feature is not being used without being aware of it. > > I would suggest making the property consists of keys (comma separated) > so you must opt-in to each preview feature separately, or having > multiple properties that follow a specific pattern. > > A preview check can be as simple as: > > ???? if (!Boolean.getProperty("javafx.enablePreview.platformPrefs") ) > throw new UnsupportedOperationException(STANDARD_DISCLAIMER + "preview > feature, please enable: xyz"); > > The disclaimer can be a standard piece of text explaining what a > preview feature is, what it means, and what guarantees we offer (as > limited as they might be).? For example, I think preview features are > still guaranteed to be maintained for the release version they target, > but that may be altered or completely removed in a next major release. > > I think a warning line is insufficient, especially when preview > feature use may be inherited via a dependency. > > --John > > On 07/02/2024 02:06, Michael Strau? wrote: >> Hi Kevin, >> >> my suggestion would be to annotate and document the preview API (at >> least annotations do show up by default in most IDEs), and emit a >> one-time runtime warning when the API is used (this works for methods >> and constructors). This would make it quite visible to developers that >> they are using a preview feature, or that a third-party library uses a >> preview feature. >> >> The runtime warning can be suppressed with a command line parameter >> such as "javafx.enablePreviewFeatures". A more drastic approach would >> be to throw an exception from new APIs when the parameter is not >> specified. >> >> Given that there are very tangible benefits to previewing new API, >> this would seem to me like a good enough solution. >> >> >> On Wed, Feb 7, 2024 at 12:59?AM Kevin Rushforth >> wrote: >>> In order for preview features and incubating features to not cause more >>> problems than they solve, there needs to be a robust way to ensure that >>> applications and libraries don't use them without knowing that they are >>> doing so. We know how to do that for a feature that lives in its own >>> module (an incubating feature), but not how to do that for something >>> like a preview feature. >>> >>> For incubating features, this is relatively straight-forward, since >>> they >>> are delivered in a separate module that has "incubator" in the name, >>> isn't resolved by default, and warns you at runtime when those modules >>> are resolved. Adapting what the JDK does for JavaFX should be pretty >>> easy, and retain the benefit that an app knows when they are using >>> incubating features. >>> >>> I don't think it is feasible to do the same thing for preview features. >>> The way the JDK preview features work is that a command line option is >>> needed both at compile time and at runtime to opt into preview features >>> for a specific release. This prevents using a preview API from an >>> existing module and package without knowing that it is subject to >>> change. Without a clear "opt in" mechanism to be able to use an API, an >>> app would be able to accidentally use a feature whose API is unstable >>> and quite possible might change. An annotation isn't good enough (and >>> documentation certainly isn't sufficient). IDEs will still autocomplete >>> and show the API, and once an app uses it -- accidentally or otherwise >>> -- there is no indication at runtime that you are using a feature that >>> will likely stop working without any notice in the next version. >>> >>> I don't see a good way to do this for JavaFX given the limitations. >>> >>> -- Kevin From john.hendrikx at gmail.com Wed Feb 7 13:22:10 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 7 Feb 2024 14:22:10 +0100 Subject: Preview features for JavaFX In-Reply-To: <010b221f-e06c-42eb-87c4-17a7584d4cae@oracle.com> References: <96c2ffb3-b744-4066-91e5-95c58a7172c5@oracle.com> <830a320a-2867-97d1-ebf0-1905170f0adc@gmail.com> <010b221f-e06c-42eb-87c4-17a7584d4cae@oracle.com> Message-ID: Hi, I don't think it's possible to give a custom warning at compile time without the user having a specific annotation processor active (ie, to get the warning, they'd first need to set up an annotation processor which FX provides).? The problem here is that we can't enforce the use of the annotation processor unconditionally. The only annotation that you can use to intentionally create a compiler warning is the @Deprecated annotation (perhaps the compiler team should look into more annotations for this purpose). The deprecated annotation was used at the time of the first preview features to indicate their status, from JEP-12: > The earliest version of this JEP proposed to use the deprecation > mechanism for flagging APIs associated with preview features. > Consequently, in Java SE 12 and 13, the APIs associated with preview > features were terminally deprecated at birth, that is, annotated > with|@Deprecated(forRemoval=true, since=...)|when they were > introduced. For example, Java SE 13 declared anessential API > associated with text blocks > , > and areflective API associated with switch expressions > . > However, the deprecation-based approach was eventually dropped because > it was confusing to see an API element introduced in the same Java SE > release as it was deprecated, that is, to see|@since > 13|and|@Deprecated(forRemoval=true, since="13")|on the same API element. The PreviewFeature annotation can't be used I think, it's part of `jdk.internal.javac`. --John On 07/02/2024 13:21, Kevin Rushforth wrote: > Yes, something like an opt-in property might be workable and is worth > considering. We would also want to explore ideas for producing a > compile-time warning along with with a pattern to document them. I'm > not familiar enough with what you can do with annotations, but maybe > there is something there that could help. > > We should explore this further for JavaFX 23. > > -- Kevin > > > On 2/7/2024 1:22 AM, John Hendrikx wrote: >> Hi Kevin, Michael, >> >> I think throwing an exception when using features that are preview >> without a prerequisite property being present or set to some value >> would be a good idea.? JavaFX has quite a few properties already, and >> a special one for previews would make it possible to ensure that such >> a feature is not being used without being aware of it. >> >> I would suggest making the property consists of keys (comma >> separated) so you must opt-in to each preview feature separately, or >> having multiple properties that follow a specific pattern. >> >> A preview check can be as simple as: >> >> ???? if (!Boolean.getProperty("javafx.enablePreview.platformPrefs") ) >> throw new UnsupportedOperationException(STANDARD_DISCLAIMER + >> "preview feature, please enable: xyz"); >> >> The disclaimer can be a standard piece of text explaining what a >> preview feature is, what it means, and what guarantees we offer (as >> limited as they might be).? For example, I think preview features are >> still guaranteed to be maintained for the release version they >> target, but that may be altered or completely removed in a next major >> release. >> >> I think a warning line is insufficient, especially when preview >> feature use may be inherited via a dependency. >> >> --John >> >> On 07/02/2024 02:06, Michael Strau? wrote: >>> Hi Kevin, >>> >>> my suggestion would be to annotate and document the preview API (at >>> least annotations do show up by default in most IDEs), and emit a >>> one-time runtime warning when the API is used (this works for methods >>> and constructors). This would make it quite visible to developers that >>> they are using a preview feature, or that a third-party library uses a >>> preview feature. >>> >>> The runtime warning can be suppressed with a command line parameter >>> such as "javafx.enablePreviewFeatures". A more drastic approach would >>> be to throw an exception from new APIs when the parameter is not >>> specified. >>> >>> Given that there are very tangible benefits to previewing new API, >>> this would seem to me like a good enough solution. >>> >>> >>> On Wed, Feb 7, 2024 at 12:59?AM Kevin Rushforth >>> wrote: >>>> In order for preview features and incubating features to not cause >>>> more >>>> problems than they solve, there needs to be a robust way to ensure >>>> that >>>> applications and libraries don't use them without knowing that they >>>> are >>>> doing so. We know how to do that for a feature that lives in its own >>>> module (an incubating feature), but not how to do that for something >>>> like a preview feature. >>>> >>>> For incubating features, this is relatively straight-forward, since >>>> they >>>> are delivered in a separate module that has "incubator" in the name, >>>> isn't resolved by default, and warns you at runtime when those modules >>>> are resolved. Adapting what the JDK does for JavaFX should be pretty >>>> easy, and retain the benefit that an app knows when they are using >>>> incubating features. >>>> >>>> I don't think it is feasible to do the same thing for preview >>>> features. >>>> The way the JDK preview features work is that a command line option is >>>> needed both at compile time and at runtime to opt into preview >>>> features >>>> for a specific release. This prevents using a preview API from an >>>> existing module and package without knowing that it is subject to >>>> change. Without a clear "opt in" mechanism to be able to use an >>>> API, an >>>> app would be able to accidentally use a feature whose API is unstable >>>> and quite possible might change. An annotation isn't good enough (and >>>> documentation certainly isn't sufficient). IDEs will still >>>> autocomplete >>>> and show the API, and once an app uses it -- accidentally or otherwise >>>> -- there is no indication at runtime that you are using a feature that >>>> will likely stop working without any notice in the next version. >>>> >>>> I don't see a good way to do this for JavaFX given the limitations. >>>> >>>> -- Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Wed Feb 7 13:51:57 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 7 Feb 2024 13:51:57 +0000 Subject: Preview features for JavaFX Message-ID: Hi, Just adding my 2 cents to the discussion. I think there's a precedent to this that the JavaFX team was using back in JavaFX 8 and before it. It wasn't for preview features, but it had a somewhat similar purpose. There was an "@treatAsPrivate" annotation. This annotation was used in methods that were only meant to be used internally by JavaFX itself. They were an implementation detail. They could be used by programmers, but they had a risk of being removed or their behavior later being changed entirely. That annotation seemed to be enough. Some developers used these methods (including myself), and I don't remember any issues with this. Developers were well aware these methods could get removed and some of them have actually been removed. (I think they were also marked with the "@Deprecated" annotation so that you had an extra warning from the IDE, and the @treatAsPrivate annotation also hid them from the javadocs). I like the idea of preview features. Some features need to be tested by programmers for a long time before we are sure they can be set in stone. Like others have said this could also allow features to come out quicker. Thanks! Kind regards, -- Pedro Duque Vieira - https://www.pixelduke.com Sem v?rus.www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Wed Feb 7 15:06:18 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Feb 2024 15:06:18 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... John Hendrikx 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 16 additional commits since the last revision: - Merge branch 'openjdk:master' into feature/wrapped-aligned-text-rendering - Fix test comment - More test cases (for hard wrapping) and another small fix - Improve tests, fix a bug - Fix bug which confused char index with glyph index - Move test that needs QuantumToolkit to system tests - Clean-up, re-enable and extend ancient TextLayout test - TextRun getAdvance should return 0 when positions array is null - Fix justify alignment to take all trailing spaces into account - Fix trailing space calculation to access positions array directly - ... and 6 more: https://git.openjdk.org/jfx/compare/9842db9e...388696a6 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1236/files - new: https://git.openjdk.org/jfx/pull/1236/files/a49b99a6..388696a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=09-10 Stats: 2431 lines in 200 files changed: 1552 ins; 300 del; 579 mod Patch: https://git.openjdk.org/jfx/pull/1236.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236 PR: https://git.openjdk.org/jfx/pull/1236 From angorya at openjdk.org Wed Feb 7 15:45:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 15:45:06 GMT Subject: RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 08:14:26 GMT, Robert Lichtenberger wrote: > I hope this is the right approach for an RFE ... thank you for filing an RFE, @effad ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1932319542 From jhendrikx at openjdk.org Wed Feb 7 16:00:03 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Feb 2024 16:00:03 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Tue, 6 Feb 2024 23:32:25 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test comment > > one thing: you may sync up with the latest master branch, that's the configuration I am testing. @andy-goryachev-oracle I'm not quite seeing what you are seeing. Here is a screenshots of `LOGICAL` setting with the text `The quick brown fox jumps over the lazy dog`; notice that there is a horizontal scroll bar -- that looks incorrect: ![image](https://github.com/openjdk/jfx/assets/995917/0ce6b106-2fd6-4688-9f3c-ba7ec23484ad) Now, for the `VISUAL` setting it is a bit hard to see if it is doing the right thing because the `Text` node is lacking any kind of border to see where the actual bounds are. However, I do clearly see it responding to underline on/off, so it is taking that into account somehow (which makes sense for `VISUAL`) `VISUAL` with underline on (notice scroll bar): ![image](https://github.com/openjdk/jfx/assets/995917/90d770fc-3001-4492-ae68-0359739e81d9) And off (notice scroll bar is gone): ![image](https://github.com/openjdk/jfx/assets/995917/6171ec23-9a2f-4b13-81ff-5bfe999b1f30) So, it seems that: - Logical bounds still have a bug where the `Text` is getting a scroll bar - Visual bounds seem to be what you'd expect (I see no bugs -- text is correctly aligned with respect to **other** lines, but there may be trailing spaces that take up additional visual space which results in the overall alignment to be off (ie. right aligned text is not touching the right most edge, since there are spaces there, but **only** when strike through or underline is on (!!) ) -- again it is bit hard to tell as there is no border to see where the visual bounds really are -- you have to look at the horizonal scroll bar :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1932352725 From mfox at openjdk.org Wed Feb 7 17:36:11 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 7 Feb 2024 17:36:11 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5] In-Reply-To: <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> Message-ID: On Mon, 5 Feb 2024 16:46:40 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with two additional commits since the last revision: > > - Work-around for using a call not present in the Xcode 13.3 SDK. > - Need correctly formed NSNotification when running tests This is now compiling on 13.3 and I was able to do a Robot test run on macOS 14 with only one failure that's also present in the master branch. I still don't know why the compiler doesn't flag the `activate` call, in macOS 13 `NSApp` does not respond to that selector and will throw an exception if it's sent. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1932546143 From angorya at openjdk.org Wed Feb 7 19:15:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 19:15:00 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:44:12 GMT, Andy Goryachev wrote: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. The flicker you see is a subject of another ticket, [JDK-8305003](https://bugs.openjdk.org/browse/JDK-8305003). Possibly caused by [JDK-8097060](https://bugs.openjdk.org/browse/JDK-8097060). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1932700610 From michaelstrau2 at gmail.com Wed Feb 7 20:06:15 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 7 Feb 2024 21:06:15 +0100 Subject: Preview features proposal Message-ID: I've created a proposal that defines preview features [0]. The definition very closely matches the language used in JEP-12, but is adapted for JavaFX in some places. Additionally, I've created the internal helper class `PreviewFeature` that can be used to verify that applications have opted into using preview features at runtime. If the system property "javafx.enablePreview" system property has not been set, the `PreviewFeature.checkEnabled()` method will throw an exception similar to the following: is a preview feature of JavaFX 23. Preview features may be removed in a future release, or upgraded to permanent features of JavaFX. Programs can only use preview features when the following system property is set: -Djavafx.enablePreview=true If the system property has been set, the method will log a one-time warning to the error output stream, similar to the following: Note: This program uses the following preview feature of JavaFX 23: Preview features may be removed in a future release, or upgraded to permanent features of JavaFX. This warning can be disabled with the following system property: -Djavafx.suppressPreviewBanner=true I think that we should use the @Depcreated annotation to document API elements of preview features, with a @deprecated javadoc tag similar to the following: @deprecated This is a preview feature which may be changed or removed in a future release. The specification of @Deprecated specifically mentions this usage: "An element may be deprecated for any of several reasons, for example, its usage is likely to lead to errors; it may be changed incompatibly or removed in a future version; it has been superseded by a newer, usually preferable alternative; or it is obsolete." Finally, all preview features of a JavaFX release should be listed in the release notes. [0] https://github.com/openjdk/jfx/pull/1359 From angorya at openjdk.org Wed Feb 7 21:25:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 21:25:32 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font [v2] In-Reply-To: References: Message-ID: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: - works - tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1217/files - new: https://git.openjdk.org/jfx/pull/1217/files/6051f8d9..f9daad79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1217&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1217&range=00-01 Stats: 163 lines in 3 files changed: 145 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1217.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1217/head:pull/1217 PR: https://git.openjdk.org/jfx/pull/1217 From angorya at openjdk.org Wed Feb 7 21:41:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 21:41:10 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font [v3] In-Reply-To: References: Message-ID: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1217/files - new: https://git.openjdk.org/jfx/pull/1217/files/f9daad79..e888deae Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1217&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1217&range=01-02 Stats: 40 lines in 2 files changed: 0 ins; 33 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1217.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1217/head:pull/1217 PR: https://git.openjdk.org/jfx/pull/1217 From angorya at openjdk.org Wed Feb 7 22:55:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 22:55:03 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: <4-Mq2TAGkse0h7gM2pI3nKDh65dsbHzULyUbBzghaFs=.7bfb2751-8893-4c85-93a4-849ca5322ecb@github.com> On Wed, 7 Feb 2024 15:57:35 GMT, John Hendrikx wrote: >> one thing: you may sync up with the latest master branch, that's the configuration I am testing. > > @andy-goryachev-oracle > > I'm not quite seeing what you are seeing. Here is a screenshots of `LOGICAL` setting with the text `The quick brown fox jumps over the lazy dog`; notice that there is a horizontal scroll bar -- that looks incorrect: > > ![image](https://github.com/openjdk/jfx/assets/995917/0ce6b106-2fd6-4688-9f3c-ba7ec23484ad) > > Now, for the `VISUAL` setting it is a bit hard to see if it is doing the right thing because the `Text` node is lacking any kind of border to see where the actual bounds are. However, I do clearly see it responding to underline on/off, so it is taking that into account somehow (which makes sense for `VISUAL`) > > `VISUAL` with underline on (notice scroll bar): > > ![image](https://github.com/openjdk/jfx/assets/995917/90d770fc-3001-4492-ae68-0359739e81d9) > > And off (notice scroll bar is gone): > > ![image](https://github.com/openjdk/jfx/assets/995917/6171ec23-9a2f-4b13-81ff-5bfe999b1f30) > > So, it seems that: > - Logical bounds still have a bug where the `Text` is getting a scroll bar > - Visual bounds seem to be what you'd expect (I see no bugs -- text is correctly aligned with respect to **other** lines, but there may be trailing spaces that take up additional visual space which results in the overall alignment to be off (ie. right aligned text is not touching the right most edge, since there are spaces there, but **only** when strike through or underline is on (!!) ) -- again it is bit hard to tell as there is no border to see where the visual bounds really are -- you have to look at the horizonal scroll bar :) @hjohn are you trying a single line? Try this string: The quick brown fox jumps over the lazy dog The quick brown fox jumps over the lazy dog ![Screenshot 2024-02-07 at 14 50 56](https://github.com/openjdk/jfx/assets/107069028/b883d887-c16a-4af4-bd17-21ba9b8fdec6) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1933066608 From jhendrikx at openjdk.org Wed Feb 7 23:30:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Feb 2024 23:30:59 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Wed, 7 Feb 2024 15:57:35 GMT, John Hendrikx wrote: >> one thing: you may sync up with the latest master branch, that's the configuration I am testing. > > @andy-goryachev-oracle > > I'm not quite seeing what you are seeing. Here is a screenshots of `LOGICAL` setting with the text `The quick brown fox jumps over the lazy dog`; notice that there is a horizontal scroll bar -- that looks incorrect: > > ![image](https://github.com/openjdk/jfx/assets/995917/0ce6b106-2fd6-4688-9f3c-ba7ec23484ad) > > Now, for the `VISUAL` setting it is a bit hard to see if it is doing the right thing because the `Text` node is lacking any kind of border to see where the actual bounds are. However, I do clearly see it responding to underline on/off, so it is taking that into account somehow (which makes sense for `VISUAL`) > > `VISUAL` with underline on (notice scroll bar): > > ![image](https://github.com/openjdk/jfx/assets/995917/90d770fc-3001-4492-ae68-0359739e81d9) > > And off (notice scroll bar is gone): > > ![image](https://github.com/openjdk/jfx/assets/995917/6171ec23-9a2f-4b13-81ff-5bfe999b1f30) > > So, it seems that: > - Logical bounds still have a bug where the `Text` is getting a scroll bar > - Visual bounds seem to be what you'd expect (I see no bugs -- text is correctly aligned with respect to **other** lines, but there may be trailing spaces that take up additional visual space which results in the overall alignment to be off (ie. right aligned text is not touching the right most edge, since there are spaces there, but **only** when strike through or underline is on (!!) ) -- again it is bit hard to tell as there is no border to see where the visual bounds really are -- you have to look at the horizonal scroll bar :) > @hjohn are you trying a single line? Try this string: > > ``` > The quick brown fox jumps over the lazy dog > The quick brown fox jumps over the lazy dog > ``` > > ![Screenshot 2024-02-07 at 14 50 56](https://private-user-images.githubusercontent.com/107069028/303159866-b883d887-c16a-4af4-bd17-21ba9b8fdec6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDczNDY2NDUsIm5iZiI6MTcwNzM0NjM0NSwicGF0aCI6Ii8xMDcwNjkwMjgvMzAzMTU5ODY2LWI4ODNkODg3LWMxNmEtNGFmNC1iZDE3LTIxYmE5YjhmZGVjNi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwMjA3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDIwN1QyMjUyMjVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT00YzcxYzMyYWM3ZGY4OTgxMzIxZTNhYzAzMmUxNTk0NDExNTQ4NjQyMzUxNmM2OWYxMzQ2YTQxOGJjOTMzZjAxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.OAwnWRI6Y7Qfy-p4KXB_MJPtC0wRBKIdztQXix2F7iA) Well, wrap text is on, so that allows the code to strip spaces between words if it places a soft wrap there (which is working). At the end of the first line, it doesn't want to wrap yet, but a hard wrap is encountered (`\n`). Since there is no soft wrap there, the spaces are kept intact. The question really is if this is correct for the 2nd line. There is no soft wrap at the 2nd `dog`, so why is it stripping spaces there? I don't have a test case for that one yet in my `TextLayoutTest` but I will add one. For the 2nd line it is stripping **trailing** spaces (not spaces between words where a soft wrap occurred), so I think that the 2nd line is incorrect. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1933109332 From angorya at openjdk.org Wed Feb 7 23:33:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 23:33:59 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Wed, 7 Feb 2024 23:28:12 GMT, John Hendrikx wrote: > so I think that the 2nd line is incorrect. interesting: I would think the second line is correct. Could you check what a browser does in this situation? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1933113164 From angorya at openjdk.org Wed Feb 7 23:45:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Feb 2024 23:45:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 10:43:53 GMT, Karthik P K wrote: > Since the emoji itself is not rendered properly I don't think it is an issue relevant to this PR. Quite possibly, these are grapheme clusters which are currently not supported: `???????????` I see the emoji and tab text options work now, but inline nodes still fail. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1933123542 From jhendrikx at openjdk.org Wed Feb 7 23:50:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Feb 2024 23:50:59 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <4RI02IK9HBxjKom1kJhrFG9f5ZLg_GeiVL1RbfriANc=.82451ef0-7dcf-4457-9177-4ebedcea23f9@github.com> Message-ID: On Wed, 7 Feb 2024 23:31:43 GMT, Andy Goryachev wrote: > > so I think that the 2nd line is incorrect. > > interesting: I would think the second line is correct. Could you check what a browser does in this situation? Tested with `pre-wrap` which I think is the closest match there is for browsers (and the setting we want to emulate), and it shows this: ![image](https://github.com/openjdk/jfx/assets/995917/ef0a16e4-3734-4862-93e4-816522fa6ff3) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1933127921 From angorya at openjdk.org Thu Feb 8 00:12:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 00:12:59 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <4PYKPn-0_YJTx86tE2wL-Pjcft67G4EqaW5ks6QOOms=.3ae05e93-4fd4-4b48-a7e9-7c40e4963153@github.com> On Wed, 7 Feb 2024 15:06:18 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx 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 16 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/wrapped-aligned-text-rendering > - Fix test comment > - More test cases (for hard wrapping) and another small fix > - Improve tests, fix a bug > - Fix bug which confused char index with glyph index > - Move test that needs QuantumToolkit to system tests > - Clean-up, re-enable and extend ancient TextLayout test > - TextRun getAdvance should return 0 when positions array is null > - Fix justify alignment to take all trailing spaces into account > - Fix trailing space calculation to access positions array directly > - ... and 6 more: https://git.openjdk.org/jfx/compare/c1828f0d...388696a6 it's weird, but if this is how you think it should work, i am ok with it. another question: should TABs (0x09) be considered whitespace? AAAA BBBB CCCC DDDD EEEE FFFF GGG HHHH II TABS TABS ![Screenshot 2024-02-07 at 16 09 54](https://github.com/openjdk/jfx/assets/107069028/3543901a-fcda-4ed7-a60e-e8b79f56733b) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1933147962 From kpk at openjdk.org Thu Feb 8 06:14:57 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Feb 2024 06:14:57 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: <10J4kPFKkrT_jTe212nxGZ8j5BzeMUdfEy_DLgkf1sY=.eeb13b2c-2ca4-4fe1-9999-f65ccbc28cd8@github.com> On Wed, 7 Feb 2024 23:43:41 GMT, Andy Goryachev wrote: > I see the emoji and tab text options work now, but inline nodes still fail. I don't see issue with inline nodes. Please let me know in which case you are facing issue. Screenshot 2024-02-08 at 11 37 36?AM ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1933422383 From jbechberger at openjdk.org Thu Feb 8 09:16:14 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 8 Feb 2024 09:16:14 GMT Subject: [jfx17u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Message-ID: Clean backport of 8221261: Deadlock on macOS in JFXPanel app when handling IME calls ------------- Commit messages: - 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Changes: https://git.openjdk.org/jfx17u/pull/178/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221261 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/178.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/178/head:pull/178 PR: https://git.openjdk.org/jfx17u/pull/178 From kpk at openjdk.org Thu Feb 8 10:18:59 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Feb 2024 10:18:59 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font [v3] In-Reply-To: References: Message-ID: <6K3xAW47ECo5UgFEll25rEAIKScOo6Gn-7Szn9DWHfY=.f66b62cb-1b00-4297-92eb-8562a832094f@github.com> On Wed, 7 Feb 2024 21:41:10 GMT, Andy Goryachev wrote: >> Requesting content layout when font changes. >> >> This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace The flickering looks to be gone now but I see another issue. When the font size is changed from larger value like 144 to a smaller value like 10, the position of text in the TextArea shifts. Screenshot 2024-02-08 at 3 35 50?PM When monkey tester window loses focus, it goes back to the original position. Steps to reproduce the issue: 1. Open the MonkeyTester with TextArea having larger font size like 144. (If smaller font size is present, change the font size without clicking on the text) 2. Click on the text to get caret. 3. Change font size to 10. 4. Click on the text to get caret again, the text shifts. Not sure if this is related to the other issues you have mentioned in this PR before. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1933759782 From jhendrikx at openjdk.org Thu Feb 8 12:44:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 8 Feb 2024 12:44:11 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Wed, 7 Feb 2024 15:06:18 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx 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 16 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/wrapped-aligned-text-rendering > - Fix test comment > - More test cases (for hard wrapping) and another small fix > - Improve tests, fix a bug > - Fix bug which confused char index with glyph index > - Move test that needs QuantumToolkit to system tests > - Clean-up, re-enable and extend ancient TextLayout test > - TextRun getAdvance should return 0 when positions array is null > - Fix justify alignment to take all trailing spaces into account > - Fix trailing space calculation to access positions array directly > - ... and 6 more: https://git.openjdk.org/jfx/compare/fed78522...388696a6 I've been doing some more investigation, and digging up different kinds of problems, that are not entirely related to this change. - Font calculation is using `float`s, which are converted to/from `double`s which FX uses. This causes slight inaccuracies at the places these translations occur. For example, wrap width is converted from double to float, then later bounds are returned (also as floats) which are then promoted back to double. A scroll pane which may be expecting `(double)wrapWidth` but sees a bounds value returned that is `(double)(float)wrapWidth` which may be slightly smaller or larger than what the pane expects. If it is larger, it will suddenly display a horizonal scroll bar to compensate for some tiny difference of 0.00001 pixels. - The `Group` wrapper around `Text` used by MonkeyTester is somehow amplifying these inaccuracies (or is adding its own), causing a horizontal scroll bar to be almost always displayed (flickering during resizes) -- `StackPane` seems to not cause such additional problems (as `Group` has a very specific purpose, I think using it here is incorrect). - Text justification (`JUSTIFY`) is creating cumulative errors -- it divides the amount of extra space by the number of white spaces in the line (which then gets rounded to fit in a `float`), then for each white space, it adds this amount, each time increasing the error a bit more. A better approach is to substract the distributed space from the total space each time, and for the last space use the left over amount. - Text justification with certain fonts cuts off the last portion of the last character on a line sometimes (primarily with serif fonts, a small part of the serif is outside the expected bounds). This seems to be more than the above accumulated error can account for. Oddly enough, when switching to LEFT/RIGHT alignment, it is clear the text should fit easily (the lines are not wrapped differently), but as soon as JUSTIFY alignment is used, the spaces between the words get large enough that a small part of the last character is out of bounds. Still investigating why this happens. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1934033307 From angorya at openjdk.org Thu Feb 8 16:09:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 16:09:08 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <-sveILclGcJWC_nBkUaRFxYlo9Jzy6muu8btuAxkulU=.8fb55d2e-35dd-4373-8708-65e904669d57@github.com> On Wed, 7 Feb 2024 15:06:18 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx 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 16 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/wrapped-aligned-text-rendering > - Fix test comment > - More test cases (for hard wrapping) and another small fix > - Improve tests, fix a bug > - Fix bug which confused char index with glyph index > - Move test that needs QuantumToolkit to system tests > - Clean-up, re-enable and extend ancient TextLayout test > - TextRun getAdvance should return 0 when positions array is null > - Fix justify alignment to take all trailing spaces into account > - Fix trailing space calculation to access positions array directly > - ... and 6 more: https://git.openjdk.org/jfx/compare/b6f2d51f...388696a6 The Group use in the MT is intentional: we want to see the preferred sizes of the content. StackPane does not work correctly at all (example: change to StackPane in TextPage:197 and click on 'show characters'). Also, aren't all coordinates typically snapped? But your observation about JUSTIFY are justified (pun intended). I see horizontal scroll bar flickering on and off when resizing a long text due to the vertical scroll bar appearing. But I still see the HSB even with the short text as you described. Perhaps some variant of your resize algorithm should be used here as well (maybe together with my snapInnerSpace() method). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1934448645 From angorya at openjdk.org Thu Feb 8 16:14:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 16:14:04 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font [v3] In-Reply-To: <6K3xAW47ECo5UgFEll25rEAIKScOo6Gn-7Szn9DWHfY=.f66b62cb-1b00-4297-92eb-8562a832094f@github.com> References: <6K3xAW47ECo5UgFEll25rEAIKScOo6Gn-7Szn9DWHfY=.f66b62cb-1b00-4297-92eb-8562a832094f@github.com> Message-ID: On Thu, 8 Feb 2024 10:16:51 GMT, Karthik P K wrote: > the position of text in the TextArea shifts. yes, that's [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) the padding size is expressed in ems which is incorrect - it should be fixed like everywhere else. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1934457788 From angorya at openjdk.org Thu Feb 8 18:02:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 18:02:10 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: <10J4kPFKkrT_jTe212nxGZ8j5BzeMUdfEy_DLgkf1sY=.eeb13b2c-2ca4-4fe1-9999-f65ccbc28cd8@github.com> References: <10J4kPFKkrT_jTe212nxGZ8j5BzeMUdfEy_DLgkf1sY=.eeb13b2c-2ca4-4fe1-9999-f65ccbc28cd8@github.com> Message-ID: On Thu, 8 Feb 2024 06:12:05 GMT, Karthik P K wrote: >>> Since the emoji itself is not rendered properly I don't think it is an issue relevant to this PR. >> >> Quite possibly, these are grapheme clusters which are currently not supported: >> `???????????` >> >> I see the emoji and tab text options work now, but inline nodes still fail. > >> I see the emoji and tab text options work now, but inline nodes still fail. > > I don't see issue with inline nodes. Please let me know in which case you are facing issue. > Screenshot 2024-02-08 at 11 37 36?AM You are right, @karthikpandelu , the inline nodes work as expected. Sorry, I got confused by low indexes in Text which is correct because there are multiple instances of Text in the flow and the hit info from Text is relative to the text fragment in that particular instance of Text. I do see that grapheme clusters are rendered incorrectly in RTL ????????? due to lack of support for grapheme clusters [JDK-8309565](https://bugs.openjdk.org/browse/JDK-8309565) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1934664210 From angorya at openjdk.org Thu Feb 8 18:25:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 18:25:05 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 10:43:12 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix emoji issue Looks good with minor comments. @hjohn this might impact your work in #1236 - would you like to take a look? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 459: > 457: break; > 458: } > 459: if (i - 1 >= 0) { `if (i > 0)` ? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 531: > 529: for (int i = runs.length - 1; i > runIdx; i--) { > 530: TextRun r = runs[i]; > 531: boolean addLtrIdx = run.getTextSpan().getText().length() != run.length; Q: we should never get an NPE here, correct? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1865964546 PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1934698730 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1483395969 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1483400064 From angorya at openjdk.org Thu Feb 8 18:25:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 18:25:05 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 10:31:18 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Inline node issue fix modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 509: > 507: TextRun r = runs[i]; > 508: if (r.getStart() != curRunStart && r.getTextSpan().getText().equals(text) > 509: && x > r.getWidth() && textWidthPrevLine == 0) { minor: could we move equals() after all other checks where we have logical AND `&&`? same in lines 515, 524, 532 (and possibly somewhere else) in other words, compute equals() only after the fast checks do not fail. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1480324450 From angorya at openjdk.org Thu Feb 8 18:26:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 18:26:05 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 00:08:41 GMT, Kevin Rushforth wrote: > would it be possible to create an automated test for this? created a robot test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1217#issuecomment-1934700117 From mariushanl at web.de Thu Feb 8 18:45:53 2024 From: mariushanl at web.de (Marius Hanl) Date: Thu, 8 Feb 2024 19:45:53 +0100 Subject: Aw: Re: Preview features for JavaFX In-Reply-To: References: <059e4e78-1c92-4251-aa96-d60fb1b3bac6@gmail.com> <4f8afeb6-74fb-4481-b0ef-969dc00d5a63@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Thu Feb 8 19:00:28 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Feb 2024 19:00:28 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations Message-ID: `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all other implementations of the cell. This also means that the `TreeTableRow` always updates the item, although it should not, resulting in a performance loss as a `TreeTableRow` will always call `updateItem(..)`. It looks like that this was forgotten in [JDK-8092593](https://bugs.openjdk.org/browse/JDK-8092593). Checking the whole history, it looks like the following was happening: 1. There was a check if the item is the same in all cell implementations (with `.equals(..)`) 2. Check was removed as it caused bugs 3. Check was readded, but instead we first check the index (same index) and then if we also have the same item (this time with `.isItemChanged(..)`, to allow developers to subclass it) 4. Forgotten for `TreeTableRow`. Added many tests for the case where an item should be changed and where it should not. ------------- Commit messages: - JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations Changes: https://git.openjdk.org/jfx/pull/1360/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325402 Stats: 541 lines in 11 files changed: 512 ins; 2 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1360.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1360/head:pull/1360 PR: https://git.openjdk.org/jfx/pull/1360 From angorya at openjdk.org Thu Feb 8 19:31:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Feb 2024 19:31:03 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 20:05:09 GMT, Martin Fox wrote: > On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. > > This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. > > On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. sorry this PR was out waiting for too long. could you sync it up with the latest master please? modules/javafx.graphics/src/main/java/com/sun/glass/events/KeyEvent.java line 255: > 253: * character with respect to the currently active keyboard layout or > 254: * VK_UNDEFINED if the character isn't present in the current layout. > 255: * The hint is the KeyCode of the key the system is attempting to match. is this clear enough or should we say that it's KeyCode.getCode()? (also Application:746) modules/javafx.graphics/src/main/java/com/sun/glass/events/KeyEvent.java line 257: > 255: * The hint is the KeyCode of the key the system is attempting to match. > 256: * It can be used to optimize the search or to distinguish between the > 257: * main keyboard and the numeric keypad. should we mention that it is supposed to be `KeyEvent.VK_UNDEFINED` when not available? tests/system/src/test/java/test/robot/com/sun/glass/ui/monocle/MonocleApplicationTest.java line 143: > 141: char ch = (char) TEST_CASES[i][0]; > 142: int expectedCode = TEST_CASES[i][1]; > 143: int code = MonocleApplicationShim._getKeyCodeForChar(ch, KeyEvent.VK_UNDEFINED); Do you want to add a new test(s) for the cases when the hint is important? ------------- PR Review: https://git.openjdk.org/jfx/pull/1289#pullrequestreview-1871084872 PR Review Comment: https://git.openjdk.org/jfx/pull/1289#discussion_r1483488977 PR Review Comment: https://git.openjdk.org/jfx/pull/1289#discussion_r1483493173 PR Review Comment: https://git.openjdk.org/jfx/pull/1289#discussion_r1483495224 From mhanl at openjdk.org Thu Feb 8 21:28:08 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Feb 2024 21:28:08 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: <2MzH3ZuU2xSg6bNY3i2ANGTZ3deVgKxVZwQkdjdYmuc=.c4067502-da10-4bca-9df3-0c2a0fc8af16@github.com> On Fri, 9 Jun 2023 12:00:06 GMT, John Hendrikx wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| >> |Removal during notification|As above|Entry is `null`ed| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| >> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| >> >> # About nested changes >> >> Nested changes are simply changes that are made to a property that is currently in the process of notif... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix generic warnings I completely forgot about this PR, but it looks very interesting, especially about the nested events. If helpful, I can test this soon in a bigger application, especially for any regressions. And of course also review the code, but need more time for that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1934958209 From nlisker at openjdk.org Thu Feb 8 21:39:11 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 8 Feb 2024 21:39:11 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Fri, 9 Jun 2023 12:00:06 GMT, John Hendrikx wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| >> |Removal during notification|As above|Entry is `null`ed| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| >> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| >> >> # About nested changes >> >> Nested changes are simply changes that are made to a property that is currently in the process of notif... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix generic warnings It's the first item on my review list for FX 23. Hope to get the time for the review queue in 1-2 weeks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1934971092 From john.hendrikx at gmail.com Fri Feb 9 01:28:02 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 9 Feb 2024 02:28:02 +0100 Subject: Layout and property bindings question, what is allowed? Message-ID: Hi, I'm pretty sure I read somewhere in JavaFX docs, code or website that binding certain properties which are changed during layout is a really bad idea, but I can't find where I've seen this.? Anyone know what I mean? It was something like: binding the values of a property like width/height which are changed during layout to another property (which may in turn affect layout) should not be done, and one should be using properties like min/pref/max width/height. The reason I ask is because I'm running into a weird problem where I'm binding the value of ScrollPane.viewportBoundsProperty.width to a Label's text property.? What I noticed is that the Label simply is not updating correctly, and will display the correct value **BUT** use the previous value for its width calculation which causes the text to not fit -- the fact that it is displayed wrong is especially obvious when the Label's value switches between values like "312.0" and "313.333333333" where the 2nd value often gets an ellipsis (like "31...") because its width was computed based on "312.0".? What I see happening is this: - A splitpane is resized (with a scrollpane in it) - The ScrollPane's viewportBoundsProperty changes (in layoutChildren code of ScrollPaneSkin), so layout is already running... - A binding on viewportBoundsProperty.width updates the label text from "312.0" to "313.33333333" However, before that binding is executed, I see a call to `computePrefWidth` on the Label, which uses the old text (ie. "312.0") -- there is NO other call to computePrefWidth, so the layout process continues with an incorrect width value... When later the layout code of the Label is called, it concludes that the current width (based on the text "312.0") is insufficient to display "313.33333333", and so adds an ellipsis... So, I'm thinking this may be "expected" behavior -- I'm binding on a property that is updated during layout, and then making another change (to Label.text) which in turn should trigger a new layout.? However, that doesn't happen, and it just runs in the current layout, where it then uses part new, part old values (new text, but old width). Any insights are appreciated. --John From jhendrikx at openjdk.org Fri Feb 9 01:36:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 01:36:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Wed, 7 Feb 2024 15:06:18 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx 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 16 additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/wrapped-aligned-text-rendering > - Fix test comment > - More test cases (for hard wrapping) and another small fix > - Improve tests, fix a bug > - Fix bug which confused char index with glyph index > - Move test that needs QuantumToolkit to system tests > - Clean-up, re-enable and extend ancient TextLayout test > - TextRun getAdvance should return 0 when positions array is null > - Fix justify alignment to take all trailing spaces into account > - Fix trailing space calculation to access positions array directly > - ... and 6 more: https://git.openjdk.org/jfx/compare/c1e97be2...388696a6 I fixed the slight inaccuracies surrounding the float/double conversion but it didn't fix the flickering scrollbar. My theory is now that how the wrap width of the `Text` node is updated is not entirely legal (I posted on the mailinglist to see if anyone can remember how this is supposed to work when you update a value (that may cause layout changes) based on a property that is already changed by layout code). What I'm thinking is that `ScrollPane.viewportBoundsProperty`, which is only set in `layoutChildren` of its skin, should not be bound to the `Text` wrapping width -- a layout is already running, and updating another property that will affect layout will result in undefined behavior. I see the same issue when I bind that value to a simple `Label`'s text -- the text width is often incorrect resulting in an ellipsis being displayed. So I'm thinking the reason the horizontal scroll bar appears on the `ScrollPane` is because the bounds it calculated were based on the previous `Text`'s wrapping width, and is not recalculated again when we update the `Text` wrapping width **during** layout. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1935203621 From mfox at openjdk.org Fri Feb 9 03:37:17 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 9 Feb 2024 03:37:17 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v2] In-Reply-To: References: Message-ID: > On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. > > This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. > > On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. Martin Fox 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 seven additional commits since the last revision: - Consistent terminology and more details in comments. - Merge remote-tracking branch 'upstream/master' into keypadcombo - Added SEPARATOR to list of keypad keys - CharacterCombinations now work on the numeric keypad - Fixed Monocle - Merge remote-tracking branch 'upstream/master' into keypadcombo - Added hint to getKeyCodeForChar to enable numeric keypad ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1289/files - new: https://git.openjdk.org/jfx/pull/1289/files/7a297aee..6400299e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1289&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1289&range=00-01 Stats: 347637 lines in 7144 files changed: 198051 ins; 105131 del; 44455 mod Patch: https://git.openjdk.org/jfx/pull/1289.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1289/head:pull/1289 PR: https://git.openjdk.org/jfx/pull/1289 From kpk at openjdk.org Fri Feb 9 04:34:06 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Feb 2024 04:34:06 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 21:41:10 GMT, Andy Goryachev wrote: >> Requesting content layout when font changes. >> >> This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace LGTM ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1217#pullrequestreview-1871638470 From kpk at openjdk.org Fri Feb 9 07:59:47 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Feb 2024 07:59:47 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system 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/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/43f1f186..8732047c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=09-10 Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Fri Feb 9 07:59:48 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Feb 2024 07:59:48 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 18:13:58 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix emoji issue > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 531: > >> 529: for (int i = runs.length - 1; i > runIdx; i--) { >> 530: TextRun r = runs[i]; >> 531: boolean addLtrIdx = run.getTextSpan().getText().length() != run.length; > > Q: we should never get an NPE here, correct? Yes we will not get NPE here. We enter this block only when `spans != null` so I don't think we need another null check here. We have one null check at l.no.515 which is not really necessary but I will keep it as it is for now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1483973542 From jhendrikx at openjdk.org Fri Feb 9 10:05:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 10:05:06 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <07e-mtMannnuIkUEMO2ASBVCPe8VszoktIHwzhypvaE=.f34c559a-42cd-4635-8643-50b2335f6e29@github.com> On Fri, 9 Feb 2024 01:33:20 GMT, John Hendrikx wrote: > My theory is now that how the wrap width of the `Text` node is updated is not entirely legal (I posted on the mailinglist to see if anyone can remember how this is supposed to work when you update a value (that may cause layout changes) based on a property that is already changed by layout code). I tested this now by using a `Label` instead of `Text`, setting the `ScrollPane` to `setFitToWidth(true)`, removing the `Group` around the `Label`, and removing the binding that updates wrapping width (which `Label` doesn't have). A horizontal scroll bar now never appears, and the text seems to always perfectly fit (aside from side bearings which sometimes fall outside the bounds, especially noticeable with italic fonts -- this is considered normal though). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1935639938 From jhendrikx at openjdk.org Fri Feb 9 12:38:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 12:38:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v11] In-Reply-To: <-sveILclGcJWC_nBkUaRFxYlo9Jzy6muu8btuAxkulU=.8fb55d2e-35dd-4373-8708-65e904669d57@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-sveILclGcJWC_nBkUaRFxYlo9Jzy6muu8btuAxkulU=.8fb55d2e-35dd-4373-8708-65e904669d57@github.com> Message-ID: On Thu, 8 Feb 2024 16:06:39 GMT, Andy Goryachev wrote: >> John Hendrikx 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 16 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/wrapped-aligned-text-rendering >> - Fix test comment >> - More test cases (for hard wrapping) and another small fix >> - Improve tests, fix a bug >> - Fix bug which confused char index with glyph index >> - Move test that needs QuantumToolkit to system tests >> - Clean-up, re-enable and extend ancient TextLayout test >> - TextRun getAdvance should return 0 when positions array is null >> - Fix justify alignment to take all trailing spaces into account >> - Fix trailing space calculation to access positions array directly >> - ... and 6 more: https://git.openjdk.org/jfx/compare/69aaa708...388696a6 > > The Group use in the MT is intentional: we want to see the preferred sizes of the content. StackPane does not work correctly at all (example: change to StackPane in TextPage:197 and click on 'show characters'). > > Also, aren't all coordinates typically snapped? > > But your observation about JUSTIFY are justified (pun intended). I see horizontal scroll bar flickering on and off when resizing a long text due to the vertical scroll bar appearing. But I still see the HSB even with the short text as you described. > > Perhaps some variant of your resize algorithm should be used here as well (maybe together with my snapInnerSpace() method). @andy-goryachev-oracle about tabs There is a lot of special handling going on around tabs. Tabs are always separate runs (one run for each tab). When the logic that creates lines and looks for wrapping points encounters a tab, it will set the width of that run (containing the tab) to be the exact width it needs to reach the next tab stop. if (run.isTab()) { float tabStop = ((int)(lineWidth / tabAdvance) +1) * tabAdvance; run.setWidth(tabStop - lineWidth); } Then it will continue with the code that finds a point to soft wrap. This code will call `run.getWrapIndex` which can return a tab as hit offset, but because a tab is always a run with just the tab character, the logic to "skip" white space is not triggered because the first condition in this while loop is `false` (the run is of length 1, so `offset + 1` will always be less than `runEnd`): // Don't take spaces into account at the preferred wrap index: while (offset + 1 < runEnd && Character.isWhitespace(chars[offset])) { offset++; } Since we don't really have a specification for how we want to deal with tabs, I think it is best for now to leave this as it works currently (it's the same as it was before, I checked that the old logic handles tabs the same). If there is a good argument to handle these differently than they are now, we can revisit this, as it would be non-trivial change (we'd need to take multiple runs into account when skipping white space, while the current logic only looks at a single run). I will add a comment about tabs in this code to clarify why tabs (even though they're white space) are not handled. There is also already this comment in the code that seems to exclude tabs specifically -- it already alludes to the fact that you'd need to take multiple runs into account (which are not "shaped" yet), which highlights that it would be a non-trivial change. /* Only keep whitespaces (not tabs) in the current run to avoid * dealing with unshaped runs. */ ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1935849303 From jhendrikx at openjdk.org Fri Feb 9 12:54:17 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 12:54:17 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Add some clarifying documentation - Do not collapse trailing spaces of last line (where no soft wrap occurs) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1236/files - new: https://git.openjdk.org/jfx/pull/1236/files/388696a6..3a93cdf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=10-11 Stats: 178 lines in 5 files changed: 122 ins; 16 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1236.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236 PR: https://git.openjdk.org/jfx/pull/1236 From kcr at openjdk.org Fri Feb 9 13:03:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 13:03:13 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used Message-ID: JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. ------------- Commit messages: - Test cleanup - Make test more robust - 8311492: FontSmoothingType LCD produces wrong color when transparency is used Changes: https://git.openjdk.org/jfx/pull/1361/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1361&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311492 Stats: 285 lines in 3 files changed: 284 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1361.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1361/head:pull/1361 PR: https://git.openjdk.org/jfx/pull/1361 From jhendrikx at openjdk.org Fri Feb 9 13:19:07 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 13:19:07 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used In-Reply-To: References: Message-ID: <3XceDcgu3PEFX3-NJTaYzlsvLmXikefkvPzyO0fk2so=.e102310b-c475-4e91-87cb-80d23339b1f1@github.com> On Fri, 9 Feb 2024 12:56:15 GMT, Kevin Rushforth wrote: > JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. > > ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) > > The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. > > I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. Looks good to me modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java line 664: > 662: getRenderTarget().isOpaque() && > 663: (this.paint.getType() == Paint.Type.COLOR) && > 664: ((Color)this.paint).getAlpha() == 1.0f && Could avoid the cast here if you want: Suggestion: this.paint instanceof Color c && c.getAlpha() == 1.0f && tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 96: > 94: > 95: private static final Color transpColor = Color.color(0.5, 0.5, 0.5, 0.6); > 96: private static final Color opaqueColor = makeOpaque(transpColor); minor: These look like constants to me, but are not in caps. tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 146: > 144: int a = (int)(c.getOpacity() * 255.0); > 145: return "rgba(" + r + "," + g + "," + b + "," + a + ")"; > 146: } Color has a decent `toString` already @Override public String toString() { return "Color[" + "r=" + r + ", g=" + g + ", b=" + b + ", a=" + a + "]"; } ------------- Marked as reviewed by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1361#pullrequestreview-1872337676 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484297571 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484299457 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484301947 From kcr at openjdk.org Fri Feb 9 14:29:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 14:29:18 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: References: Message-ID: > JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. > > ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) > > The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. > > I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review feedback ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1361/files - new: https://git.openjdk.org/jfx/pull/1361/files/25ad1dab..62c768cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1361&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1361&range=00-01 Stats: 19 lines in 2 files changed: 0 ins; 9 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1361.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1361/head:pull/1361 PR: https://git.openjdk.org/jfx/pull/1361 From kcr at openjdk.org Fri Feb 9 14:32:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 14:32:02 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: <3XceDcgu3PEFX3-NJTaYzlsvLmXikefkvPzyO0fk2so=.e102310b-c475-4e91-87cb-80d23339b1f1@github.com> References: <3XceDcgu3PEFX3-NJTaYzlsvLmXikefkvPzyO0fk2so=.e102310b-c475-4e91-87cb-80d23339b1f1@github.com> Message-ID: On Fri, 9 Feb 2024 13:09:23 GMT, John Hendrikx wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review feedback > > modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWGraphics.java line 664: > >> 662: getRenderTarget().isOpaque() && >> 663: (this.paint.getType() == Paint.Type.COLOR) && >> 664: ((Color)this.paint).getAlpha() == 1.0f && > > Could avoid the cast here if you want: > > Suggestion: > > this.paint instanceof Color c && > c.getAlpha() == 1.0f && I had thought of it earlier, but didn't do it at the time. I made this change along with the suggested test changes. Thanks for the suggestions. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484397314 From nlisker at gmail.com Fri Feb 9 14:48:22 2024 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 9 Feb 2024 16:48:22 +0200 Subject: Layout and property bindings question, what is allowed? In-Reply-To: References: Message-ID: You're thinking about the docs of the note in the bounds properties I think: https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/Node.html#boundsInLocalProperty() https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/Node.html#boundsInParentProperty() On Fri, Feb 9, 2024, 03:28 John Hendrikx wrote: > Hi, > > I'm pretty sure I read somewhere in JavaFX docs, code or website that > binding certain properties which are changed during layout is a really > bad idea, but I can't find where I've seen this. Anyone know what I mean? > > It was something like: binding the values of a property like > width/height which are changed during layout to another property (which > may in turn affect layout) should not be done, and one should be using > properties like min/pref/max width/height. > > The reason I ask is because I'm running into a weird problem where I'm > binding the value of ScrollPane.viewportBoundsProperty.width to a > Label's text property. What I noticed is that the Label simply is not > updating correctly, and will display the correct value **BUT** use the > previous value for its width calculation which causes the text to not > fit -- the fact that it is displayed wrong is especially obvious when > the Label's value switches between values like "312.0" and > "313.333333333" where the 2nd value often gets an ellipsis (like > "31...") because its width was computed based on "312.0". What I see > happening is this: > > - A splitpane is resized (with a scrollpane in it) > - The ScrollPane's viewportBoundsProperty changes (in layoutChildren > code of ScrollPaneSkin), so layout is already running... > - A binding on viewportBoundsProperty.width updates the label text from > "312.0" to "313.33333333" > > However, before that binding is executed, I see a call to > `computePrefWidth` on the Label, which uses the old text (ie. "312.0") > -- there is NO other call to computePrefWidth, so the layout process > continues with an incorrect width value... > > When later the layout code of the Label is called, it concludes that the > current width (based on the text "312.0") is insufficient to display > "313.33333333", and so adds an ellipsis... > > So, I'm thinking this may be "expected" behavior -- I'm binding on a > property that is updated during layout, and then making another change > (to Label.text) which in turn should trigger a new layout. However, > that doesn't happen, and it just runs in the current layout, where it > then uses part new, part old values (new text, but old width). > > Any insights are appreciated. > > --John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Feb 9 15:38:07 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 15:38:07 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: References: Message-ID: <13Wy7dPkWv_1Gmp1Sl44D_qUh0ecLcIFFI2bWKc6ZtE=.7e5a15f0-78f7-4e84-9370-534642e9ba13@github.com> On Fri, 9 Feb 2024 14:29:18 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1361#pullrequestreview-1872674735 From john.hendrikx at gmail.com Fri Feb 9 15:40:05 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 9 Feb 2024 16:40:05 +0100 Subject: Layout and property bindings question, what is allowed? In-Reply-To: References: Message-ID: <421d0190-1fb8-ef45-5cf8-f579bd4db736@gmail.com> Hi Nir, Thanks, yes, those are what I was thinking about.? It seems to apply to more properties though, anything that is changed in a layout methods seems like a bad idea to bind to something else that may affect layout. ScrollPane#viewportBoundsProperty seems to be such a property that you better not bind to something else layout related. --John On 09/02/2024 15:48, Nir Lisker wrote: > You're thinking about the docs of the note in the bounds properties I > think: > > https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/Node.html#boundsInLocalProperty() > > https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/Node.html#boundsInParentProperty() > > On Fri, Feb 9, 2024, 03:28 John Hendrikx wrote: > > Hi, > > I'm pretty sure I read somewhere in JavaFX docs, code or website that > binding certain properties which are changed during layout is a > really > bad idea, but I can't find where I've seen this.? Anyone know what > I mean? > > It was something like: binding the values of a property like > width/height which are changed during layout to another property > (which > may in turn affect layout) should not be done, and one should be > using > properties like min/pref/max width/height. > > The reason I ask is because I'm running into a weird problem where > I'm > binding the value of ScrollPane.viewportBoundsProperty.width to a > Label's text property.? What I noticed is that the Label simply is > not > updating correctly, and will display the correct value **BUT** use > the > previous value for its width calculation which causes the text to not > fit -- the fact that it is displayed wrong is especially obvious when > the Label's value switches between values like "312.0" and > "313.333333333" where the 2nd value often gets an ellipsis (like > "31...") because its width was computed based on "312.0". What I see > happening is this: > > - A splitpane is resized (with a scrollpane in it) > - The ScrollPane's viewportBoundsProperty changes (in layoutChildren > code of ScrollPaneSkin), so layout is already running... > - A binding on viewportBoundsProperty.width updates the label text > from > "312.0" to "313.33333333" > > However, before that binding is executed, I see a call to > `computePrefWidth` on the Label, which uses the old text (ie. > "312.0") > -- there is NO other call to computePrefWidth, so the layout process > continues with an incorrect width value... > > When later the layout code of the Label is called, it concludes > that the > current width (based on the text "312.0") is insufficient to display > "313.33333333", and so adds an ellipsis... > > So, I'm thinking this may be "expected" behavior -- I'm binding on a > property that is updated during layout, and then making another > change > (to Label.text) which in turn should trigger a new layout. However, > that doesn't happen, and it just runs in the current layout, where it > then uses part new, part old values (new text, but old width). > > Any insights are appreciated. > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Feb 9 16:02:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 16:02:04 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 14:29:18 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 67: > 65: * > 66: * @test > 67: * @bug 8311492 for my education: what is the meaning of these tags? how are they used? tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 81: > 79: // color, or in the middle of the text fill area, where we expect to find > 80: // the unadjusted text color. > 81: private static final double TOLERANCE = 2.0 / 255.0; if the intent is to allow for 2 levels of difference, perhaps it should be (2.0 / 255) + 0.00001 or something tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 190: > 188: @AfterEach > 189: public void doTeardown() { > 190: Platform.runLater(() -> { should this be Util.runAndWait() ? tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 272: > 270: runTest(true); > 271: } > 272: extra newline? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484506628 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484509375 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484512177 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484513289 From kcr at openjdk.org Fri Feb 9 16:02:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 16:02:04 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: References: Message-ID: <2xT8PBpIMEvOuXbmQVYDwwNLDix92Fct5ho1KPPLXvk=.cb5262ed-64ea-4793-85b5-56e81a016b06@github.com> On Fri, 9 Feb 2024 15:53:20 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review feedback > > tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 67: > >> 65: * >> 66: * @test >> 67: * @bug 8311492 > > for my education: what is the meaning of these tags? how are they used? These are jtreg tags. They aren't used now, since we don't use jtreg to run our tests, but might in the future. > tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 81: > >> 79: // color, or in the middle of the text fill area, where we expect to find >> 80: // the unadjusted text color. >> 81: private static final double TOLERANCE = 2.0 / 255.0; > > if the intent is to allow for 2 levels of difference, perhaps it should be (2.0 / 255) + 0.00001 or something Maybe. Or maybe even `2.5 / 255.0`. I like the latter idea better, so will do that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484508446 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484512704 From angorya at openjdk.org Fri Feb 9 16:02:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 16:02:05 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: <2xT8PBpIMEvOuXbmQVYDwwNLDix92Fct5ho1KPPLXvk=.cb5262ed-64ea-4793-85b5-56e81a016b06@github.com> References: <2xT8PBpIMEvOuXbmQVYDwwNLDix92Fct5ho1KPPLXvk=.cb5262ed-64ea-4793-85b5-56e81a016b06@github.com> Message-ID: On Fri, 9 Feb 2024 15:58:12 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 81: >> >>> 79: // color, or in the middle of the text fill area, where we expect to find >>> 80: // the unadjusted text color. >>> 81: private static final double TOLERANCE = 2.0 / 255.0; >> >> if the intent is to allow for 2 levels of difference, perhaps it should be (2.0 / 255) + 0.00001 or something > > Maybe. Or maybe even `2.5 / 255.0`. I like the latter idea better, so will do that. yes, much better, thank you. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484514261 From angorya at openjdk.org Fri Feb 9 16:06:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 16:06:12 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 14:29:18 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback looks good, some minor comments. tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 69: > 67: * @bug 8311492 > 68: */ > 69: public class TransparentLCDTest { Was there a reason you did not use `VisualTestBase` class? The code is fine the way it is, I am just curious. ------------- PR Review: https://git.openjdk.org/jfx/pull/1361#pullrequestreview-1872732167 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484517970 From kcr at openjdk.org Fri Feb 9 16:24:21 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 16:24:21 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: > JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. > > ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) > > The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. > > I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: more review feedback ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1361/files - new: https://git.openjdk.org/jfx/pull/1361/files/62c768cf..ee1a621c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1361&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1361&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1361.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1361/head:pull/1361 PR: https://git.openjdk.org/jfx/pull/1361 From mfox at openjdk.org Fri Feb 9 16:26:09 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 9 Feb 2024 16:26:09 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v2] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 19:20:32 GMT, Andy Goryachev wrote: >> Martin Fox 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 seven additional commits since the last revision: >> >> - Consistent terminology and more details in comments. >> - Merge remote-tracking branch 'upstream/master' into keypadcombo >> - Added SEPARATOR to list of keypad keys >> - CharacterCombinations now work on the numeric keypad >> - Fixed Monocle >> - Merge remote-tracking branch 'upstream/master' into keypadcombo >> - Added hint to getKeyCodeForChar to enable numeric keypad > > modules/javafx.graphics/src/main/java/com/sun/glass/events/KeyEvent.java line 255: > >> 253: * character with respect to the currently active keyboard layout or >> 254: * VK_UNDEFINED if the character isn't present in the current layout. >> 255: * The hint is the KeyCode of the key the system is attempting to match. > > is this clear enough or should we say that it's KeyCode.getCode()? > > (also Application:746) I updated the comment so the wording better matches the existing text. The new comment also adds a reminder that the hint could be VK_UNDEFINED. > modules/javafx.graphics/src/main/java/com/sun/glass/events/KeyEvent.java line 257: > >> 255: * The hint is the KeyCode of the key the system is attempting to match. >> 256: * It can be used to optimize the search or to distinguish between the >> 257: * main keyboard and the numeric keypad. > > should we mention that it is supposed to be `KeyEvent.VK_UNDEFINED` when not available? I updated the comment here as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1289#discussion_r1484541213 PR Review Comment: https://git.openjdk.org/jfx/pull/1289#discussion_r1484541702 From mfox at openjdk.org Fri Feb 9 16:35:06 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 9 Feb 2024 16:35:06 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v2] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 19:26:42 GMT, Andy Goryachev wrote: >> Martin Fox 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 seven additional commits since the last revision: >> >> - Consistent terminology and more details in comments. >> - Merge remote-tracking branch 'upstream/master' into keypadcombo >> - Added SEPARATOR to list of keypad keys >> - CharacterCombinations now work on the numeric keypad >> - Fixed Monocle >> - Merge remote-tracking branch 'upstream/master' into keypadcombo >> - Added hint to getKeyCodeForChar to enable numeric keypad > > tests/system/src/test/java/test/robot/com/sun/glass/ui/monocle/MonocleApplicationTest.java line 143: > >> 141: char ch = (char) TEST_CASES[i][0]; >> 142: int expectedCode = TEST_CASES[i][1]; >> 143: int code = MonocleApplicationShim._getKeyCodeForChar(ch, KeyEvent.VK_UNDEFINED); > > Do you want to add a new test(s) for the cases when the hint is important? Looking through the Monocle code I see that it does support the numeric keypad and could benefit from the provided hint. I didn't find any bug in the database concerning KeyCharacterCombination support on Monocle so this may be a non-issue. If it is a problem I think it should be addressed in a separate PR at which point the test cases can be expanded. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1289#discussion_r1484552266 From kcr at openjdk.org Fri Feb 9 16:39:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 16:39:03 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 16:02:19 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review feedback > > tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 69: > >> 67: * @bug 8311492 >> 68: */ >> 69: public class TransparentLCDTest { > > Was there a reason you did not use `VisualTestBase` class? > The code is fine the way it is, I am just curious. I started out using `VisualTestBase`, but I needed to set system properties before launching the FX runtime, and there is no way that I could find to insert any code into the subclass that would get executed before the superclass. The only thing I ended up using from `VisualTestBase` was the `assertColorEquals` method, which could be moved to Util anyway. There is other cleanup that could be done to `VisualTestBase`, so I'll file a follow-on bug. > tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 190: > >> 188: @AfterEach >> 189: public void doTeardown() { >> 190: Platform.runLater(() -> { > > should this be Util.runAndWait() ? It doesn't really matter in this case since Runnables are run in order, meaning that the creation and showing of the stage for the next text is guaranteed to happen after the stage is hidden. I can change it, though. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484526979 PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484529935 From hmeda at openjdk.org Fri Feb 9 17:10:11 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 9 Feb 2024 17:10:11 GMT Subject: RFR: 8325258: Cherry-pick WebKit 617.1 stabilization fixes (2) Message-ID: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> Cherry-picked changes related to webkit-2.42.5. Verified build on all platforms. Sanity testing looks fine. ------------- Commit messages: - white space correction - commit 3d5373575695b293b8559155431d0079a6153aff from webkitglib/2.42 to resolve build error on 32 bit - cherry-pick 2.42.5 Changes: https://git.openjdk.org/jfx/pull/1362/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1362&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325258 Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod Patch: https://git.openjdk.org/jfx/pull/1362.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1362/head:pull/1362 PR: https://git.openjdk.org/jfx/pull/1362 From kcr at openjdk.org Fri Feb 9 17:19:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 17:19:02 GMT Subject: RFR: 8325258: Cherry-pick WebKit 617.1 stabilization fixes (2) In-Reply-To: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> References: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> Message-ID: On Fri, 9 Feb 2024 17:05:53 GMT, Hima Bindu Meda wrote: > Cherry-picked changes related to webkit-2.42.5. Verified build on all platforms. Sanity testing looks fine. Reviewers: @kevinrushforth and @johanvos or @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1362#issuecomment-1936298011 From angorya at openjdk.org Fri Feb 9 17:22:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 17:22:03 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 16:24:21 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > more review feedback tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 172: > 170: @AfterAll > 171: public static void doTeardownOnce() { > 172: Util.shutdown(); I am sorry, Kevin, you just walked into a trap carefully laid by me before. Util.shutdown() needs a Stage argument, otherwise it does nothing. Perhaps we could change the impl. to shutdown all the stages regardless instead of passing an array of them. And, of course, there is more than one place where we do it. Good job, me! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484600775 From angorya at openjdk.org Fri Feb 9 17:22:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 17:22:03 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 17:17:28 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> more review feedback > > tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 172: > >> 170: @AfterAll >> 171: public static void doTeardownOnce() { >> 172: Util.shutdown(); > > I am sorry, Kevin, you just walked into a trap carefully laid by me before. > Util.shutdown() needs a Stage argument, otherwise it does nothing. > Perhaps we could change the impl. to shutdown all the stages regardless instead of passing an array of them. > > And, of course, there is more than one place where we do it. Good job, me! We can leave this code as is and fix it during the test sprint... I'll file a bug. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484602528 From angorya at openjdk.org Fri Feb 9 17:26:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 17:26:03 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: <2jQBm7jOoj5YcA0NNB9G1NSJ_tQn085yMlo-3BG2Naw=.765e9add-2a96-4dd5-8cff-a4d2fee2ab4e@github.com> On Fri, 9 Feb 2024 16:24:21 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > more review feedback LgTm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1361#pullrequestreview-1872875914 From angorya at openjdk.org Fri Feb 9 17:30:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 17:30:09 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v2] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 03:37:17 GMT, Martin Fox wrote: >> On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. >> >> This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. >> >> On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. > > Martin Fox 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 seven additional commits since the last revision: > > - Consistent terminology and more details in comments. > - Merge remote-tracking branch 'upstream/master' into keypadcombo > - Added SEPARATOR to list of keypad keys > - CharacterCombinations now work on the numeric keypad > - Fixed Monocle > - Merge remote-tracking branch 'upstream/master' into keypadcombo > - Added hint to getKeyCodeForChar to enable numeric keypad Thank you for clarification! LGTM(tm) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1289#pullrequestreview-1872883477 From prr at openjdk.org Fri Feb 9 17:39:03 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 9 Feb 2024 17:39:03 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 16:24:21 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > more review feedback Didn't look at the test, but the code change seems right. I'm surprised this didn't get reported a long time ago. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1361#pullrequestreview-1872897616 From angorya at openjdk.org Fri Feb 9 18:03:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 18:03:07 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 12:54:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add some clarifying documentation > - Do not collapse trailing spaces of last line (where no soft wrap occurs) modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextSpan.java line 36: > 34: * A text span can contain line breaks if the text should span multiple > 35: * lines. > 36: */ thank you for adding this explanation! modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 1245: > 1243: * no matter where it occurs). > 1244: */ > 1245: @karthikpandelu could you please take a look at this comment here and this PR in general (since you both are modifying the same file)? Is there anything to add? tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved. weird, github shows this file as new, but it is not. 2024 tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 58: > 56: private final PrismTextLayout layout = new PrismTextLayout(); > 57: private final PGFont font = (PGFont) FontHelper.getNativeFont(Font.font("Monaco", 12)); > 58: private final PGFont font2 = (PGFont) FontHelper.getNativeFont(Font.font("Tahoma", 12)); are these fonts available on all platforms? what would happen if the font with this name is not found? tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 60: > 58: private final PGFont font2 = (PGFont) FontHelper.getNativeFont(Font.font("Tahoma", 12)); > 59: > 60: class TestSpan implements TextSpan { could this class be static? tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 62: > 60: class TestSpan implements TextSpan { > 61: String text; > 62: Object font; final text and font? tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 83: > 81: int i = 0; > 82: while (i < content.length) { > 83: spans[i>>1] = new TestSpan(content[i++], content[i++]); I would seriously recommend adhering to one statement per line here: Object text = content[i++]; Object font = content[i++]; spans[i>>1] = new TestSpan(text, font); tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 338: > 336: HARD_WRAP(new Parameters( > 337: "The quick brown fox jumps\nover the lazy dog", > 338: Font.font("Monaco", 12), same comment about font not found on all the platforms tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 414: > 412: 12.0f, 4.001953f > 413: )); > 414: should we add tests for leading/trailing tabs and milti-line strings, and multi-line with leading/trailing spaces? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484613629 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484616479 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484619240 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484620756 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484621432 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484622292 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484628361 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484630360 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484632163 From angorya at openjdk.org Fri Feb 9 18:08:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 18:08:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 12:54:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add some clarifying documentation > - Do not collapse trailing spaces of last line (where no soft wrap occurs) So we treat trailing spaces before \n as hard wrap, does it mean the same treatment is applied to the leading space (i.e. leading spaces in the first line), as seen here with TextAlignment=CENTER aaa bbb bbbb ccc dddd eee ffffff aaa b c ![Screenshot 2024-02-09 at 09 59 31](https://github.com/openjdk/jfx/assets/107069028/9541c449-0c25-44ee-b85e-827b760d4710) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936378285 From angorya at openjdk.org Fri Feb 9 18:18:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 18:18:04 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 07:59:47 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system 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 now. Thank you for the hard work! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1872960155 From kcr at openjdk.org Fri Feb 9 19:06:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 19:06:03 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 17:19:06 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TransparentLCDTest.java line 172: >> >>> 170: @AfterAll >>> 171: public static void doTeardownOnce() { >>> 172: Util.shutdown(); >> >> I am sorry, Kevin, you just walked into a trap carefully laid by me before. >> Util.shutdown() needs a Stage argument, otherwise it does nothing. >> Perhaps we could change the impl. to shutdown all the stages regardless instead of passing an array of them. >> >> And, of course, there is more than one place where we do it. Good job, me! > > We can leave this code as is and fix it during the test sprint... I'll file a bug. > > edit: Created > [JDK-8325566](https://bugs.openjdk.org/browse/JDK-8325566) > [TestBug] Util.shutdown() to hide ALL the scenes > > I am so embarrassed. One could argue that the method is fine as it is. It will first hide the stages that are passed in (possibly zero of them), and then shutdown the platform. I guess I don't see the problem. Note that by the time this method is called, there are no visible stages. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484701223 From angorya at openjdk.org Fri Feb 9 19:11:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 19:11:04 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 19:03:00 GMT, Kevin Rushforth wrote: >> We can leave this code as is and fix it during the test sprint... I'll file a bug. >> >> edit: Created >> [JDK-8325566](https://bugs.openjdk.org/browse/JDK-8325566) >> [TestBug] Util.shutdown() to hide ALL the scenes >> >> I am so embarrassed. > > One could argue that the method is fine as it is. It will first hide the stages that are passed in (possibly zero of them), and then shutdown the platform. I guess I don't see the problem. > > Note that by the time this method is called, there are no visible stages. I guess the reason for explicit hiding() of the stages passed to it was done for the sake of headless tests? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484705119 From kcr at openjdk.org Fri Feb 9 19:23:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 19:23:05 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: <9JSvkX_GcnKA1Yddskxunvqcc-zwHeKVdGI6pUFkBA8=.22dac1b4-7d14-4f28-94d0-14a45f20e461@github.com> On Fri, 9 Feb 2024 17:36:33 GMT, Phil Race wrote: > I'm surprised this didn't get reported a long time ago. I'm also surprised. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1361#issuecomment-1936472576 From kcr at openjdk.org Fri Feb 9 19:23:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 19:23:06 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 19:07:53 GMT, Andy Goryachev wrote: >> One could argue that the method is fine as it is. It will first hide the stages that are passed in (possibly zero of them), and then shutdown the platform. I guess I don't see the problem. >> >> Note that by the time this method is called, there are no visible stages. > > I guess the reason for explicit hiding() of the stages passed to it was done for the sake of headless tests? It's not really a headless vs headful distinction (the system tests are all headful). It's just that some tests have a global (static) Stage that should be hidden at shutdown time. Others, like the test in this PR, create, hide, and show a Stage in each test instance. Both are valid use cases. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484712786 From angorya at openjdk.org Fri Feb 9 19:23:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 19:23:07 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: <_38TZ-x_dBySjONts1j9MyQr8Zte2TQhCPv7oH7_Z0k=.c0cca23e-a073-4bb7-be66-c21eb66d86c0@github.com> On Fri, 9 Feb 2024 19:17:00 GMT, Kevin Rushforth wrote: >> I guess the reason for explicit hiding() of the stages passed to it was done for the sake of headless tests? > > It's not really a headless vs headful distinction (the system tests are all headful). It's just that some tests have a global (static) Stage that should be hidden at shutdown time. Others, like the test in this PR, create, hide, and show a Stage in each test instance. Both are valid use cases. here it's under @AfterAll, not after each test. But still, what's the point of hiding the stage(s) if we follow it with Platform.exit() ? Then we should get rid of the stage(s) argument and simply hide all the current stages, regardless. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484715440 From sykora at openjdk.org Fri Feb 9 20:24:02 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 9 Feb 2024 20:24:02 GMT Subject: RFR: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 In-Reply-To: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> References: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> Message-ID: On Fri, 9 Feb 2024 17:05:53 GMT, Hima Bindu Meda wrote: > Ported changes related to webkit-2.42.5. Verified build on all platforms. Sanity testing looks fine. Builds and tests ran succesfully. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1362#pullrequestreview-1873140822 From jhendrikx at openjdk.org Fri Feb 9 21:34:16 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:34:16 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 16:24:21 GMT, Kevin Rushforth wrote: >> JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. >> >> ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) >> >> The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. >> >> I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > more review feedback Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1361#pullrequestreview-1873227966 From jhendrikx at openjdk.org Fri Feb 9 21:34:17 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:34:17 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: <9JSvkX_GcnKA1Yddskxunvqcc-zwHeKVdGI6pUFkBA8=.22dac1b4-7d14-4f28-94d0-14a45f20e461@github.com> References: <9JSvkX_GcnKA1Yddskxunvqcc-zwHeKVdGI6pUFkBA8=.22dac1b4-7d14-4f28-94d0-14a45f20e461@github.com> Message-ID: On Fri, 9 Feb 2024 19:17:59 GMT, Kevin Rushforth wrote: > > I'm surprised this didn't get reported a long time ago. > > I'm also surprised. I do a lot of transparent text, cross fades, animation and other stuff, but first thing I always do is turn lcd rendering off... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1361#issuecomment-1936630349 From jhendrikx at openjdk.org Fri Feb 9 21:38:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:38:13 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 17:36:04 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add some clarifying documentation >> - Do not collapse trailing spaces of last line (where no soft wrap occurs) > > tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved. > > weird, github shows this file as new, but it is not. > 2024 It's sort of new, it's moved, it used to reside in the graphics project, but as it needs real fonts for its tests to work, it had to be a system test. > tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 58: > >> 56: private final PrismTextLayout layout = new PrismTextLayout(); >> 57: private final PGFont font = (PGFont) FontHelper.getNativeFont(Font.font("Monaco", 12)); >> 58: private final PGFont font2 = (PGFont) FontHelper.getNativeFont(Font.font("Tahoma", 12)); > > are these fonts available on all platforms? > what would happen if the font with this name is not found? They may not be present on all platforms, but that doesn't matter. All that matters is that they're present in our 3 build environments (linux, mac, windows), and since the build is succeeding, they must be present :) If they're not present, the test will simply fail. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484825164 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484826625 From jhendrikx at openjdk.org Fri Feb 9 21:44:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:44:08 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 17:38:16 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add some clarifying documentation >> - Do not collapse trailing spaces of last line (where no soft wrap occurs) > > tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 62: > >> 60: class TestSpan implements TextSpan { >> 61: String text; >> 62: Object font; > > final text and font? This is from the original test, I went ahead and converted it to a `record`. > tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 83: > >> 81: int i = 0; >> 82: while (i < content.length) { >> 83: spans[i>>1] = new TestSpan(content[i++], content[i++]); > > I would seriously recommend adhering to one statement per line here: > > Object text = content[i++]; > Object font = content[i++]; > spans[i>>1] = new TestSpan(text, font); This is not my code, it's from the original test. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484829896 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484830495 From jhendrikx at openjdk.org Fri Feb 9 21:49:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:49:06 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <_8xhdlpt9LW3AB9_Cgc-Uc0v09G8yVvUTznc-13x4hQ=.3364dc03-7bed-453e-a079-f39f7fe62414@github.com> On Fri, 9 Feb 2024 21:36:03 GMT, John Hendrikx wrote: >> tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 58: >> >>> 56: private final PrismTextLayout layout = new PrismTextLayout(); >>> 57: private final PGFont font = (PGFont) FontHelper.getNativeFont(Font.font("Monaco", 12)); >>> 58: private final PGFont font2 = (PGFont) FontHelper.getNativeFont(Font.font("Tahoma", 12)); >> >> are these fonts available on all platforms? >> what would happen if the font with this name is not found? > > They may not be present on all platforms, but that doesn't matter. All that matters is that they're present in our 3 build environments (linux, mac, windows), and since the build is succeeding, they must be present :) > > If they're not present, the test will simply fail. However... it does mean these fonts need to be present on your local environment as well if you want to build with test succeeding. I don't know if we can make that a requirement. I could add JUnit 5 `assume` here, but then it may magically stop executing the test if these fonts were ever removed from our build environment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484833587 From jhendrikx at openjdk.org Fri Feb 9 21:49:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:49:06 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 17:48:09 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add some clarifying documentation >> - Do not collapse trailing spaces of last line (where no soft wrap occurs) > > tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 414: > >> 412: 12.0f, 4.001953f >> 413: )); >> 414: > > should we add tests for leading/trailing tabs and milti-line strings, and multi-line with leading/trailing spaces? Multi line strings are I think addressed in the `hard wrap` cases (they contain line breaks). I can add a case for leading space (I only have one for trailing space), and can add cases for tabs (although there is uncertainty on how they should be treated). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484834811 From jhendrikx at openjdk.org Fri Feb 9 21:56:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 21:56:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <-C2UxOpicbNFmtvRTloPyZAoDiaJun6f9otnxW40XiQ=.5e64b7a0-1546-4242-9188-b715bbd22c07@github.com> On Fri, 9 Feb 2024 12:54:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add some clarifying documentation > - Do not collapse trailing spaces of last line (where no soft wrap occurs) > So we treat trailing spaces before \n as hard wrap, does it mean the same treatment is applied to the leading space (i.e. leading spaces in the first line), as seen here with TextAlignment=CENTER > > ``` > aaa bbb bbbb > ccc dddd eee ffffff > aaa b c > ``` > > ![Screenshot 2024-02-09 at 09 59 31](https://private-user-images.githubusercontent.com/107069028/303737487-9541c449-0c25-44ee-b85e-827b760d4710.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDc1MTUyODIsIm5iZiI6MTcwNzUxNDk4MiwicGF0aCI6Ii8xMDcwNjkwMjgvMzAzNzM3NDg3LTk1NDFjNDQ5LTBjMjUtNDRlZS1iODVlLTgyN2I3NjBkNDcxMC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwMjA5JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDIwOVQyMTQzMDJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT00OWY4ODZhYWQ3Mzg4MjliNDRjNmY5ZDY3NGUxOTdhMGJlZjIyMzJjZTExY2IzYjE0MmNlOTI0NmI1NDBmY2M0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.Ww_efTpd0AxSa_QVMjmKH2z8K1BPcVd8Kqp5vJtHE7o) Yes, white space is only collapsed when a soft wrap is inserted to keep it within `wrappingWidth` -- this is because a user can't predict where such wrapping occurs and would have to strip spaces there themselves (never mind that it wouldn't wrap anymore there then as there is no space). The other cases the user can easily solve themselves by ensuring that the strings they supply are `trim`ed. I think removing leading/trailing spaces (and double spaces) is a different feature (browsers like to do this) but not really suitable as a good default for FX. It could be made optional, but I think it is easy enough for a user to sanitize the strings they deliver a bit, while it would be impossible for the user to do so at the soft wrap locations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936652246 From angorya at openjdk.org Fri Feb 9 21:56:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 21:56:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: <-C2UxOpicbNFmtvRTloPyZAoDiaJun6f9otnxW40XiQ=.5e64b7a0-1546-4242-9188-b715bbd22c07@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-C2UxOpicbNFmtvRTloPyZAoDiaJun6f9otnxW40XiQ=.5e64b7a0-1546-4242-9188-b715bbd22c07@github.com> Message-ID: On Fri, 9 Feb 2024 21:51:15 GMT, John Hendrikx wrote: > I think it is easy enough for a user to sanitize the strings they deliver a bit, while it would be impossible for the user to do so at the soft wrap locations. I agree. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936653904 From angorya at openjdk.org Fri Feb 9 21:56:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 21:56:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 21:46:46 GMT, John Hendrikx wrote: >> tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 414: >> >>> 412: 12.0f, 4.001953f >>> 413: )); >>> 414: >> >> should we add tests for leading/trailing tabs and milti-line strings, and multi-line with leading/trailing spaces? > > Multi line strings are I think addressed in the `hard wrap` cases (they contain line breaks). I can add a case for leading space (I only have one for trailing space), and can add cases for tabs (although there is uncertainty on how they should be treated). I think we can leave the existing behavior with TABs as is. I would favor adding a test to capture the existing behavior, since you have the context and are the most knowledgeable person to do so right now :-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1484836844 From prr at openjdk.org Fri Feb 9 21:59:02 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 9 Feb 2024 21:59:02 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: References: <9JSvkX_GcnKA1Yddskxunvqcc-zwHeKVdGI6pUFkBA8=.22dac1b4-7d14-4f28-94d0-14a45f20e461@github.com> Message-ID: On Fri, 9 Feb 2024 21:31:14 GMT, John Hendrikx wrote: > > > I'm surprised this didn't get reported a long time ago. > > > > > > I'm also surprised. > > I do a lot of transparent text, cross fades, animation and other stuff, but first thing I always do is turn lcd rendering off... Which is a reasonable thing to do for all of that. LCD text is for the standard case of labels, textfields, menu items etc, and so only UI controls make it the default (where available). But I am STILL surprised ------------- PR Comment: https://git.openjdk.org/jfx/pull/1361#issuecomment-1936657379 From kcr at openjdk.org Fri Feb 9 22:07:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 22:07:13 GMT Subject: RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used [v3] In-Reply-To: <_38TZ-x_dBySjONts1j9MyQr8Zte2TQhCPv7oH7_Z0k=.c0cca23e-a073-4bb7-be66-c21eb66d86c0@github.com> References: <_38TZ-x_dBySjONts1j9MyQr8Zte2TQhCPv7oH7_Z0k=.c0cca23e-a073-4bb7-be66-c21eb66d86c0@github.com> Message-ID: On Fri, 9 Feb 2024 19:19:58 GMT, Andy Goryachev wrote: >> It's not really a headless vs headful distinction (the system tests are all headful). It's just that some tests have a global (static) Stage that should be hidden at shutdown time. Others, like the test in this PR, create, hide, and show a Stage in each test instance. Both are valid use cases. > > here it's under @AfterAll, not after each test. > > But still, what's the point of hiding the stage(s) if we follow it with Platform.exit() ? > Then we should get rid of the stage(s) argument and simply hide all the current stages, regardless. For this test, the call to shutdown is in an `@AfterAll` method. The call to `Stage.hide` is in an `@AfterEach` method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1361#discussion_r1484845747 From kcr at openjdk.org Fri Feb 9 22:07:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 22:07:13 GMT Subject: Integrated: 8311492: FontSmoothingType LCD produces wrong color when transparency is used In-Reply-To: References: Message-ID: <5_DDnOzb9TENvYhMt8szMFrYEkAs2qXBOL-jDkR7toE=.6843e7b5-27e4-4b70-ad69-1f4921b0c4e3@github.com> On Fri, 9 Feb 2024 12:56:15 GMT, Kevin Rushforth wrote: > JavaFX LCD text rendering (aka sub-pixel antialiasing) uses a pixel shader and alpha blending. The alpha channel is used is ways that interfere with its use for transparency. The existing logic checks that the current blend equation is SRC_OVER and that the surface is opaque, and that we are rendering using a Paint of type Color. It fails to check that the text color is opaque. When it isn't, the resulting alpha value is not preserved, even in the middle of the filled portion of the text, resulting in a visually noticeable difference in color. > > ![transparent-lcd-text](https://github.com/openjdk/jfx/assets/34689748/81f9503c-c706-44d8-b4db-6b47f0eb5fea) > > The solution is to add the missing check for alpha == 1 to the test that checks whether we can use LCD text rendering. I note that Java2D falls back to gray scale when the text color is transparent for a similar reason. > > I added a robot test that checks the color in the middle of the filled portion of a rendered text character and also checks that we use LCD for opaque colors and GRAY scale for transparent colors. This pull request has now been integrated. Changeset: a39732a3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/a39732a3c66e7168f3a9be84743eb52d4fd0043c Stats: 276 lines in 3 files changed: 274 ins; 0 del; 2 mod 8311492: FontSmoothingType LCD produces wrong color when transparency is used Reviewed-by: jhendrikx, angorya, prr ------------- PR: https://git.openjdk.org/jfx/pull/1361 From kcr at openjdk.org Fri Feb 9 22:28:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 22:28:04 GMT Subject: RFR: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 In-Reply-To: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> References: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> Message-ID: On Fri, 9 Feb 2024 17:05:53 GMT, Hima Bindu Meda wrote: > Ported changes related to webkit-2.42.5. Verified build on all platforms. Sanity testing looks fine. Looks good. Testing is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1362#pullrequestreview-1873283247 From angorya at openjdk.org Fri Feb 9 22:47:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 22:47:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 12:54:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add some clarifying documentation > - Do not collapse trailing spaces of last line (where no soft wrap occurs) The test is failing on macOS 14.3: 3a93cdf4f7 HEAD@{0}: checkout: moving from review.rtl_hittest_issue to review.wrapped-aligned-text-rendering TextLayoutTest > caseTest(Case) > [7] SOFT_WRAP_WITH_COMPLEX_TEXT FAILED org.opentest4j.AssertionFailedError: left aligned: line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:468) TextLayoutTest > caseTest(Case) > [8] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_TRAILING_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned: line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:468) TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() FAILED org.opentest4j.AssertionFailedError: runCount ==> expected: <2> but was: <1> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:559) at app//test.com.sun.javafx.text.TextLayoutTest.verifyLayout(TextLayoutTest.java:106) at app//test.com.sun.javafx.text.TextLayoutTest.fixedComplexTestsToEnsureNoFurtherRegressions(TextLayoutTest.java:192) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936701066 From kcr at openjdk.org Fri Feb 9 22:55:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Feb 2024 22:55:17 GMT Subject: [jfx22u] RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used Message-ID: Clean backport to jfx22u. ------------- Commit messages: - Backport a39732a3c66e7168f3a9be84743eb52d4fd0043c Changes: https://git.openjdk.org/jfx22u/pull/10/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=10&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311492 Stats: 276 lines in 3 files changed: 274 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx22u/pull/10.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/10/head:pull/10 PR: https://git.openjdk.org/jfx22u/pull/10 From jhendrikx at openjdk.org Fri Feb 9 23:27:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 23:27:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 22:44:07 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add some clarifying documentation >> - Do not collapse trailing spaces of last line (where no soft wrap occurs) > > The test is failing on macOS 14.3: > > > 3a93cdf4f7 HEAD@{0}: checkout: moving from review.rtl_hittest_issue to review.wrapped-aligned-text-rendering > > TextLayoutTest > caseTest(Case) > [7] SOFT_WRAP_WITH_COMPLEX_TEXT FAILED > org.opentest4j.AssertionFailedError: left aligned: line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) > at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) > at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:468) > > TextLayoutTest > caseTest(Case) > [8] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_TRAILING_SPACE FAILED > org.opentest4j.AssertionFailedError: left aligned: line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) > at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) > at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:468) > > TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() FAILED > org.opentest4j.AssertionFailedError: runCount ==> expected: <2> but was: <1> > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtil... @andy-goryachev-oracle > The test is failing on macOS 14.3: I can't do much here, I don't own a mac, and it does work in the build environment. Although I can't confirm that those tests actually run there... My own two tests fail because there is some 3 pixel width difference when complex text is used. The last test (an original one) fails due to a different number of runs. This suggests that it is not switching between character sets when it encounters the complex glyphs, so perhaps the font it is using doesn't have those glyphs? These are the reason I can think of why the test fails for you: 1. The test doesn't run on our build environment, and so it was never run on a mac before 2. There are multiple versions of the Monaco font 3. You don't have an international version of the Monaco font (if there is a distinction...) -- ie, the complex characters are rendered as "boxes" (that would be consistent with a width increase, the boxes are likely to be wider, and with a lower amount of runs) 4. You don't have the Monaco font at all, and it is falling back to something 5. Mac isn't consistent across different OS versions(?) Perhaps we can add an assumption in this test so it only runs on our build environment? All that matters (for me) is that no regressions get introduced, we'd just discover that a bit later then. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936732751 From jhendrikx at openjdk.org Fri Feb 9 23:37:16 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 23:37:16 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v13] In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: - Fix test description - Improve test - Test TextSpans (rich text) and String text (plain text) - Add test cases for leading spaces, tabs - Fix justified test to take hard wrapped lines into account correctly - Convert class to record ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1236/files - new: https://git.openjdk.org/jfx/pull/1236/files/3a93cdf4..cec1171a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=11-12 Stats: 106 lines in 1 file changed: 48 ins; 5 del; 53 mod Patch: https://git.openjdk.org/jfx/pull/1236.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236 PR: https://git.openjdk.org/jfx/pull/1236 From angorya at openjdk.org Fri Feb 9 23:37:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 23:37:16 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 12:54:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add some clarifying documentation > - Do not collapse trailing spaces of last line (where no soft wrap occurs) I see, so the test in graphics was @Ignore("JDK-8087615") I'd suggest to move the failing cases into a separate method and @Ignore that. We still have JDK-8087615 to deal with the failure, but at least we'll have a good working test with the rest of the scenarios. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936738038 From jhendrikx at openjdk.org Fri Feb 9 23:37:16 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 23:37:16 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <96anL--0D-ih9_KOgQjZpcYONmmzgG-roy4c9O4aIos=.0d41592c-5f27-40af-aa90-22f9ac3b914e@github.com> On Fri, 9 Feb 2024 12:54:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add some clarifying documentation > - Do not collapse trailing spaces of last line (where no soft wrap occurs) Justification + tabs are an odd combination. You can't adjust the tabs as they're supposed to go to tab stops, and tabs in the middle of a piece of text that is being wrapped will make really odd jumps (even without justification). Also lines with tabs will usually have a hard wrap (a line feed) as you otherwise don't know where a next tab would end up if you leave it up to soft wrapping -- lines with a hard wrap are considered to be the "last" line for justification, and so are simply left aligned. Even when the text is mostly justifiable, a tab will often end up at the "end" of a line, leaving white space there (which is what you want to avoid with justified text). All in all, it's a bad combination... so I think it's doing the "correct" thing currently, for certain definitions of "correct". So... I think for the tab tests, it doesn't make much sense to add tests that do soft wrapping + tabs, so I only added a few hard wrapped cases. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936738229 From jhendrikx at openjdk.org Fri Feb 9 23:43:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 23:43:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v13] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 23:37:16 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: > > - Fix test description > - Improve test > > - Test TextSpans (rich text) and String text (plain text) > - Add test cases for leading spaces, tabs > - Fix justified test to take hard wrapped lines into account correctly > - Convert class to record > I see, so the test in graphics was @ignore("JDK-8087615") > > I'd suggest to move the failing cases into a separate method and @ignore that. We still have JDK-8087615 to deal with the failure, but at least we'll have a good working test with the rest of the scenarios. > > What do you think? I think other tests may fail on other people's local environments, what you discovered may just be the tip of the iceberg, so we'd effectively be disabling many of these tests -- they really require a predictable environment (I would include fonts in the `src/test/resources` folder and load those if that was allowed) I think I would favor running these only on the build environment. Could you check if your Monaco font has those complex glyphs that it mentions in the failure message? `brown ?????? jumps`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936742756 From jhendrikx at openjdk.org Fri Feb 9 23:48:15 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Feb 2024 23:48:15 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add failing test to confirm build is running the TextLayoutTest ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1236/files - new: https://git.openjdk.org/jfx/pull/1236/files/cec1171a..00d83030 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=12-13 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1236.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236 PR: https://git.openjdk.org/jfx/pull/1236 From angorya at openjdk.org Fri Feb 9 23:48:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Feb 2024 23:48:15 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v13] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 23:37:16 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: > > - Fix test description > - Improve test > > - Test TextSpans (rich text) and String text (plain text) > - Add test cases for leading spaces, tabs > - Fix justified test to take hard wrapped lines into account correctly > - Convert class to record Monaco seems to have the glyphs: ![Screenshot 2024-02-09 at 15 43 19](https://github.com/openjdk/jfx/assets/107069028/f54eb2b7-f86f-4916-ae19-06785afbd4d2) I let @kevinrushforth weigh on whether we can add this test in its current form if it fails on macOS. I think we need to extract the complex failing cases into a separate section and ignore them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936746188 From kcr at openjdk.org Sat Feb 10 00:05:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 00:05:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Fri, 9 Feb 2024 23:48:15 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add failing test to confirm build is running the TextLayoutTest We can't have tests that fail consistently on our CI systems. I'll do a headful test run and post the results. For each test that doesn't pass on some platforms, we have a three options: 1. If we can characterize a set of requirements (platform, font) that make that test pass reliably, add the necessary JUnit5 Assumptions. 2. If the test passes most of the time, but is unstable, we can mark it as unstable using `assumeTrue(Boolean.getBoolean("unstable.test"));` 3. Skip the failing test with `@Disabled`. For the 2nd and 3rd options we need to reference an open bug ID. I suspect that it will be some combination of 1 and 3. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936753990 From jhendrikx at openjdk.org Sat Feb 10 00:05:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 00:05:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Fri, 9 Feb 2024 23:48:15 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add failing test to confirm build is running the TextLayoutTest Okay, so I'm getting the impression that the system tests are not run during the build (ie. `TextLayoutTest`). Is that an oversight or intended, or is my test somehow not qualifying? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936754982 From kcr at openjdk.org Sat Feb 10 00:13:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 00:13:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Sat, 10 Feb 2024 00:02:38 GMT, John Hendrikx wrote: > Okay, so I'm getting the impression that the system tests are not run during the build (ie. `TextLayoutTest`). Is that an oversight or intended, or is my test somehow not qualifying? > > clarification: I meant during the Github CI run, it does run during a normal (local) build That's intentional. We can only run headless tests in the GHA build. We do the same thing in our (Oracle's) CI build system. We do have a nightly Jenkins job that runs on physical systems that are set up for headful testing, and we can similarly submit dev jobs that use those machines. That's what I just did and will post the list of failing tests (if any). We don't yet have a headful Windows machine, so I'll run that locally. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936759766 From jhendrikx at openjdk.org Sat Feb 10 00:16:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 00:16:08 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Sat, 10 Feb 2024 00:10:33 GMT, Kevin Rushforth wrote: > That's intentional. We can only run headless tests in the GHA build. We do the same thing in our (Oracle's) CI build system. I was already pleasantly surprised that the three environments all had the correct Monaco and Tahoma font... guess I was being too optimistic, and the test simply never ran. > We do have a nightly Jenkins job that runs on physical systems that are set up for headful testing, and we can similarly submit dev jobs that use those machines. That's what I just did and will post the list of failing tests (if any). We don't yet have a headful Windows machine, so I'll run that locally. Thanks, at least on my Windows they are all passing, but I can add assumes, or fix them for a different platform based on the failure output (that may take 2 or 3 passes as it doesn't display all failures in one go). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936761354 From jhendrikx at openjdk.org Sat Feb 10 00:19:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 00:19:05 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Fri, 9 Feb 2024 23:48:15 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add failing test to confirm build is running the TextLayoutTest Also I think the `TextLayoutTest` isn't really headful, it never displays anything (no stages, uses no `Node`s), but it does need a real `PrismFont` -- it may be difficult to get that to work though ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936763262 From kcr at openjdk.org Sat Feb 10 00:35:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 00:35:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Fri, 9 Feb 2024 23:48:15 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add failing test to confirm build is running the TextLayoutTest Results on my local Windows 11 system: $ gradle --info -PFULL_TEST=true :systemTests:test --tests TextLayoutTest ... > Task :systemTests:test FAILED TextLayoutTest > shouldIgnoreAlignmentWhenWrappingIsDisabled() FAILED org.opentest4j.AssertionFailedError: line 0 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.assertLineBounds(TextLayoutTest.java:98) at app//test.com.sun.javafx.text.TextLayoutTest.shouldIgnoreAlignmentWhenWrappingIsDisabled(TextLayoutTest.java:314) TextLayoutTest > fail() FAILED org.opentest4j.AssertionFailedError: Check if this system test actually runs on the build environment; font loaded was [System Regular, System, Regular, System Regular, 12.0] and [Tahoma, Tahoma, Regular, Tahoma, 12.0] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.com.sun.javafx.text.TextLayoutTest.fail(TextLayoutTest.java:570) TextLayoutTest > caseTest(Case) > [1] NO_WRAP FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown fox jumps over the lazy dog, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=0.0, lineWidths=[309.6504], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [2] HARD_WRAP FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown fox jumps over the lazy dog, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=0.0, lineWidths=[180.0293, 122.41992], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [3] HARD_WRAP_WITH_EXTRA_TRAILING_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown fox jumps over the lazy dog , font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=0.0, lineWidths=[259.2422, 201.63281], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [4] HARD_WRAP_WITH_TABS FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text= A A x A A xx A A, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=0.0, lineWidths=[79.21289, 79.21289, 79.21289], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [5] HARD_WRAP_WITH_MULTIPLE_TABS FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text= , font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=0.0, lineWidths=[57.609375, 115.21875, 172.82812], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [6] SOFT_WRAP FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown fox jumps over the lazy dog, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[180.0293, 122.41992], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [7] SOFT_WRAP_WITH_LEADING_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text= The quick brown fox jumps over the lazy dog, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[165.62695, 165.62695], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [8] SOFT_WRAP_WITH_TRAILING_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown fox jumps over the lazy dog , font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[180.0293, 151.22461], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [9] SOFT_WRAP_WITH_EXTRA_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown fox jumps over the lazy dog, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[180.0293, 122.41992], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [10] SOFT_WRAP_WITH_COMPLEX_TEXT FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [11] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_TRAILING_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=System Regular, family=System, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED 17 tests completed, 13 failed, 1 skipped ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936770039 From kcr at openjdk.org Sat Feb 10 00:35:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 00:35:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: <_mAo_4Ah5Fcj9MRBRnjPAy5II5LcPXwonikacINqYrE=.9ef220ac-a939-404c-b2f7-99fe4f4e3a87@github.com> On Sat, 10 Feb 2024 00:16:33 GMT, John Hendrikx wrote: > Also I think the `TextLayoutTest` isn't really headful, it never displays anything (no stages, uses no `Node`s), but it does need a real `PrismFont` -- it may be difficult to get that to work though Yeah, without a proper headless glass toolkit (which Johan is working on), this will be difficult. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936770950 From jhendrikx at openjdk.org Sat Feb 10 00:35:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 00:35:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Fri, 9 Feb 2024 23:48:15 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add failing test to confirm build is running the TextLayoutTest That's interesting, your local Windows 11 system does not have the Monaco font (it is falling back to System Regular it seems). I guess I installed it on mine at some point. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936771799 From kcr at openjdk.org Sat Feb 10 00:38:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 00:38:03 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Sat, 10 Feb 2024 00:32:18 GMT, John Hendrikx wrote: > That's interesting, your local Windows 11 system does not have the Monaco font (it is falling back to System Regular it seems). I guess I installed it on mine at some point. Probably so. I just verified that I don't have Monaco on my Windows 11 system. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936773233 From kcr at openjdk.org Sat Feb 10 00:43:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 00:43:03 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Fri, 9 Feb 2024 23:48:15 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add failing test to confirm build is running the TextLayoutTest Here are the failures from our macOS 14.x headful test system (run on Jenkins). TextLayoutTest > fail() FAILED org.opentest4j.AssertionFailedError: Check if this system test actually runs on the build environment; font loaded was [Monaco, Monaco, Regular, Monaco, 12.0] and [Tahoma, Tahoma, Regular, Tahoma, 12.0] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.com.sun.javafx.text.TextLayoutTest.fail(TextLayoutTest.java:570) Failed to map supported failure 'org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: ' with mapper 'org.gradle.api.internal.tasks.testing.failure.mappers.OpenTestAssertionFailedMapper at 38b27cdc': Cannot invoke "Object.getClass()" because "expectedValue" is null Failed to map supported failure 'org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: ' with mapper 'org.gradle.api.internal.tasks.testing.failure.mappers.OpenTestAssertionFailedMapper at 38b27cdc': Cannot invoke "Object.getClass()" because "expectedValue" is null TextLayoutTest > caseTest(Case) > [10] SOFT_WRAP_WITH_COMPLEX_TEXT FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > caseTest(Case) > [11] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_TRAILING_SPACE FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, font=Font[name=Monaco, family=Monaco, style=Regular, size=12.0], wrapWidth=200.0, lineWidths=[189.89648, 122.583984], ascent=12.0, descent=4.001953] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:509) TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() FAILED org.opentest4j.AssertionFailedError: runCount ==> expected: <2> but was: <1> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:559) at app//test.com.sun.javafx.text.TextLayoutTest.verifyLayout(TextLayoutTest.java:106) at app//test.com.sun.javafx.text.TextLayoutTest.fixedComplexTestsToEnsureNoFurtherRegressions(TextLayoutTest.java:192) And on Linux I get similar failures to my Windows system due to no Monaco font. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936774895 PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936775486 From jhendrikx at openjdk.org Sat Feb 10 04:01:03 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 04:01:03 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Sat, 10 Feb 2024 00:40:41 GMT, Kevin Rushforth wrote: > And on Linux I get similar failures to my Windows system due to no Monaco font. Was the Tahoma font available there (you can see from the `TextLayoutTest > fail()` test) ? If so, I could rewrite most of the tests to use the Tahoma font, and then probably disable most of the tests for MacOS, unless we can find a font that is common to all platforms -- searching around the web, I get the impression that the fonts "Arial", "Verdana" and "Times New Roman" may be present on all three platforms. The test isn't so much a test of the font rendering or engine, but a test of alignment and soft wrapping, so having it run on even one OS is a big win. Variations in font, sizes, etc, don't really change what code paths are hit, just the resulting widths will be off by a few pixels (still need a specific font to use as baseline though as the test widths are manually picked to match). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1936846984 From prr at openjdk.org Sat Feb 10 04:59:02 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 10 Feb 2024 04:59:02 GMT Subject: [jfx22u] RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used In-Reply-To: References: Message-ID: <89OswoeVW3tbpphqUUX_vzBSoK1Whb7f9Uk568vRSiI=.b9d6cb75-73a7-4da0-816f-11d307ac719d@github.com> On Fri, 9 Feb 2024 22:50:42 GMT, Kevin Rushforth wrote: > Clean backport to jfx22u. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/10#pullrequestreview-1873401759 From crschnick at xpipe.io Sat Feb 10 05:17:50 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 10 Feb 2024 06:17:50 +0100 Subject: Detecting successful file drops on macOS Message-ID: <51292c6e-2be7-4dda-a43b-6513b947e899@xpipe.io> Hello, I'm using macOS Sonoma 14.3 aarch64 and I'm trying to recognize whether a file was successfully dropped into finder from the JavaFX application. However, the event always reports that it was not accepted. I was under the impression that event.isAccepted() should return true if it was successfully dropped. This is the reproducer: |public class DragDrop extends Application { ??? @Override ??? public void start(Stage primaryStage) throws Exception { ??????? var file = Files.createTempFile("test", null); ??????? var r = new Region(); ??????? r.setOnDragDetected(event -> { ??????????? event.setDragDetect(true); ??????????? Dragboard db = r.startDragAndDrop(TransferMode.MOVE); ??????????? var cc = new ClipboardContent(); ??????????? cc.putFiles(List.of(file.toFile())); ??????????? db.setContent(cc); ??????????? event.consume(); ??????? }); ??????? r.setOnDragDone(event -> { ??????????? System.out.println("Accepted: " + event.isAccepted()); ??????????? System.out.println(event); ??????? }); ??????? var scene = new Scene(r, 450, 500); ??????? primaryStage.setScene(scene); ??????? primaryStage.setTitle("Test"); ??????? primaryStage.show(); ??? } }| | | I looked through the documentation of DragEvent but I'm still not really sure whether this is a bug. The documentation of DragEvent is a little bit light when it comes to behavior of drag events that go to the system itself. Best Christopher Schnick -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Feb 10 14:43:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 14:43:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Sat, 10 Feb 2024 03:58:24 GMT, John Hendrikx wrote: > > And on Linux I get similar failures to my Windows system due to no Monaco font. > > Was the Tahoma font available there (you can see from the `TextLayoutTest > fail()` test) ? It doesn't look like it: org.opentest4j.AssertionFailedError: Check if this system test actually runs on the build environment; font loaded was [System Regular, System, Regular, System Regular, 12.0] and [System Regular, System, Regular, System Regular, 12.0] ==> expected: but was: > ...searching around the web, I get the impression that the fonts "Arial", "Verdana" and "Times New Roman" may be present on all three platforms. That might make sense. Whichever font you do choose, you will want to add an Assumption to check for its existence and skip the tests if not found. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1937022815 From crschnick at xpipe.io Sat Feb 10 04:55:19 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 10 Feb 2024 05:55:19 +0100 Subject: Platform preferences theme detection In-Reply-To: <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> Message-ID: Lastly I also tried it on macOS. The accent color detection works there, but the color scheme detection does not, i.e. it always returns light mode. I'm using macOS Sonoma 14.3 with aarch64. Here are the preferences when dark mode is set in the settings: So since you are thinking about making this a preview-only feature, I don't think there is that much to do to properly handle systems where some properties are not supported. Just a few methods to set the default value of foreground, background, and accent color would be enough. In theory I don't need to know exactly what color observation is supported, I only want to have the ability to use my own colors as defaults in that case. Best Christopher Schnick On 06/02/2024 01:57, Christopher Schnick wrote: > > Alright, if the accent is not supported yet then almost everything is > fine I guess. The settings issue is not noticeable as all the updates > happen very fast. > > I want to open my previous question about detecting unsupported colors > again here. So I assume that for example accent detection is not > supported on any Linux system and I have not tested yet how widespread > the support for color scheme detection is on other desktop > environments. From an application developer's point of view, the > platform preferences feature loses some appeal if there is no way of > enabling a control flow like: If the system color is supported use > that one, else use the color that I manually define somehow. > > So it would be nice to either have a relatively simple way of > detecting which basic color property foreground, background, accent, > color scheme is actually supported or allow application developers to > set the default value for that property manually. In this case, I > could just set a good looking default accent color, which would then > be returned on Linux systems as that property is not supported yet. > > I don't have access to the JBS, I'm not even sure how you get that. > > On 2/6/2024 1:26 AM, Michael Strau? wrote: >> Hi Christopher! >> >> 1) Accent color detection is not yet implemented for Linux/GTK. I >> think this is a fairly recent addition for Ubuntu, probably in >> version 22. >> >> 2) I don't see this behavior on my Ubuntu 20.04 system (need to >> upgrade to 23 and test again). If you have acess to JBS, feel free to >> open a bug ticket to track this issue. >> >> >> On Mon, Feb 5, 2024 at 10:56?PM Christopher Schnick >> wrote: >> >> I finally found some time to test the latest ea build and can >> confirm that it works now on Windows as expected. >> >> Next, I moved to Linux, more specifically Ubuntu 23.04, and >> encountered some issues: >> - The accent color detection does not work, i.e. it does not >> initially detect the value set in the settings and also does not >> change when I modify the accent color in the Ubuntu Settings. I >> can see some values changing in the map, however the end result >> is still the same >> - When opening the Ubuntu Settings application, the entire >> platform preferences map is updated with weird values but somehow >> changes back immediately after. Maybe it reports the default >> light mode colors for a split second when opening the settings? >> >> Once again I do not know whether this is intended or not as there >> is no definitive list of which operating systems are supported. >> Here is the obligatory preferences map on that system: >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2024-02-10 at 05.45.59.png Type: image/png Size: 192507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2024-02-10 at 05.47.20.png Type: image/png Size: 130446 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img.png Type: image/png Size: 97121 bytes Desc: not available URL: From kcr at openjdk.org Sat Feb 10 14:56:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 14:56:04 GMT Subject: [jfx22u] RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 22:50:42 GMT, Kevin Rushforth wrote: > Clean backport to jfx22u. @johanvos Presuming you have no concerns, can you do the maintainer approval (`/approve yes`) when you get a chance? ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/10#issuecomment-1937025067 From kcr at openjdk.org Sat Feb 10 15:03:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 15:03:09 GMT Subject: [jfx22u] RFR: 8311492: FontSmoothingType LCD produces wrong color when transparency is used In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 22:50:42 GMT, Kevin Rushforth wrote: > Clean backport to jfx22u. Thanks. ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/10#issuecomment-1937026198 From kcr at openjdk.org Sat Feb 10 15:03:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 15:03:10 GMT Subject: [jfx22u] Integrated: 8311492: FontSmoothingType LCD produces wrong color when transparency is used In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 22:50:42 GMT, Kevin Rushforth wrote: > Clean backport to jfx22u. This pull request has now been integrated. Changeset: d4328d96 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/d4328d969aa69751e9171918c14bacf294c45e46 Stats: 276 lines in 3 files changed: 274 ins; 0 del; 2 mod 8311492: FontSmoothingType LCD produces wrong color when transparency is used Reviewed-by: prr Backport-of: a39732a3c66e7168f3a9be84743eb52d4fd0043c ------------- PR: https://git.openjdk.org/jfx22u/pull/10 From kcr at openjdk.org Sat Feb 10 15:17:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 15:17:02 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <-xrX5h4pIZS8H5RfX7vzgdsxLaj0TsS9IF2UUkZft3U=.be5518f3-8647-4834-8ffe-2529953c4c25@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> <-xrX5h4pIZS8H5RfX7vzgdsxLaj0TsS9IF2UUkZft3U=.be5518f3-8647-4834-8ffe-2529953c4c25@github.com> Message-ID: <3SeWc6uXmgtTSjBLq6wSjd9lpTUOt4pkNIOEfshKaRQ=.86a9f763-12ff-4d6b-b565-ae29390fe25a@github.com> On Mon, 5 Feb 2024 22:25:36 GMT, John Hendrikx wrote: >>> need 2 passes, because there already is a method named like that: >> >> oh yeah, sorry. >> `getStyleClassesSet()` ? > >> > need 2 passes, because there already is a method named like that: >> >> oh yeah, sorry. `getStyleClassesSet()` ? > > That one is still available yes :) @hjohn I'm now leaning towards either `getStyleClassNames` or `getClassNames`, but it isn't a strong preference. Why don't you pick one, update the PR, and create a Draft CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1937040083 From kcr at openjdk.org Sat Feb 10 15:41:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Feb 2024 15:41:02 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5] In-Reply-To: <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> Message-ID: <4-EPYLj7kXkzTeL_fZphQFFZOSCcBLVhCeVmXllr5Is=.2e8b463e-3cf1-4895-a99b-cd03f29fa594@github.com> On Mon, 5 Feb 2024 16:46:40 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with two additional commits since the last revision: > > - Work-around for using a call not present in the Xcode 13.3 SDK. > - Need correctly formed NSNotification when running tests This now passes on our CI build systems. I'll review it next week some time. Most of the changes are trivial, but there are a couple I want to double-check that there is no change in behavior. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1937046048 From michaelstrau2 at gmail.com Sat Feb 10 17:10:23 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 10 Feb 2024 18:10:23 +0100 Subject: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> Message-ID: Hi Christopher, the relevant preferences for color scheme detection are textColor=0x000000ff and textBackgroundColor=0xffffffff on your system. That's pretty strange, I'm getting the following values on macOS Sonoma 14.3.1 M1: in light mode: textColor=0x000000ff, textBackgroundColor=0xffffffff in dark mode: textColor=0xffffffff, textBackgroundColor=0x1e1e1eff Consequently, I'm also getting the correct color scheme when I'm switching between light and dark mode on macOS (verified with the PlatformPreferencesChangedTest application). On Sat, Feb 10, 2024 at 5:55?AM Christopher Schnick wrote: > Lastly I also tried it on macOS. The accent color detection works there, > but the color scheme detection does not, i.e. it always returns light mode. > I'm using macOS Sonoma 14.3 with aarch64. > > Here are the preferences when dark mode is set in the settings: > > > > So since you are thinking about making this a preview-only feature, I > don't think there is that much to do to properly handle systems where some > properties are not supported. Just a few methods to set the default value > of foreground, background, and accent color would be enough. In theory I > don't need to know exactly what color observation is supported, I only want > to have the ability to use my own colors as defaults in that case. > > Best > Christopher Schnick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Sat Feb 10 17:24:17 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 17:24:17 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v15] In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Change test to use the more common Arial font and add assumptions ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1236/files - new: https://git.openjdk.org/jfx/pull/1236/files/00d83030..206b3a2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=13-14 Stats: 107 lines in 1 file changed: 18 ins; 26 del; 63 mod Patch: https://git.openjdk.org/jfx/pull/1236.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236 PR: https://git.openjdk.org/jfx/pull/1236 From jhendrikx at openjdk.org Sat Feb 10 17:28:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 17:28:04 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v14] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <_9QVC3oktc-Skq3Be7emHFuO3WFxiJ5cFAA6ANy5X3U=.c0947957-310f-4bb8-a8b8-4a6eba85f37b@github.com> Message-ID: On Sat, 10 Feb 2024 14:40:45 GMT, Kevin Rushforth wrote: >>> And on Linux I get similar failures to my Windows system due to no Monaco font. >> >> Was the Tahoma font available there (you can see from the `TextLayoutTest > fail()` test) ? >> >> If so, I could rewrite most of the tests to use the Tahoma font, and then probably disable most of the tests for MacOS, unless we can find a font that is common to all platforms -- searching around the web, I get the impression that the fonts "Arial", "Verdana" and "Times New Roman" may be present on all three platforms. >> >> The test isn't so much a test of the font rendering or engine, but a test of alignment and soft wrapping, so having it run on even one OS is a big win. Variations in font, sizes, etc, don't really change what code paths are hit, just the resulting widths will be off by a few pixels (still need a specific font to use as baseline though as the test widths are manually picked to match). > >> > And on Linux I get similar failures to my Windows system due to no Monaco font. >> >> Was the Tahoma font available there (you can see from the `TextLayoutTest > fail()` test) ? > > It doesn't look like it: > > > org.opentest4j.AssertionFailedError: Check if this system test actually runs on the build environment; > font loaded was [System Regular, System, Regular, System Regular, 12.0] > and [System Regular, System, Regular, System Regular, 12.0] > ==> expected: but was: > > >> ...searching around the web, I get the impression that the fonts "Arial", "Verdana" and "Times New Roman" may be present on all three platforms. > > That might make sense. Whichever font you do choose, you will want to add an Assumption to check for its existence and skip the tests if not found. @kevinrushforth @andy-goryachev-oracle I've modified the test to use the Arial font instead of Monaco (hoping that at least Arial is available on all systems). The Tahoma font I kept intact as the original test is doing some special case with it (but it's only one test). With any luck, 95% of the tests work on all systems now. The test using Tahoma probably only works on a Windows system. I've added assumptions as well, so the tests are automatically skipped when fonts are returned that are unexpected. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1937076930 From jhendrikx at openjdk.org Sat Feb 10 17:33:03 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 17:33:03 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: <2MzH3ZuU2xSg6bNY3i2ANGTZ3deVgKxVZwQkdjdYmuc=.c4067502-da10-4bca-9df3-0c2a0fc8af16@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> <2MzH3ZuU2xSg6bNY3i2ANGTZ3deVgKxVZwQkdjdYmuc=.c4067502-da10-4bca-9df3-0c2a0fc8af16@github.com> Message-ID: On Thu, 8 Feb 2024 21:25:41 GMT, Marius Hanl wrote: > I completely forgot about this PR, but it looks very interesting, especially about the nested events. If helpful, I can test this soon in a bigger application, especially for any regressions. And of course also review the code, but need more time for that. @Maran23 both will be appreciated; I've tested this with my own FX applications for a while, and haven't encountered anything unexpected. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1937078085 From michaelstrau2 at gmail.com Sat Feb 10 17:44:19 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 10 Feb 2024 18:44:19 +0100 Subject: Platform preferences theme detection In-Reply-To: <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> Message-ID: Since I can't reproduce the error on macOS, it's hard to say what could be causing it. If you have the chance, maybe you could run the PlatformPreferencesChangedTest application: https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java That might rule out that the differences we're seeing have anything to do with the way we're using the API. On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: > > I checked again, restarted everything, but still the same problem: > > Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. From jhendrikx at openjdk.org Sat Feb 10 17:53:27 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Feb 2024 17:53:27 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v5] In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Use getStyleClassNames ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1340/files - new: https://git.openjdk.org/jfx/pull/1340/files/631ca587..117a8025 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1340&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1340.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1340/head:pull/1340 PR: https://git.openjdk.org/jfx/pull/1340 From martin at martinfox.com Sun Feb 11 00:31:06 2024 From: martin at martinfox.com (Martin Fox) Date: Sat, 10 Feb 2024 16:31:06 -0800 Subject: Detecting successful file drops on macOS In-Reply-To: <51292c6e-2be7-4dda-a43b-6513b947e899@xpipe.io> References: <51292c6e-2be7-4dda-a43b-6513b947e899@xpipe.io> Message-ID: <748A8300-CEF9-4815-BA04-1D6C669D74AA@martinfox.com> Hi Christopher, This is a bug in the Mac platform code. I?ve created a JBS issue, see https://bugs.openjdk.org/browse/JDK-8325591. Unfortunately I haven?t found a work-around for it. Martin > On Feb 9, 2024, at 9:17?PM, Christopher Schnick wrote: > > Hello, > I'm using macOS Sonoma 14.3 aarch64 and I'm trying to recognize whether a file was successfully dropped into finder from the JavaFX application. However, the event always reports that it was not accepted. I was under the impression that event.isAccepted() should return true if it was successfully dropped. This is the reproducer: > > public class DragDrop extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > var file = Files.createTempFile("test", null); > > var r = new Region(); > r.setOnDragDetected(event -> { > event.setDragDetect(true); > Dragboard db = r.startDragAndDrop(TransferMode.MOVE); > var cc = new ClipboardContent(); > cc.putFiles(List.of(file.toFile())); > db.setContent(cc); > event.consume(); > }); > > r.setOnDragDone(event -> { > System.out.println("Accepted: " + event.isAccepted()); > System.out.println(event); > }); > > var scene = new Scene(r, 450, 500); > primaryStage.setScene(scene); > primaryStage.setTitle("Test"); > primaryStage.show(); > } > } > > > > I looked through the documentation of DragEvent but I'm still not really sure whether this is a bug. The documentation of DragEvent is a little bit light when it comes to behavior of drag events that go to the system itself. > > Best > Christopher Schnick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Sun Feb 11 05:05:23 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sun, 11 Feb 2024 06:05:23 +0100 Subject: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> Message-ID: <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> Well, that is going to be a fun one to debug ... In my application I check for a headless environment with GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). If you call that one before you initialize your application, the preferences detection does no longer update. So if you augment your PlatformPreferencesChangedTest application with this main method, it no longer works. Also, it throws another exception when clicking on the fail button. |??? public static void main(String[] args) { GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); ??????? Application.launch(args); ??? }| On 10/02/2024 18:44, Michael Strau? wrote: > Since I can't reproduce the error on macOS, it's hard to say what > could be causing it. > > If you have the chance, maybe you could run the > PlatformPreferencesChangedTest application: > https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java > > That might rule out that the differences we're seeing have anything to > do with the way we're using the API. > > > On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >> I checked again, restarted everything, but still the same problem: >> >> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Feb 12 04:00:04 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 12 Feb 2024 04:00:04 GMT Subject: RFR: 8307117: TextArea: wrapText property ignored when changing font [v3] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 21:41:10 GMT, Andy Goryachev wrote: >> Requesting content layout when font changes. >> >> This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1217#pullrequestreview-1874523664 From hmeda at openjdk.org Mon Feb 12 04:35:03 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 12 Feb 2024 04:35:03 GMT Subject: Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 In-Reply-To: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> References: <4ADe72AIyq1Fpe6fkCiC9iU-QEJg8948W6KL1ix9s1Y=.36f5ad3c-1446-4d54-8df4-ae972f64d6da@github.com> Message-ID: <1OIjezy3f3gUwMJuJVNhqt4IXnvL22FKoeNn3dFnXlk=.ff33b9b9-2e5a-4ed4-9bb6-43f198893c2e@github.com> On Fri, 9 Feb 2024 17:05:53 GMT, Hima Bindu Meda wrote: > Ported changes related to webkit-2.42.5. Verified build on all platforms. Sanity testing looks fine. This pull request has now been integrated. Changeset: a7f6de8d Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/a7f6de8d13fd7a7e37ca80b28badcb24566153d8 Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Reviewed-by: sykora, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1362 From kpk at openjdk.org Mon Feb 12 06:24:04 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 12 Feb 2024 06:24:04 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v10] In-Reply-To: References: Message-ID: <-XAKEjhrZtDREEDTXg3yQBa3zHeRHdEmVYSoFXyEt-o=.0ca6390d-b5e7-4b41-800f-168305d80d09@github.com> On Thu, 8 Feb 2024 18:22:28 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix emoji issue > > @hjohn this might impact your work in #1236 - would you like to take a look? Thanks for reviewing @andy-goryachev-oracle @hjohn / @prrace would you like to take a look at this PR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1938117492 From kpk at openjdk.org Mon Feb 12 10:05:11 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 12 Feb 2024 10:05:11 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v15] In-Reply-To: <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> Message-ID: On Sat, 10 Feb 2024 17:24:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change test to use the more common Arial font and add assumptions I ran the tests in my Mac system with macOS 14.3 and found 2 tests are failing with following error: TextLayoutTest > caseTest(Case) > test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[10] FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501) TextLayoutTest > caseTest(Case) > test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[11] FAILED org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501) TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() SKIPPED TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED The failing tests are SOFT_WRAP_WITH_COMPLEX_TEXT and SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE. Added a minor comment inline as well. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 1228: > 1226: * > 1227: * Text effects have no effect on the alignment, and so with underlining on > 1228: * the right right aligned text would look like: Minor: "right" is repeated ------------- PR Review: https://git.openjdk.org/jfx/pull/1236#pullrequestreview-1874624074 PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1485798441 From kpk at openjdk.org Mon Feb 12 10:05:11 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 12 Feb 2024 10:05:11 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v12] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Fri, 9 Feb 2024 17:33:04 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add some clarifying documentation >> - Do not collapse trailing spaces of last line (where no soft wrap occurs) > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 1245: > >> 1243: * no matter where it occurs). >> 1244: */ >> 1245: > > @karthikpandelu could you please take a look at this comment here and this PR in general (since you both are modifying the same file)? > > Is there anything to add? I checked my changes along with the changes in this PR. The changes made in [PR#1323](https://github.com/openjdk/jfx/pull/1323) works fine with these changes and proper hit test values are obtained. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1485956832 From hmeda at openjdk.org Mon Feb 12 15:53:28 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 12 Feb 2024 15:53:28 GMT Subject: [jfx22u] Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Message-ID: Clean Backport ------------- Commit messages: - Backport a7f6de8d13fd7a7e37ca80b28badcb24566153d8 Changes: https://git.openjdk.org/jfx22u/pull/11/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=11&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325258 Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod Patch: https://git.openjdk.org/jfx22u/pull/11.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/11/head:pull/11 PR: https://git.openjdk.org/jfx22u/pull/11 From hmeda at openjdk.org Mon Feb 12 15:53:28 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 12 Feb 2024 15:53:28 GMT Subject: [jfx22u] Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 In-Reply-To: References: Message-ID: <8biMVe4M_4aTe_PiffZE7Dk8xChbRrt1LZygxD-sUUA=.92f21b0b-7152-41b5-b88a-2f5ac62e1af2@github.com> On Mon, 12 Feb 2024 15:46:41 GMT, Hima Bindu Meda wrote: > Clean Backport This pull request has now been integrated. Changeset: 82618d0e Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx22u/commit/82618d0e41806df238128b7199a09bf208ebb428 Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Backport-of: a7f6de8d13fd7a7e37ca80b28badcb24566153d8 ------------- PR: https://git.openjdk.org/jfx22u/pull/11 From kcr at openjdk.org Mon Feb 12 16:12:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Feb 2024 16:12:07 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v15] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> Message-ID: On Mon, 12 Feb 2024 10:00:57 GMT, Karthik P K wrote: > I ran the tests in my Mac system with macOS 14.3 and found 2 tests are failing with following error: I see the same two failures on our CI macOS 13.x and macOS 14.x test machines. On our Linux systems, all tests are skipped (meaning that they don't have the Arial font available). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1939005318 From crschnick at xpipe.io Sat Feb 10 17:23:30 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 10 Feb 2024 18:23:30 +0100 Subject: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> Message-ID: <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> I checked again, restarted everything, but still the same problem: Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. On 10/02/2024 18:10, Michael Strau? wrote: > Hi Christopher, > > the relevant preferences for color scheme detection are > textColor=0x000000ff and textBackgroundColor=0xffffffff on your system. > > That's pretty strange, I'm getting the following values on macOS > Sonoma 14.3.1 M1: > ? ? in light mode: textColor=0x000000ff, textBackgroundColor=0xffffffff > ? ? in dark mode: textColor=0xffffffff, textBackgroundColor=0x1e1e1eff > > Consequently, I'm also getting the correct color scheme when I'm > switching between light and dark mode on macOS (verified with the > PlatformPreferencesChangedTest application). > > > > On Sat, Feb 10, 2024 at 5:55?AM Christopher Schnick > wrote: > > Lastly I also tried it on macOS. The accent color detection works > there, but the color scheme detection does not, i.e. it always > returns light mode. I'm using macOS Sonoma 14.3 with aarch64. > > Here are the preferences when dark mode is set in the settings: > > > > So since you are thinking about making this a preview-only > feature, I don't think there is that much to do to properly handle > systems where some properties are not supported. Just a few > methods to set the default value of foreground, background, and > accent color would be enough. In theory I don't need to know > exactly what color observation is supported, I only want to have > the ability to use my own colors as defaults in that case. > > Best > Christopher Schnick > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2024-02-10 at 18.19.00.png Type: image/png Size: 400642 bytes Desc: not available URL: From angorya at openjdk.org Mon Feb 12 16:18:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Feb 2024 16:18:08 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v15] In-Reply-To: <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> Message-ID: On Sat, 10 Feb 2024 17:24:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change test to use the more common Arial font and add assumptions It looks like the original intent was to have one monospaced (Monaco) and one proportional (Tahoma) font. Perhaps we could come up with a list of candidates and pick a font to use based on availability? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1939038503 From kcr at openjdk.org Mon Feb 12 16:18:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Feb 2024 16:18:11 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v5] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <2rMhw4l382vEYq5Wjw3ucgFmqfeD5fezzZnYfDTFoOI=.48e4db7b-d434-427b-9384-e6b0aacc6e8e@github.com> On Sat, 10 Feb 2024 17:53:27 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Use getStyleClassNames Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1340#pullrequestreview-1875631782 From kevin.rushforth at oracle.com Mon Feb 12 16:20:05 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2024 08:20:05 -0800 Subject: Platform preferences theme detection In-Reply-To: <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> Message-ID: <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> That likely means that initializing the AWT toolkit is interfering with this functionality. I presume you are using a very recent ea build of JavaFX 22. What version of JDK are you using? -- Kevin On 2/10/2024 9:05 PM, Christopher Schnick wrote: > > Well, that is going to be a fun one to debug ... In my application I > check for a headless environment with > GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). > If you call that one before you initialize your application, the > preferences detection does no longer update. So if you augment your > PlatformPreferencesChangedTest application with this main method, it > no longer works. Also, it throws another exception when clicking on > the fail button. > > |??? public static void main(String[] args) { > GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); > ??????? Application.launch(args); > ??? }| > > On 10/02/2024 18:44, Michael Strau? wrote: >> Since I can't reproduce the error on macOS, it's hard to say what >> could be causing it. >> >> If you have the chance, maybe you could run the >> PlatformPreferencesChangedTest application: >> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >> >> That might rule out that the differences we're seeing have anything to >> do with the way we're using the API. >> >> >> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>> I checked again, restarted everything, but still the same problem: >>> >>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Mon Feb 12 16:36:26 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Mon, 12 Feb 2024 17:36:26 +0100 Subject: Platform preferences theme detection In-Reply-To: <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> Message-ID: <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. I guess I can try upgrading to JDK 21.0.2, but I will just assume that there haven't been many changes to awt in that time. Interestingly, I found another issue that occurs when that call to |GraphicsEnvironment| is made/not made where it is not possible to quit a JavaFX application via the dock quit operation when it is minimized to an AWT tray icon. I can file a separate issue for that. On 12/02/2024 17:20, Kevin Rushforth wrote: > That likely means that initializing the AWT toolkit is interfering > with this functionality. > > I presume you are using a very recent ea build of JavaFX 22. What > version of JDK are you using? > > -- Kevin > > > On 2/10/2024 9:05 PM, Christopher Schnick wrote: >> >> Well, that is going to be a fun one to debug ... In my application I >> check for a headless environment with >> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). >> If you call that one before you initialize your application, the >> preferences detection does no longer update. So if you augment your >> PlatformPreferencesChangedTest application with this main method, it >> no longer works. Also, it throws another exception when clicking on >> the fail button. >> >> |??? public static void main(String[] args) { >> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); >> ??????? Application.launch(args); >> ??? }| >> >> On 10/02/2024 18:44, Michael Strau? wrote: >>> Since I can't reproduce the error on macOS, it's hard to say what >>> could be causing it. >>> >>> If you have the chance, maybe you could run the >>> PlatformPreferencesChangedTest application: >>> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >>> >>> That might rule out that the differences we're seeing have anything to >>> do with the way we're using the API. >>> >>> >>> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>>> I checked again, restarted everything, but still the same problem: >>>> >>>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Feb 12 16:49:36 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2024 08:49:36 -0800 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <17a3f653-96f0-4dd2-8e7e-af86cd760704@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> Message-ID: There were changes to AWT in JDK 22 for macOS 14, so it might be worth trying JDK 21.0.2. In the mean time, I'll do some testing of this as well now that I know it is related to initializing the AWT toolkit. -- Kevin On 2/12/2024 8:36 AM, Christopher Schnick wrote: > > I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. > I guess I can try upgrading to JDK 21.0.2, but I will just assume that > there haven't been many changes to awt in that time. > > Interestingly, I found another issue that occurs when that call to > |GraphicsEnvironment| is made/not made where it is not possible to > quit a JavaFX application via the dock quit operation when it is > minimized to an AWT tray icon. I can file a separate issue for that. > > On 12/02/2024 17:20, Kevin Rushforth wrote: >> That likely means that initializing the AWT toolkit is interfering >> with this functionality. >> >> I presume you are using a very recent ea build of JavaFX 22. What >> version of JDK are you using? >> >> -- Kevin >> >> >> On 2/10/2024 9:05 PM, Christopher Schnick wrote: >>> >>> Well, that is going to be a fun one to debug ... In my application I >>> check for a headless environment with >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). >>> If you call that one before you initialize your application, the >>> preferences detection does no longer update. So if you augment your >>> PlatformPreferencesChangedTest application with this main method, it >>> no longer works. Also, it throws another exception when clicking on >>> the fail button. >>> >>> |??? public static void main(String[] args) { >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); >>> ??????? Application.launch(args); >>> ??? }| >>> >>> On 10/02/2024 18:44, Michael Strau? wrote: >>>> Since I can't reproduce the error on macOS, it's hard to say what >>>> could be causing it. >>>> >>>> If you have the chance, maybe you could run the >>>> PlatformPreferencesChangedTest application: >>>> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >>>> >>>> That might rule out that the differences we're seeing have anything to >>>> do with the way we're using the API. >>>> >>>> >>>> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>>>> I checked again, restarted everything, but still the same problem: >>>>> >>>>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Mon Feb 12 17:00:55 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Mon, 12 Feb 2024 18:00:55 +0100 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> Message-ID: <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> Just tested with JDK 21.0.2 and the behavior is unchanged. I don't have an older macOS version <14 to test whether this issue is actually specific to 14 or not. On 12/02/2024 17:49, Kevin Rushforth wrote: > There were changes to AWT in JDK 22 for macOS 14, so it might be worth > trying JDK 21.0.2. In the mean time, I'll do some testing of this as > well now that I know it is related to initializing the AWT toolkit. > > -- Kevin > > > On 2/12/2024 8:36 AM, Christopher Schnick wrote: >> >> I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. >> I guess I can try upgrading to JDK 21.0.2, but I will just assume >> that there haven't been many changes to awt in that time. >> >> Interestingly, I found another issue that occurs when that call to >> |GraphicsEnvironment| is made/not made where it is not possible to >> quit a JavaFX application via the dock quit operation when it is >> minimized to an AWT tray icon. I can file a separate issue for that. >> >> On 12/02/2024 17:20, Kevin Rushforth wrote: >>> That likely means that initializing the AWT toolkit is interfering >>> with this functionality. >>> >>> I presume you are using a very recent ea build of JavaFX 22. What >>> version of JDK are you using? >>> >>> -- Kevin >>> >>> >>> On 2/10/2024 9:05 PM, Christopher Schnick wrote: >>>> >>>> Well, that is going to be a fun one to debug ... In my application >>>> I check for a headless environment with >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). >>>> If you call that one before you initialize your application, the >>>> preferences detection does no longer update. So if you augment your >>>> PlatformPreferencesChangedTest application with this main method, >>>> it no longer works. Also, it throws another exception when clicking >>>> on the fail button. >>>> >>>> |??? public static void main(String[] args) { >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); >>>> ??????? Application.launch(args); >>>> ??? }| >>>> >>>> On 10/02/2024 18:44, Michael Strau? wrote: >>>>> Since I can't reproduce the error on macOS, it's hard to say what >>>>> could be causing it. >>>>> >>>>> If you have the chance, maybe you could run the >>>>> PlatformPreferencesChangedTest application: >>>>> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >>>>> >>>>> That might rule out that the differences we're seeing have anything to >>>>> do with the way we're using the API. >>>>> >>>>> >>>>> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>>>>> I checked again, restarted everything, but still the same problem: >>>>>> >>>>>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Feb 12 17:20:03 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2024 09:20:03 -0800 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> Message-ID: <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> I can reproduce this on macOS 13.x using JDK 21.0.2 and the latest JavaFX. If I run the PlatformPreferencesChangedTest program in tests/manual/events we correctly detect the appearance changes. If I first initialize the AWT toollkit as follows, then it doesn't detect the changes: ??? public static void main(String[] args) { ??????? java.awt.Toolkit.getDefaultToolkit(); ??????? PlatformPreferencesChangedTest.main(args); ??? } I'll file a bug...not sure yet whether it is AWT or JavaFX. -- Kevin On 2/12/2024 9:00 AM, Christopher Schnick wrote: > > Just tested with JDK 21.0.2 and the behavior is unchanged. I don't > have an older macOS version <14 to test whether this issue is actually > specific to 14 or not. > > On 12/02/2024 17:49, Kevin Rushforth wrote: >> There were changes to AWT in JDK 22 for macOS 14, so it might be >> worth trying JDK 21.0.2. In the mean time, I'll do some testing of >> this as well now that I know it is related to initializing the AWT >> toolkit. >> >> -- Kevin >> >> >> On 2/12/2024 8:36 AM, Christopher Schnick wrote: >>> >>> I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on >>> macOS. I guess I can try upgrading to JDK 21.0.2, but I will just >>> assume that there haven't been many changes to awt in that time. >>> >>> Interestingly, I found another issue that occurs when that call to >>> |GraphicsEnvironment| is made/not made where it is not possible to >>> quit a JavaFX application via the dock quit operation when it is >>> minimized to an AWT tray icon. I can file a separate issue for that. >>> >>> On 12/02/2024 17:20, Kevin Rushforth wrote: >>>> That likely means that initializing the AWT toolkit is interfering >>>> with this functionality. >>>> >>>> I presume you are using a very recent ea build of JavaFX 22. What >>>> version of JDK are you using? >>>> >>>> -- Kevin >>>> >>>> >>>> On 2/10/2024 9:05 PM, Christopher Schnick wrote: >>>>> >>>>> Well, that is going to be a fun one to debug ... In my application >>>>> I check for a headless environment with >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). >>>>> If you call that one before you initialize your application, the >>>>> preferences detection does no longer update. So if you augment >>>>> your PlatformPreferencesChangedTest application with this main >>>>> method, it no longer works. Also, it throws another exception when >>>>> clicking on the fail button. >>>>> >>>>> |??? public static void main(String[] args) { >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); >>>>> ??????? Application.launch(args); >>>>> ??? }| >>>>> >>>>> On 10/02/2024 18:44, Michael Strau? wrote: >>>>>> Since I can't reproduce the error on macOS, it's hard to say what >>>>>> could be causing it. >>>>>> >>>>>> If you have the chance, maybe you could run the >>>>>> PlatformPreferencesChangedTest application: >>>>>> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >>>>>> >>>>>> That might rule out that the differences we're seeing have anything to >>>>>> do with the way we're using the API. >>>>>> >>>>>> >>>>>> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>>>>>> I checked again, restarted everything, but still the same problem: >>>>>>> >>>>>>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Feb 12 17:26:40 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2024 09:26:40 -0800 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> Message-ID: Actually, it's worse than not detecting changes, it's simply not getting the right values at all. If I run the program when the system appearance is already in Dark mode, it doesn't get the correct values at start up. -- Kevin On 2/12/2024 9:20 AM, Kevin Rushforth wrote: > I can reproduce this on macOS 13.x using JDK 21.0.2 and the latest > JavaFX. If I run the PlatformPreferencesChangedTest program in > tests/manual/events we correctly detect the appearance changes. If I > first initialize the AWT toollkit as follows, then it doesn't detect > the changes: > > ??? public static void main(String[] args) { > ??????? java.awt.Toolkit.getDefaultToolkit(); > ??????? PlatformPreferencesChangedTest.main(args); > ??? } > > I'll file a bug...not sure yet whether it is AWT or JavaFX. > > -- Kevin > > On 2/12/2024 9:00 AM, Christopher Schnick wrote: >> >> Just tested with JDK 21.0.2 and the behavior is unchanged. I don't >> have an older macOS version <14 to test whether this issue is >> actually specific to 14 or not. >> >> On 12/02/2024 17:49, Kevin Rushforth wrote: >>> There were changes to AWT in JDK 22 for macOS 14, so it might be >>> worth trying JDK 21.0.2. In the mean time, I'll do some testing of >>> this as well now that I know it is related to initializing the AWT >>> toolkit. >>> >>> -- Kevin >>> >>> >>> On 2/12/2024 8:36 AM, Christopher Schnick wrote: >>>> >>>> I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on >>>> macOS. I guess I can try upgrading to JDK 21.0.2, but I will just >>>> assume that there haven't been many changes to awt in that time. >>>> >>>> Interestingly, I found another issue that occurs when that call to >>>> |GraphicsEnvironment| is made/not made where it is not possible to >>>> quit a JavaFX application via the dock quit operation when it is >>>> minimized to an AWT tray icon. I can file a separate issue for that. >>>> >>>> On 12/02/2024 17:20, Kevin Rushforth wrote: >>>>> That likely means that initializing the AWT toolkit is interfering >>>>> with this functionality. >>>>> >>>>> I presume you are using a very recent ea build of JavaFX 22. What >>>>> version of JDK are you using? >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 2/10/2024 9:05 PM, Christopher Schnick wrote: >>>>>> >>>>>> Well, that is going to be a fun one to debug ... In my >>>>>> application I check for a headless environment with >>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). >>>>>> If you call that one before you initialize your application, the >>>>>> preferences detection does no longer update. So if you augment >>>>>> your PlatformPreferencesChangedTest application with this main >>>>>> method, it no longer works. Also, it throws another exception >>>>>> when clicking on the fail button. >>>>>> >>>>>> |??? public static void main(String[] args) { >>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); >>>>>> ??????? Application.launch(args); >>>>>> ??? }| >>>>>> >>>>>> On 10/02/2024 18:44, Michael Strau? wrote: >>>>>>> Since I can't reproduce the error on macOS, it's hard to say what >>>>>>> could be causing it. >>>>>>> >>>>>>> If you have the chance, maybe you could run the >>>>>>> PlatformPreferencesChangedTest application: >>>>>>> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >>>>>>> >>>>>>> That might rule out that the differences we're seeing have anything to >>>>>>> do with the way we're using the API. >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>>>>>>> I checked again, restarted everything, but still the same problem: >>>>>>>> >>>>>>>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Mon Feb 12 17:31:07 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Feb 2024 17:31:07 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v15] In-Reply-To: References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> Message-ID: On Mon, 12 Feb 2024 16:15:03 GMT, Andy Goryachev wrote: > It looks like the original intent was to have one monospaced (Monaco) and one proportional (Tahoma) font. Perhaps we could come up with a list of candidates and pick a font to use based on availability? These would all have to be separate tests, as each font will have different widths. Since the specific font is not really relevant for alignment and wrapping code coverage, only that it is a real font, I think this isn't going to really add much (the code is already fully covered, a different font won't add any new branch coverage). Even a mono spaced font makes no difference for the tests (it would at most be a bit easier to test for). Other tests are free to use different fonts. The linux build environment could have Arial installed (it is freely available), Mac apparently has some slight differences with complex chars in Arial -- I don't know why that happens, but it doesn't really affect the tests. I can split the tests for those in two parts with different assumptions for platform. Anyway, IMHO, all that matters is that the test runs in the nightly, and that regressions can be spotted, no matter what platform. If there are any Mac/Linux/Windows specific issues reported (that are not related to the specific font), we can add more regression tests for those then. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1939200760 From kevin.rushforth at oracle.com Mon Feb 12 17:53:56 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Feb 2024 09:53:56 -0800 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> Message-ID: <73397738-e78a-4c36-9e77-4d9a44215198@oracle.com> Never mind about not knowing whether it's a JavaFX or an AWT bug. It's either a JavaFX bug or an inherent limitation. The problem you are running into is that when the AWT toolkit is initialized before the JavaFX toolkit, then necessarily, AWT is in charge of the NSApplication. Prior to the macOS 14 fixes I was mentioning, AWT used to take change even when it shouldn't have, but now that's been fixed (both in AWT and JavaFX). Whichever toolkit is started first owns the NSApplication, and installs its NSApplicationDelegate. This means that NSApplication{Delegate} callbacks are only delivered to the toolkit that owns it. I haven't checked this, but my guess is that the "NSDistributedNotificationCenter" methods being used to listen to preferences don't get called when JavaFX is not the NSApplication owner. -- Kevin On 2/12/2024 9:26 AM, Kevin Rushforth wrote: > Actually, it's worse than not detecting changes, it's simply not > getting the right values at all. If I run the program when the system > appearance is already in Dark mode, it doesn't get the correct values > at start up. > > -- Kevin > > On 2/12/2024 9:20 AM, Kevin Rushforth wrote: >> I can reproduce this on macOS 13.x using JDK 21.0.2 and the latest >> JavaFX. If I run the PlatformPreferencesChangedTest program in >> tests/manual/events we correctly detect the appearance changes. If I >> first initialize the AWT toollkit as follows, then it doesn't detect >> the changes: >> >> ??? public static void main(String[] args) { >> ??????? java.awt.Toolkit.getDefaultToolkit(); >> ??????? PlatformPreferencesChangedTest.main(args); >> ??? } >> >> I'll file a bug...not sure yet whether it is AWT or JavaFX. >> >> -- Kevin >> >> On 2/12/2024 9:00 AM, Christopher Schnick wrote: >>> >>> Just tested with JDK 21.0.2 and the behavior is unchanged. I don't >>> have an older macOS version <14 to test whether this issue is >>> actually specific to 14 or not. >>> >>> On 12/02/2024 17:49, Kevin Rushforth wrote: >>>> There were changes to AWT in JDK 22 for macOS 14, so it might be >>>> worth trying JDK 21.0.2. In the mean time, I'll do some testing of >>>> this as well now that I know it is related to initializing the AWT >>>> toolkit. >>>> >>>> -- Kevin >>>> >>>> >>>> On 2/12/2024 8:36 AM, Christopher Schnick wrote: >>>>> >>>>> I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on >>>>> macOS. I guess I can try upgrading to JDK 21.0.2, but I will just >>>>> assume that there haven't been many changes to awt in that time. >>>>> >>>>> Interestingly, I found another issue that occurs when that call to >>>>> |GraphicsEnvironment| is made/not made where it is not possible to >>>>> quit a JavaFX application via the dock quit operation when it is >>>>> minimized to an AWT tray icon. I can file a separate issue for that. >>>>> >>>>> On 12/02/2024 17:20, Kevin Rushforth wrote: >>>>>> That likely means that initializing the AWT toolkit is >>>>>> interfering with this functionality. >>>>>> >>>>>> I presume you are using a very recent ea build of JavaFX 22. What >>>>>> version of JDK are you using? >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 2/10/2024 9:05 PM, Christopher Schnick wrote: >>>>>>> >>>>>>> Well, that is going to be a fun one to debug ... In my >>>>>>> application I check for a headless environment with >>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). >>>>>>> If you call that one before you initialize your application, the >>>>>>> preferences detection does no longer update. So if you augment >>>>>>> your PlatformPreferencesChangedTest application with this main >>>>>>> method, it no longer works. Also, it throws another exception >>>>>>> when clicking on the fail button. >>>>>>> >>>>>>> |??? public static void main(String[] args) { >>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); >>>>>>> ??????? Application.launch(args); >>>>>>> ??? }| >>>>>>> >>>>>>> On 10/02/2024 18:44, Michael Strau? wrote: >>>>>>>> Since I can't reproduce the error on macOS, it's hard to say what >>>>>>>> could be causing it. >>>>>>>> >>>>>>>> If you have the chance, maybe you could run the >>>>>>>> PlatformPreferencesChangedTest application: >>>>>>>> https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java >>>>>>>> >>>>>>>> That might rule out that the differences we're seeing have anything to >>>>>>>> do with the way we're using the API. >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Feb 10, 2024 at 6:23?PM Christopher Schnick wrote: >>>>>>>>> I checked again, restarted everything, but still the same problem: >>>>>>>>> >>>>>>>>> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE Plasma. The preferences values there are all detected correctly, but are never updated at runtime when changed in the settings menu. >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Feb 12 19:09:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Feb 2024 19:09:08 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v5] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Sat, 10 Feb 2024 17:53:27 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Use getStyleClassNames lgtm, thank you. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1340#pullrequestreview-1875982886 From angorya at openjdk.org Mon Feb 12 22:22:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Feb 2024 22:22:08 GMT Subject: Integrated: 8307117: TextArea: wrapText property ignored when changing font In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:44:12 GMT, Andy Goryachev wrote: > Requesting content layout when font changes. > > This change makes the visual impact of [JDK-8314683](https://bugs.openjdk.org/browse/JDK-8314683) more visible, so perhaps both bugs should be fixed at the same time. This pull request has now been integrated. Changeset: de0255d6 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/de0255d6b6da52a7af367319f883afb08de5182a Stats: 135 lines in 3 files changed: 117 ins; 6 del; 12 mod 8307117: TextArea: wrapText property ignored when changing font Reviewed-by: kpk, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1217 From kcr at openjdk.org Tue Feb 13 00:37:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 00:37:04 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5] In-Reply-To: <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> Message-ID: On Mon, 5 Feb 2024 16:46:40 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with two additional commits since the last revision: > > - Work-around for using a call not present in the Xcode 13.3 SDK. > - Need correctly formed NSNotification when running tests I ran a full set of headful tests on macOS 13 and 14. I also ran some local tests and verified the modified code. All looks good. modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 655: > 653: // try again using Java generic icon (this icon might go away eventually ?) > 654: iconPath = [NSString stringWithFormat:@"%s", "/System/Library/Frameworks/JavaVM.framework/Resources/GenericApp.icns"]; > 655: } I presume you removed this because it is obsolete code? I do note that the file in question is no longer there, so this seems fine. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/687#pullrequestreview-1876247827 PR Review Comment: https://git.openjdk.org/jfx/pull/687#discussion_r1486754653 From arapte at openjdk.org Tue Feb 13 12:33:37 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 13 Feb 2024 12:33:37 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time Message-ID: This is accessibility specific fix. **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem **Cause:** The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready **Verification:** - On Windows machine, launch Narrator. Issue is observed only with Narrator - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. ------------- Commit messages: - a11y ListView focused item fix Changes: https://git.openjdk.org/jfx/pull/1363/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1363&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309374 Stats: 31 lines in 1 file changed: 31 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1363.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1363/head:pull/1363 PR: https://git.openjdk.org/jfx/pull/1363 From jhendrikx at openjdk.org Tue Feb 13 13:36:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Feb 2024 13:36:06 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: <3SeWc6uXmgtTSjBLq6wSjd9lpTUOt4pkNIOEfshKaRQ=.86a9f763-12ff-4d6b-b565-ae29390fe25a@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> <-xrX5h4pIZS8H5RfX7vzgdsxLaj0TsS9IF2UUkZft3U=.be5518f3-8647-4834-8ffe-2529953c4c25@github.com> <3SeWc6uXmgtTSjBLq6wSjd9lpTUOt4pkNIOEfshKaRQ=.86a9f763-12ff-4d6b-b565-ae29390fe25a@github.com> Message-ID: On Sat, 10 Feb 2024 15:13:44 GMT, Kevin Rushforth wrote: >>> > need 2 passes, because there already is a method named like that: >>> >>> oh yeah, sorry. `getStyleClassesSet()` ? >> >> That one is still available yes :) > > @hjohn I'm now leaning towards either `getStyleClassNames` or `getClassNames`, but it isn't a strong preference. Why don't you pick one, update the PR, and create a Draft CSR. @kevinrushforth CSR was created ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1941529341 From mfox at openjdk.org Tue Feb 13 16:09:09 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 13 Feb 2024 16:09:09 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5] In-Reply-To: References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> Message-ID: On Mon, 12 Feb 2024 20:48:22 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with two additional commits since the last revision: >> >> - Work-around for using a call not present in the Xcode 13.3 SDK. >> - Need correctly formed NSNotification when running tests > > modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 655: > >> 653: // try again using Java generic icon (this icon might go away eventually ?) >> 654: iconPath = [NSString stringWithFormat:@"%s", "/System/Library/Frameworks/JavaVM.framework/Resources/GenericApp.icns"]; >> 655: } > > I presume you removed this because it is obsolete code? I do note that the file in question is no longer there, so this seems fine. Yes, I think it's obsolete. I haven't seen an icon file in the JavaVM framework since I started working on JavaFX years ago. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/687#discussion_r1488159498 From jbhaskar at openjdk.org Tue Feb 13 17:06:31 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 13 Feb 2024 17:06:31 GMT Subject: RFR: 8323880: Caret rendered at wrong position in case of a click event on RTL text Message-ID: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> Issue: The current implementation of complex text rendering paths on the Java platform is experiencing side effects. Solution: We need to align with WebKit 616.1 standards. The patch supports two paths simple rendering path and complex rendering path based on text rendering mode. ------------- Commit messages: - 8323880: Caret rendered at wrong position in case of a click event on RTL text Changes: https://git.openjdk.org/jfx/pull/1364/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1364&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323880 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1364.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1364/head:pull/1364 PR: https://git.openjdk.org/jfx/pull/1364 From kcr at openjdk.org Tue Feb 13 18:14:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 18:14:06 GMT Subject: RFR: 8323880: Caret rendered at wrong position in case of a click event on RTL text In-Reply-To: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> References: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> Message-ID: On Tue, 13 Feb 2024 16:57:37 GMT, Jay Bhaskar wrote: > Issue: The current implementation of complex text rendering paths on the Java platform is experiencing side effects. > Solution: We need to align with WebKit 616.1 standards. The patch supports two paths simple rendering path and complex rendering path based on text rendering mode. Reviewers: @kevinrushforth @HimaBinduMeda ------------- PR Comment: https://git.openjdk.org/jfx/pull/1364#issuecomment-1942127715 From kcr at openjdk.org Tue Feb 13 18:16:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 18:16:09 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time In-Reply-To: References: Message-ID: <6hMjIDh78Zl8AAyp3X4SBM3V5RpRAjPTtfh1V25JULQ=.b52f362c-05f9-4e13-a8e2-62323db84a4a@github.com> On Tue, 13 Feb 2024 12:29:49 GMT, Ambarish Rapte wrote: > This is accessibility specific fix. > > **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem > > **Cause:** > The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) > If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. > > **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready > > **Verification:** > - On Windows machine, launch Narrator. Issue is observed only with Narrator > - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) > Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. > Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. Reviewers: @kevinrushforth @azuev-java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1363#issuecomment-1942130364 From michaelstrau2 at gmail.com Tue Feb 13 19:11:39 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 13 Feb 2024 20:11:39 +0100 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <103f7f78-8d86-49a7-b0a4-3fa66f1e5f15@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> Message-ID: The reason why the values are wrong might be that in PlatformSupport.m L105, we query [NSApp effectiveApperance], but this always seems to return the light appearance if JavaFX doesn't own the NSApplication. On Mon, Feb 12, 2024 at 6:26?PM Kevin Rushforth wrote: > > Actually, it's worse than not detecting changes, it's simply not getting the right values at all. If I run the program when the system appearance is already in Dark mode, it doesn't get the correct values at start up. > > -- Kevin From mhanl at openjdk.org Tue Feb 13 20:46:09 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 13 Feb 2024 20:46:09 GMT Subject: RFR: JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text Message-ID: When a `Spinner` is configured with e.g. Integers (`IntegerSpinnerValueFactory`) and the user types in a `String`, e.g. 'abc' and focuses another `Node`, an exception is thrown (`NumberFormatException`). This exception is literally uncatchable, as it happens on focus lost. The issue is the same as for the `DatePicker` component described in [JDK-8303478](https://bugs.openjdk.org/browse/JDK-8303478), which was fixed in PR: https://github.com/openjdk/jfx/pull/1274. I did the exact same fix in this PR. Also added the same test. ------------- Commit messages: - JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text Changes: https://git.openjdk.org/jfx/pull/1365/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325798 Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1365.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1365/head:pull/1365 PR: https://git.openjdk.org/jfx/pull/1365 From mhanl at openjdk.org Tue Feb 13 20:50:05 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 13 Feb 2024 20:50:05 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v5] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: On Sat, 10 Feb 2024 17:53:27 GMT, John Hendrikx wrote: >> The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. >> >> We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Use getStyleClassNames Looks good and reasonable to me as well. I can also confirm that I have never used both `Selector` classes or seen any use for them. Also +1 for `getStyleClassNames`, feels the most natural to me. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1340#pullrequestreview-1878881707 From kcr at openjdk.org Tue Feb 13 21:18:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 21:18:07 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 12:29:49 GMT, Ambarish Rapte wrote: > This is accessibility specific fix. > > **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem > > **Cause:** > The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) > If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. > > **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready > > **Verification:** > - On Windows machine, launch Narrator. Issue is observed only with Narrator > - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) > Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. > Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. The fix looks good to me, and my initial testing shows that it works as expected. I left a few suggestions on minor wording changes inline. I'll reapprove if you make the changes. modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 351: > 349: > 350: /* > 351: * The layoutChildren() method is overloaded to address a specific accessibility issue: JBS-8309374 Minor typos: "overloaded" --> "overridden"; "JBS" --> "JDK" modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 366: > 364: if (listView != null) { > 365: /* > 366: * The notifyAccessibleAttributeChanged() call is submitted on the Application thread, because: This method is already being run on the application thread. Suggestion: "is submitted via runLater to defer it until after the layout completes, because:" modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 371: > 369: * notification from here. > 370: * We observed that this scenario occurs when client application is trying to get the > 371: * UIA_HasKeyboardFocusPropertyId property of a focused ListItem's parent(ListView). I might replace `UIA_HasKeyboardFocusPropertyId`, which is Windows-specific, with something more generic like "the focus item". modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 372: > 370: * We observed that this scenario occurs when client application is trying to get the > 371: * UIA_HasKeyboardFocusPropertyId property of a focused ListItem's parent(ListView). > 372: * This scenario is avoided by submitting the call notifyAccessibleAttributeChanged() on Application thread, Similar comment to the earlier one about the thread. I suggest something like: "This scenario is avoided by submitting the call via runLater," ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1363#pullrequestreview-1878722288 PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1488437475 PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1488442179 PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1488445070 PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1488447524 From kcr at openjdk.org Tue Feb 13 21:19:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 21:19:07 GMT Subject: RFR: 8323880: Caret rendered at wrong position in case of a click event on RTL text In-Reply-To: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> References: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> Message-ID: On Tue, 13 Feb 2024 16:57:37 GMT, Jay Bhaskar wrote: > Issue: The current implementation of complex text rendering paths on the Java platform is experiencing side effects. > Solution: We need to align with WebKit 616.1 standards. The patch supports two paths simple rendering path and complex rendering path based on text rendering mode. Looks good. Tested on macOS. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1364#pullrequestreview-1878933440 From angorya at openjdk.org Tue Feb 13 21:43:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Feb 2024 21:43:03 GMT Subject: RFR: JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 20:42:08 GMT, Marius Hanl wrote: > When a `Spinner` is configured with e.g. Integers (`IntegerSpinnerValueFactory`) and the user types in a `String`, e.g. 'abc' and focuses another `Node`, an exception is thrown (`NumberFormatException`). > This exception is literally uncatchable, as it happens on focus lost. > > The issue is the same as for the `DatePicker` component described in [JDK-8303478](https://bugs.openjdk.org/browse/JDK-8303478), which was fixed in PR: https://github.com/openjdk/jfx/pull/1274. > > I did the exact same fix in this PR. Also added the same test. looks good. thank you for referring to the other bug! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1365#pullrequestreview-1878983533 From mstrauss at openjdk.org Tue Feb 13 22:48:03 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 13 Feb 2024 22:48:03 GMT Subject: RFR: JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 20:42:08 GMT, Marius Hanl wrote: > When a `Spinner` is configured with e.g. Integers (`IntegerSpinnerValueFactory`) and the user types in a `String`, e.g. 'abc' and focuses another `Node`, an exception is thrown (`NumberFormatException`). > This exception is literally uncatchable, as it happens on focus lost. > > The issue is the same as for the `DatePicker` component described in [JDK-8303478](https://bugs.openjdk.org/browse/JDK-8303478), which was fixed in PR: https://github.com/openjdk/jfx/pull/1274. > > I did the exact same fix in this PR. Also added the same test. LGTM modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1588: > 1586: > 1587: /** > 1588: * When Spinner looses focus with misformatted text in the editor, typo: loses modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1609: > 1607: spinner.getEditor().setText("2abc"); > 1608: > 1609: // loosing focus triggers cancelEdit() because the text cannot be parsed typo: losing ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1365#pullrequestreview-1879077791 PR Review Comment: https://git.openjdk.org/jfx/pull/1365#discussion_r1488678419 PR Review Comment: https://git.openjdk.org/jfx/pull/1365#discussion_r1488678809 From arapte at openjdk.org Wed Feb 14 02:55:15 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 14 Feb 2024 02:55:15 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: References: Message-ID: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> > This is accessibility specific fix. > > **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem > > **Cause:** > The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) > If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. > > **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready > > **Verification:** > - On Windows machine, launch Narrator. Issue is observed only with Narrator > - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) > Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. > Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review corrections-1 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1363/files - new: https://git.openjdk.org/jfx/pull/1363/files/438f7946..938c6be6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1363&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1363&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1363.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1363/head:pull/1363 PR: https://git.openjdk.org/jfx/pull/1363 From arapte at openjdk.org Wed Feb 14 02:58:01 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 14 Feb 2024 02:58:01 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 21:15:16 GMT, Kevin Rushforth wrote: > The fix looks good to me, and my initial testing shows that it works as expected. I left a few suggestions on minor wording changes inline. I'll reapprove if you make the changes. Thank you Kevin, Please have a re-look, I made the changes as per the comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1363#issuecomment-1943009421 From jhendrikx at openjdk.org Wed Feb 14 05:32:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 14 Feb 2024 05:32:08 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 07:59:47 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I think we should simplify the `getHitInfo` method in the `TextLayout` interface. The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 213: > 211: * @param textRunStart Start position of first Text run where hit info is requested. > 212: * @param curRunStart Start position of text run where hit info is requested. > 213: * @param forTextFlow Indicates if the hit info is requested for TextFlow or Text node. {@code true} for TextFlow and {@code false} for Text node. I have the impression that we're overcomplicating things here. There is a flag (`forTextFlow`) for Text/TextFlow, and a String (`text`) for Text/TextFlow, and there are already `setContent` methods for Text/TextFlow. I don't see a need for any of these changes to `getHitInfo` at all. If the content was set with `setContent(TextSpan[] spans)`, then we know it is a TextFlow (actually we don't care, we have spans which is the difference we're interested in). This fact can be checked at any time with: boolean isThisForTextFlow = this.spans != null; See how the `setContent` methods work; they either set `spans` or they don't. The rest of the code is already full of alternate paths with `if (spans == null) { /* do Text stuff */ } else { /* do TextFlow stuff */ }` The `text` parameter is also already known, because this is explicitely set for `Text` nodes because they use `setContent(String text, Object font)`. However, before using it (specifically for `Text`), make sure that check `spans == null` as it is filled for `TextFlow` as well at a later point. So, I think: - the `text` parameter should never have been added (it wasn't until recently) - `forTextFlow` flag is unnecessary, just check `spans != null`. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 424: > 422: > 423: @Override > 424: public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart, boolean forTextFlow) { This method has become huge, with I think upto 7 levels of nesting. It would benefit from some splitting. Suggestions in that area: - Split it in one that handles RTL and one for LTR **or** - Split it in one that handles `spans != null` (`TextFlow`) and one that handles `Text` You can also reduce the nesting of the first `if/else` by returning early: if (lineIndex >= getLineCount()) { charIndex = getCharCount(); insertionIndex = charIndex + 1; return new Hit(charIndex, insertionIndex, leading); // return early here } else { // no need to nest 150+ lines of code More suggestions inline below modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 432: > 430: int ltrIndex = 0; > 431: int textWidthPrevLine = 0; > 432: float xHitPos = x; This variable seems important, yet is only used in the RTL+Text branches. It seems that this variable can also be easily calculated as: originalX - (getMirroringWidth() - x) + bounds.getMinX This calculation can be done in the final RTL+Text branch near the end, no need to precalculate it IMHO modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 438: > 436: if (lineIndex >= getLineCount()) { > 437: charIndex = getCharCount(); > 438: insertionIndex = charIndex + 1; By returning early here, you can avoid the `else` and save a lot of nesting. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 440: > 438: insertionIndex = charIndex + 1; > 439: } else { > 440: if (isMirrored && (forTextFlow || spans == null)) { The extra condition here adds nothing of value, the original `if` was correct. Because `spans == null` means "for Text", and `forTextFlow == true` means "for TextFlow". Since it always is either a `TextFlow` or a `Text` the `||` always evaluates to `true` -- unless of course you pass in this flag incorrectly (again, I think the flag should be removed). modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 448: > 446: TextRun run = null; > 447: //TODO binary search > 448: if (text == null || spans == null) { `text` now refers to the `text` parameter here, and not to the original `text` field -- as discussed earlier, I think you shouldn't be passing in `text` as argument at all. Furthermore, I think the original code was also flawed; `text` is only `null` for a short while, and it is never `null` when `spans == null`. In other words, this `if` should IMHO be: Suggestion: if (spans == null) { // not a TextFlow, must be Text Use `getText()` function to get the value of the text (it will just use the one from `Text` set via `setContent(String text, Object font)` or it will calculate it for `TextFlow` from the spans set via `setContent(TextSpan[] spans)`; modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 468: > 466: for (int i = 0; i < runIndex; i++) { > 467: xHitPos -= runs[i].getWidth(); > 468: } This code modifies the `x` parameter that was passed in as an argument, making it harder than necessary to reason about it (I have to talk about "original x" etc), however, I think this loop, and `runIndex` is not necessary, because `xHitPos` can just be calculated directly (see comment on `xHitPos`). modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 567: > 565: int[] trailing = new int[1]; > 566: if (text != null && spans != null) { > 567: charIndex = run.getOffsetAtX(x, trailing); Here also: `text` is no longer referring to the field `text` but to the argument `text`. I also again think the check is wrong. It should just be: if (spans != null) { // must be a TextFlow There are more oddities in the code below (which you didn't change this round -- see my comments inline: // !! getText() ***never*** returns `null`, the check is not needed if (getText() != null && insertionIndex < getText().length) { if (!leading) { BreakIterator charIterator = BreakIterator.getCharacterInstance(); // before, when `text` was a field, this could never be null here if (text != null) { charIterator.setText(text); } else { charIterator.setText(new String(getText())); } int next = charIterator.following(insertionIndex); if (next == BreakIterator.DONE) { insertionIndex += 1; } else { insertionIndex = next; } } } else if (!leading) { insertionIndex += 1; } modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 576: > 574: int indexOffset; > 575: if (isMirrored) { > 576: indexOffset = run.getOffsetAtX(xHitPos, trailing); Here is the only place where `xHitPos` is used again (the RTL + Text case). I think it can just be calculated (you need to save off the original `x` value, or even better, don't modify the `x` argument but use a different variable for the `x` calculation). modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1035: > 1033: curRunStart = ((TextRun) runs[runIndex]).getStart(); > 1034: } > 1035: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, getText(), textRunStart, curRunStart, false); I think `getText()` as a parameter is not needed here (it is passed at line 260 when it calls `setContent`). Also, I think this should be `getTextInternal()` -- see the comment in that method. I also think the `false` is not needed, see comments on the interface. modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1050: > 1048: > 1049: private int findRunIndex(double x, double y, GlyphList[] runs) { > 1050: int ix = 0; The naming leaves something to be desired. `ix` is the run index is it not? Maybe leave it as `runIndex` ? modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1061: > 1059: while (ix < lastIndex) { > 1060: GlyphList r = runs[ix]; > 1061: GlyphList nr = runs[ix + 1]; Suggestion: GlyphList run = runs[ix]; GlyphList nextRun = runs[ix + 1]; modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1075: > 1073: double ptY = ptInParent.getY(); > 1074: while (ix < lastIndex) { > 1075: GlyphList r = runs[ix]; Suggestion: GlyphList run = runs[ix]; modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202: > 200: double x = point.getX(); > 201: double y = point.getY(); > 202: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, null, 0, 0, true); The `null` and `true` here are not needed IMHO (what would even happen when they conflict, `null` + `false`, or non-`null` + `true`?) tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 107: > 105: */ > 106: > 107: public class RTLTextCharacterIndexTest { This is a system test, which don't run with the build system. Are you sure this will work on all platforms? I don't see a specific `Font` used, which means `X_LEADING_OFFSET` may be incorrect when the platform is supplying a different font. tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 121: > 119: > 120: final int Y_OFFSET = 30; > 121: final int X_LEADING_OFFSET = 10; If they're constant, they should also be `static`, otherwise may want to write them with lower case. ------------- Changes requested by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1879325091 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488868375 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488870805 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488873469 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488871928 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488878650 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488876272 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488858423 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488882538 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488881462 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488888035 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488889561 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488889939 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488890087 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488891380 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488892493 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1488894397 From kcr at openjdk.org Wed Feb 14 12:48:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Feb 2024 12:48:04 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> References: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> Message-ID: On Wed, 14 Feb 2024 02:55:15 GMT, Ambarish Rapte wrote: >> This is accessibility specific fix. >> >> **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem >> >> **Cause:** >> The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) >> If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. >> >> **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready >> >> **Verification:** >> - On Windows machine, launch Narrator. Issue is observed only with Narrator >> - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) >> Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. >> Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review corrections-1 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1363#pullrequestreview-1880186266 From kcr at openjdk.org Wed Feb 14 13:00:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Feb 2024 13:00:06 GMT Subject: RFR: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes [v2] In-Reply-To: References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> <01g9gkpoIqKHs7urntiyN4rwwhtU4yjYPcnX-ZC_xoE=.e99349a5-870d-493a-abdc-d7bae7914871@github.com> <17Dp-rOk7_p9nzTAjeeckuPqko2ua2yBxD7iksGWpaQ=.748108fe-3546-424e-a51d-fc404687f12d@github.com> <87vU-uFjI95MeDoFX7ZPYAfcrt8mqMp2f4OYW-Gi5Ac=.4cf400f2-48e3-4268-8c86-4b8a184e9575@github.com> <-xrX5h4pIZS8H5RfX7vzgdsxLaj0TsS9IF2UUkZft3U=.be5518f3-8647-4834-8ffe-2529953c4c25@github.com> <3SeWc6uXmgtTSjBLq6wSjd9lpTUOt4pkNIOEfshKaRQ=.86a9f763-12ff-4d6b-b565-ae29390fe25a@github.com> Message-ID: On Tue, 13 Feb 2024 13:33:36 GMT, John Hendrikx wrote: > CSR was created I reviewed the CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1340#issuecomment-1943718956 From kcr at openjdk.org Wed Feb 14 15:25:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Feb 2024 15:25:38 GMT Subject: RFR: 8325873: Update JDK_DOCS property to point to JDK 21 docs Message-ID: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> Simple fix to update the pointer to the JDK docs to JDK 21 (matching the current boot JDK). The only impact of this change is that hyperlinks in the generated API docs will link to the online JDK 21 docs. As this is a docs-only change, I intend to backport this to the jfx22 stabilization branch during RDP2. ------------- Commit messages: - 8325873: Update JDK_DOCS property to point to JDK 21 docs Changes: https://git.openjdk.org/jfx/pull/1366/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1366&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325873 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1366.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1366/head:pull/1366 PR: https://git.openjdk.org/jfx/pull/1366 From kcr at openjdk.org Wed Feb 14 15:25:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Feb 2024 15:25:38 GMT Subject: RFR: 8325873: Update JDK_DOCS property to point to JDK 21 docs In-Reply-To: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> References: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> Message-ID: On Wed, 14 Feb 2024 15:19:47 GMT, Kevin Rushforth wrote: > Simple fix to update the pointer to the JDK docs to JDK 21 (matching the current boot JDK). The only impact of this change is that hyperlinks in the generated API docs will link to the online JDK 21 docs. As this is a docs-only change, I intend to backport this to the jfx22 stabilization branch during RDP2. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1366#issuecomment-1944048236 From crschnick at xpipe.io Wed Feb 14 15:33:43 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Wed, 14 Feb 2024 16:33:43 +0100 Subject: Attachment size limits for the mailing list Message-ID: <6bb84d0c-14e5-472e-a51c-0130feab46f2@xpipe.io> Hello, over the last few days I ran into the attachment size limit of this mailing list several times, causing the mails to be suspended until they are approved. There is also I think another mail still in the moderation queue. I think it would be a good idea to increase the size limit to allow for screenshots to be sent, especially since JavaFX is graphical and will involve screenshots more than the average JDK mailing list. Of course you can also just link to a third-party site where you uploaded the image, but that is also not an ideal solution. I think being able to send at least a 1920x1080 screenshot would be a good start. That would also make the life of the moderators easier. Best Christopher Schnick From rlichten at openjdk.org Wed Feb 14 15:36:08 2024 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Wed, 14 Feb 2024 15:36:08 GMT Subject: Integrated: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:36 GMT, Robert Lichtenberger wrote: > The PR simply moves column and view-updates outside the loop. Since the column or view never changes within the for-loop it is not necessary to call these again and again. This pull request has now been integrated. Changeset: e2f42c5b Author: Robert Lichtenberger Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/e2f42c5b71ef061c614540508fbac3fb610b1ae3 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod 8325154: resizeColumnToFitContent is slower than it needs to be Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1358 From andy.goryachev at oracle.com Wed Feb 14 15:38:51 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 14 Feb 2024 15:38:51 +0000 Subject: Attachment size limits for the mailing list In-Reply-To: <6bb84d0c-14e5-472e-a51c-0130feab46f2@xpipe.io> References: <6bb84d0c-14e5-472e-a51c-0130feab46f2@xpipe.io> Message-ID: +1 PNG Screenshots on macOS retina might easily be 3MB or more. -andy From: openjfx-dev on behalf of Christopher Schnick Date: Wednesday, February 14, 2024 at 07:33 To: openjfx-dev at openjdk.org Subject: Attachment size limits for the mailing list Hello, over the last few days I ran into the attachment size limit of this mailing list several times, causing the mails to be suspended until they are approved. There is also I think another mail still in the moderation queue. I think it would be a good idea to increase the size limit to allow for screenshots to be sent, especially since JavaFX is graphical and will involve screenshots more than the average JDK mailing list. Of course you can also just link to a third-party site where you uploaded the image, but that is also not an ideal solution. I think being able to send at least a 1920x1080 screenshot would be a good start. That would also make the life of the moderators easier. Best Christopher Schnick -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Tue Feb 13 10:13:48 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Tue, 13 Feb 2024 11:13:48 +0100 Subject: UI scaling issues when physical and logical screen resolutions differ on Linux Message-ID: Hello, several users of our JavaFX applications have reported that the UI scale is too small when the physical and logical screen resolutions differ on Linux. For example in this case there is an implicit scaling factor of 150% included as the monitor is a 4k display but is using a lowered resolution of 2560x1440. This is then further stretched as the OS resolution is 1920x1080, but the main problem is that the 150% factor is somehow not getting picked up and JavaFX is treating this as a 4k display, thus making everything too small. For now these users can use -Dglass.gtk.uiScale=1.5 but that is not a nice solution to this problem. Best Christopher Schnick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20240125_115224(1).png Type: image/png Size: 194993 bytes Desc: not available URL: From kevin.rushforth at oracle.com Wed Feb 14 15:44:33 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2024 07:44:33 -0800 Subject: Attachment size limits for the mailing list In-Reply-To: References: <6bb84d0c-14e5-472e-a51c-0130feab46f2@xpipe.io> Message-ID: I was pleasantly surprised to see that this setting is configurable on a per-mailing-list basis. I just now bumped the limit to 4 Mbytes (for openjfx-dev only). -- Kevin On 2/14/2024 7:38 AM, Andy Goryachev wrote: > > +1 > > PNG Screenshots on macOS retina might easily be 3MB or more. > > -andy > > *From: *openjfx-dev on behalf of > Christopher Schnick > *Date: *Wednesday, February 14, 2024 at 07:33 > *To: *openjfx-dev at openjdk.org > *Subject: *Attachment size limits for the mailing list > > Hello, > > over the last few days I ran into the attachment size limit of this > mailing list several times, causing the mails to be suspended until they > are approved. There is also I think another mail still in the moderation > queue. > > I think it would be a good idea to increase the size limit to allow for > screenshots to be sent, especially since JavaFX is graphical and will > involve screenshots more than the average JDK mailing list. Of course > you can also just link to a third-party site where you uploaded the > image, but that is also not an ideal solution. I think being able to > send at least a 1920x1080 screenshot would be a good start. That would > also make the life of the moderators easier. > > Best > Christopher Schnick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Feb 14 15:51:35 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 14 Feb 2024 15:51:35 +0000 Subject: Attachment size limits for the mailing list In-Reply-To: References: <6bb84d0c-14e5-472e-a51c-0130feab46f2@xpipe.io> Message-ID: Thank you, Kevin! -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, February 14, 2024 at 07:45 To: openjfx-dev at openjdk.org Subject: Re: Attachment size limits for the mailing list I was pleasantly surprised to see that this setting is configurable on a per-mailing-list basis. I just now bumped the limit to 4 Mbytes (for openjfx-dev only). -- Kevin On 2/14/2024 7:38 AM, Andy Goryachev wrote: +1 PNG Screenshots on macOS retina might easily be 3MB or more. -andy From: openjfx-dev on behalf of Christopher Schnick Date: Wednesday, February 14, 2024 at 07:33 To: openjfx-dev at openjdk.org Subject: Attachment size limits for the mailing list Hello, over the last few days I ran into the attachment size limit of this mailing list several times, causing the mails to be suspended until they are approved. There is also I think another mail still in the moderation queue. I think it would be a good idea to increase the size limit to allow for screenshots to be sent, especially since JavaFX is graphical and will involve screenshots more than the average JDK mailing list. Of course you can also just link to a third-party site where you uploaded the image, but that is also not an ideal solution. I think being able to send at least a 1920x1080 screenshot would be a good start. That would also make the life of the moderators easier. Best Christopher Schnick -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Wed Feb 14 16:34:03 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 14 Feb 2024 16:34:03 GMT Subject: RFR: 8325873: Update JDK_DOCS property to point to JDK 21 docs In-Reply-To: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> References: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> Message-ID: On Wed, 14 Feb 2024 15:19:47 GMT, Kevin Rushforth wrote: > Simple fix to update the pointer to the JDK docs to JDK 21 (matching the current boot JDK). The only impact of this change is that hyperlinks in the generated API docs will link to the online JDK 21 docs. As this is a docs-only change, I intend to backport this to the jfx22 stabilization branch during RDP2. Verified build on Mac. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1366#pullrequestreview-1880752266 From kevin.rushforth at oracle.com Wed Feb 14 18:54:49 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Feb 2024 10:54:49 -0800 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> Message-ID: <61ed9ba3-9330-4124-91c7-5ea94824aa26@oracle.com> I filed https://bugs.openjdk.org/browse/JDK-8325888 to track this. -- Kevin On 2/13/2024 11:11 AM, Michael Strau? wrote: > The reason why the values are wrong might be that in PlatformSupport.m > L105, we query [NSApp effectiveApperance], but this always seems to > return the light appearance if JavaFX doesn't own the NSApplication. > > On Mon, Feb 12, 2024 at 6:26?PM Kevin Rushforth > wrote: >> Actually, it's worse than not detecting changes, it's simply not getting the right values at all. If I run the program when the system appearance is already in Dark mode, it doesn't get the correct values at start up. >> >> -- Kevin From angorya at openjdk.org Wed Feb 14 19:48:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Feb 2024 19:48:07 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 18:55:54 GMT, Marius Hanl wrote: > `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all other implementations of the cell. > > This also means that the `TreeTableRow` always updates the item, although it should not, resulting in a performance loss as a `TreeTableRow` will always call `updateItem(..)`. > > It looks like that this was forgotten in [JDK-8092593](https://bugs.openjdk.org/browse/JDK-8092593). > > Checking the whole history, it looks like the following was happening: > 1. There was a check if the item is the same in all cell implementations (with `.equals(..)`) > 2. Check was removed as it caused bugs > 3. Check was readded, but instead we first check the index (same index) and then if we also have the same item (this time with `.isItemChanged(..)`, to allow developers to subclass it) > 4. Forgotten for `TreeTableRow` inbetween this chaos. > > Added many tests for the case where an item should be changed and where it should not. > Improved existing tests as well. Using `stageLoader`, as before the tests only created a stage when doing the assert. > > NOTE: The update logic is now the same as for all other 5 cell implementations. Especially `TreeCell` (since it is for a tree structure as well). Tried the path with the TreeTableView page in the MonkeyTester on macOS 14.3, see no ill effects - though the page is somewhat limited to what it can exercise. The SCCE generates the following output: updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem updateItem isItemChanged isItemChanged isItemChanged updateItem isItemChanged isItemChanged isItemChanged updateItem isItemChanged is this expected output? modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 421: > 419: if (oldIndex == newIndex) { > 420: if (!isItemChanged(oldValue, newValue)) { > 421: // RT-37054: we break out of the if/else code here and could we also add (or replace?) the new reference for RT-37054: JDK-8096969 modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 424: > 422: // proceed with the code following this, so that we may > 423: // still update references, listeners, etc as required. > 424: break outer; I understand neither the comment nor this `break outer;`: there is no code that follows `outer: if`, so we might as well `return`, right? modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 1150: > 1148: super.updateItem(item, empty); > 1149: > 1150: counter.incrementAndGet(); very, very minor, and probably not important: shouldn't 'incrementAndGet()` be called before `super.updateItem()`? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 943: > 941: super.updateItem(item, empty); > 942: > 943: counter.incrementAndGet(); same here: move before super.updateItem? modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 961: > 959: * is called when the index is 'changed' to the same number as the old one, to evaluate if we need to call > 960: * updateItem(..). > 961: */ thank you so much for providing clear explanations of what all these tests are trying to accomplish! modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 176: > 174: super.updateItem(item, empty); > 175: > 176: counter.incrementAndGet(); and here. the reason is that if super.updateItem() throws an exception which gets eaten (it shouldn't but we should not be assuming that) we still get the counter incremented. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java line 1078: > 1076: super.updateItem(item, empty); > 1077: > 1078: counter.incrementAndGet(); ... modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 1255: > 1253: super.updateItem(item, empty); > 1254: > 1255: counter.incrementAndGet(); ... modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 960: > 958: super.updateItem(item, empty); > 959: > 960: counter.incrementAndGet(); ... modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 1777: > 1775: } > 1776: > 1777: @Test public void testSetChildrenShouldUpdateTheCells() { we probably should have `@Test` on its own line modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 2639: > 2637: StageLoader sl = new StageLoader(treeTableView); > 2638: > 2639: assertEquals(18, rt_31200_count); magic number... should we explain why exactly 18 ? ------------- PR Review: https://git.openjdk.org/jfx/pull/1360#pullrequestreview-1881075752 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489954389 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489958225 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489961310 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489965524 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489966660 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489968231 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489968818 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489969213 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489969686 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489970617 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1489972931 From mhanl at openjdk.org Wed Feb 14 20:52:02 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 14 Feb 2024 20:52:02 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 19:25:27 GMT, Andy Goryachev wrote: >> `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all other implementations of the cell. >> >> This also means that the `TreeTableRow` always updates the item, although it should not, resulting in a performance loss as a `TreeTableRow` will always call `updateItem(..)`. >> >> It looks like that this was forgotten in [JDK-8092593](https://bugs.openjdk.org/browse/JDK-8092593). >> >> Checking the whole history, it looks like the following was happening: >> 1. There was a check if the item is the same in all cell implementations (with `.equals(..)`) >> 2. Check was removed as it caused bugs >> 3. Check was readded, but instead we first check the index (same index) and then if we also have the same item (this time with `.isItemChanged(..)`, to allow developers to subclass it) >> 4. Forgotten for `TreeTableRow` inbetween this chaos. >> >> Added many tests for the case where an item should be changed and where it should not. >> Improved existing tests as well. Using `stageLoader`, as before the tests only created a stage when doing the assert. >> >> NOTE: The update logic is now the same as for all other 5 cell implementations. Especially `TreeCell` (since it is for a tree structure as well). > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 424: > >> 422: // proceed with the code following this, so that we may >> 423: // still update references, listeners, etc as required. >> 424: break outer; > > I understand neither the comment nor this `break outer;`: there is no code that follows `outer: if`, so we might as well `return`, right? Yes! I did it this way to be consistent with all other cell implementations. I really think that this should be refactored, I can also create a ticket for this. My preference would be to be consistent now, but change it for all cell implementations in one go. What is your opinion? > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 1777: > >> 1775: } >> 1776: >> 1777: @Test public void testSetChildrenShouldUpdateTheCells() { > > we probably should have `@Test` on its own line sure, just copied from above. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490048165 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490049249 From mhanl at openjdk.org Wed Feb 14 21:00:06 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 14 Feb 2024 21:00:06 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 19:21:39 GMT, Andy Goryachev wrote: >> `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all other implementations of the cell. >> >> This also means that the `TreeTableRow` always updates the item, although it should not, resulting in a performance loss as a `TreeTableRow` will always call `updateItem(..)`. >> >> It looks like that this was forgotten in [JDK-8092593](https://bugs.openjdk.org/browse/JDK-8092593). >> >> Checking the whole history, it looks like the following was happening: >> 1. There was a check if the item is the same in all cell implementations (with `.equals(..)`) >> 2. Check was removed as it caused bugs >> 3. Check was readded, but instead we first check the index (same index) and then if we also have the same item (this time with `.isItemChanged(..)`, to allow developers to subclass it) >> 4. Forgotten for `TreeTableRow` inbetween this chaos. >> >> Added many tests for the case where an item should be changed and where it should not. >> Improved existing tests as well. Using `stageLoader`, as before the tests only created a stage when doing the assert. >> >> NOTE: The update logic is now the same as for all other 5 cell implementations. Especially `TreeCell` (since it is for a tree structure as well). > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 421: > >> 419: if (oldIndex == newIndex) { >> 420: if (!isItemChanged(oldValue, newValue)) { >> 421: // RT-37054: we break out of the if/else code here and > > could we also add (or replace?) the new reference for RT-37054: JDK-8096969 same as the other comment, I would prefer to do that for all cell implementations in one go. If that is okay for you as well. :) > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 1150: > >> 1148: super.updateItem(item, empty); >> 1149: >> 1150: counter.incrementAndGet(); > > very, very minor, and probably not important: shouldn't 'incrementAndGet()` be called before `super.updateItem()`? Hm, I see no reason for either one or the other. So not strong preference from my side here. > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 2639: > >> 2637: StageLoader sl = new StageLoader(treeTableView); >> 2638: >> 2639: assertEquals(18, rt_31200_count); > > magic number... should we explain why exactly 18 ? It is the count, how often update item was called. That it got smaller shows, that we call it less often, as the item was not changed (which is a good thing). That also matches with your observation, which is the expected output here. I saw that this was changed for some tests in https://github.com/openjdk/jfx/pull/863, we also can do something similar here as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490054700 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490056222 PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490053457 From angorya at openjdk.org Wed Feb 14 21:00:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Feb 2024 21:00:06 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 20:48:33 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 424: >> >>> 422: // proceed with the code following this, so that we may >>> 423: // still update references, listeners, etc as required. >>> 424: break outer; >> >> I understand neither the comment nor this `break outer;`: there is no code that follows `outer: if`, so we might as well `return`, right? > > Yes! I did it this way to be consistent with all other cell implementations. I really think that this should be refactored, I can also create a ticket for this. My preference would be to be consistent now, but change it for all cell implementations in one go. > What is your opinion? my opinion: the code is not broken per se. Since this block is edited, I would have changed it just in this file to make the logic clearer (in other places, like TreeTableCell:685 it is functional because we have more code in line 692 and on). I don't think another ticket is necessary because, technically speaking, the code is not broken. (just my opinion) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490058786 From angorya at openjdk.org Wed Feb 14 21:05:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Feb 2024 21:05:03 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 20:52:44 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 2639: >> >>> 2637: StageLoader sl = new StageLoader(treeTableView); >>> 2638: >>> 2639: assertEquals(18, rt_31200_count); >> >> magic number... should we explain why exactly 18 ? > > It is the count, how often update item was called. > That it got smaller shows, that we call it less often, as the item was not changed (which is a good thing). > That also matches with your observation, which is the expected output here. > > I saw that this was changed for some tests in https://github.com/openjdk/jfx/pull/863, we also can do something similar here as well. on second thought, this is ok as is - I asked because the code is not testing a specific requirement. The second `assertEquals(18)` might be testing a specific requirement - that the count has not changed, right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490064468 From mstrauss at openjdk.org Wed Feb 14 21:13:10 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Feb 2024 21:13:10 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance Message-ID: Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. The workaround is to set the system property "apple.awt.application.appearance=system". If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem property apple.awt.application.appearance=system is set. This warning can be disabled by setting javafx.preferences.suppressAppleAwtWarning=true. ------------- Commit messages: - Emit a warning on macOS if AWT has set the NSAppearance Changes: https://git.openjdk.org/jfx/pull/1367/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325900 Stats: 53 lines in 4 files changed: 48 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1367.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1367/head:pull/1367 PR: https://git.openjdk.org/jfx/pull/1367 From kcr at openjdk.org Wed Feb 14 22:52:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Feb 2024 22:52:05 GMT Subject: Integrated: 8325873: Update JDK_DOCS property to point to JDK 21 docs In-Reply-To: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> References: <9iYRY49am-7tXMtwYpC4iXW54F_V1JUHOnANvBharSw=.7de8e36c-20d4-4bc4-a8cf-2370025980d5@github.com> Message-ID: On Wed, 14 Feb 2024 15:19:47 GMT, Kevin Rushforth wrote: > Simple fix to update the pointer to the JDK docs to JDK 21 (matching the current boot JDK). The only impact of this change is that hyperlinks in the generated API docs will link to the online JDK 21 docs. As this is a docs-only change, I intend to backport this to the jfx22 stabilization branch during RDP2. This pull request has now been integrated. Changeset: f379eae6 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f379eae65aab963779d7b7335cbade810f8efe82 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8325873: Update JDK_DOCS property to point to JDK 21 docs Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1366 From kcr at openjdk.org Wed Feb 14 22:53:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Feb 2024 22:53:02 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance In-Reply-To: References: Message-ID: <-nFkLfmHNFaucZXn6n740BzF86TDP1nPFSkuErjc7VY=.a9e292f3-6329-46c3-8228-f5ccf3866f4a@github.com> On Wed, 14 Feb 2024 21:09:39 GMT, Michael Strau? wrote: > Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. > > The workaround is to set the system property "apple.awt.application.appearance=system". > > If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: > > > WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem > property apple.awt.application.appearance=system is set. This warning can be disabled by > setting javafx.preferences.suppressAppleAwtWarning=true. I'll take a closer look tomorrow or Friday. This might need to be refactored a bit so we don't call directly into glass from `javafx.application.Platform`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1944900417 From angorya at openjdk.org Wed Feb 14 23:53:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Feb 2024 23:53:13 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves Message-ID: Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8322748.blink - 8322748: Caret blinking in JavaFX should only stop when caret moves Changes: https://git.openjdk.org/jfx/pull/1368/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322748 Stats: 22 lines in 3 files changed: 4 ins; 14 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1368.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1368/head:pull/1368 PR: https://git.openjdk.org/jfx/pull/1368 From angorya at openjdk.org Wed Feb 14 23:53:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Feb 2024 23:53:13 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 22:44:07 GMT, Andy Goryachev wrote: > Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. > > This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) @hjohn would you like to review this change? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1945057755 From kcr at openjdk.org Thu Feb 15 00:36:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Feb 2024 00:36:14 GMT Subject: [jfx22] RFR: 8325873: Update JDK_DOCS property to point to JDK 21 docs Message-ID: Clean backport of a docs-only fix to jfx22. ------------- Commit messages: - Backport f379eae65aab963779d7b7335cbade810f8efe82 Changes: https://git.openjdk.org/jfx/pull/1369/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325873 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1369.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1369/head:pull/1369 PR: https://git.openjdk.org/jfx/pull/1369 From kcr at openjdk.org Thu Feb 15 00:41:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Feb 2024 00:41:05 GMT Subject: [jfx22] RFR: 8325873: Update JDK_DOCS property to point to JDK 21 docs In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 00:31:23 GMT, Kevin Rushforth wrote: > Clean backport of a docs-only fix to jfx22. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1369#issuecomment-1945177161 From arapte at openjdk.org Thu Feb 15 01:41:01 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 15 Feb 2024 01:41:01 GMT Subject: [jfx22] RFR: 8325873: Update JDK_DOCS property to point to JDK 21 docs In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 00:31:23 GMT, Kevin Rushforth wrote: > Clean backport of a docs-only fix to jfx22. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1369#pullrequestreview-1881602522 From mstrauss at openjdk.org Thu Feb 15 04:20:15 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Feb 2024 04:20:15 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v2] In-Reply-To: References: Message-ID: <6RVPGtK-IeBp3amyz2aLalnSMBGU2G_UJFYIC3f1vkA=.0e4ba3c0-5386-4169-bc25-e66c82d67967@github.com> > Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. > > The workaround is to set the system property "apple.awt.application.appearance=system". > > If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: > > > WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem > property apple.awt.application.appearance=system is set. This warning can be disabled by > setting javafx.preferences.suppressAppleAwtWarning=true. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Don't call into the native toolkit from Platform.getPreferences() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1367/files - new: https://git.openjdk.org/jfx/pull/1367/files/27ae6a7d..688b2f80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=00-01 Stats: 25 lines in 3 files changed: 14 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1367.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1367/head:pull/1367 PR: https://git.openjdk.org/jfx/pull/1367 From mhanl at openjdk.org Thu Feb 15 09:58:07 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 15 Feb 2024 09:58:07 GMT Subject: RFR: JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 22:44:50 GMT, Michael Strau? wrote: >> When a `Spinner` is configured with e.g. Integers (`IntegerSpinnerValueFactory`) and the user types in a `String`, e.g. 'abc' and focuses another `Node`, an exception is thrown (`NumberFormatException`). >> This exception is literally uncatchable, as it happens on focus lost. >> >> The issue is the same as for the `DatePicker` component described in [JDK-8303478](https://bugs.openjdk.org/browse/JDK-8303478), which was fixed in PR: https://github.com/openjdk/jfx/pull/1274. >> >> I did the exact same fix in this PR. Also added the same test. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1609: > >> 1607: spinner.getEditor().setText("2abc"); >> 1608: >> 1609: // loosing focus triggers cancelEdit() because the text cannot be parsed > > typo: losing Thanks, I didn't know until today that `loose` and `lose` are actually different words in a way.? I think I will still integrate it to avoid a new review cycle and given that I copied this test. But good to know for the future! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1365#discussion_r1490732581 From mhanl at openjdk.org Thu Feb 15 09:58:08 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 15 Feb 2024 09:58:08 GMT Subject: Integrated: JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 20:42:08 GMT, Marius Hanl wrote: > When a `Spinner` is configured with e.g. Integers (`IntegerSpinnerValueFactory`) and the user types in a `String`, e.g. 'abc' and focuses another `Node`, an exception is thrown (`NumberFormatException`). > This exception is literally uncatchable, as it happens on focus lost. > > The issue is the same as for the `DatePicker` component described in [JDK-8303478](https://bugs.openjdk.org/browse/JDK-8303478), which was fixed in PR: https://github.com/openjdk/jfx/pull/1274. > > I did the exact same fix in this PR. Also added the same test. This pull request has now been integrated. Changeset: 49d7d52f Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/49d7d52fdf1c7341538e5bf4bd1a841dcc85c906 Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod 8325798: Spinner throws uncatchable exception on tab out from garbled text Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1365 From mhanl at openjdk.org Thu Feb 15 10:00:06 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 15 Feb 2024 10:00:06 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> References: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> Message-ID: On Wed, 14 Feb 2024 02:55:15 GMT, Ambarish Rapte wrote: >> This is accessibility specific fix. >> >> **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem >> >> **Cause:** >> The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) >> If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. >> >> **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready >> >> **Verification:** >> - On Windows machine, launch Narrator. Issue is observed only with Narrator >> - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) >> Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. >> Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review corrections-1 modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 376: > 374: * so that the notification is not sent during any getAttribute() call. > 375: */ > 376: Platform.runLater(() -> listView.notifyAccessibleAttributeChanged(AccessibleAttribute.FOCUS_ITEM)); What I'm wondering here: Don't the other cells also suffer from this issue? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1490736811 From kpk at openjdk.org Thu Feb 15 10:39:05 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 15 Feb 2024 10:39:05 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 05:27:19 GMT, John Hendrikx wrote: > I think we should simplify the `getHitInfo` method in the `TextLayout` interface. > > The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). > > Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. Thanks for reviewing @hjohn Certainly we could simplify the `getHitInfo` method but the complication starts when we have to support Text node embedded in TextFlow. Just to differentiate Text node and TextFlow, spans can be used as you suggested. I had to introduce these parameters for the case of Text node embedded in TextFlow. On top of that we need to support emojis and RTL text. This is where it started getting complex and I had to use these new parameters. If you have any thoughts on this, please let me know. I'll got through all the comments and incorporate wherever possible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1945799592 From jhendrikx at openjdk.org Thu Feb 15 11:23:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Feb 2024 11:23:06 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 10:36:51 GMT, Karthik P K wrote: > > I think we should simplify the `getHitInfo` method in the `TextLayout` interface. > > The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). > > Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. > > Thanks for reviewing @hjohn Certainly we could simplify the `getHitInfo` method but the complication starts when we have to support Text node embedded in TextFlow. Just to differentiate Text node and TextFlow, spans can be used as you suggested. I had to introduce these parameters for the case of Text node embedded in TextFlow. On top of that we need to support emojis and RTL text. This is where it started getting complex and I had to use these new parameters. If you have any thoughts on this, please let me know. I'll got through all the comments and incorporate wherever possible. Sure, if you can give me more details as to why this is necessary, perhaps I can follow the logic. From an outside observer, `PrismTextLayout` already seems to have far too much specialization related to how text is supplied (spans/String) and who is supplying it (TextFlow/Text), making the logic hard to follow (but also error prone, and likely has more than a few bugs). I'd expect a class that does text layout measurements to be able to do this with a uniform format without special casing (ie. perhaps `Text` should wrap their text in a `TextSpan` and all the special casing can disappear). Your current changes seems to increase this divide with even more specialization, hence why I'm wondering if this is the best approach. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1945892410 From mhanl at openjdk.org Thu Feb 15 12:11:01 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 15 Feb 2024 12:11:01 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: <44CBVbcW4IcwgLNzrqd5s61MslyvXcDH86iHji6KEVM=.838635b8-61c4-4f5f-92eb-0ae97a017e9b@github.com> On Wed, 14 Feb 2024 21:01:59 GMT, Andy Goryachev wrote: >> It is the count, how often update item was called. >> That it got smaller shows, that we call it less often, as the item was not changed (which is a good thing). >> That also matches with your observation, which is the expected output here. >> >> I saw that this was changed for some tests in https://github.com/openjdk/jfx/pull/863, we also can do something similar here as well. > > on second thought, this is ok as is - I asked because the code is not testing a specific requirement. > The second `assertEquals(18)` might be testing a specific requirement - that the count has not changed, right? Yes, as far as I can see. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490914400 From mhanl at openjdk.org Thu Feb 15 12:16:03 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 15 Feb 2024 12:16:03 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 20:57:14 GMT, Andy Goryachev wrote: >> Yes! I did it this way to be consistent with all other cell implementations. I really think that this should be refactored, I can also create a ticket for this. My preference would be to be consistent now, but change it for all cell implementations in one go. >> What is your opinion? > > my opinion: the code is not broken per se. Since this block is edited, I would have changed it just in this file to make the logic clearer (in other places, like TreeTableCell:685 it is functional because we have more code in line 692 and on). > I don't think another ticket is necessary because, technically speaking, the code is not broken. > (just my opinion) yes, but other cells have the exact same pattern, although it is not needed. And technically speaking, this is not even needed in `TreeTableCell`, tbh I never even needed a labeled if ever. ? But sure, can also change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1490919877 From jbechberger at openjdk.org Thu Feb 15 12:40:09 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 15 Feb 2024 12:40:09 GMT Subject: [jfx17u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:11:13 GMT, Johannes Bechberger wrote: > Clean backport of 8221261: Deadlock on macOS in JFXPanel app when handling IME calls @kevinrushforth could you review it? ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/178#issuecomment-1946017234 From crschnick at xpipe.io Thu Feb 15 12:46:57 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Thu, 15 Feb 2024 13:46:57 +0100 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <2e941d3f-b6e6-4669-81ca-4dd0a30737e0@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> Message-ID: <8678353f-f73b-4635-afc0-1bf1a5c3d975@xpipe.io> Just wanted to let you know that after setting apple.awt.application.appearance=system everything works as expected now. Thanks for all the work on this great feature. I plan to release the next version of our application with platform preferences integration soon to production. On 13/02/2024 20:11, Michael Strau? wrote: > The reason why the values are wrong might be that in PlatformSupport.m > L105, we query [NSApp effectiveApperance], but this always seems to > return the light appearance if JavaFX doesn't own the NSApplication. > > On Mon, Feb 12, 2024 at 6:26?PM Kevin Rushforth > wrote: >> Actually, it's worse than not detecting changes, it's simply not getting the right values at all. If I run the program when the system appearance is already in Dark mode, it doesn't get the correct values at start up. >> >> -- Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Feb 15 12:54:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Feb 2024 12:54:04 GMT Subject: [jfx22] Integrated: 8325873: Update JDK_DOCS property to point to JDK 21 docs In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 00:31:23 GMT, Kevin Rushforth wrote: > Clean backport of a docs-only fix to jfx22. This pull request has now been integrated. Changeset: f15a4add Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f15a4add7133c94f4bae3c0abaeb16d1b31ee6cd Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8325873: Update JDK_DOCS property to point to JDK 21 docs Reviewed-by: arapte Backport-of: f379eae65aab963779d7b7335cbade810f8efe82 ------------- PR: https://git.openjdk.org/jfx/pull/1369 From jhendrikx at openjdk.org Thu Feb 15 13:35:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Feb 2024 13:35:06 GMT Subject: Integrated: JDK-8324182 Deprecate for removal SimpleSelector and CompoundSelector classes In-Reply-To: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> References: <8wK8qufh-_rOM2BI4dleBu__g0eEsnQrn5sCM6uyhC0=.2cffa004-0ff9-4091-9155-1722e3254704@github.com> Message-ID: <_VbxXXXDbnsk5yASvK2WnlkCOjLX390dactwPk8ZeTo=.9efb00dd-3e8c-4453-9be5-947faac73541@github.com> On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote: > The SimpleSelector and CompoundSelector classes are public classes in an exported package, javafx.css, but they are not intended to be used by applications. They are implementation details. They cannot be constructed directly and no other JavaFX API accepts or returns a SimpleSelector or CompoundSelector. > > We should deprecate them for removal so we can move them to a non-exported package, removing them from the public API. This pull request has now been integrated. Changeset: 48be7d36 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/48be7d36d5033d215d585619f34c2dde518e4b53 Stats: 31 lines in 3 files changed: 31 ins; 0 del; 0 mod 8324182: Deprecate for removal SimpleSelector and CompoundSelector classes Reviewed-by: kcr, angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1340 From jhendrikx at openjdk.org Thu Feb 15 13:36:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Feb 2024 13:36:08 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Sun, 14 Jan 2024 14:32:49 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong exception name in javadoc I think we can continue with this one, now that #1340 is done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1946106187 From jhendrikx at openjdk.org Thu Feb 15 14:11:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Feb 2024 14:11:59 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 22:44:07 GMT, Andy Goryachev wrote: > Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. > > This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) I think if we're busy here, it would be worthwhile to also remove the other calls to the skin to change the caret animating. I think it would require a focus listener in Skin. Also code like this in `TextInputControlSkin` makes me believe that it may work out of the box correctly, even with selections, and all the code in the behavior is unnecessary (or can at least be fully handled by the `Skin` with perhaps another listener: >From `TextInputControlSkin`: /** * The caret is visible when the text box is focused AND when the selection * is empty. If the selection is non empty or the text box is not focused * then we don't want to show the caret. Also, we show the caret while * performing some operations such as most key strokes. In that case we * simply toggle its opacity. *

*/ caretVisible = new BooleanBinding() { { bind(control.focusedProperty(), control.anchorProperty(), control.caretPositionProperty(), control.disabledProperty(), control.editableProperty(), displayCaret, blinkProperty());} @Override protected boolean computeValue() { // RT-10682: On Windows, we show the caret during selection, but on others we hide it return !blinkProperty().get() && displayCaret.get() && control.isFocused() && (isWindows() || (control.getCaretPosition() == control.getAnchor())) && !control.isDisabled() && control.isEditable(); } }; At a minimum it seems there is some duplication going on... modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 183: > 181: setForwardBias(true); > 182: } > 183: setCaretAnimating(true); I find this a bit confusing. By putting the two `setCaretAnimating` separate, you give the impression it must stop blinking for a while before continuing because of the call to `setForwardBias`. However, all we want to is call it with `false` then `true` to restart the animation (for a lack of a `playFromStart` call). Perhaps it may be good to introduce a method that captures this more clearly as I find it confusing (`restartCaretAnimation`) Same comment for `TextFieldSkin`. ------------- Changes requested by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1368#pullrequestreview-1882863451 PR Review Comment: https://git.openjdk.org/jfx/pull/1368#discussion_r1491059806 From angorya at openjdk.org Thu Feb 15 16:06:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Feb 2024 16:06:01 GMT Subject: RFR: JDK-8325798: Spinner throws uncatchable exception on tab out from garbled text In-Reply-To: References: Message-ID: <-ToUccbN17-mEggTKtsnmhl5_0PV32l1_sUMGlIQxQ8=.29dee71c-e3b1-47dc-be56-5e6d494aaa25@github.com> On Thu, 15 Feb 2024 09:54:18 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1609: >> >>> 1607: spinner.getEditor().setText("2abc"); >>> 1608: >>> 1609: // loosing focus triggers cancelEdit() because the text cannot be parsed >> >> typo: losing > > Thanks, I didn't know until today that `loose` and `lose` are actually different words in a way.? > I think I will still integrate it to avoid a new review cycle and given that I copied this test. > But good to know for the future! no worries, I'll fix it later in [JDK-8296810](https://bugs.openjdk.org/browse/JDK-8296810) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1365#discussion_r1491249465 From angorya at openjdk.org Thu Feb 15 16:39:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Feb 2024 16:39:59 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: <44CBVbcW4IcwgLNzrqd5s61MslyvXcDH86iHji6KEVM=.838635b8-61c4-4f5f-92eb-0ae97a017e9b@github.com> References: <44CBVbcW4IcwgLNzrqd5s61MslyvXcDH86iHji6KEVM=.838635b8-61c4-4f5f-92eb-0ae97a017e9b@github.com> Message-ID: On Thu, 15 Feb 2024 12:08:27 GMT, Marius Hanl wrote: >> on second thought, this is ok as is - I asked because the code is not testing a specific requirement. >> The second `assertEquals(18)` might be testing a specific requirement - that the count has not changed, right? > > Yes, as far as I can see. so in theory, we could just test the fact that the count has not changed: int ct = rt_31200_count; ... assertEquals(ct, rt_31200_count); this will make the test independent of the first number (which might change) and only test what's important (that the count does not change later). what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1491304604 From angorya at openjdk.org Thu Feb 15 16:56:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Feb 2024 16:56:58 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 14:04:30 GMT, John Hendrikx wrote: >> Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. >> >> This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 183: > >> 181: setForwardBias(true); >> 182: } >> 183: setCaretAnimating(true); > > I find this a bit confusing. By putting the two `setCaretAnimating` separate, you give the impression it must stop blinking for a while before continuing because of the call to `setForwardBias`. > > However, all we want to is call it with `false` then `true` to restart the animation (for a lack of a `playFromStart` call). Perhaps it may be good to introduce a method that captures this more clearly as I find it confusing (`restartCaretAnimation`) > > Same comment for `TextFieldSkin`. good point ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1368#discussion_r1491332357 From angorya at openjdk.org Thu Feb 15 17:29:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Feb 2024 17:29:10 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: Message-ID: > Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. > > This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) 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 four additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8322748.blink - Merge remote-tracking branch 'origin/master' into 8322748.blink - 8322748: Caret blinking in JavaFX should only stop when caret moves ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1368/files - new: https://git.openjdk.org/jfx/pull/1368/files/f04cd069..558ab28e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1368&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1368&range=00-01 Stats: 79 lines in 7 files changed: 74 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1368.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1368/head:pull/1368 PR: https://git.openjdk.org/jfx/pull/1368 From angorya at openjdk.org Thu Feb 15 17:29:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Feb 2024 17:29:10 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: Message-ID: <55BoHDk_KI4V6Xr2HqIvm6N4zBA3iy-AjvY1HcZ7wgM=.dc2037ca-95c3-4cb0-af60-e5a73c51df0f@github.com> On Thu, 15 Feb 2024 14:08:59 GMT, John Hendrikx wrote: > I think if we're busy here, it would be worthwhile to also remove the other calls to the skin to change the caret animating. I would rather not: it would require a much larger effort. Avoiding the caret flickering when its position does not change is an incremental improvement from which we all benefit. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1946678770 From kcr at openjdk.org Thu Feb 15 20:45:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Feb 2024 20:45:05 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 Message-ID: This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 21**. In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK required run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. This is targeted to JavaFX 23, and must not be backported to any earlier version. This needs a CSR and a release note. ------------- Commit messages: - 8321603: Bump minimum JDK version for JavaFX to JDK 21 Changes: https://git.openjdk.org/jfx/pull/1370/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321603 Stats: 8 lines in 3 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1370.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1370/head:pull/1370 PR: https://git.openjdk.org/jfx/pull/1370 From kizune at openjdk.org Thu Feb 15 22:02:03 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 15 Feb 2024 22:02:03 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> References: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> Message-ID: On Wed, 14 Feb 2024 02:55:15 GMT, Ambarish Rapte wrote: >> This is accessibility specific fix. >> >> **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem >> >> **Cause:** >> The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) >> If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. >> >> **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready >> >> **Verification:** >> - On Windows machine, launch Narrator. Issue is observed only with Narrator >> - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) >> Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. >> Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review corrections-1 Aside of the copyright year issue looks fine to me. modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 31: > 29: import java.util.List; > 30: > 31: import javafx.application.Platform; Since we changing the file, shouldn't we bump the copyright year too? ------------- Marked as reviewed by kizune (Author). PR Review: https://git.openjdk.org/jfx/pull/1363#pullrequestreview-1883962598 PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1491718863 From hmeda at openjdk.org Fri Feb 16 04:49:59 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 16 Feb 2024 04:49:59 GMT Subject: RFR: 8323880: Caret rendered at wrong position in case of a click event on RTL text In-Reply-To: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> References: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> Message-ID: On Tue, 13 Feb 2024 16:57:37 GMT, Jay Bhaskar wrote: > Issue: The current implementation of complex text rendering paths on the Java platform is experiencing side effects. > Solution: We need to align with WebKit 616.1 standards. The patch supports two paths simple rendering path and complex rendering path based on text rendering mode. Sanity testing is fine ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1364#pullrequestreview-1884305369 From arapte at openjdk.org Fri Feb 16 05:07:59 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 16 Feb 2024 05:07:59 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: References: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> Message-ID: On Thu, 15 Feb 2024 09:57:17 GMT, Marius Hanl wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review corrections-1 > > modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 376: > >> 374: * so that the notification is not sent during any getAttribute() call. >> 375: */ >> 376: Platform.runLater(() -> listView.notifyAccessibleAttributeChanged(AccessibleAttribute.FOCUS_ITEM)); > > What I'm wondering here: Don't the other cells also suffer from this issue? Yes, the issue can be observed with TreeTableCell or TableCell. I shall create a ticket for them. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1491961387 From arapte at openjdk.org Fri Feb 16 05:13:59 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 16 Feb 2024 05:13:59 GMT Subject: RFR: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time [v2] In-Reply-To: References: <4Zr0CUaLKvqDGl1y7h2q0deVM_nn75E-k2GYSpjaXiE=.325ba086-be9e-4def-a8af-f0d4cdc281b5@github.com> Message-ID: On Thu, 15 Feb 2024 21:59:18 GMT, Alexander Zuev wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review corrections-1 > > modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 31: > >> 29: import java.util.List; >> 30: >> 31: import javafx.application.Platform; > > Since we changing the file, shouldn't we bump the copyright year too? Thanks, Alex, We do update the copyright year in batch for all needed files before release. So, it can be skipped in individual fixes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1363#discussion_r1491963192 From arapte at openjdk.org Fri Feb 16 05:13:59 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 16 Feb 2024 05:13:59 GMT Subject: Integrated: 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 12:29:49 GMT, Ambarish Rapte wrote: > This is accessibility specific fix. > > **Issue**: When a ListView is shown for first time then accessibility focus rectangle is not drawn around the focused ListIem > > **Cause:** > The ListView takes a little time to create it's skin(ListViewSkin) and the skins for ListItems(ListCellSkin) > If the Accessibility client application requests focused item before ListView is completely ready then JavaFX return null. > > **Fix**: Send a focus item change notification to accessibility client application after the ListIteam is ready > > **Verification:** > - On Windows machine, launch Narrator. Issue is observed only with Narrator > - Execute the [program](https://bugs.openjdk.org/secure/attachment/104180/Main.java) attached to the JBS issue [JDK-8309374](https://bugs.openjdk.org/browse/JDK-8309374) > Move through the TextFields and press `Alt+down`, observe that focus rectangle is drawn correctly. > Once the ListView is showing Press and hold `Up/Down` or `Ctrl + Up/Down` keys, observe that focus rectangle is always drawn. This pull request has now been integrated. Changeset: 27549395 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/2754939556aa767a298fcf24f5caaa277351a4d7 Stats: 32 lines in 1 file changed: 32 ins; 0 del; 0 mod 8309374: Accessibility Focus Rectangle on ListItem is not drawn when ListView is shown for first time Reviewed-by: kcr, kizune ------------- PR: https://git.openjdk.org/jfx/pull/1363 From jbhaskar at openjdk.org Fri Feb 16 05:56:13 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 16 Feb 2024 05:56:13 GMT Subject: Integrated: 8323880: Caret rendered at wrong position in case of a click event on RTL text In-Reply-To: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> References: <2XSc4ZdFX4OfBmMU9NIIyhD0mkpspqWidgguRlp3J14=.c0c1aa6e-6c5a-42d9-a7ff-d2a1d83422d0@github.com> Message-ID: On Tue, 13 Feb 2024 16:57:37 GMT, Jay Bhaskar wrote: > Issue: The current implementation of complex text rendering paths on the Java platform is experiencing side effects. > Solution: We need to align with WebKit 616.1 standards. The patch supports two paths simple rendering path and complex rendering path based on text rendering mode. This pull request has now been integrated. Changeset: 1fb56e33 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod 8323880: Caret rendered at wrong position in case of a click event on RTL text Reviewed-by: kcr, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/1364 From jhendrikx at openjdk.org Fri Feb 16 13:17:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Feb 2024 13:17:58 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 17:29:10 GMT, Andy Goryachev wrote: >> Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. >> >> This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) > > 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 four additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - 8322748: Caret blinking in JavaFX should only stop when caret moves Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1368#pullrequestreview-1885127795 From jhendrikx at openjdk.org Fri Feb 16 13:17:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Feb 2024 13:17:58 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: <55BoHDk_KI4V6Xr2HqIvm6N4zBA3iy-AjvY1HcZ7wgM=.dc2037ca-95c3-4cb0-af60-e5a73c51df0f@github.com> References: <55BoHDk_KI4V6Xr2HqIvm6N4zBA3iy-AjvY1HcZ7wgM=.dc2037ca-95c3-4cb0-af60-e5a73c51df0f@github.com> Message-ID: On Thu, 15 Feb 2024 17:26:39 GMT, Andy Goryachev wrote: > > I think if we're busy here, it would be worthwhile to also remove the other calls to the skin to change the caret animating. > > I would rather not: it would require a much larger effort. Avoiding the caret flickering when its position does not change is an incremental improvement from which we all benefit. Alright, the original issue did envision this though, specifically to start get rid of some of the blockers for a Behavior API. The issue isn't fully addressed then, so I guess I'll file another one. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1948368629 From kcr at openjdk.org Fri Feb 16 13:20:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Feb 2024 13:20:05 GMT Subject: [jfx17u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:11:13 GMT, Johannes Bechberger wrote: > Clean backport of 8221261: Deadlock on macOS in JFXPanel app when handling IME calls The backport looks fine to me. @johanvos will need to review / approve it for inclusion into jfx17u as he maintains this code line. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/178#issuecomment-1948371652 From jbhaskar at openjdk.org Fri Feb 16 14:06:07 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 16 Feb 2024 14:06:07 GMT Subject: [jfx22u] RFR: 8323880: Caret rendered at wrong position in case of a click event on RTL text Message-ID: A clean backport to jfx22u. The fix is for rtl text issue, where the caret position is at the wrong position. I have tested the fix it is working with the fix and failing without the fix. ------------- Commit messages: - Backport 1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3 Changes: https://git.openjdk.org/jfx22u/pull/12/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=12&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323880 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/12.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/12/head:pull/12 PR: https://git.openjdk.org/jfx22u/pull/12 From jbhaskar at openjdk.org Fri Feb 16 15:41:05 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 16 Feb 2024 15:41:05 GMT Subject: [jfx22u] Integrated: 8323880: Caret rendered at wrong position in case of a click event on RTL text In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 14:00:57 GMT, Jay Bhaskar wrote: > A clean backport to jfx22u. The fix is for rtl text issue, where the caret position is at the wrong position. I have tested the fix it is working with the fix and failing without the fix. This pull request has now been integrated. Changeset: 9fac61d7 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx22u/commit/9fac61d7afd5bfb6095edc50572a84026f9c419f Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod 8323880: Caret rendered at wrong position in case of a click event on RTL text Backport-of: 1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3 ------------- PR: https://git.openjdk.org/jfx22u/pull/12 From angorya at openjdk.org Fri Feb 16 16:02:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Feb 2024 16:02:59 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 17:29:10 GMT, Andy Goryachev wrote: >> Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. >> >> This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) > > 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 four additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - 8322748: Caret blinking in JavaFX should only stop when caret moves @aghaisas or @karthikpandelu could you please take a look at this PR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1948731415 From angorya at openjdk.org Fri Feb 16 16:02:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Feb 2024 16:02:58 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: <55BoHDk_KI4V6Xr2HqIvm6N4zBA3iy-AjvY1HcZ7wgM=.dc2037ca-95c3-4cb0-af60-e5a73c51df0f@github.com> Message-ID: On Fri, 16 Feb 2024 13:15:14 GMT, John Hendrikx wrote: > so I guess I'll file another one. Thank you, please do. As a side note, before we can start re-writing the controls' behaviors, we should: a) identify all the behavioral aspects of each control and b) develop a set of tests to exercise each one, along the lines of [JDK-8314906](https://bugs.openjdk.org/browse/JDK-8314906) without these steps, we are guaranteed to create regression. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1948730006 From kevin.rushforth at oracle.com Fri Feb 16 18:37:36 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Feb 2024 10:37:36 -0800 Subject: [External] : Re: Platform preferences theme detection In-Reply-To: <8678353f-f73b-4635-afc0-1bf1a5c3d975@xpipe.io> References: <249f5b51-5eb2-4bb8-a4ef-b7c0ae95d19c@xpipe.io> <43cecb08-a6b4-4574-b8e8-051dccceb533@xpipe.io> <270873c0-106b-4ae3-a495-00ac569983a9@xpipe.io> <30494e55-eb9a-48d7-a783-9852b3593638@xpipe.io> <37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io> <7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com> <59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io> <4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io> <34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com> <8678353f-f73b-4635-afc0-1bf1a5c3d975@xpipe.io> Message-ID: <560fefb8-40ee-4e0b-b4d2-515cdae7069d@oracle.com> Good to hear. Thanks for confirming. -- Kevin On 2/15/2024 4:46 AM, Christopher Schnick wrote: > > Just wanted to let you know that after setting > apple.awt.application.appearance=system everything works as expected > now. Thanks for all the work on this great feature. I plan to release > the next version of our application with platform preferences > integration soon to production. > > On 13/02/2024 20:11, Michael Strau? wrote: >> The reason why the values are wrong might be that in PlatformSupport.m >> L105, we query [NSApp effectiveApperance], but this always seems to >> return the light appearance if JavaFX doesn't own the NSApplication. >> >> On Mon, Feb 12, 2024 at 6:26?PM Kevin Rushforth >> wrote: >>> Actually, it's worse than not detecting changes, it's simply not getting the right values at all. If I run the program when the system appearance is already in Dark mode, it doesn't get the correct values at start up. >>> >>> -- Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Feb 16 19:26:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Feb 2024 19:26:04 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: <55BoHDk_KI4V6Xr2HqIvm6N4zBA3iy-AjvY1HcZ7wgM=.dc2037ca-95c3-4cb0-af60-e5a73c51df0f@github.com> Message-ID: On Fri, 16 Feb 2024 16:00:07 GMT, Andy Goryachev wrote: > As a side note, before we can start re-writing the controls' behaviors, we should: > > a) identify all the behavioral aspects of each control and b) develop a set of tests to exercise each one, along the lines of [JDK-8314906](https://bugs.openjdk.org/browse/JDK-8314906) > > without these steps, we are guaranteed to create regression. I think those tests should be unit tests, not via Robot, to make this a feasible endeavor. This is the reason why I asked about a mocking framework to be included in FX test utilities. We should look into making it much easier to set up a Behavior or Control or Skin, without having to fire up a complete FX. Things like animations and timers should be mocked out, so there can be precise control during the tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1949186138 From angorya at openjdk.org Fri Feb 16 19:31:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Feb 2024 19:31:05 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: <55BoHDk_KI4V6Xr2HqIvm6N4zBA3iy-AjvY1HcZ7wgM=.dc2037ca-95c3-4cb0-af60-e5a73c51df0f@github.com> Message-ID: <58kT6nxQPHWJ6RqPK8f88RAGMocinBcHyo6b5FqFLgA=.b81afbb3-1cb6-4e6e-957f-fcda84ad1e0a@github.com> On Fri, 16 Feb 2024 19:23:00 GMT, John Hendrikx wrote: > I think those tests should be unit tests, not via Robot Preferably, yes. If something can be tested via headless unit tests, it should be done so, you are absolutely right. Some tests, however, require a fully rendered skin - for example, PgUp in a TextArea. I suspect only 10-20% of all the tests will require a headful environment. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1368#issuecomment-1949198317 From jvos at openjdk.org Fri Feb 16 20:26:04 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 16 Feb 2024 20:26:04 GMT Subject: [jfx17u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: <-_QfFHIDY0XmOyZ1Av3w1wd5HmNYO5XD8hQydnfIGas=.5346b9da-a547-498a-9786-ecfb7846c796@github.com> On Thu, 8 Feb 2024 09:11:13 GMT, Johannes Bechberger wrote: > Clean backport of 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/178#pullrequestreview-1885952738 From martin at martinfox.com Fri Feb 16 20:31:50 2024 From: martin at martinfox.com (Martin Fox) Date: Fri, 16 Feb 2024 12:31:50 -0800 Subject: UI scaling issues when physical and logical screen resolutions differ on Linux In-Reply-To: References: Message-ID: <3FDC27F8-0BD5-466F-B099-0100843974D3@martinfox.com> Hi Christopher, This may be a side-effect of using KDE. To determine the UI scale the JavaFX code consults the ?scaling-factor? setting in the ?org.gnome.desktop.interface? schema. You can check this on the command line: gsettings get org.gnome.desktop.interface scaling-factor This should be 0 so JavaFX can compute the scale itself. If it?s greater than 0 that?s the value JavaFX will use for the UI scale. It appears that a KDE install can set this value to 1. In my case I started with the ARM version of Ubuntu server and then installed KDE (kubuntu-desktop) and afterward the scaling-factor was 1. This doesn?t happen when installing the standard GNOME desktop. Martin > On Feb 13, 2024, at 2:13?AM, Christopher Schnick wrote: > > Hello, > > several users of our JavaFX applications have reported that the UI scale is too small when the physical and logical screen resolutions differ on Linux. For example in this case > > > > there is an implicit scaling factor of 150% included as the monitor is a 4k display but is using a lowered resolution of 2560x1440. This is then further stretched as the OS resolution is 1920x1080, but the main problem is that the 150% factor is somehow not getting picked up and JavaFX is treating this as a 4k display, thus making everything too small. For now these users can use -Dglass.gtk.uiScale=1.5 but that is not a nice solution to this problem. > > Best > Christopher Schnick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Fri Feb 16 21:16:28 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 16 Feb 2024 21:16:28 GMT Subject: [jfx21u] RFR: 8325154: resizeColumnToFitContent is slower than it needs to be Message-ID: Hi all, This pull request contains a clean backport of commit [e2f42c5b](https://github.com/openjdk/jfx/commit/e2f42c5b71ef061c614540508fbac3fb610b1ae3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Robert Lichtenberger on 14 Feb 2024 and was reviewed by Andy Goryachev and Marius Hanl. Thanks! ------------- Commit messages: - Backport e2f42c5b71ef061c614540508fbac3fb610b1ae3 Changes: https://git.openjdk.org/jfx21u/pull/42/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=42&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325154 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/42.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/42/head:pull/42 PR: https://git.openjdk.org/jfx21u/pull/42 From kevin.rushforth at oracle.com Fri Feb 16 22:11:45 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Feb 2024 14:11:45 -0800 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 Message-ID: All, Even though we build JavaFX binaries with JDK 21 as the boot JDK, the latest version of JavaFX still runs with JDK 17, although it isn't tested with older JDK versions. In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and very little reason to continue to do so. A question was raised [1] as to whether we should go even further and, once JDK 22 is released, jump straight to JDK 22 as a? minimum. While we could do that, I feel that there isn't sufficient justification for this at this time, although we could reconsider for next release. To this end, I propose to bump the minimum version of the JDK needed to run JavaFX 23 to JDK 21. I filed?JDK-8321603 [2] to track this and prepared PR? #1370 [3] (I've moved the PR back to Draft, pending this discussion). This will not affect update releases of earlier versions of JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will continue to run with the same minimum JDK that they run on today. As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or later, although in practice, we don't bump the minimum required JDK version without a good reason. For example, while JavaFX 22 is built using JDK 21 as the boot JDK, it produces class files that will run with JDK 17, using "--release 17". The proposed change discussed here would update that in JavaFX 23 to?"--release 21". NOTE: this will not be an invitation to do wholesale refactoring of existing classes or methods to use newer language features (e.g., a PR that refactors existing switch statements and switch expressions into pattern-matching switch expressions would not be welcome). Rather, this can be seen as enabling judicious use of new features in new code, much as we did when we started allowing the use of "var", records, and pattern-matching instanceof. Comments are welcome. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html [2] https://bugs.openjdk.org/browse/JDK-8321603 [3] https://github.com/openjdk/jfx/pull/1370 From mfox at openjdk.org Fri Feb 16 22:40:10 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 16 Feb 2024 22:40:10 GMT Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external Message-ID: At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event. At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations. ------------- Commit messages: - Using OS to determine DRAG_DONE operation Changes: https://git.openjdk.org/jfx/pull/1371/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325591 Stats: 29 lines in 5 files changed: 20 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1371.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1371/head:pull/1371 PR: https://git.openjdk.org/jfx/pull/1371 From kcr at openjdk.org Fri Feb 16 22:51:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Feb 2024 22:51:58 GMT Subject: [jfx22u] RFR: Merge jfx:jfx22 Message-ID: Clean merge of `jfx:jfx22` to `jfx22u:master` ------------- Commit messages: - Merge jfx:master - 8325873: Update JDK_DOCS property to point to JDK 21 docs The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx22u/pull/13/files Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx22u/pull/13.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/13/head:pull/13 PR: https://git.openjdk.org/jfx22u/pull/13 From kcr at openjdk.org Sat Feb 17 00:08:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Feb 2024 00:08:00 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 22:47:52 GMT, Kevin Rushforth wrote: > Clean merge of `jfx:jfx22` to `jfx22u:master` This pull request has now been integrated. Changeset: 9d0592f5 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/9d0592f5a44cad789e92e6bff218bc9606272c1f Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Merge ------------- PR: https://git.openjdk.org/jfx22u/pull/13 From shankar.kalel at gmail.com Sat Feb 17 10:31:02 2024 From: shankar.kalel at gmail.com (Shankar Kalel) Date: Sat, 17 Feb 2024 16:01:02 +0530 Subject: Java 11 to 17 - exception while calling MonocleRobot->getScreenCapture Message-ID: This issue is already reported at - https://github.com/TestFX/Monocle/issues/83 and now it is reproducible even with latest versions of OpenJDK, OpenJFx and Monocle as below - OpenJDk 17.0.10 OpenJfx 17.0.10 OpenJfx-Monocle 17.0.10 Any fix or workaround would be highly beneficial for the teams using TestFX with Headless for test automation Thanks Shankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbechberger at openjdk.org Sat Feb 17 10:56:59 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Sat, 17 Feb 2024 10:56:59 GMT Subject: [jfx17u] Integrated: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: <4WjroU45e3QtjtaY96nmh2vTiPxsYtwZzX3fsdnXB58=.9763c07b-8982-488e-8830-65ca74b3bc1a@github.com> On Thu, 8 Feb 2024 09:11:13 GMT, Johannes Bechberger wrote: > Clean backport of 8221261: Deadlock on macOS in JFXPanel app when handling IME calls This pull request has now been integrated. Changeset: 4b630c30 Author: Johannes Bechberger Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/4b630c30b240a9139da9f7b70c856c317109cba8 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Reviewed-by: jvos Backport-of: 90cbc66305d0a1380cf3a8cd99ad40db240e554c ------------- PR: https://git.openjdk.org/jfx17u/pull/178 From jvos at openjdk.org Sat Feb 17 11:00:58 2024 From: jvos at openjdk.org (Johan Vos) Date: Sat, 17 Feb 2024 11:00:58 GMT Subject: [jfx21u] RFR: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 21:12:21 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [e2f42c5b](https://github.com/openjdk/jfx/commit/e2f42c5b71ef061c614540508fbac3fb610b1ae3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Robert Lichtenberger on 14 Feb 2024 and was reviewed by Andy Goryachev and Marius Hanl. > > Thanks! Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/42#pullrequestreview-1886537981 From john.hendrikx at gmail.com Sat Feb 17 13:36:48 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 17 Feb 2024 14:36:48 +0100 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 In-Reply-To: References: Message-ID: +1 On 16/02/2024 23:11, Kevin Rushforth wrote: > All, > > Even though we build JavaFX binaries with JDK 21 as the boot JDK, the > latest version of JavaFX still runs with JDK 17, although it isn't > tested with older JDK versions. In order for JavaFX to be able to use > newer JDK features, such as code snippets (in API docs), record > patterns, pattern matching for switch statements, and so forth, we > need to increase the minimum version of the JDK that can run the > latest JavaFX. Additionally, there is an ongoing cost to keeping > JavaFX buildable and runnable on older versions of Java, and very > little reason to continue to do so. > > A question was raised [1] as to whether we should go even further and, > once JDK 22 is released, jump straight to JDK 22 as a minimum. While > we could do that, I feel that there isn't sufficient justification for > this at this time, although we could reconsider for next release. > > To this end, I propose to bump the minimum version of the JDK needed > to run JavaFX 23 to JDK 21. I filed?JDK-8321603 [2] to track this and > prepared PR? #1370 [3] (I've moved the PR back to Draft, pending this > discussion). This will not affect update releases of earlier versions > of JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will > continue to run with the same minimum JDK that they run on today. > > As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or > later, although in practice, we don't bump the minimum required JDK > version without a good reason. For example, while JavaFX 22 is built > using JDK 21 as the boot JDK, it produces class files that will run > with JDK 17, using "--release 17". The proposed change discussed here > would update that in JavaFX 23 to?"--release 21". > > NOTE: this will not be an invitation to do wholesale refactoring of > existing classes or methods to use newer language features (e.g., a PR > that refactors existing switch statements and switch expressions into > pattern-matching switch expressions would not be welcome). Rather, > this can be seen as enabling judicious use of new features in new > code, much as we did when we started allowing the use of "var", > records, and pattern-matching instanceof. > > Comments are welcome. > > -- Kevin > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html > [2] https://bugs.openjdk.org/browse/JDK-8321603 > [3] https://github.com/openjdk/jfx/pull/1370 > From kcr at openjdk.org Sat Feb 17 14:50:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Feb 2024 14:50:58 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v2] In-Reply-To: <6RVPGtK-IeBp3amyz2aLalnSMBGU2G_UJFYIC3f1vkA=.0e4ba3c0-5386-4169-bc25-e66c82d67967@github.com> References: <6RVPGtK-IeBp3amyz2aLalnSMBGU2G_UJFYIC3f1vkA=.0e4ba3c0-5386-4169-bc25-e66c82d67967@github.com> Message-ID: On Thu, 15 Feb 2024 04:20:15 GMT, Michael Strau? wrote: >> Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. >> >> The workaround is to set the system property "apple.awt.application.appearance=system". >> >> If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: >> >> >> WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem >> property apple.awt.application.appearance=system is set. This warning can be disabled by >> setting javafx.preferences.suppressAppleAwtWarning=true. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Don't call into the native toolkit from Platform.getPreferences() The code looks fine other than missing `doPrivileged` calls. I left a couple other minor suggestions. I haven't tested it yet, but will do so next week. Since we are defining a new system property a CSR might be in order (let me think about it). modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 806: > 804: /** > 805: * Checks whether there are any problems with platform preferences detection, > 806: * and emits a warning otherwise. Suggestion: change "otherwise" to "if so" or similar (the current comment indicates that a warning will be produced if there are no problems). modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 466: > 464: private static final String SUPPRESS_AWT_WARNING_PROPERTY = "javafx.preferences.suppressAppleAwtWarning"; > 465: private static final String AWT_APPEARANCE_PROPERTY = "apple.awt.application.appearance"; > 466: private boolean checkSystemAppearance = !Boolean.getBoolean(SUPPRESS_AWT_WARNING_PROPERTY); This needs to be wrapped in a `doPrivileged` call, with a `@SuppressWarnings` annotation, or it will fail to run with a security manager (which we still support as of now, even though it is deprecated). See, for example, `PlatformImpl.java` for the pattern to use. modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 470: > 468: @Override > 469: public void checkPlatformPreferencesSupport() { > 470: if (checkSystemAppearance && "NSApplicationAWT".equals(applicationClassName)) { Minor: consider using a static constant for the name of the AWT app class? modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 473: > 471: checkSystemAppearance = false; > 472: > 473: if (!"system".equals(System.getProperty(AWT_APPEARANCE_PROPERTY))) { You need to wrap the call to `System.getProperty` in `doPrivileged (so you will need to create a local var). ------------- PR Review: https://git.openjdk.org/jfx/pull/1367#pullrequestreview-1886580420 PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1493344795 PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1493345874 PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1493346242 PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1493346477 From kcr at openjdk.org Sat Feb 17 14:58:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Feb 2024 14:58:58 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 15 Feb 2024 13:33:23 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong exception name in javadoc > > I think we can continue with this one, now that #1340 is done. @hjohn Please merge the latest upstream master to pick up the fix for [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1950229308 From mstrauss at openjdk.org Sat Feb 17 18:11:09 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 17 Feb 2024 18:11:09 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3] In-Reply-To: References: Message-ID: > Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. > > The workaround is to set the system property "apple.awt.application.appearance=system". > > If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: > > > WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem > property apple.awt.application.appearance=system is set. This warning can be disabled by > setting javafx.preferences.suppressAppleAwtWarning=true. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1367/files - new: https://git.openjdk.org/jfx/pull/1367/files/688b2f80..5c743df7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=01-02 Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1367.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1367/head:pull/1367 PR: https://git.openjdk.org/jfx/pull/1367 From jpereda at openjdk.org Sat Feb 17 19:15:57 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Sat, 17 Feb 2024 19:15:57 GMT Subject: [jfx21u] Integrated: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 21:12:21 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [e2f42c5b](https://github.com/openjdk/jfx/commit/e2f42c5b71ef061c614540508fbac3fb610b1ae3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Robert Lichtenberger on 14 Feb 2024 and was reviewed by Andy Goryachev and Marius Hanl. > > Thanks! This pull request has now been integrated. Changeset: e6cc0715 Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/e6cc0715f293fbd3055180f284cb422e7ab47e1d Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod 8325154: resizeColumnToFitContent is slower than it needs to be Reviewed-by: jvos Backport-of: e2f42c5b71ef061c614540508fbac3fb610b1ae3 ------------- PR: https://git.openjdk.org/jfx21u/pull/42 From jpereda at openjdk.org Sat Feb 17 20:04:07 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Sat, 17 Feb 2024 20:04:07 GMT Subject: [jfx22u] RFR: 8325154: resizeColumnToFitContent is slower than it needs to be Message-ID: Hi all, This pull request contains a clean backport of commit [e2f42c5b](https://github.com/openjdk/jfx/commit/e2f42c5b71ef061c614540508fbac3fb610b1ae3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Robert Lichtenberger on 14 Feb 2024 and was reviewed by Andy Goryachev and Marius Hanl. Thanks! ------------- Commit messages: - Backport e2f42c5b71ef061c614540508fbac3fb610b1ae3 Changes: https://git.openjdk.org/jfx22u/pull/14/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=14&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325154 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/14.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/14/head:pull/14 PR: https://git.openjdk.org/jfx22u/pull/14 From nlisker at gmail.com Sun Feb 18 08:42:03 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 18 Feb 2024 10:42:03 +0200 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 In-Reply-To: References: Message-ID: +1 On Sat, Feb 17, 2024, 15:37 John Hendrikx wrote: > +1 > > On 16/02/2024 23:11, Kevin Rushforth wrote: > > All, > > > > Even though we build JavaFX binaries with JDK 21 as the boot JDK, the > > latest version of JavaFX still runs with JDK 17, although it isn't > > tested with older JDK versions. In order for JavaFX to be able to use > > newer JDK features, such as code snippets (in API docs), record > > patterns, pattern matching for switch statements, and so forth, we > > need to increase the minimum version of the JDK that can run the > > latest JavaFX. Additionally, there is an ongoing cost to keeping > > JavaFX buildable and runnable on older versions of Java, and very > > little reason to continue to do so. > > > > A question was raised [1] as to whether we should go even further and, > > once JDK 22 is released, jump straight to JDK 22 as a minimum. While > > we could do that, I feel that there isn't sufficient justification for > > this at this time, although we could reconsider for next release. > > > > To this end, I propose to bump the minimum version of the JDK needed > > to run JavaFX 23 to JDK 21. I filed JDK-8321603 [2] to track this and > > prepared PR #1370 [3] (I've moved the PR back to Draft, pending this > > discussion). This will not affect update releases of earlier versions > > of JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will > > continue to run with the same minimum JDK that they run on today. > > > > As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or > > later, although in practice, we don't bump the minimum required JDK > > version without a good reason. For example, while JavaFX 22 is built > > using JDK 21 as the boot JDK, it produces class files that will run > > with JDK 17, using "--release 17". The proposed change discussed here > > would update that in JavaFX 23 to "--release 21". > > > > NOTE: this will not be an invitation to do wholesale refactoring of > > existing classes or methods to use newer language features (e.g., a PR > > that refactors existing switch statements and switch expressions into > > pattern-matching switch expressions would not be welcome). Rather, > > this can be seen as enabling judicious use of new features in new > > code, much as we did when we started allowing the use of "var", > > records, and pattern-matching instanceof. > > > > Comments are welcome. > > > > -- Kevin > > > > [1] > > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html > > [2] https://bugs.openjdk.org/browse/JDK-8321603 > > [3] https://github.com/openjdk/jfx/pull/1370 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Sun Feb 18 20:00:08 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 18 Feb 2024 20:00:08 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen Message-ID: This PR fixes the dialog freeze problem once and for all. This one is a bit tricky to understand, here is how it works: This bug happens on every platform, although the implementation of nested event loops differs on every platform. E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. Funny enough, the reason why this bug happens is always the same: Timing. 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. Lets see if this is the right approach (for all platforms). Testing appreciated. # - [x] Tested on Windows - [x] Tested on Linux - [x] Tested on Mac - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) - [ ] Adjust copyright - [ ] Write Systemtest ------------- Commit messages: - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen Changes: https://git.openjdk.org/jfx/pull/1324/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285893 Stats: 164 lines in 13 files changed: 12 ins; 81 del; 71 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From tsayao at openjdk.org Sun Feb 18 23:10:12 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Feb 2024 23:10:12 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v19] In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 17:10:24 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: > > Add signals to avoid warnings I need help to test positioning on a HiDPI monitor. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1951477097 From tsayao at openjdk.org Sun Feb 18 23:10:12 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Feb 2024 23:10:12 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: - Merge branch 'master' into new_ime - Add signals to avoid warnings - Merge branch 'master' into new_ime # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp - Add check for jview - - Fix comment path - - Fix double keyrelease - - Use a work-around to relative positioning (until wayland is not officially supported) - Unref pango attr list - Merge branch 'master' into new_ime - Account the case of !filtered - Fix change of focus when on preedit + add filter on key release - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=19 Stats: 448 lines in 7 files changed: 62 ins; 265 del; 121 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Mon Feb 19 00:37:59 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 19 Feb 2024 00:37:59 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat A shot in the dark since I don't own a touch enabled monitor: Test 1: Add `GDK_SCROLL_MASK` on the original `gdk_pointer_grab` function; Test 2: This PR uses `GDK_SEAT_CAPABILITY_ALL_POINTING` which includes the touch masks. So the equivalent would include `GDK_TOUCH_MASK` on `gdk_pointer_grab`. I would bet on option 2. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1951510764 From mfox at openjdk.org Mon Feb 19 06:50:03 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 19 Feb 2024 06:50:03 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I did all of my testing on a Mac Retina display running Ubuntu 22 at 200% scale. Everything worked fine. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1951805227 From jpereda at openjdk.org Mon Feb 19 09:21:01 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 19 Feb 2024 09:21:01 GMT Subject: [jfx22u] Integrated: 8325154: resizeColumnToFitContent is slower than it needs to be In-Reply-To: References: Message-ID: On Sat, 17 Feb 2024 20:00:22 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [e2f42c5b](https://github.com/openjdk/jfx/commit/e2f42c5b71ef061c614540508fbac3fb610b1ae3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Robert Lichtenberger on 14 Feb 2024 and was reviewed by Andy Goryachev and Marius Hanl. > > Thanks! This pull request has now been integrated. Changeset: 8d26e071 Author: Jose Pereda URL: https://git.openjdk.org/jfx22u/commit/8d26e071dafb5debe673868c7e704ba7ae54bf83 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod 8325154: resizeColumnToFitContent is slower than it needs to be Backport-of: e2f42c5b71ef061c614540508fbac3fb610b1ae3 ------------- PR: https://git.openjdk.org/jfx22u/pull/14 From kpk at openjdk.org Mon Feb 19 09:58:23 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 09:58:23 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v12] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Code refactoring ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/8732047c..72287851 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=10-11 Stats: 259 lines in 7 files changed: 79 ins; 69 del; 111 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Mon Feb 19 10:05:04 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 10:05:04 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: <0UWgoQbRXPMKcG8Z7RSTFE91OUJdCDIhT770OLtPHN8=.dc2b740a-0b6c-4d40-a63a-d081b49f9187@github.com> On Wed, 14 Feb 2024 04:27:42 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 213: > >> 211: * @param textRunStart Start position of first Text run where hit info is requested. >> 212: * @param curRunStart Start position of text run where hit info is requested. >> 213: * @param forTextFlow Indicates if the hit info is requested for TextFlow or Text node. {@code true} for TextFlow and {@code false} for Text node. > > I have the impression that we're overcomplicating things here. There is a flag (`forTextFlow`) for Text/TextFlow, and a String (`text`) for Text/TextFlow, and there are already `setContent` methods for Text/TextFlow. > > I don't see a need for any of these changes to `getHitInfo` at all. > > If the content was set with `setContent(TextSpan[] spans)`, then we know it is a TextFlow (actually we don't care, we have spans which is the difference we're interested in). This fact can be checked at any time with: > > boolean isThisForTextFlow = this.spans != null; > > See how the `setContent` methods work; they either set `spans` or they don't. The rest of the code is already full of alternate paths with `if (spans == null) { /* do Text stuff */ } else { /* do TextFlow stuff */ }` > > The `text` parameter is also already known, because this is explicitely set for `Text` nodes because they use `setContent(String text, Object font)`. However, before using it (specifically for `Text`), make sure that check `spans == null` as it is filled for `TextFlow` as well at a later point. > > So, I think: > - the `text` parameter should never have been added (it wasn't until recently) > - `forTextFlow` flag is unnecessary, just check `spans != null`. The `getHitInfo` calculates the hit test information for the Text nodes embedded inside a TextFlow as well. Because of this `boolean isThisForTextFlow = this.spans != null;` is not enough. When hit test is requested on a Text embedded in TextFlow, if we use `getText()`, it gives the entire content rather than giving the Text node on which hit test is requested. Since we only have x, y coordinates, I found sending text as parameter is necessary. We are sending the run start value and start value of the first run in the line, but this also did not prove to be enough when we have cases such as multiline text, emojis, RTL text embedded in LTR text, repeated texts etc. So I have kept the `text` parameter as it is and removed `forTextFlow` parameter. This is now calculated using following condition `boolean forTextFlow = spans != null && text == null;` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494300074 From kpk at openjdk.org Mon Feb 19 10:13:03 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 10:13:03 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: <6o1R2DipRGrmu7SvDygcSUgXLqzG9vCfp8Mx396T6Es=.75cf6846-4626-41b7-8eaa-a713c90f528b@github.com> On Wed, 14 Feb 2024 04:33:00 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 424: > >> 422: >> 423: @Override >> 424: public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart, boolean forTextFlow) { > > This method has become huge, with I think upto 7 levels of nesting. It would benefit from some splitting. > > Suggestions in that area: > - Split it in one that handles RTL and one for LTR **or** > - Split it in one that handles `spans != null` (`TextFlow`) and one that handles `Text` > > You can also reduce the nesting of the first `if/else` by returning early: > > > if (lineIndex >= getLineCount()) { > charIndex = getCharCount(); > insertionIndex = charIndex + 1; > > return new Hit(charIndex, insertionIndex, leading); // return early here > } else { // no need to nest 150+ lines of code > > > More suggestions inline below I did not find splitting the `getHitInfo` method based on some condition very helpful. Since we are calculating effective value of x and TextRun, many values are dependant on intermediate values and the calculation involves many variables. Hence I decided to keep the major calculations inside `getHitInfo` method. Added 2 methods to move the calculation of values like previous line text width and width of LTR text in RTL text out of `getHitInfo`. > You can also reduce the nesting of the first `if/else` by returning early: > Made changes to return early in this case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494309979 From kpk at openjdk.org Mon Feb 19 10:25:04 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 10:25:04 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 04:39:04 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 432: > >> 430: int ltrIndex = 0; >> 431: int textWidthPrevLine = 0; >> 432: float xHitPos = x; > > This variable seems important, yet is only used in the RTL+Text branches. > > It seems that this variable can also be easily calculated as: > > originalX - (getMirroringWidth() - x) + bounds.getMinX > > This calculation can be done in the final RTL+Text branch near the end, no need to precalculate it IMHO The calculation done ln.no.486 calculates the effective value of x relative to the Text node on which hit test is requested. As far as I understood, the above suggested calculation doesn't perform the same calculation. So I did not make any changes. Am I missing something here. Please let me know if you have any suggestions. > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 440: > >> 438: insertionIndex = charIndex + 1; >> 439: } else { >> 440: if (isMirrored && (forTextFlow || spans == null)) { > > The extra condition here adds nothing of value, the original `if` was correct. > > Because `spans == null` means "for Text", and `forTextFlow == true` means "for TextFlow". Since it always is either a `TextFlow` or a `Text` the `||` always evaluates to `true` -- unless of course you pass in this flag incorrectly (again, I think the flag should be removed). The additional conditions are added to differentiate between the three cases: Text, TexFlow and Text embedded in TextFlow. Hence not make changes in this. > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 448: > >> 446: TextRun run = null; >> 447: //TODO binary search >> 448: if (text == null || spans == null) { > > `text` now refers to the `text` parameter here, and not to the original `text` field -- as discussed earlier, I think you shouldn't be passing in `text` as argument at all. > > Furthermore, I think the original code was also flawed; `text` is only `null` for a short while, and it is never `null` when `spans == null`. In other words, this `if` should IMHO be: > > Suggestion: > > if (spans == null) { // not a TextFlow, must be Text > > > Use `getText()` function to get the value of the text (it will just use the one from `Text` set via `setContent(String text, Object font)` or it will calculate it for `TextFlow` from the spans set via `setContent(TextSpan[] spans)`; As I mentioned earlier, the condition is required to differentiate between Text, TexFlow and Text embedded in TextFlow. Hence not removing condition, made modification to use `forTextFlow` instead of `text == null` > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 567: > >> 565: int[] trailing = new int[1]; >> 566: if (text != null && spans != null) { >> 567: charIndex = run.getOffsetAtX(x, trailing); > > Here also: `text` is no longer referring to the field `text` but to the argument `text`. I also again think the check is wrong. It should just be: > > if (spans != null) { // must be a TextFlow > > There are more oddities in the code below (which you didn't change this round -- see my comments inline: > > // !! getText() ***never*** returns `null`, the check is not needed > if (getText() != null && insertionIndex < getText().length) { > if (!leading) { > BreakIterator charIterator = BreakIterator.getCharacterInstance(); > > // before, when `text` was a field, this could never be null here > if (text != null) { > charIterator.setText(text); > } else { > charIterator.setText(new String(getText())); > } > int next = charIterator.following(insertionIndex); > if (next == BreakIterator.DONE) { > insertionIndex += 1; > } else { > insertionIndex = next; > } > } > } else if (!leading) { > insertionIndex += 1; > } Made changes to use `forTextFlow` instead of condition `text != null` so that it is easier to understand > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 576: > >> 574: int indexOffset; >> 575: if (isMirrored) { >> 576: indexOffset = run.getOffsetAtX(xHitPos, trailing); > > Here is the only place where `xHitPos` is used again (the RTL + Text case). I think it can just be calculated (you need to save off the original `x` value, or even better, don't modify the `x` argument but use a different variable for the `x` calculation). Added comment above regarding this > modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1035: > >> 1033: curRunStart = ((TextRun) runs[runIndex]).getStart(); >> 1034: } >> 1035: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, getText(), textRunStart, curRunStart, false); > > I think `getText()` as a parameter is not needed here (it is passed at line 260 when it calls `setContent`). Also, I think this should be `getTextInternal()` -- see the comment in that method. > > I also think the `false` is not needed, see comments on the interface. Used `getTextInternal()` instead of `getText()`. I believe the text parameter is needed as mentioned before > modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202: > >> 200: double x = point.getX(); >> 201: double y = point.getY(); >> 202: TextLayout.Hit h = layout.getHitInfo((float)x, (float)y, null, 0, 0, true); > > The `null` and `true` here are not needed IMHO (what would even happen when they conflict, `null` + `false`, or non-`null` + `true`?) Removed last parameter as suggested > tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 107: > >> 105: */ >> 106: >> 107: public class RTLTextCharacterIndexTest { > > This is a system test, which don't run with the build system. Are you sure this will work on all platforms? I don't see a specific `Font` used, which means `X_LEADING_OFFSET` may be incorrect when the platform is supplying a different font. I see that the tests don't run on all the platforms. I will look into this and update the PR ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494314778 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494322207 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494317666 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494324563 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494323474 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494326008 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494326979 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1494328009 From jpereda at openjdk.org Mon Feb 19 11:22:00 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 19 Feb 2024 11:22:00 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 19 Feb 2024 00:35:48 GMT, Thiago Milczarek Sayao wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add compile-time checks to GdkSeat > > A shot in the dark since I don't own a touch enabled monitor: > > Test 1: > > Add `GDK_SCROLL_MASK` on the original `gdk_pointer_grab` function; > > Test 2: > > This PR uses `GDK_SEAT_CAPABILITY_ALL_POINTING` which includes the touch masks. > > So the equivalent would include `GDK_TOUCH_MASK` on `gdk_pointer_grab`. > > > I would bet on option 2. Thanks @tsayao, I can definitely test those suggestions. If I get it right, you are proposing this change: status = gdk_pointer_grab(gdkWindow, owner_events, (GdkEventMask) (GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK + | GDK_TOUCH_MASK // or GDK_SCROLL_MASK | GDK_BUTTON_MOTION_MASK | GDK_BUTTON1_MOTION_MASK | GDK_BUTTON2_MOTION_MASK | GDK_BUTTON3_MOTION_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK NULL, cursor, GDK_CURRENT_TIME); But I don't see how this would fix the issue of the failing test on Linux that happens also without a touch enabled display. I tried both, the test still fails (two out of 5 times or so). Also, this is called only if there is no gdk_seat_grab function (which happens before GTK 3.20). However, if I use `GDK_SEAT_CAPABILITY_NONE` instead of `GDK_SEAT_CAPABILITY_ALL_POINTING`, it passes 10 out of 10, but that would cancel pointer/touch events, wouldn't it? Is there any chance that the robot implementation (via XTest, that uses `XTestGrabControl`) might not work fine with the new seat_grab approach after GTK 3.20+? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1952237235 From mstrauss at openjdk.org Mon Feb 19 11:23:04 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 19 Feb 2024 11:23:04 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v2] In-Reply-To: References: Message-ID: <93D0Af-tRqGvT6hl8J9f-C_Z3QKBzu2Njr0gnE7zxKg=.07a13876-8221-4075-a34b-a98cd959cd3a@github.com> On Fri, 9 Feb 2024 03:37:17 GMT, Martin Fox wrote: >> On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. >> >> This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. >> >> On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. > > Martin Fox 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 seven additional commits since the last revision: > > - Consistent terminology and more details in comments. > - Merge remote-tracking branch 'upstream/master' into keypadcombo > - Added SEPARATOR to list of keypad keys > - CharacterCombinations now work on the numeric keypad > - Fixed Monocle > - Merge remote-tracking branch 'upstream/master' into keypadcombo > - Added hint to getKeyCodeForChar to enable numeric keypad Looks good to me. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1289#pullrequestreview-1888180397 From tsayao at openjdk.org Mon Feb 19 11:48:00 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 19 Feb 2024 11:48:00 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: <1Lw8652hR6vQb3RYJJDxx301dNzWuONCxyLKUPf5puc=.146f1675-a14f-4fa7-8186-6e3de509ea14@github.com> On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat The rationale was: This tells which events get delivered to the window while grabbing. XWayland might be sensitive to `GDK_TOUCH_MASK` while Xorg is not. So the Idea was to keep the current way (with `gdk_pointer_grab` or `gdk_device_grab`, and adding the "deliver TOUCH events to me" might fix it. Another place to investigate is: #define GDK_FILTERED_EVENTS_MASK static_cast(GDK_ALL_EVENTS_MASK \ & ~GDK_TOUCH_MASK) It seems that Xorg converts touch events to regular mouse events, but XWayland might be different. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1952278279 From jhendrikx at openjdk.org Mon Feb 19 12:00:09 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 19 Feb 2024 12:00:09 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 10:36:51 GMT, Karthik P K wrote: >> I think we should simplify the `getHitInfo` method in the `TextLayout` interface. >> >> The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). >> >> Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. > >> I think we should simplify the `getHitInfo` method in the `TextLayout` interface. >> >> The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). >> >> Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. > > Thanks for reviewing @hjohn > Certainly we could simplify the `getHitInfo` method but the complication starts when we have to support Text node embedded in TextFlow. > Just to differentiate Text node and TextFlow, spans can be used as you suggested. I had to introduce these parameters for the case of Text node embedded in TextFlow. On top of that we need to support emojis and RTL text. This is where it started getting complex and I had to use these new parameters. If you have any thoughts on this, please let me know. > I'll got through all the comments and incorporate wherever possible. @karthikpandelu You mentioned there is special casing going on when a `Text` is part of a `TextFlow`. What are those cases and where is this happening? How does it even know that a `Text` is involved and that it is part of a `TextFlow`? IMHO, this class is in desperate need of simplification (out of scope of course for this PR), which I think can be done by having `Text` supply a (single) `TextSpan`, and removing the option to supply the content as a `String` + `Font`. However, that would break down if there are also special cases for `Text` within `TextFlow` -- I can't think of what those would be, and if it indeed is the case, I strongly suspect that `PrismTextLayout` may be overstepping its mandate (ie, such concerns when a `Text` is nested in a `TextFlow` should be the concern of `TextFlow`). Since I think simplifying this class would be a very good step, I'd just like to ensure we're not introducing more special casing now to make this future work even more impossible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1952298422 From kpk at openjdk.org Mon Feb 19 13:13:02 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 13:13:02 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 17:29:10 GMT, Andy Goryachev wrote: >> Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. >> >> This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) > > 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 four additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - 8322748: Caret blinking in JavaFX should only stop when caret moves LGTM ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1368#pullrequestreview-1888384026 From jpereda at openjdk.org Mon Feb 19 13:37:59 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 19 Feb 2024 13:37:59 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat I see... so removing all the changes from this PR, and using this diff from head instead: diff --git a/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp b/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp index e7a230b2b6..e89db2a55f 100644 --- a/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp +++ b/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp @@ -605,7 +605,8 @@ glass_gdk_mouse_devices_grab_with_cursor(GdkWindow *gdkWindow, GdkCursor *cursor | GDK_BUTTON2_MOTION_MASK | GDK_BUTTON3_MOTION_MASK | GDK_BUTTON_PRESS_MASK - | GDK_BUTTON_RELEASE_MASK), + | GDK_BUTTON_RELEASE_MASK + | GDK_TOUCH_MASK), NULL, cursor, GDK_CURRENT_TIME); return (status == GDK_GRAB_SUCCESS) ? TRUE : FALSE; it looks like dragging works on a touch enabled display and Wayland. (No changes needed in `GDK_FILTERED_EVENTS_MASK`). Tested this change on X11 as well, I don't see any issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1952469103 From kpk at openjdk.org Mon Feb 19 13:47:58 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 13:47:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> On Thu, 15 Feb 2024 10:36:51 GMT, Karthik P K wrote: >> I think we should simplify the `getHitInfo` method in the `TextLayout` interface. >> >> The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). >> >> Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. > >> I think we should simplify the `getHitInfo` method in the `TextLayout` interface. >> >> The code currently seems to be making distinctions where there are none. `TextFlow`s provide spans, while `Text`s provide a text. `getHitInfo` can take advantage of this to avoid the `text` and `forTextFlow` parameters altogether. This will reduce confusion (as there is no distinction) and also avoids cases that are non-sensical (providing `text` while `forTextFlow` is `true` or vice versa). >> >> Previous changes to this code (when the parameter `text` was introduced to `getHitInfo`) should probably be partially undone and simplified with this new knowledge. > > Thanks for reviewing @hjohn > Certainly we could simplify the `getHitInfo` method but the complication starts when we have to support Text node embedded in TextFlow. > Just to differentiate Text node and TextFlow, spans can be used as you suggested. I had to introduce these parameters for the case of Text node embedded in TextFlow. On top of that we need to support emojis and RTL text. This is where it started getting complex and I had to use these new parameters. If you have any thoughts on this, please let me know. > I'll got through all the comments and incorporate wherever possible. > @karthikpandelu You mentioned there is special casing going on when a `Text` is part of a `TextFlow`. What are those cases and where is this happening? How does it even know that a `Text` is involved and that it is part of a `TextFlow`? > We see these cases for every case when Text node is embedded in TextFlow. Basically we do not get x coordinate relative to the Text node since it is embedded in TextFlow. There are additional scenarios like RichText and Inline nodes present in TextFlow as well. In this case spans != null and text is supplied as parameter from Text class. This condition is considered as Text embedded in TextFlow. Below is the simple test code which shows above mentioned case. public class TextFlowRTLSample extends Application { TextFlow control = new TextFlow(); Label hitInfo2 = new Label(); Label pickResult = new Label(); @Override public void start(Stage primaryStage) throws Exception { Node[] ts = createRTLText(); control.getChildren().addAll(ts); control.addEventHandler(MouseEvent.ANY, this::handleMouseEvent); VBox root = new VBox(control, hitInfo2, pickResult); Scene scene = new Scene(root, 400, 600); scene.setNodeOrientation(NodeOrientation.RIGHT_TO_LEFT); primaryStage.setScene(scene); primaryStage.show(); } protected static Text t(String text) { Text t = new Text(text); t.setFont(new Font(48)); return t; } protected Node[] createRTLText() { return new Node[] { t("Arabic**"), t("??????????"), }; } protected void handleMouseEvent(MouseEvent ev) { PickResult pick = ev.getPickResult(); Node n = pick.getIntersectedNode(); hitInfo2.setText(null); if (n == null) { pickResult.setText("null"); } else { pickResult.setText(n.getClass().getSimpleName() + "." + n.hashCode()); if (n instanceof Text t) { Point3D p3 = pick.getIntersectedPoint(); Point2D p = new Point2D(p3.getX(), p3.getY()); HitInfo h = t.hitTest(p); hitInfo2.setText("Text: " + String.valueOf(h)); } } } public static void main(String[] args) { launch(); } } > However, that would break down if there are also special cases for `Text` within `TextFlow` -- I can't think of what those would be, and if it indeed is the case, I strongly suspect that `PrismTextLayout` may be overstepping its mandate (ie, such concerns when a `Text` is nested in a `TextFlow` should be the concern of `TextFlow`). Since I think simplifying this class would be a very good step, I'd just like to ensure we're not introducing more special casing now to make this future work even more impossible. I agree that simplifying would help in making this class clean, but at the same time I believe these changes are necessary to handle Text and TextFlow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1952485420 From jhendrikx at openjdk.org Mon Feb 19 14:34:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 19 Feb 2024 14:34:59 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> References: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> Message-ID: On Mon, 19 Feb 2024 13:45:00 GMT, Karthik P K wrote: > > @karthikpandelu You mentioned there is special casing going on when a `Text` is part of a `TextFlow`. What are those cases and where is this happening? How does it even know that a `Text` is involved and that it is part of a `TextFlow`? > > We see these cases for every case when Text node is embedded in TextFlow. Basically we do not get x coordinate relative to the Text node since it is embedded in TextFlow. There are additional scenarios like RichText and Inline nodes present in TextFlow as well. In this case spans != null and text is supplied as parameter from Text class. This condition is considered as Text embedded in TextFlow. Below is the simple test code which shows above mentioned case. Okay, so let me summarize (and let me know if that's correct): - You have a `Text` embedded into `TextFlow` - Mouse supplies a coordinate (`PickResult`) - You call `hitTest` on the node under the mouse (the intersected node, in this case, a `Text`) - The `Text` notices it is part of a `TextFlow`, and uses the parents `TextLayout` (which uses different coordinates) - We make the mouse coordinates relative to the `Text` node (not to the `TextFlow`, even though it uses its `TextLayout`...) - It then proceeds to call `layout.getHitInfo` with the `x`, `y` coordinates which are relative to the `Text`, but to compensate for that provides runStart/runEnd + extra logic in `getHitInfo` So, where I think there is a disconnect here between what I would expect and what is being implemented here is that the logic to compensate for a `Text` being part of a `TextFlow` has been pushed down into `PrismTextLayout` -- to compensate properly, `getHitInfo` needs a lot of extra parameters and has special paths for cases where a `Text` is part of a `TextFlow`. To determine the runStart/runEnd, `Text` is already analyzing the runs (and doing coordinate tests on them). Runs however have locations, with x/y coordinates. Would it not be possible, and more sensible, to adjust the `x`, `y` coordinates passed to `getHitInfo` instead of leaving those as coordinates relative to the `Text` ? I mean, you are using the parents `TextLayout`, so it would make sense to pass that `TextLayout` coordinates that are correct for it in the first place? In other words, I think the last few steps should be: - The `Text` notices it is part of a `TextFlow`, and uses the parents `TextLayout` - If using the parent `TextLayout`, then coordinates are made relative to the `TextFlow` node by analyzing the run locations - It then proceeds to call `layout.getHitInfo` with the new `x`, `y` coordinates which are relative to the `TextFlow` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1952572682 From mfox at openjdk.org Mon Feb 19 16:33:00 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 19 Feb 2024 16:33:00 GMT Subject: Integrated: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 20:05:09 GMT, Martin Fox wrote: > On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. > > This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. > > On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. This pull request has now been integrated. Changeset: ee8633cb Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/ee8633cb6d19b6da7bf32ad3cdee31261a7cf458 Stats: 81 lines in 19 files changed: 48 ins; 0 del; 33 mod 8089373: Translation from character to key code is not sufficient Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1289 From asarkar at openjdk.org Mon Feb 19 17:17:01 2024 From: asarkar at openjdk.org (Anirvan Sarkar) Date: Mon, 19 Feb 2024 17:17:01 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3] In-Reply-To: References: Message-ID: On Sat, 17 Feb 2024 18:11:09 GMT, Michael Strau? wrote: >> Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. >> >> The workaround is to set the system property "apple.awt.application.appearance=system". >> >> If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: >> >> >> WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem >> property apple.awt.application.appearance=system is set. This warning can be disabled by >> setting javafx.preferences.suppressAppleAwtWarning=true. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > address review comments > Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. What about SWT ? It looks like SWT also supports dark mode since version 4.12 [1][2]. [1] : https://eclipse.dev/eclipse/news/4.12/platform_isv.php#dark-theme-mac [2] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1952905143 From kpk at openjdk.org Mon Feb 19 17:51:02 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Feb 2024 17:51:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> Message-ID: On Mon, 19 Feb 2024 14:32:36 GMT, John Hendrikx wrote: >Okay, so let me summarize (and let me know if that's correct) @hjohn you have summarised it correctly. I understood your concern and thanks for explaining your suggestion it in details. I will look into this approach and get back to you. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1952947869 From jdv at openjdk.org Tue Feb 20 06:45:09 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 20 Feb 2024 06:45:09 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f Message-ID: IJG has released latest version of libjpeg 9f and we need to update our version also match 9f changes. IJG reference : https://www.ijg.org/ With updated changes both headless and headful tests are green on all platforms. Also while updating to 9f noticed that many files don't have latest copyright year and comments from previous version updates like 9e, so updated that part also to match 9f version. ------------- Commit messages: - jcheck errors - Whitespace errors - Initial change Changes: https://git.openjdk.org/jfx/pull/1372/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324233 Stats: 450 lines in 28 files changed: 171 ins; 86 del; 193 mod Patch: https://git.openjdk.org/jfx/pull/1372.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1372/head:pull/1372 PR: https://git.openjdk.org/jfx/pull/1372 From jpereda at openjdk.org Tue Feb 20 10:24:15 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 20 Feb 2024 10:24:15 GMT Subject: [jfx21u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Message-ID: Hi all, This pull request contains a clean backport of commit [90cbc663](https://github.com/openjdk/jfx/commit/90cbc66305d0a1380cf3a8cd99ad40db240e554c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Kevin Rushforth on 15 Jan 2024 and was reviewed by Phil Race, Prasanta Sadhukhan and Sergey Bylokhov. Thanks! ------------- Commit messages: - Backport 90cbc66305d0a1380cf3a8cd99ad40db240e554c Changes: https://git.openjdk.org/jfx21u/pull/43/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=43&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221261 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/43.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/43/head:pull/43 PR: https://git.openjdk.org/jfx21u/pull/43 From jpereda at openjdk.org Tue Feb 20 12:16:12 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 20 Feb 2024 12:16:12 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v4] In-Reply-To: References: Message-ID: > This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Revert changes and add touch mask to gdk pointer grab function ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1305/files - new: https://git.openjdk.org/jfx/pull/1305/files/f8ffe87f..ca5766fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=02-03 Stats: 105 lines in 5 files changed: 1 ins; 93 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1305.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1305/head:pull/1305 PR: https://git.openjdk.org/jfx/pull/1305 From jpereda at openjdk.org Tue Feb 20 12:16:13 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 20 Feb 2024 12:16:13 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat I've just reverted the previous changes, and just applied the touch mask to the `gdk_pointer_grab` function. Tests should be green now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1954087066 From angorya at openjdk.org Tue Feb 20 15:51:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Feb 2024 15:51:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: Message-ID: <07SKXfZlDvfvi2N9R-k__hxrFqS9EiL574C8yVNruQs=.4af16ef2-2a14-4a41-9501-bba7beb862a7@github.com> On Mon, 19 Feb 2024 10:21:52 GMT, Karthik P K wrote: >> tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java line 107: >> >>> 105: */ >>> 106: >>> 107: public class RTLTextCharacterIndexTest { >> >> This is a system test, which don't run with the build system. Are you sure this will work on all platforms? I don't see a specific `Font` used, which means `X_LEADING_OFFSET` may be incorrect when the platform is supplying a different font. > > I see that the tests don't run on all the platforms. I will look into this and update the PR A valid concern about specific fonts, similar to https://github.com/openjdk/jfx/pull/1236#issuecomment-1937022815 What was the resolution there? To use a hard-coded font based on the platform, or pick an available one from the list? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1496062620 From andy.goryachev at oracle.com Tue Feb 20 16:16:16 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 20 Feb 2024 16:16:16 +0000 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 In-Reply-To: References: Message-ID: +1 I would like to put forth an opinion that we should NOT use non-comprehensive switch expressions over enums, as they introduce a major incompatibility when evolving that enum (i.e. when adding new values). Consider this: enum E { A, B } E e; switch(e) { case A -> "a"; case B -> "b"; } evolving to enum A { A, B, C }; previously comprehensive switch expression explodes. -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Friday, February 16, 2024 at 14:12 To: openjfx-dev Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 All, Even though we build JavaFX binaries with JDK 21 as the boot JDK, the latest version of JavaFX still runs with JDK 17, although it isn't tested with older JDK versions. In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and very little reason to continue to do so. A question was raised [1] as to whether we should go even further and, once JDK 22 is released, jump straight to JDK 22 as a minimum. While we could do that, I feel that there isn't sufficient justification for this at this time, although we could reconsider for next release. To this end, I propose to bump the minimum version of the JDK needed to run JavaFX 23 to JDK 21. I filed JDK-8321603 [2] to track this and prepared PR #1370 [3] (I've moved the PR back to Draft, pending this discussion). This will not affect update releases of earlier versions of JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will continue to run with the same minimum JDK that they run on today. As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or later, although in practice, we don't bump the minimum required JDK version without a good reason. For example, while JavaFX 22 is built using JDK 21 as the boot JDK, it produces class files that will run with JDK 17, using "--release 17". The proposed change discussed here would update that in JavaFX 23 to "--release 21". NOTE: this will not be an invitation to do wholesale refactoring of existing classes or methods to use newer language features (e.g., a PR that refactors existing switch statements and switch expressions into pattern-matching switch expressions would not be welcome). Rather, this can be seen as enabling judicious use of new features in new code, much as we did when we started allowing the use of "var", records, and pattern-matching instanceof. Comments are welcome. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html [2] https://bugs.openjdk.org/browse/JDK-8321603 [3] https://github.com/openjdk/jfx/pull/1370 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Feb 20 16:21:07 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Feb 2024 08:21:07 -0800 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 In-Reply-To: References: Message-ID: This is unrelated to the discussion of bumping the minimum version to JDK 21, since we can already use switch expressions (they were added in JDK 14, which is below the current minimum of JDK 17). I recommend starting a? new thread if you would like to discuss this. -- Kevin On 2/20/2024 8:16 AM, Andy Goryachev wrote: > > +1 > > I would like to put forth an opinion that we should NOT use > non-comprehensive switch expressions over enums, as they introduce a > major incompatibility when evolving that enum (i.e. when adding new > values). > > Consider this: > > enum E { A, B } > > E e; > > switch(e) { > > case A -> "a"; > > case B -> "b"; > > } > > evolving to > > enum A { A, B, C }; > > previously comprehensive switch expression explodes. > > -andy > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Friday, February 16, 2024 at 14:12 > *To: *openjfx-dev > *Subject: *Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 > > All, > > Even though we build JavaFX binaries with JDK 21 as the boot JDK, the > latest version of JavaFX still runs with JDK 17, although it isn't > tested with older JDK versions. In order for JavaFX to be able to use > newer JDK features, such as code snippets (in API docs), record > patterns, pattern matching for switch statements, and so forth, we need > to increase the minimum version of the JDK that can run the latest > JavaFX. Additionally, there is an ongoing cost to keeping JavaFX > buildable and runnable on older versions of Java, and very little reason > to continue to do so. > > A question was raised [1] as to whether we should go even further and, > once JDK 22 is released, jump straight to JDK 22 as a minimum. While we > could do that, I feel that there isn't sufficient justification for this > at this time, although we could reconsider for next release. > > To this end, I propose to bump the minimum version of the JDK needed to > run JavaFX 23 to JDK 21. I filed?JDK-8321603 [2] to track this and > prepared PR? #1370 [3] (I've moved the PR back to Draft, pending this > discussion). This will not affect update releases of earlier versions of > JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will continue to > run with the same minimum JDK that they run on today. > > As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or > later, although in practice, we don't bump the minimum required JDK > version without a good reason. For example, while JavaFX 22 is built > using JDK 21 as the boot JDK, it produces class files that will run with > JDK 17, using "--release 17". The proposed change discussed here would > update that in JavaFX 23 to?"--release 21". > > NOTE: this will not be an invitation to do wholesale refactoring of > existing classes or methods to use newer language features (e.g., a PR > that refactors existing switch statements and switch expressions into > pattern-matching switch expressions would not be welcome). Rather, this > can be seen as enabling judicious use of new features in new code, much > as we did when we started allowing the use of "var", records, and > pattern-matching instanceof. > > Comments are welcome. > > -- Kevin > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html > [2] https://bugs.openjdk.org/browse/JDK-8321603 > [3] https://github.com/openjdk/jfx/pull/1370 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Tue Feb 20 18:12:05 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 20 Feb 2024 18:12:05 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout Message-ID: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. ------------- Commit messages: - Comment fixes - Consistency in naming conventions and comment cleanup. - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - Expanded robot lookup table, general cleanup - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - Resolving duplicates for Robot, fallback for getKeyCodeForChar - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - KeyCharacterCombination fixes on Linux Changes: https://git.openjdk.org/jfx/pull/1373/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1373&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8273743 Stats: 228 lines in 4 files changed: 210 ins; 10 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1373.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1373/head:pull/1373 PR: https://git.openjdk.org/jfx/pull/1373 From crschnick at xpipe.io Wed Feb 21 04:57:06 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Wed, 21 Feb 2024 05:57:06 +0100 Subject: UI scaling issues when physical and logical screen resolutions differ on Linux In-Reply-To: <3FDC27F8-0BD5-466F-B099-0100843974D3@martinfox.com> References: <3FDC27F8-0BD5-466F-B099-0100843974D3@martinfox.com> Message-ID: <9c2b5504-f5fe-4162-9933-3bfd2d8d1738@xpipe.io> So I tested this on my Asahi Fedora Linux KDE setup. So you were right about the scaling-factor being set to 1, but I'm still a little bit confused about this situation. If I go into the KDE settings, and change the display scaling to 150% for example, other (native) applications somehow get scaled appropriately. However, the scaling-factor property in gsettings is an integer and gets rounded down. So if I set display scaling to 150% in the settings, it will still get rounded down to one, leading to a wrong scaling for JavaFX applications. I would argue that JavaFX applications not scaling correctly on KDE systems is not a small issue as it makes some applications unusable unless the developer add support for custom scaling explicitly. So I have two questions: - Is the default dpi calculation also error prone? If not, why not always use the manual calculation on KDE systems - Are there better alternatives to the gsettings scaling-factor? Something like |org.gnome.desktop.interface text-scaling-factor| On 16/02/2024 21:31, Martin Fox wrote: > Hi Christopher, > > This may be a side-effect of using KDE. To determine the UI scale the > JavaFX code consults the ?scaling-factor? setting in the > ?org.gnome.desktop.interface? schema. You can check this on the > command line: > > gsettings get org.gnome.desktop.interface scaling-factor > > This should be 0 so JavaFX can compute the scale itself. If it?s > greater than 0 that?s the value JavaFX will use for the UI scale. > > It appears that a KDE install can set this value to 1. In my case I > started with the ARM version of Ubuntu server and then installed KDE > (kubuntu-desktop) and afterward the scaling-factor was 1. This doesn?t > happen when installing the standard GNOME desktop. > > Martin > >> On Feb 13, 2024, at 2:13?AM, Christopher Schnick >> wrote: >> >> Hello, >> >> several users of our JavaFX applications have reported that the UI >> scale is too small when the physical and logical screen resolutions >> differ on Linux. For example in this case >> >> >> >> there is an implicit scaling factor of 150% included as the monitor >> is a 4k display but is using a lowered resolution of 2560x1440. This >> is then further stretched as the OS resolution is 1920x1080, but the >> main problem is that the 150% factor is somehow not getting picked up >> and JavaFX is treating this as a 4k display, thus making everything >> too small. For now these users can use -Dglass.gtk.uiScale=1.5 but >> that is not a nice solution to this problem. >> >> Best >> Christopher Schnick >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Wed Feb 21 10:01:37 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 21 Feb 2024 10:01:37 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K 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 13 additional commits since the last revision: - Merge branch 'master' into rtl_hittest_issue - Code refactoring - Review comments - Fix emoji issue - Inline node issue fix - Code review changes - Fix issue with multiline text - Fix issue with RTL text within LTR text - Review changes - Fix multiline text insertion index calculation issue - ... and 3 more: https://git.openjdk.org/jfx/compare/96c496a0...e3812732 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/72287851..e3812732 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=11-12 Stats: 294814 lines in 6614 files changed: 173890 ins; 83927 del; 36997 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From mariushanl at web.de Wed Feb 21 10:58:58 2024 From: mariushanl at web.de (Marius Hanl) Date: Wed, 21 Feb 2024 11:58:58 +0100 Subject: =?UTF-8?Q?Aw=3A=C2=A0Proposal=3A_Bump_minimum_JDK_?= =?UTF-8?Q?version_for_JavaFX_23_to_JDK_21?= In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From kpk at openjdk.org Wed Feb 21 13:06:02 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 21 Feb 2024 13:06:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> Message-ID: On Mon, 19 Feb 2024 14:32:36 GMT, John Hendrikx wrote: > To determine the runStart/runEnd, `Text` is already analyzing the runs (and doing coordinate tests on them). Runs however have locations, with x/y coordinates. Would it not be possible, and more sensible, to adjust the `x`, `y` coordinates passed to `getHitInfo` instead of leaving those as coordinates relative to the `Text` ? I mean, you are using the parents `TextLayout`, so it would make sense to pass that `TextLayout` coordinates that are correct for it in the first place? > I'm afraid we can't do this. Primarily because if we pass `TextLayout` coordinates in the case of Text node embedded in TextFlow, we do not know if the character index needs to be calculated relative to the Text node or for the entire TextFlow. There is no way we could figure out this case without the extra parameters. Also if we do not pass the start value of the TextRun on which hit test is requested, there is no way to figure out on which Text node it is requested when same Text is repeated in the TextFlow. For the case like wrapped Text node inside TextFlow, we need to have text value, otherwise we can't determine if the same text is present in the previous line. So I believe we need these extra parameters to calculate the hit info for all the cases. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1956608182 From kevin.rushforth at oracle.com Wed Feb 21 17:37:16 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Feb 2024 09:37:16 -0800 Subject: Proposal: JavaFX Incubator Modules In-Reply-To: References: Message-ID: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> JEP 11 [1] defines a process for delivering non-final JDK APIs in incubator modules. Similarly, some JavaFX APIs would benefit from spending a period of time in a JavaFX release prior to being deemed stable. I propose JavaFX incubator modules as a means of putting non-final API in the hands of developers, while the API progresses towards either finalization or removal in a future release. This is especially useful for complex features with a large API surface. The JavaFX proposal is largely the same as the JDK one, but has some important differences. Please take a look at the preliminary proposal [2]. I have also created a Draft PR [3], for illustrative purposes only, to show how this might work. Please reply to this message with any feedback. Thanks. -- Kevin [1] https://openjdk.org/jeps/11 [2] https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md [3] https://github.com/openjdk/jfx/pull/1375 From kevin.rushforth at oracle.com Wed Feb 21 17:46:27 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Feb 2024 09:46:27 -0800 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 In-Reply-To: References: Message-ID: Based on feedback, I've moved the PR [1] for this enhancement [2] back to 'rfr'. A Provisional CSR [2] is also ready for review (by one or more people with a "Reviewer" role in the project). Thank you. -- Kevin [1] https://github.com/openjdk/jfx/pull/1370 [2] https://bugs.openjdk.org/browse/JDK-8321603 [3] https://bugs.openjdk.org/browse/JDK-8325993 From philip.race at oracle.com Wed Feb 21 17:47:44 2024 From: philip.race at oracle.com (Philip Race) Date: Wed, 21 Feb 2024 09:47:44 -0800 Subject: Proposal: JavaFX Incubator Modules In-Reply-To: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> Message-ID: <895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com> 1) The first thing that jumps out at me is the namespace : javafx.incubator The JDK's JEP 11 says "An incubator module is identified by the|jdk.incubator.|prefix in its module name" It says the same about the packages inside the module. "An incubating API is identified by the|jdk.incubator.|prefix in its exported package names". This is to avoid using the standard namespace prefixes for JDK of java. and javax. used for final APIs/modules. So similarly I think JavaFX incubators should avoid the javafx. prefix and I suggest "jfx." be used instead. This closely mirrors the "jdk." used in JEP 11, taking "java" out of the prefix and making it entirely an acronym, for both module and package names. The pain of updating your code when the API goes final can be eased by IDEs and is something you would need to do anyway because "incubator" is in all the names in either case. 2) The second thing is you don't say what the steps are to promote the incubating module to final. JEP 11 says a new JEP is needed for that, but it also says a new JEP is needed to re-incubate which is something JavaFX will not require. So do you expect it will be a new JEP for that ? I think that would be best to do that as the JEP to propose the incubator could be several years old and stale by then. You also don't say what it takes to drop it. So how about the basic process is that the first JEP simply proposes the incubating module, once it is in as you say it evolves by normal RFEs across releases ? Then when it is EITHER ready to go final OR be removed, a new JEP must be proposed for that. A removal JEP should generally be quite short :-) So I suggest to add a sentence along those lines to the proposal. "To either make the API of an incubating module final, or to remove it, then a new JEP should be submitted, referencing the incubator JEP". 3) The "reasonably small number of JavaFX releases" is I am sure intentionally vague, but perhaps we could say (1) Incubators which span beyond a 24 month period and are not yet ready will need a simple public approval from the project lead to remain for some additiional period at the discretion of the Project Lead by adding a simple comment in the JEP, otherwise the Project Lead will submit a removal JEP and (2) the submitter of the JEP can propose to remove it at any time. -phil. On 2/21/24 9:37 AM, Kevin Rushforth wrote: > JEP 11 [1] defines a process for delivering non-final JDK APIs in > incubator modules. > > Similarly, some JavaFX APIs would benefit from spending a period of > time in a JavaFX release prior to being deemed stable. I propose > JavaFX incubator modules as a means of putting non-final API in the > hands of developers, while the API progresses towards either > finalization or removal in a future release. This is especially useful > for complex features with a large API surface. > > The JavaFX proposal is largely the same as the JDK one, but has some > important differences. > > Please take a look at the preliminary proposal [2]. I have also > created a Draft PR [3], for illustrative purposes only, to show how > this might work. > > Please reply to this message with any feedback. > > Thanks. > > -- Kevin > > [1] https://openjdk.org/jeps/11 > [2] > https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md > [3] https://github.com/openjdk/jfx/pull/1375 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Feb 21 17:55:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Feb 2024 17:55:00 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 20:38:14 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 21**. > > In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK required run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This is targeted to JavaFX 23, and must not be backported to any earlier version. This needs a CSR and a release note. Are there any special steps needed to re-configure github actions? Are there any other dependencies? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1370#issuecomment-1957513455 From andy.goryachev at oracle.com Wed Feb 21 18:07:32 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 21 Feb 2024 18:07:32 +0000 Subject: Proposal: RichTextArea Control (Incubator) Message-ID: Dear JavaFX developers: We would like to propose a new feature - rich text control, RichTextArea, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, javafx.incubator.richtext. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. For context, the links to the original RFE [4] and a list of missing APIs related to rich text [5] are provided below. Sincerely, Your friendly JavaFX development team. References [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md [2] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1374 [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 [5] Missing APIs related to rich text control: https://bugs.openjdk.org/browse/JDK-8300569 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Feb 21 18:39:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Feb 2024 18:39:16 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 [v2] In-Reply-To: References: Message-ID: > This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 21**. > > In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK required run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This is targeted to JavaFX 23, and must not be backported to any earlier version. This needs a CSR and a release note. Kevin Rushforth 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 two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8321603-jdk-21-min - 8321603: Bump minimum JDK version for JavaFX to JDK 21 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1370/files - new: https://git.openjdk.org/jfx/pull/1370/files/a08dfd2f..4577f37e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1370&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1370&range=00-01 Stats: 210 lines in 29 files changed: 166 ins; 4 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1370.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1370/head:pull/1370 PR: https://git.openjdk.org/jfx/pull/1370 From angorya at openjdk.org Wed Feb 21 18:46:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Feb 2024 18:46:57 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 18:39:16 GMT, Kevin Rushforth wrote: >> This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 21**. >> >> In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK required run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. >> >> This is targeted to JavaFX 23, and must not be backported to any earlier version. This needs a CSR and a release note. > > Kevin Rushforth 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8321603-jdk-21-min > - 8321603: Bump minimum JDK version for JavaFX to JDK 21 combined (pr + master) builds on macOS 14.3 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1370#pullrequestreview-1894169026 From jhendrikx at openjdk.org Wed Feb 21 19:02:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 21 Feb 2024 19:02:06 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> Message-ID: On Wed, 21 Feb 2024 13:03:46 GMT, Karthik P K wrote: > > To determine the runStart/runEnd, `Text` is already analyzing the runs (and doing coordinate tests on them). Runs however have locations, with x/y coordinates. Would it not be possible, and more sensible, to adjust the `x`, `y` coordinates passed to `getHitInfo` instead of leaving those as coordinates relative to the `Text` ? I mean, you are using the parents `TextLayout`, so it would make sense to pass that `TextLayout` coordinates that are correct for it in the first place? > > I'm afraid we can't do this. Primarily because if we pass `TextLayout` coordinates in the case of Text node embedded in TextFlow, we do not know if the character index needs to be calculated relative to the Text node or for the entire TextFlow. There is no way we could figure out this case without the extra parameters. Also if we do not pass the start value of the TextRun on which hit test is requested, there is no way to figure out on which Text node it is requested when same Text is repeated in the TextFlow. I'm unclear on this part, do you mean it's possible that multiple `Text` objects could be hit at the same time? There should only be one `TextRun` at a certain x/y coordinate right? > For the case like wrapped Text node inside TextFlow, we need to have text value, otherwise we can't determine if the same text is present in the previous line. If the `Text` is wrapped, there will be multiple `TextRun`s. The coordinate given will match to one of the runs. The run then has a link back to a `TextSpan`, which has a `getText()` ? > So I believe we need these extra parameters to calculate the hit info for all the cases. Okay, well, we have some good new tests, so perhaps I'll play with it a bit to see what it is possible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1957709245 From johan.vos at gluonhq.com Wed Feb 21 19:08:42 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 21 Feb 2024 20:08:42 +0100 Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21 In-Reply-To: References: Message-ID: Hi Kevin, all, I agree with this proposal and with the rationale behind it. It provides a solid foundation for future consistent decisions as well. - Johan On Fri, Feb 16, 2024 at 11:14?PM Kevin Rushforth wrote: > All, > > Even though we build JavaFX binaries with JDK 21 as the boot JDK, the > latest version of JavaFX still runs with JDK 17, although it isn't > tested with older JDK versions. In order for JavaFX to be able to use > newer JDK features, such as code snippets (in API docs), record > patterns, pattern matching for switch statements, and so forth, we need > to increase the minimum version of the JDK that can run the latest > JavaFX. Additionally, there is an ongoing cost to keeping JavaFX > buildable and runnable on older versions of Java, and very little reason > to continue to do so. > > A question was raised [1] as to whether we should go even further and, > once JDK 22 is released, jump straight to JDK 22 as a minimum. While we > could do that, I feel that there isn't sufficient justification for this > at this time, although we could reconsider for next release. > > To this end, I propose to bump the minimum version of the JDK needed to > run JavaFX 23 to JDK 21. I filed JDK-8321603 [2] to track this and > prepared PR #1370 [3] (I've moved the PR back to Draft, pending this > discussion). This will not affect update releases of earlier versions of > JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will continue to > run with the same minimum JDK that they run on today. > > As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or > later, although in practice, we don't bump the minimum required JDK > version without a good reason. For example, while JavaFX 22 is built > using JDK 21 as the boot JDK, it produces class files that will run with > JDK 17, using "--release 17". The proposed change discussed here would > update that in JavaFX 23 to "--release 21". > > NOTE: this will not be an invitation to do wholesale refactoring of > existing classes or methods to use newer language features (e.g., a PR > that refactors existing switch statements and switch expressions into > pattern-matching switch expressions would not be welcome). Rather, this > can be seen as enabling judicious use of new features in new code, much > as we did when we started allowing the use of "var", records, and > pattern-matching instanceof. > > Comments are welcome. > > -- Kevin > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html > [2] https://bugs.openjdk.org/browse/JDK-8321603 > [3] https://github.com/openjdk/jfx/pull/1370 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Wed Feb 21 19:11:59 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 21 Feb 2024 19:11:59 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 18:39:16 GMT, Kevin Rushforth wrote: >> This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 21**. >> >> In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK required run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. >> >> This is targeted to JavaFX 23, and must not be backported to any earlier version. This needs a CSR and a release note. > > Kevin Rushforth 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8321603-jdk-21-min > - 8321603: Bump minimum JDK version for JavaFX to JDK 21 Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1370#pullrequestreview-1894210700 From prr at openjdk.org Wed Feb 21 19:29:57 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Feb 2024 19:29:57 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 18:39:16 GMT, Kevin Rushforth wrote: >> This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 21**. >> >> In order for JavaFX to be able to use newer JDK features, such as code snippets (in API docs), record patterns, pattern matching for switch statements, and so forth, we need to increase the minimum version of the JDK required run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. >> >> This is targeted to JavaFX 23, and must not be backported to any earlier version. This needs a CSR and a release note. > > Kevin Rushforth 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8321603-jdk-21-min > - 8321603: Bump minimum JDK version for JavaFX to JDK 21 Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1370#pullrequestreview-1894238971 From kcr at openjdk.org Wed Feb 21 19:29:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Feb 2024 19:29:58 GMT Subject: RFR: 8321603: Bump minimum JDK version for JavaFX to JDK 21 In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 17:52:33 GMT, Andy Goryachev wrote: > Are there any special steps needed to re-configure github actions? No. We already bumped the boot JDK used to build JavaFX to JDK 21 a couple months ago (in the JavaFX 22 release). > Are there any other dependencies? Not that I know of. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1370#issuecomment-1957753134 From kcr at openjdk.org Wed Feb 21 19:58:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Feb 2024 19:58:00 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors [v5] In-Reply-To: <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> <9cSSl-L1V8JVzojo_Q6wkpp4jzhVN876mEY5cNrowqk=.129ada68-df87-48ab-8e09-5d055a22eda9@github.com> Message-ID: On Mon, 5 Feb 2024 16:46:40 GMT, Martin Fox wrote: >> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. >> >> In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. >> >> The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. > > Martin Fox has updated the pull request incrementally with two additional commits since the last revision: > > - Work-around for using a call not present in the Xcode 13.3 SDK. > - Need correctly formed NSNotification when running tests @aghaisas said he could be the second reviewer. Thanks, Ajit. ------------- PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1957795684 From kevin.rushforth at oracle.com Wed Feb 21 21:55:14 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Feb 2024 13:55:14 -0800 Subject: Proposal: JavaFX Incubator Modules In-Reply-To: <895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com> References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com> Message-ID: <9607cefb-9d61-401e-983a-33a4ab00f729@oracle.com> These are all good points. 1. I agree. This seems like a good idea for all the reasons you mention. 2. I'll add the additional information. And I like your suggestion to require a JEP (*) to either drop or finalize an incubating feature. 3. Yes, I was deliberately vague on what constitutes a reasonable amount of time. Given that we are changing the default to "re-incubate" it does make sense to have a "soft timeout" so incubating features don't incubate forever without an intentional action to keep them alive. I'll update the proposal accordingly. Thanks. -- Kevin (*) We don't exactly follow the JEP process as described in JEP 2, but for larger features we expect a proposal that touches on the important points in a JEP-like document and is discussed on the mailing list. That's what we mean when we say "needs a JEP". On 2/21/2024 9:47 AM, Philip Race wrote: > 1) The first thing that jumps out at me is the namespace : > javafx.incubator > > The JDK's JEP 11 says "An incubator module is identified by > the|jdk.incubator.|prefix in its module name" > It says the same about the packages inside the module. > "An incubating API is identified by the|jdk.incubator.|prefix in its > exported package names". > > This is to avoid using the standard namespace prefixes for JDK of > java. and javax. used for final APIs/modules. > > So similarly I think JavaFX incubators should avoid the javafx. prefix > and I suggest "jfx." be used instead. > This closely mirrors the "jdk." used in JEP 11, taking "java" out of > the prefix and making it entirely an acronym, > for both module and package names. > The pain of updating your code when the API goes final can be eased by > IDEs and is something you would > need to do anyway because "incubator" is in all the names in either case. > > 2) The second thing is you don't say what the steps are to promote the > incubating module to final. > JEP 11 says a new JEP is needed for that, but it also says a new JEP > is needed to re-incubate > which is something JavaFX will not require. > So do you expect it will be a new JEP for that ? > I think that would be best to do that as the JEP to propose the > incubator could be several years old and stale by then. > You also don't say what it takes to drop it. > > So how about the basic process is that the first JEP simply proposes > the incubating module, once > it is in as you say it evolves by normal RFEs across releases ? > Then when it is EITHER ready to go final OR be removed, a new JEP must > be proposed for that. > A removal JEP should generally be quite short :-) > > So I suggest to add a sentence along those lines to the proposal. > "To either make the API of an incubating module final, or to remove > it, then a new JEP should be submitted, > referencing the incubator JEP". > > 3) The "reasonably small number of JavaFX releases" is I am sure > intentionally vague, but perhaps > we could say > (1) Incubators which span beyond a 24 month period and are not yet > ready will need > a simple public approval from the project lead to remain for some > additiional period at the discretion > of the Project Lead by adding a simple comment in the JEP, otherwise > the Project Lead will submit a removal JEP and > (2) the submitter of the JEP can propose to remove it at any time. > > -phil. > > On 2/21/24 9:37 AM, Kevin Rushforth wrote: >> JEP 11 [1] defines a process for delivering non-final JDK APIs in >> incubator modules. >> >> Similarly, some JavaFX APIs would benefit from spending a period of >> time in a JavaFX release prior to being deemed stable. I propose >> JavaFX incubator modules as a means of putting non-final API in the >> hands of developers, while the API progresses towards either >> finalization or removal in a future release. This is especially >> useful for complex features with a large API surface. >> >> The JavaFX proposal is largely the same as the JDK one, but has some >> important differences. >> >> Please take a look at the preliminary proposal [2]. I have also >> created a Draft PR [3], for illustrative purposes only, to show how >> this might work. >> >> Please reply to this message with any feedback. >> >> Thanks. >> >> -- Kevin >> >> [1] https://openjdk.org/jeps/11 >> [2] >> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md >> [3] https://github.com/openjdk/jfx/pull/1375 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Feb 21 22:05:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Feb 2024 22:05:59 GMT Subject: RFR: 8322748: Caret blinking in JavaFX should only stop when caret moves [v2] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 17:29:10 GMT, Andy Goryachev wrote: >> Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. >> >> This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) > > 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 four additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - Merge remote-tracking branch 'origin/master' into 8322748.blink > - 8322748: Caret blinking in JavaFX should only stop when caret moves Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1368#pullrequestreview-1894501784 From martin at martinfox.com Wed Feb 21 22:06:58 2024 From: martin at martinfox.com (Martin Fox) Date: Wed, 21 Feb 2024 14:06:58 -0800 Subject: UI scaling issues when physical and logical screen resolutions differ on Linux In-Reply-To: <9c2b5504-f5fe-4162-9933-3bfd2d8d1738@xpipe.io> References: <3FDC27F8-0BD5-466F-B099-0100843974D3@martinfox.com> <9c2b5504-f5fe-4162-9933-3bfd2d8d1738@xpipe.io> Message-ID: <3B3AE639-8496-47F6-A191-93F5BFE75013@martinfox.com> Christopher, I?ve entered a bug to track this. See https://bugs.openjdk.org/browse/JDK-8326428 JavaFX added support for scaling-factor back in 2016 to address an issue with Ubuntu 16. Since then I suspect that setting has fallen into disuse. I know that it?s not set in Ubuntu/Kubuntu 22 but I can?t easily test earlier releases. My hunch is that on most distros it is set to 0 which would allow JavaFX to compute the correct UI scale. Until recently KDE did not mess with this setting but that changed with version 5.27.8 which was released in the middle of last year. According to the commit message KDE started setting scaling-factor to make apps like IntelliJ IDE behave better. But this means the value is sure to be incorrect when the real scaling is fractional. I suspect JavaFX should probably be ignoring this setting. Until we can sort this out the only work-around is to set the scaling-factor to 0 yourself to undo what KDE did or use the glass.gtk.uiScale override. Martin > On Feb 20, 2024, at 8:57?PM, Christopher Schnick wrote: > > So I tested this on my Asahi Fedora Linux KDE setup. So you were right about the scaling-factor being set to 1, but I'm still a little bit confused about this situation. > > If I go into the KDE settings, and change the display scaling to 150% for example, other (native) applications somehow get scaled appropriately. However, the scaling-factor property in gsettings is an integer and gets rounded down. So if I set display scaling to 150% in the settings, it will still get rounded down to one, leading to a wrong scaling for JavaFX applications. I would argue that JavaFX applications not scaling correctly on KDE systems is not a small issue as it makes some applications unusable unless the developer add support for custom scaling explicitly. So I have two questions: > - Is the default dpi calculation also error prone? If not, why not always use the manual calculation on KDE systems > - Are there better alternatives to the gsettings scaling-factor? Something like org.gnome.desktop.interface text-scaling-factor > > On 16/02/2024 21:31, Martin Fox wrote: >> Hi Christopher, >> >> This may be a side-effect of using KDE. To determine the UI scale the JavaFX code consults the ?scaling-factor? setting in the ?org.gnome.desktop.interface? schema. You can check this on the command line: >> >> gsettings get org.gnome.desktop.interface scaling-factor >> >> This should be 0 so JavaFX can compute the scale itself. If it?s greater than 0 that?s the value JavaFX will use for the UI scale. >> >> It appears that a KDE install can set this value to 1. In my case I started with the ARM version of Ubuntu server and then installed KDE (kubuntu-desktop) and afterward the scaling-factor was 1. This doesn?t happen when installing the standard GNOME desktop. >> >> Martin >> >>> On Feb 13, 2024, at 2:13?AM, Christopher Schnick wrote: >>> >>> Hello, >>> >>> several users of our JavaFX applications have reported that the UI scale is too small when the physical and logical screen resolutions differ on Linux. For example in this case >>> >>> >>> >>> there is an implicit scaling factor of 150% included as the monitor is a 4k display but is using a lowered resolution of 2560x1440. This is then further stretched as the OS resolution is 1920x1080, but the main problem is that the 150% factor is somehow not getting picked up and JavaFX is treating this as a 4k display, thus making everything too small. For now these users can use -Dglass.gtk.uiScale=1.5 but that is not a nice solution to this problem. >>> >>> Best >>> Christopher Schnick >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Feb 21 22:11:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Feb 2024 22:11:03 GMT Subject: Integrated: 8322748: Caret blinking in JavaFX should only stop when caret moves In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 22:44:07 GMT, Andy Goryachev wrote: > Move caret animation handling due to keyboard input to the Skin, by registering a listener on the caretPosition property. This will restart animation only when the caret position changes instead of every key press. > > This also simplifies internal behaviors of TextArea, TextField, and PasswordField in light of the future InputMap RFE [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) This pull request has now been integrated. Changeset: 9a06bf9c Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/9a06bf9c5bce40cf842ddf25fe3360c366c3156c Stats: 24 lines in 3 files changed: 6 ins; 14 del; 4 mod 8322748: Caret blinking in JavaFX should only stop when caret moves Reviewed-by: jhendrikx, kpk, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1368 From kcr at openjdk.org Thu Feb 22 00:24:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 00:24:02 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v4] In-Reply-To: References: Message-ID: <2epP61nvIkLzYrhcvMsoDrqDIKu2kwDTPk8Aeegwiy0=.d865fa6f-f51d-4d8d-8950-bb099366e042@github.com> On Tue, 20 Feb 2024 12:16:12 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes and add touch mask to gdk pointer grab function This is a much less intrusive fix. The tests are indeed green now with no regressions. I don't have access to a Lunux system with a touch enabled display to test it on, but as long as you've verified that it fixes the problem, it's a +1 from me. ------------- PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1894647152 From kpk at openjdk.org Thu Feb 22 06:44:03 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 22 Feb 2024 06:44:03 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: <5TLIPcfP14NImjHvaExxwyKKZ9DUCCeoo_PaB479dk0=.cff928d7-03ac-44d2-a717-20d1ba6ae5ad@github.com> Message-ID: On Wed, 21 Feb 2024 18:59:02 GMT, John Hendrikx wrote: > I'm unclear on this part, do you mean it's possible that multiple `Text` objects could be hit at the same time? There should only be one `TextRun` at a certain x/y coordinate right? > Yes there will be one TextRun at a certain x/y coordinate. Consider following case where "First text." and "Second text" are 2 Text nodes embedded in TextFlow. Cursor is placed on the first character of the second text as shown in the screenshot. Now if the x/y coordinates are relative to TextFlow we can map it to second text in `getHitInfo` method of `PrismTextLayout` with only the help of x/y coordinates but we will not have information to decide if the character index should be calculated relative to Text node or TextFlow. On the other hand if the x/y coordinates are relative to Text node, we will not have information to decide if the hit test was requested on first text or second text. Screenshot 2024-02-22 at 11 41 46?AM > If the `Text` is wrapped, there will be multiple `TextRun`s. The coordinate given will match to one of the runs. The run then has a link back to a `TextSpan`, which has a `getText()` ? > Again in this case, the above challenge will be there. On top of that we need to decide how much of the same text is present in the previous line. If we are calculating for TextFlow we can easily do this with the help of start value of the TextRun but when we need to calculate the character index relative to the Text node, we will not be able to decide without additional parameters. The `getText()` gives the entire text of the TextFlow rather than the text content of the Text node on which the hit test is requested. If the same text is present in previous node as well, then we will not be able to decide from which TextRun, the calculation should start. For this reason we need run start value of the current line and current Text node. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1958804257 From jvos at openjdk.org Thu Feb 22 09:17:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 22 Feb 2024 09:17:07 GMT Subject: [jfx21u] RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: <1Y5XkP0qj82k2mXI3WB4pfgRUHsipI_fhHvbyyZNUTI=.6b8558df-91c1-4335-ba39-ab3563b6d8c9@github.com> On Tue, 20 Feb 2024 10:18:36 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [90cbc663](https://github.com/openjdk/jfx/commit/90cbc66305d0a1380cf3a8cd99ad40db240e554c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Kevin Rushforth on 15 Jan 2024 and was reviewed by Phil Race, Prasanta Sadhukhan and Sergey Bylokhov. > > Thanks! Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/43#pullrequestreview-1895310437 From jpereda at openjdk.org Thu Feb 22 09:33:04 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 22 Feb 2024 09:33:04 GMT Subject: [jfx21u] Integrated: 8221261: Deadlock on macOS in JFXPanel app when handling IME calls In-Reply-To: References: Message-ID: