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: On Tue, 20 Feb 2024 10:18:36 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [90cbc663](https://github.com/openjdk/jfx/commit/90cbc66305d0a1380cf3a8cd99ad40db240e554c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Kevin Rushforth on 15 Jan 2024 and was reviewed by Phil Race, Prasanta Sadhukhan and Sergey Bylokhov. > > Thanks! This pull request has now been integrated. Changeset: e00407b6 Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/e00407b6919cfe6fedefc74dba55c160640c5267 Stats: 30 lines in 1 file changed: 28 ins; 0 del; 2 mod 8221261: Deadlock on macOS in JFXPanel app when handling IME calls Reviewed-by: jvos Backport-of: 90cbc66305d0a1380cf3a8cd99ad40db240e554c ------------- PR: https://git.openjdk.org/jfx21u/pull/43 From tsayao at openjdk.org Thu Feb 22 10:25:09 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 22 Feb 2024 10:25:09 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: <5HXR9vg4Di4sFjITiW-58pjpBpgqxQBD74nvL96w9CI=.0008c9f3-4d28-4a7c-8f09-0c7f42073314@github.com> On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 The CSR requirement can be removed (probably) because the change that required it was reverted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1959135127 From kpk at openjdk.org Thu Feb 22 10:36:06 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 22 Feb 2024 10:36:06 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: <07SKXfZlDvfvi2N9R-k__hxrFqS9EiL574C8yVNruQs=.4af16ef2-2a14-4a41-9501-bba7beb862a7@github.com> References: <07SKXfZlDvfvi2N9R-k__hxrFqS9EiL574C8yVNruQs=.4af16ef2-2a14-4a41-9501-bba7beb862a7@github.com> Message-ID: On Tue, 20 Feb 2024 15:48:26 GMT, Andy Goryachev wrote: >> I see that the tests don't run on all the platforms. I will look into this and update the PR > > A valid concern about specific fonts, similar to > https://github.com/openjdk/jfx/pull/1236#issuecomment-1937022815 > > What was the resolution there? To use a hard-coded font based on the platform, or pick an available one from the list? The tests passes on Mac and Linux. The failures I mentioned above were because this branch was not upto date with the master and completely unrelated to this PR. Im facing some issue with my Windows system. I will check in windows once it is sorted and update the details here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1499026529 From thiago.sayao at gmail.com Thu Feb 22 10:47:43 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 22 Feb 2024 07:47:43 -0300 Subject: [Linux] JavaFX is displaying unicode characters incorrectly Message-ID: Hi, This possible bug is reported here: https://bugs.openjdk.org/browse/JDK-8322251 Running the code bellow produces incorrect text on Ubuntu 24.04 (still not released). I would like to fix it, but some hints would be appreciated. I might be missing a font, but the same text render fine on GTK based applications. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.TextArea; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class TextAreaSample extends Application { @Override public void start(Stage primaryStage) { TextArea textArea = new TextArea(); textArea.setText("?????"); StackPane root = new StackPane(); root.getChildren().add(textArea); Scene scene = new Scene(root, 300, 200); primaryStage.setTitle("Test"); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(TextAreaSample.class, args); } } Ubuntu 22.04 [image: image.png] Ubuntu 24.04 (nightly build): [image: image.png] -- Thiago import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.TextArea; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class TextAreaSample extends Application { @Override public void start(Stage primaryStage) { TextArea textArea = new TextArea(); textArea.setText("?????"); StackPane root = new StackPane(); root.getChildren().add(textArea); Scene scene = new Scene(root, 300, 200); primaryStage.setTitle("Test"); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(TextAreaSample.class, args); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 6227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3682 bytes Desc: not available URL: From jpereda at openjdk.org Thu Feb 22 10:56:06 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 22 Feb 2024 10:56:06 GMT Subject: [jfx21u] RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView Message-ID: Hi all, This pull request contains a clean backport of commit [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Jose Pereda on 21 Dec 2023 and was reviewed by Andy Goryachev. Thanks! ------------- Commit messages: - Backport ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd Changes: https://git.openjdk.org/jfx21u/pull/44/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=44&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321970 Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/44.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/44/head:pull/44 PR: https://git.openjdk.org/jfx21u/pull/44 From aghaisas at openjdk.org Thu Feb 22 11:05:01 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 22 Feb 2024 11:05:01 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 The fix looks good. Verified on macOS 14.3. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/687#pullrequestreview-1895559966 From daniel.peintner at gmail.com Thu Feb 22 11:07:35 2024 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Thu, 22 Feb 2024 12:07:35 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: Hi Andy, others, I highly appreciate and welcome the effort of a built-in RichTextArea ?. A question that popped up in my mind is whether this work might include work in the area of *rich* TextField also? Probably it is out of scope. Anyhow, JavaFX Textfields are used in even more areas in UI controls like in tables etc and having the possibility to style them would be similarly convincing. As you might know, some alternative *external* solutions like RichTextFX do provide next to StyleClassedTextArea also StyleClassedTextField. Anyway, thank you very very much for the continuous development. Sincerely, -- Daniel P.S: Maybe just one line about the use case I have in mind. We do offer (based on RichTextFX) the ability to do "spell checking" on text (like you know from all word processors). A red underline shows a possible mistake and a ContextMenu offers fixes. This red line is therefore needed for text in TextArea but also for text in TextField On Wed, Feb 21, 2024 at 7:07?PM Andy Goryachev wrote: > Dear JavaFX developers: > > > > We would like to propose a new feature - rich text control, RichTextArea, > intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane. The main design goal is to provide a control > that is complete enough to be useful out-of-the box, as well as open to > extension by the application developers. > > > > This is a complex feature with a large API surface that would be nearly > impossible to get right the first time, even after an extensive review. We > are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*. This will allow us to evolve the API in > future releases without the strict compatibility constraints that other > JavaFX modules have. > > > > Please take a look at the proposal [0], a list of discussion points [1], > and the API Specification (javadoc) [2]. While the proposed API is ready > for review, it isn't complete nor set in stone. We are looking for > feedback, and will update the proposal based on the suggestions we receive > from the community. We encourage you to comment either in the mailing > list, or by leaving comments inline in a draft pull request [3]. For > context, the links to the original RFE [4] and a list of missing APIs > related to rich text [5] are provided below. > > > > Sincerely, > > Your friendly JavaFX development team. > > > > > > References > > > > > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Feb 22 13:18:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 13:18:11 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 Confirmed. A CSR is no longer needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1959434563 From kcr at openjdk.org Thu Feb 22 14:29:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 14:29:59 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v4] In-Reply-To: References: Message-ID: On Tue, 20 Feb 2024 12:16:12 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes and add touch mask to gdk pointer grab function Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1895996832 From kcr at openjdk.org Thu Feb 22 14:33:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 14:33:03 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl wrote: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest Hmm. There was a reason we added a return value to `_enterNestedEventLoop`, but I'll take a closer look. Have you run all of the headful tests? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1959569754 From kcr at openjdk.org Thu Feb 22 14:37:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 14:37:01 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl wrote: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest @Maran23 Please merge in the latest upstream master, since your branch is out of date. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1959579953 From kcr at openjdk.org Thu Feb 22 14:41:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 14:41:03 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <1Lw8652hR6vQb3RYJJDxx301dNzWuONCxyLKUPf5puc=.146f1675-a14f-4fa7-8186-6e3de509ea14@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> <1Lw8652hR6vQb3RYJJDxx301dNzWuONCxyLKUPf5puc=.146f1675-a14f-4fa7-8186-6e3de509ea14@github.com> Message-ID: On Mon, 19 Feb 2024 11:45:04 GMT, Thiago Milczarek Sayao wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add compile-time checks to GdkSeat > > The rationale was: > > This tells which events get delivered to the window while grabbing. XWayland might be sensitive to `GDK_TOUCH_MASK` while Xorg is not. > > So the Idea was to keep the current way (with `gdk_pointer_grab` or `gdk_device_grab`, and adding the "deliver TOUCH events to me" might fix it. > > Another place to investigate is: > > > #define GDK_FILTERED_EVENTS_MASK static_cast(GDK_ALL_EVENTS_MASK \ > & ~GDK_TOUCH_MASK) > > > > It seems that Xorg converts touch events to regular mouse events, but XWayland might be different. @tsayao can you re-review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1959590000 From mfox at openjdk.org Thu Feb 22 14:55:06 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 22 Feb 2024 14:55:06 GMT Subject: Integrated: 8278021: Fix warnings in macOS glass native code and treat warnings as errors 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: On Wed, 1 Dec 2021 17:44:21 GMT, Martin Fox wrote: > Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. > > The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. This pull request has now been integrated. Changeset: e0b88bc7 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/e0b88bc7cfede46afe28cbb4a2e333df933b5100 Stats: 59 lines in 17 files changed: 39 ins; 5 del; 15 mod 8278021: Fix warnings in macOS glass native code and treat warnings as errors Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/687 From kcr at openjdk.org Thu Feb 22 15:45:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 15:45:00 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: <9x8PGA0wn8L14QQ3KvjutTcXVZRnQs3p4H3Radbthh8=.973c17d5-a2a9-4460-a52b-bbedbd70ecb2@github.com> On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl wrote: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest As I was afraid of, this change causes many test failures (see below for just one example). I think a different approach is needed, one that preserves the synchronous nature of these methods. NestedEventLoopTest > testCanEnterAndExitNestedEventLoop FAILED java.lang.AssertionError at org.junit.Assert.fail(Assert.java:87) at org.junit.Assert.assertTrue(Assert.java:42) at org.junit.Assert.assertFalse(Assert.java:65) at org.junit.Assert.assertFalse(Assert.java:75) at test.javafx.stage.NestedEventLoopTest.lambda$testCanEnterAndExitNestedEventLoop$2(NestedEventLoopTest.java:120) at test.util.Util.lambda$submit$0(Util.java:108) at javafx.graphics at 23-ea/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:456) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics at 23-ea/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:455) at javafx.graphics at 23-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at javafx.graphics at 23-ea/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native Method) at javafx.graphics at 23-ea/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(MacApplication.java:169) at javafx.graphics at 23-ea/com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:512) at javafx.graphics at 23-ea/com.sun.glass.ui.EventLoop.enter(EventLoop.java:107) at javafx.graphics at 23-ea/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:656) at javafx.graphics at 23-ea/javafx.application.Platform.enterNestedEventLoop(Platform.java:310) at test.javafx.stage.NestedEventLoopTest.lambda$testCanEnterAndExitNestedEventLoop$0(NestedEventLoopTest.java:112) @Maran23 I see from the description that you tested this on mac. How did you test it? Did you run with `-PFULL_TEST=true`? ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1324#pullrequestreview-1896186878 PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1959717323 From andy.goryachev at oracle.com Thu Feb 22 16:29:22 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 22 Feb 2024 16:29:22 +0000 Subject: [External] : Re: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: Dear Daniel: Thank you for your kind words! Re: StyledTextArea/TextField. This is a very interesting question. It is definitely out of scope right now, but we can certainly talk about it. One major difference between the new control and the regular TextField/TextArea is that we add a separate rich text model, while TextField/Area expose a String 'text' property. We could think of using the same model, or constructing some kind of StyledDocument, but in any case it won't be a drop-in replacement for TextField/TextArea. The other aspect is the visuals. Whereas a StyledTextArea might require the same kinds of surrounding toolbars and controls to function as a useable editor (font, style, color, etc.), how would a StyledTextField look? At the same time, it is possible to easily configure RichTextArea to look like a styled text area or one-line styled text field. It is also possible that another use case exists which requires a dedicated control? Re: spell checker. Yes, there is a way to add a "squiggly line", see here: https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md#creating-a-paragraph At this moment, this functionality is not a part of any standard model, but is certainly possible. It might be also possible to add a similar functionality to the regular TextField/TextArea using public APIs, simply by adding a "squiggly" line shape over the standard control. Just a thought. What do you think? -andy From: Daniel Peintner Date: Thursday, February 22, 2024 at 03:07 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: RichTextArea Control (Incubator) Hi Andy, others, I highly appreciate and welcome the effort of a built-in RichTextArea ?. A question that popped up in my mind is whether this work might include work in the area of *rich* TextField also? Probably it is out of scope. Anyhow, JavaFX Textfields are used in even more areas in UI controls like in tables etc and having the possibility to style them would be similarly convincing. As you might know, some alternative *external* solutions like RichTextFX do provide next to StyleClassedTextArea also StyleClassedTextField. Anyway, thank you very very much for the continuous development. Sincerely, -- Daniel P.S: Maybe just one line about the use case I have in mind. We do offer (based on RichTextFX) the ability to do "spell checking" on text (like you know from all word processors). A red underline shows a possible mistake and a ContextMenu offers fixes. This red line is therefore needed for text in TextArea but also for text in TextField On Wed, Feb 21, 2024 at 7:07?PM Andy Goryachev > wrote: Dear JavaFX developers: We would like to propose a new feature - rich text control, RichTextArea, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, javafx.incubator.richtext. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. For context, the links to the original RFE [4] and a list of missing APIs related to rich text [5] are provided below. Sincerely, Your friendly JavaFX development team. References [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md [2] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1374 [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 [5] Missing APIs related to rich text control: https://bugs.openjdk.org/browse/JDK-8300569 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Thu Feb 22 20:46:40 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 20:46:40 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation Message-ID: Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. ------------- Commit messages: - Whitespace - Initial commit Changes: https://git.openjdk.org/jfx/pull/1378/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314147 Stats: 637 lines in 41 files changed: 525 ins; 17 del; 95 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From nlisker at openjdk.org Thu Feb 22 20:46:40 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 20:46:40 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation In-Reply-To: References: Message-ID: <4lALJ3bsLy5IcLYoxkKC3MjgwdJZSAgYLy6KOL8GJjQ=.dd28ec28-b135-41bd-aabe-b3cd241f3a21@github.com> On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker wrote: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. @kevinrushforth Please review this. Perhaps the second reviewer can be @jayathirthrao or @arapte. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1960282365 From angorya at openjdk.org Thu Feb 22 20:51:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Feb 2024 20:51:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker wrote: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/color and map/map.png line 1: > (failed to retrieve contents of file, check the PR for context) Is this a licensed image? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1499917718 From philip.race at oracle.com Thu Feb 22 21:08:38 2024 From: philip.race at oracle.com (Philip Race) Date: Thu, 22 Feb 2024 13:08:38 -0800 Subject: Proposal: JavaFX Incubator Modules In-Reply-To: <9607cefb-9d61-401e-983a-33a4ab00f729@oracle.com> References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com> <9607cefb-9d61-401e-983a-33a4ab00f729@oracle.com> Message-ID: <6118f676-c3d4-47f3-969a-d0516c36b126@oracle.com> W.r.t to (3) perhaps we could include in the write up an expectation that continued incubation implies continued updates. Meaning if there are no updates in a release then that either means it is ready to be final next time round, or that the author is no longer actively pursuing it and this should inform the Project Lead as to what action should be taken next. -phil. On 2/21/24 1:55 PM, Kevin Rushforth wrote: > These are all good points. > > 1. I agree. This seems like a good idea for all the reasons you mention. > > 2. I'll add the additional information. And I like your suggestion to > require a JEP (*) to either drop or finalize an incubating feature. > > 3. Yes, I was deliberately vague on what constitutes a reasonable > amount of time. Given that we are changing the default to > "re-incubate" it does make sense to have a "soft timeout" so > incubating features don't incubate forever without an intentional > action to keep them alive. > > I'll update the proposal accordingly. > > Thanks. > > -- Kevin > > (*) We don't exactly follow the JEP process as described in JEP 2, but > for larger features we expect a proposal that touches on the important > points in a JEP-like document and is discussed on the mailing list. > That's what we mean when we say "needs a JEP". > > > On 2/21/2024 9:47 AM, Philip Race wrote: >> 1) The first thing that jumps out at me is the namespace : >> javafx.incubator >> >> The JDK's JEP 11 says "An incubator module is identified by >> the|jdk.incubator.|prefix in its module name" >> It says the same about the packages inside the module. >> "An incubating API is identified by the|jdk.incubator.|prefix in its >> exported package names". >> >> This is to avoid using the standard namespace prefixes for JDK of >> java. and javax. used for final APIs/modules. >> >> So similarly I think JavaFX incubators should avoid the javafx. >> prefix and I suggest "jfx." be used instead. >> This closely mirrors the "jdk." used in JEP 11, taking "java" out of >> the prefix and making it entirely an acronym, >> for both module and package names. >> The pain of updating your code when the API goes final can be eased >> by IDEs and is something you would >> need to do anyway because "incubator" is in all the names in either case. >> >> 2) The second thing is you don't say what the steps are to promote >> the incubating module to final. >> JEP 11 says a new JEP is needed for that, but it also says a new JEP >> is needed to re-incubate >> which is something JavaFX will not require. >> So do you expect it will be a new JEP for that ? >> I think that would be best to do that as the JEP to propose the >> incubator could be several years old and stale by then. >> You also don't say what it takes to drop it. >> >> So how about the basic process is that the first JEP simply proposes >> the incubating module, once >> it is in as you say it evolves by normal RFEs across releases ? >> Then when it is EITHER ready to go final OR be removed, a new JEP >> must be proposed for that. >> A removal JEP should generally be quite short :-) >> >> So I suggest to add a sentence along those lines to the proposal. >> "To either make the API of an incubating module final, or to remove >> it, then a new JEP should be submitted, >> referencing the incubator JEP". >> >> 3) The "reasonably small number of JavaFX releases" is I am sure >> intentionally vague, but perhaps >> we could say >> (1) Incubators which span beyond a 24 month period and are not yet >> ready will need >> a simple public approval from the project lead to remain for some >> additiional period at the discretion >> of the Project Lead by adding a simple comment in the JEP, otherwise >> the Project Lead will submit a removal JEP and >> (2) the submitter of the JEP can propose to remove it at any time. >> >> -phil. >> >> On 2/21/24 9:37 AM, Kevin Rushforth wrote: >>> JEP 11 [1] defines a process for delivering non-final JDK APIs in >>> incubator modules. >>> >>> Similarly, some JavaFX APIs would benefit from spending a period of >>> time in a JavaFX release prior to being deemed stable. I propose >>> JavaFX incubator modules as a means of putting non-final API in the >>> hands of developers, while the API progresses towards either >>> finalization or removal in a future release. This is especially >>> useful for complex features with a large API surface. >>> >>> The JavaFX proposal is largely the same as the JDK one, but has some >>> important differences. >>> >>> Please take a look at the preliminary proposal [2]. I have also >>> created a Draft PR [3], for illustrative purposes only, to show how >>> this might work. >>> >>> Please reply to this message with any feedback. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> [1] https://openjdk.org/jeps/11 >>> [2] >>> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md >>> [3] https://github.com/openjdk/jfx/pull/1375 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Thu Feb 22 22:17:27 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:17:27 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/b744540c..34bbc561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From kcr at openjdk.org Thu Feb 22 22:17:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 22:17:27 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker wrote: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. @lukostyra would be another good reviewer of this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1960405983 From nlisker at openjdk.org Thu Feb 22 22:17:27 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:17:27 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 20:49:20 GMT, Andy Goryachev wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/color and map/map.png line 1: > >> (failed to retrieve contents of file, check the PR for context) > Is this a licensed image? No, it's a standard in image processing: https://en.wikipedia.org/wiki/Lenna. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1499994625 From kcr at openjdk.org Thu Feb 22 22:17:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 22:17:27 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:10:35 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/color and map/map.png line 1: >> >>> (failed to retrieve contents of file, check the PR for context) >> Is this a licensed image? > > No, it's a standard in image processing: https://en.wikipedia.org/wiki/Lenna. But it's still third-party content and cannot go in without approval. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1499996926 From nlisker at openjdk.org Thu Feb 22 22:23:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:23:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:13:33 GMT, Kevin Rushforth wrote: >> No, it's a standard in image processing: https://en.wikipedia.org/wiki/Lenna. > > But it's still third-party content and cannot go in without approval. What would an approval require? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500002472 From kcr at openjdk.org Thu Feb 22 22:23:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 22:23:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:19:27 GMT, Nir Lisker wrote: >> But it's still third-party content and cannot go in without approval. > > What would an approval require? To add to this, such approval would be unlikely, and I am not in favor of making the request. Perhaps you can find suitable images already in the repo? Here is one that might work: https://github.com/openjdk/jfx/tree/e0b88bc7cfede46afe28cbb4a2e333df933b5100/apps/toys/FX8-3DFeatures/src/resources ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500009761 From angorya at openjdk.org Thu Feb 22 22:23:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Feb 2024 22:23:58 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:17:27 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 848: > 846: + ", specularPower=" + getSpecularPower() + ", diffuseMap=" + getDiffuseMap() + ", specularMap=" > 847: + getSpecularMap() + ", bumpMap=" + getBumpMap() + ", selfIlluminationMap=" + getSelfIlluminationMap() > 848: + "]"; could we restore the formatting please? also, the first `+` is unnecessary ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500000870 From nlisker at openjdk.org Thu Feb 22 22:23:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:23:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:18:38 GMT, Andy Goryachev wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 848: > >> 846: + ", specularPower=" + getSpecularPower() + ", diffuseMap=" + getDiffuseMap() + ", specularMap=" >> 847: + getSpecularMap() + ", bumpMap=" + getBumpMap() + ", selfIlluminationMap=" + getSelfIlluminationMap() >> 848: + "]"; > > could we restore the formatting please? > also, the first `+` is unnecessary Weird, I specifically reverted the auto-formatting, not sure how it got in. Will revert. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500007027 From nlisker at openjdk.org Thu Feb 22 22:28:40 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:28:40 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Revert unintended formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/34bbc561..0130d0f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=01-02 Stats: 53 lines in 1 file changed: 4 ins; 0 del; 49 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From kevin.rushforth at oracle.com Thu Feb 22 22:32:24 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 22 Feb 2024 14:32:24 -0800 Subject: Proposal: JavaFX Incubator Modules In-Reply-To: <6118f676-c3d4-47f3-969a-d0516c36b126@oracle.com> References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com> <9607cefb-9d61-401e-983a-33a4ab00f729@oracle.com> <6118f676-c3d4-47f3-969a-d0516c36b126@oracle.com> Message-ID: <2628f36b-abec-4114-85e5-12c9a0fec7b3@oracle.com> Something like this might be reasonable as long as we also add "and hasn't been modified in the current release". I could easily image the case where an incubating feature goes into, say JavaFX 26 in March, and by the time feedback comes in that prompts a change in the API, it's July or August already, meaning that any changes will go into JavaFX 28. The time between when a feature first released (in a GA release) and the feature freeze for the next release is only a little over 3 months (which is why most features will incubate for at least two releases). -- Kevin On 2/22/2024 1:08 PM, Philip Race wrote: > W.r.t to (3) perhaps we could include in the write up an expectation > that continued incubation implies continued updates. > Meaning if there are no updates in a release then that either means it > is ready to be final next time round, or that the > author is no longer actively pursuing it and this should inform the > Project Lead as to what action should be taken next. > > -phil. > > On 2/21/24 1:55 PM, Kevin Rushforth wrote: >> These are all good points. >> >> 1. I agree. This seems like a good idea for all the reasons you mention. >> >> 2. I'll add the additional information. And I like your suggestion to >> require a JEP (*) to either drop or finalize an incubating feature. >> >> 3. Yes, I was deliberately vague on what constitutes a reasonable >> amount of time. Given that we are changing the default to >> "re-incubate" it does make sense to have a "soft timeout" so >> incubating features don't incubate forever without an intentional >> action to keep them alive. >> >> I'll update the proposal accordingly. >> >> Thanks. >> >> -- Kevin >> >> (*) We don't exactly follow the JEP process as described in JEP 2, >> but for larger features we expect a proposal that touches on the >> important points in a JEP-like document and is discussed on the >> mailing list. That's what we mean when we say "needs a JEP". >> >> >> On 2/21/2024 9:47 AM, Philip Race wrote: >>> 1) The first thing that jumps out at me is the namespace : >>> javafx.incubator >>> >>> The JDK's JEP 11 says "An incubator module is identified by >>> the|jdk.incubator.|prefix in its module name" >>> It says the same about the packages inside the module. >>> "An incubating API is identified by the|jdk.incubator.|prefix in its >>> exported package names". >>> >>> This is to avoid using the standard namespace prefixes for JDK of >>> java. and javax. used for final APIs/modules. >>> >>> So similarly I think JavaFX incubators should avoid the javafx. >>> prefix and I suggest "jfx." be used instead. >>> This closely mirrors the "jdk." used in JEP 11, taking "java" out of >>> the prefix and making it entirely an acronym, >>> for both module and package names. >>> The pain of updating your code when the API goes final can be eased >>> by IDEs and is something you would >>> need to do anyway because "incubator" is in all the names in either >>> case. >>> >>> 2) The second thing is you don't say what the steps are to promote >>> the incubating module to final. >>> JEP 11 says a new JEP is needed for that, but it also says a new JEP >>> is needed to re-incubate >>> which is something JavaFX will not require. >>> So do you expect it will be a new JEP for that ? >>> I think that would be best to do that as the JEP to propose the >>> incubator could be several years old and stale by then. >>> You also don't say what it takes to drop it. >>> >>> So how about the basic process is that the first JEP simply proposes >>> the incubating module, once >>> it is in as you say it evolves by normal RFEs across releases ? >>> Then when it is EITHER ready to go final OR be removed, a new JEP >>> must be proposed for that. >>> A removal JEP should generally be quite short :-) >>> >>> So I suggest to add a sentence along those lines to the proposal. >>> "To either make the API of an incubating module final, or to remove >>> it, then a new JEP should be submitted, >>> referencing the incubator JEP". >>> >>> 3) The "reasonably small number of JavaFX releases" is I am sure >>> intentionally vague, but perhaps >>> we could say >>> (1) Incubators which span beyond a 24 month period and are not yet >>> ready will need >>> a simple public approval from the project lead to remain for some >>> additiional period at the discretion >>> of the Project Lead by adding a simple comment in the JEP, otherwise >>> the Project Lead will submit a removal JEP and >>> (2) the submitter of the JEP can propose to remove it at any time. >>> >>> -phil. >>> >>> On 2/21/24 9:37 AM, Kevin Rushforth wrote: >>>> JEP 11 [1] defines a process for delivering non-final JDK APIs in >>>> incubator modules. >>>> >>>> Similarly, some JavaFX APIs would benefit from spending a period of >>>> time in a JavaFX release prior to being deemed stable. I propose >>>> JavaFX incubator modules as a means of putting non-final API in the >>>> hands of developers, while the API progresses towards either >>>> finalization or removal in a future release. This is especially >>>> useful for complex features with a large API surface. >>>> >>>> The JavaFX proposal is largely the same as the JDK one, but has >>>> some important differences. >>>> >>>> Please take a look at the preliminary proposal [2]. I have also >>>> created a Draft PR [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 nlisker at openjdk.org Thu Feb 22 22:34:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:34:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:21:49 GMT, Kevin Rushforth wrote: >> What would an approval require? > > To add to this, such approval would be unlikely, and I am not in favor of making the request. Perhaps you can find suitable images already in the repo? Here is one that might work: > > https://github.com/openjdk/jfx/tree/e0b88bc7cfede46afe28cbb4a2e333df933b5100/apps/toys/FX8-3DFeatures/src/resources Do I only need to switch the ones in the introduction that show the multiplication of the color and the map, or all of the new images that use it as a background? The latter will be a lot of work. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500019932 From kcr at openjdk.org Thu Feb 22 22:38:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 22:38:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:31:59 GMT, Nir Lisker wrote: >> To add to this, such approval would be unlikely, and I am not in favor of making the request. Perhaps you can find suitable images already in the repo? Here is one that might work: >> >> https://github.com/openjdk/jfx/tree/e0b88bc7cfede46afe28cbb4a2e333df933b5100/apps/toys/FX8-3DFeatures/src/resources > > Do I only need to switch the ones in the introduction that show the multiplication of the color and the map, or all of the new images that use it as a background? The latter will be a lot of work. All of them, since they were derived from the original. I can still tell what the source is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500023069 From nlisker at openjdk.org Thu Feb 22 22:46:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:46:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:36:06 GMT, Kevin Rushforth wrote: >> Do I only need to switch the ones in the introduction that show the multiplication of the color and the map, or all of the new images that use it as a background? The latter will be a lot of work. > > All of them, since they were derived from the original. I can still tell what the source is. OK, it will be after the weekend when I can come back to this. Reviewers can assume that only the background will change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500026555 From angorya at openjdk.org Thu Feb 22 22:46:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Feb 2024 22:46:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:40:59 GMT, Nir Lisker wrote: >> All of them, since they were derived from the original. I can still tell what the source is. > > OK, it will be after the weekend when I can come back to this. Reviewers can assume that only the background will change. sorry, Nir. ;-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500027550 From nlisker at openjdk.org Thu Feb 22 22:46:58 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:46:58 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:20:56 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 848: >> >>> 846: + ", specularPower=" + getSpecularPower() + ", diffuseMap=" + getDiffuseMap() + ", specularMap=" >>> 847: + getSpecularMap() + ", bumpMap=" + getBumpMap() + ", selfIlluminationMap=" + getSelfIlluminationMap() >>> 848: + "]"; >> >> could we restore the formatting please? >> also, the first `+` is unnecessary > > Weird, I specifically reverted the auto-formatting, not sure how it got in. Will revert. > also, the first `+` is unnecessary I think it was done for uniformity with the other properties. I would use a `StringJoiner` these days for such a task anyway. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500028809 From nlisker at openjdk.org Thu Feb 22 22:54:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 22:54:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:42:18 GMT, Andy Goryachev wrote: >> OK, it will be after the weekend when I can come back to this. Reviewers can assume that only the background will change. > > sorry, Nir. ;-) Perhaps the contribution guidelines should mention what resources can be included. In all other open source projects I worked on it was enough that the resource wasn't licensed (or had something like https://en.wikipedia.org/wiki/WTFPL). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500034313 From angorya at openjdk.org Thu Feb 22 22:54:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Feb 2024 22:54:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:44:05 GMT, Nir Lisker wrote: >> Weird, I specifically reverted the auto-formatting, not sure how it got in. Will revert. > >> also, the first `+` is unnecessary > > I think it was done for uniformity with the other properties. I would use a `StringJoiner` these days for such a task anyway. StringJoiner seems to provide little benefit for maps or key=value pairs. Do you know of an alternative? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500032969 From nlisker at openjdk.org Thu Feb 22 23:06:56 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 23:06:56 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 22:50:06 GMT, Andy Goryachev wrote: >>> also, the first `+` is unnecessary >> >> I think it was done for uniformity with the other properties. I would use a `StringJoiner` these days for such a task anyway. > > StringJoiner seems to provide little benefit for maps or key=value pairs. Do you know of an alternative? A `StringJoiner` seems suitable to me in this case: new StringJoiner(",", "PhongMaterial[", "]") .add("diffuseColor=" + getDiffuseColor()) .add("specularPower=" + getSpecularPower()) ... I guess you can make a helper method that takes a property and creates the string for you, like `diffuseColor.getName() + "=" + diffuseColor.getValue()` and then it won't look like a key-value pair in the joiner. You might want to search for the default implementation of records and see how they create the `name = value` representation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500046959 From kcr at openjdk.org Thu Feb 22 23:09:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Feb 2024 23:09:56 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: <7MKmB_tUkA6v0TPI6eI0rLey85RpqNeaQGfp2V2WlSI=.e48b4f14-c0fa-4901-8a4d-c18eb552e32e@github.com> On Thu, 22 Feb 2024 22:51:56 GMT, Nir Lisker wrote: >> sorry, Nir. ;-) > > Perhaps the contribution guidelines should mention what resources can be included. In all other open source projects I worked on it was enough that the resource wasn't licensed (or had something like https://en.wikipedia.org/wiki/WTFPL). The only thing I can point at is the OCA (which is linked in the CONTRIBUTOR guidelines), which states that contributions need to be an original work. So to double-check: Aside from that image (and the ones derived from it), are all the others your original work? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500048531 From mhanl at openjdk.org Thu Feb 22 23:13:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 22 Feb 2024 23:13:26 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: 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 Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/98a97b0a..cb8865e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=00-01 Stats: 294903 lines in 6630 files changed: 173936 ins; 83950 del; 37017 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From nlisker at openjdk.org Thu Feb 22 23:16:58 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 22 Feb 2024 23:16:58 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: <7MKmB_tUkA6v0TPI6eI0rLey85RpqNeaQGfp2V2WlSI=.e48b4f14-c0fa-4901-8a4d-c18eb552e32e@github.com> References: <7MKmB_tUkA6v0TPI6eI0rLey85RpqNeaQGfp2V2WlSI=.e48b4f14-c0fa-4901-8a4d-c18eb552e32e@github.com> Message-ID: On Thu, 22 Feb 2024 23:07:21 GMT, Kevin Rushforth wrote: >> Perhaps the contribution guidelines should mention what resources can be included. In all other open source projects I worked on it was enough that the resource wasn't licensed (or had something like https://en.wikipedia.org/wiki/WTFPL). > > The only thing I can point at is the OCA (which is linked in the CONTRIBUTOR guidelines), which states that contributions need to be an original work. > > So to double-check: Aside from that image (and the ones derived from it), are all the others your original work? Yes, I created the textures in a generator, the schematics I drew myself, and the screenshots are from the 3D Lighting app. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500052213 From angorya at openjdk.org Thu Feb 22 23:16:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Feb 2024 23:16:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:04:50 GMT, Nir Lisker wrote: >> StringJoiner seems to provide little benefit for maps or key=value pairs. Do you know of an alternative? > > A `StringJoiner` seems suitable to me in this case: > > new StringJoiner(",", "PhongMaterial[", "]") > .add("diffuseColor=" + getDiffuseColor()) > .add("specularPower=" + getSpecularPower()) > ... > > I guess you can make a helper method that takes a property and creates the string for you, like `diffuseColor.getName() + "=" + diffuseColor.getValue()` and then it won't look like a key-value pair in the joiner. > > You might want to search for the default implementation of records and see how they create the `name = value` representation. It looks like compiler auto-generates code for records. The last solution is malloc galore: multiple StringBuilders, much worse than the original concatenation. All right, sorry for discussion unrelated to this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500054617 From mhanl at openjdk.org Thu Feb 22 23:21:01 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 22 Feb 2024 23:21:01 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: <9x8PGA0wn8L14QQ3KvjutTcXVZRnQs3p4H3Radbthh8=.973c17d5-a2a9-4460-a52b-bbedbd70ecb2@github.com> References: <9x8PGA0wn8L14QQ3KvjutTcXVZRnQs3p4H3Radbthh8=.973c17d5-a2a9-4460-a52b-bbedbd70ecb2@github.com> Message-ID: On Thu, 22 Feb 2024 15:41:55 GMT, Kevin Rushforth wrote: > @Maran23 I see from the description that you tested this on mac. How did you test it? Did you run with `-PFULL_TEST=true`? No, I checked the example in the ticket as well as the handling of dialogs in general on Mac. Unfortuantely, I always need to ask a colleague to test my JavaFX Builds on Mac, but maybe it's time to setup a VM on my Windows machine. Are there any recommendations I may should follow for the setup? :-) Regarding the system tests, I checked the nested event loop ones on Windows and they work for me. I just pushed a change which may fixes this for Mac as well. The change is also logical and is synchronized with the other changes I made to nested event loops. Will ask my colleague as well to test my changes again + run the most obvious (related) system tests on Mac. I also will do a much bigger testing soon, I have an application that relies heavily on nested event loops for blocking the UI while doing background work. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1960498210 From kcr at openjdk.org Fri Feb 23 00:03:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 00:03:56 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: <7MKmB_tUkA6v0TPI6eI0rLey85RpqNeaQGfp2V2WlSI=.e48b4f14-c0fa-4901-8a4d-c18eb552e32e@github.com> Message-ID: On Thu, 22 Feb 2024 23:11:55 GMT, Nir Lisker wrote: >> The only thing I can point at is the OCA (which is linked in the CONTRIBUTOR guidelines), which states that contributions need to be an original work. >> >> So to double-check: Aside from that image (and the ones derived from it), are all the others your original work? > > Yes, I created the textures in a generator, the schematics I drew myself, and the screenshots are from the 3D Lighting app. Thanks for confirming. I'll review the text of the doc changes tomorrow. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1500083607 From kcr at openjdk.org Fri Feb 23 00:19:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 00:19:57 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: <9x8PGA0wn8L14QQ3KvjutTcXVZRnQs3p4H3Radbthh8=.973c17d5-a2a9-4460-a52b-bbedbd70ecb2@github.com> Message-ID: On Thu, 22 Feb 2024 23:18:46 GMT, Marius Hanl wrote: > maybe it's time to setup a VM on my Windows machine. Are there any recommendations I may should follow for the setup? :-) I don't know of any supported way to run macOS in a VM on a Windows host, but perhaps others will be able to help. > Regarding the system tests, I checked the nested event loop ones on Windows and they work for me. It worked for me on Windows, too (and on Linux in a headful test run). I would want to make sure that we know _why_ they still work on Windows and Linux and fail on Mac, but I only saw the failures on Mac. > I just pushed a change which may fixes this for Mac as well. The change is also logical and is synchronized with the other changes I made to nested event loops. Will ask my colleague as well to test my changes again + run the most obvious (related) system tests on Mac. I can also fire off a headful test run this afternoon, and post results tomorrow. > I also will do a much bigger testing soon, I have an application that relies heavily on nested event loops for blocking the UI while doing background work. The results of that testing would be good information. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1960552062 From duke at openjdk.org Fri Feb 23 01:42:01 2024 From: duke at openjdk.org (duke) Date: Fri, 23 Feb 2024 01:42:01 GMT Subject: Withdrawn: 8313650: Add hasProperties method to MenuItem and Toggle In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 17:06:57 GMT, Andy Goryachev wrote: > 1. Creating a new `javafx.scene.ContainsProperties` interface that declares two methods: > - public ObservableMap getProperties(); > - public boolean hasProperties(); > > 2. Node, MenuItem, and Toggle now extend ContainsProperties interface. > > 3. Making implemented methods in Node, MenuItem, and Toggle final. > > While this change is an improvement from a design point of view, it introduces a larger compatibility risk (by adding 'final' keyword similar to [JDK-8313651](https://bugs.openjdk.org/browse/JDK-8313651)) > > This change requires CSR. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1215 From john.hendrikx at gmail.com Fri Feb 23 01:45:11 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 23 Feb 2024 02:45:11 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Hi, Far be it from me to tell the FX team what it should do, I am still wondering the following: - A 3rd party control, RichTextFX already exists -- what is this new proposal adding that RichTextFX does not have? - What (if anything) is stopping a 3rd party from building a RichTextArea themselves? In other words, I think the FX team ought to focus on **facilitating** the building of complex controls like RichTextArea, by identifying gaps in the current Control API that is **stopping** 3rd parties from doing this themselves in the same integrated manner as a "native" FX control. Enabling thousands or tens of thousand of developers to build more complicated controls seems to me like a much better investment than what I think will be a significant investment in one of the most complex controls imaginable.? RichTextFX was actively developed over a 4 year period, with 45 contributors and over 1400 commits (for comparison, JavaFX had 250 commits in the past year).? If it will be significantly less complicated, then what does it offer over RichTextFX? --John On 21/02/2024 19:07, Andy Goryachev wrote: > > Dear JavaFX developers: > > We would like to propose a new feature - rich text control, > RichTextArea, intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane.? The main design goal is to provide a > control that is complete enough to be useful out-of-the box, as well > as open to extension by the application developers. > > This is a complex feature with a large API surface that would be > nearly impossible to get right the first time, even after an extensive > review.? We are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*. This will allow us to evolve the API in > future releases without the strict compatibility constraints that > other JavaFX modules have. > > Please take a look at the proposal [0], a list of discussion points > [1], and the API Specification (javadoc) [2]. While the proposed API > is ready for review, it isn't complete nor set in stone. We are > looking for feedback, and will update the proposal based on the > suggestions we receive from the community.? We encourage you to > comment either in the mailing list, or by leaving comments inline in a > draft pull request [3].? For context, the links to the original RFE > [4] and a list of missing APIs related to rich text [5] are provided > below. > > Sincerely, > > Your friendly JavaFX development team. > > References > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Fri Feb 23 04:42:57 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 22 Feb 2024 23:42:57 -0500 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> References: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Message-ID: I'm speaking from ignorance, but in the same way that java 2d lets you do image reading and writing with great tools to implement it, but it also provides defaults for png, gif, jpeg, etc. A good foundation to build your own is critical. But it does not obviate the need for a useful default. On Thu, Feb 22, 2024, 8:46?PM John Hendrikx wrote: > Hi, > > Far be it from me to tell the FX team what it should do, I am still > wondering the following: > > - A 3rd party control, RichTextFX already exists -- what is this new > proposal adding that RichTextFX does not have? > - What (if anything) is stopping a 3rd party from building a RichTextArea > themselves? > > In other words, I think the FX team ought to focus on **facilitating** the > building of complex controls like RichTextArea, by identifying gaps in the > current Control API that is **stopping** 3rd parties from doing this > themselves in the same integrated manner as a "native" FX control. > > Enabling thousands or tens of thousand of developers to build more > complicated controls seems to me like a much better investment than what I > think will be a significant investment in one of the most complex controls > imaginable. RichTextFX was actively developed over a 4 year period, with > 45 contributors and over 1400 commits (for comparison, JavaFX had 250 > commits in the past year). If it will be significantly less complicated, > then what does it offer over RichTextFX? > > --John > On 21/02/2024 19:07, Andy Goryachev wrote: > > Dear JavaFX developers: > > > > We would like to propose a new feature - rich text control, RichTextArea, > intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane. The main design goal is to provide a control > that is complete enough to be useful out-of-the box, as well as open to > extension by the application developers. > > > > This is a complex feature with a large API surface that would be nearly > impossible to get right the first time, even after an extensive review. We > are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*. This will allow us to evolve the API in > future releases without the strict compatibility constraints that other > JavaFX modules have. > > > > Please take a look at the proposal [0], a list of discussion points [1], > and the API Specification (javadoc) [2]. While the proposed API is ready > for review, it isn't complete nor set in stone. We are looking for > feedback, and will update the proposal based on the suggestions we receive > from the community. We encourage you to comment either in the mailing > list, or by leaving comments inline in a draft pull request [3]. For > context, the links to the original RFE [4] and a list of missing APIs > related to rich text [5] are provided below. > > > > Sincerely, > > Your friendly JavaFX development team. > > > > > > References > > > > > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Fri Feb 23 07:13:08 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 23 Feb 2024 08:13:08 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: <803b0898-51f0-4b05-b4c4-7d30c9177f84@xpipe.io> Hey Andy and others, from my perspective as an application developer, I would look for providing an abstract but robust implementation that would allow anyone to implement such a concrete rich text field without any roadblocks. Maybe even going as far as going for a more abstract implementation than text areas. I.e. allowing you to define any kind of data model class which can be flexibly represented by a set of compound nodes and controls and can update and reflect the model state dynamically. I think that way you would also get a few more people on board who are not currently longing for a rich text area because they are either satisfied with the existing solutions or their applications that they typically work with do not use them. If such a work effort could benefit more areas of JavaFX than just rich text editing, people would be happy to jump on board. Instead of creating a RichParagraph.Builder, why not create a more generic CompoundControlSegment.Builder, CompoundControl.Builder, CompoundControl, etc.? I.e. being able to easily add arbitrary nodes and controls in segments/lines, also allowing for an easy way to set style classes and inline styles. Being able to bind each node's contents to part of the data model, having some undo/redo functionality for this model. The StyledAttribute and StyleHandlerRegistry concept can also be applied to more than just text areas. And also the idea of the ConfigurationParameters to allow for an easy but custom handling of other things such as scrollbars for the resulting compound control. This would allow developers to use these same principles for other implementations as well, for example creating forms. And I can definitely find some use for such a concept in other places far away from text areas as well. The proposed actual rich text area can then still be included as a concrete implementation of this absraction. Best Christopher Schnick On 21/02/2024 19:07, Andy Goryachev wrote: > > Dear JavaFX developers: > > We would like to propose a new feature - rich text control, > RichTextArea, intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane.? The main design goal is to provide a > control that is complete enough to be useful out-of-the box, as well > as open to extension by the application developers. > > This is a complex feature with a large API surface that would be > nearly impossible to get right the first time, even after an extensive > review.? We are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*.?? This will allow us to evolve the API in > future releases without the strict compatibility constraints that > other JavaFX modules have. > > Please take a look at the proposal [0], a list of discussion points > [1], and the API Specification (javadoc) [2]. While the proposed API > is ready for review, it isn't complete nor set in stone. We are > looking for feedback, and will update the proposal based on the > suggestions we receive from the community.? We encourage you to > comment either in the mailing list, or by leaving comments inline in a > draft pull request [3].? For context, the links to the original RFE > [4] and a list of missing APIs related to rich text [5] are provided > below. > > Sincerely, > > Your friendly JavaFX development team. > > References > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Fri Feb 23 08:31:01 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 23 Feb 2024 08:31:01 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11] In-Reply-To: References: <07SKXfZlDvfvi2N9R-k__hxrFqS9EiL574C8yVNruQs=.4af16ef2-2a14-4a41-9501-bba7beb862a7@github.com> Message-ID: On Thu, 22 Feb 2024 10:33:38 GMT, Karthik P K wrote: >> A valid concern about specific fonts, similar to >> https://github.com/openjdk/jfx/pull/1236#issuecomment-1937022815 >> >> What was the resolution there? To use a hard-coded font based on the platform, or pick an available one from the list? > > The tests passes on Mac and Linux. The failures I mentioned above were because this branch was not upto date with the master and completely unrelated to this PR. > Im facing some issue with my Windows system. I will check in windows once it is sorted and update the details here. I have run the tests in Windows and did not see any failures. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1500338714 From daniel.peintner at gmail.com Fri Feb 23 08:39:58 2024 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 23 Feb 2024 09:39:58 +0100 Subject: [External] : Re: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: Dear Andy, others, Thank you for your feedback. Yes, having a one-line TextArea, mocking up a TextField, that contains a longer text with some sub-strings being able to style is enough for my use-case. Anyhow, I agree with others that having the possibility to "style" parts of other controls like Label, TextField, etc would be very astonishing. This might introduce a lot of complexity, I guess. Having said that, this would offer a unique selling point and go beyond what other external libraries did. Anyhow, this would most probably facilitate such work in the future. Best, -- Daniel On Thu, Feb 22, 2024 at 5:29?PM Andy Goryachev wrote: > Dear Daniel: > > > > Thank you for your kind words! > > > > Re: StyledTextArea/TextField. > > > > This is a very interesting question. It is definitely out of scope right > now, but we can certainly talk about it. > > > > One major difference between the new control and the regular > TextField/TextArea is that we add a separate rich text model, while > TextField/Area expose a String 'text' property. We could think of using > the same model, or constructing some kind of StyledDocument, but in any > case it won't be a drop-in replacement for TextField/TextArea. > > > > The other aspect is the visuals. Whereas a StyledTextArea might require > the same kinds of surrounding toolbars and controls to function as a > useable editor (font, style, color, etc.), how would a StyledTextField look? > > > > At the same time, it is possible to easily configure RichTextArea to look > like a styled text area or one-line styled text field. It is also possible > that another use case exists which requires a dedicated control? > > > > > > Re: spell checker. > > > > Yes, there is a way to add a "squiggly line", see here: > > > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md#creating-a-paragraph > > > > At this moment, this functionality is not a part of any standard model, > but is certainly possible. > > > > It might be also possible to add a similar functionality to the regular > TextField/TextArea using public APIs, simply by adding a "squiggly" line > shape over the standard control. Just a thought. > > > > What do you think? > > > > -andy > > > > > > > > *From: *Daniel Peintner > *Date: *Thursday, February 22, 2024 at 03:07 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *[External] : Re: Proposal: RichTextArea Control (Incubator) > > Hi Andy, others, > > > > I highly appreciate and welcome the effort of a built-in RichTextArea ?. > > > > A question that popped up in my mind is whether this work might include > work in the area of *rich* TextField also? Probably it is out of scope. > Anyhow, JavaFX Textfields are used in even more areas in UI controls like > in tables etc and having the possibility to style them would be similarly > convincing. > > > > As you might know, some alternative *external* solutions like RichTextFX > do provide next to StyleClassedTextArea also StyleClassedTextField. > > > > Anyway, thank you very very much for the continuous development. > > > > Sincerely, > > > > -- Daniel > > > > P.S: Maybe just one line about the use case I have in mind. We do offer > (based on RichTextFX) the ability to do "spell checking" on text (like you > know from all word processors). A red underline shows a possible mistake > and a ContextMenu offers fixes. This red line is therefore needed for text > in TextArea but also for text in TextField > > > > > > On Wed, Feb 21, 2024 at 7:07?PM Andy Goryachev > wrote: > > Dear JavaFX developers: > > > > We would like to propose a new feature - rich text control, RichTextArea, > intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane. The main design goal is to provide a control > that is complete enough to be useful out-of-the box, as well as open to > extension by the application developers. > > > > This is a complex feature with a large API surface that would be nearly > impossible to get right the first time, even after an extensive review. We > are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*. This will allow us to evolve the API in > future releases without the strict compatibility constraints that other > JavaFX modules have. > > > > Please take a look at the proposal [0], a list of discussion points [1], > and the API Specification (javadoc) [2]. While the proposed API is ready > for review, it isn't complete nor set in stone. We are looking for > feedback, and will update the proposal based on the suggestions we receive > from the community. We encourage you to comment either in the mailing > list, or by leaving comments inline in a draft pull request [3]. For > context, the links to the original RFE [4] and a list of missing APIs > related to rich text [5] are provided below. > > > > Sincerely, > > Your friendly JavaFX development team. > > > > > > References > > > > > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Fri Feb 23 10:45:59 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 23 Feb 2024 11:45:59 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> References: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Message-ID: I fully agree with John on this. A RichTextArea is something that can "easily" be developed outside OpenJFX . There are a number of examples already, e.g. RichTextFX, and our (Gluon) RichTextArea at https://github.com/gluonhq/rich-text-area In the past, we clearly said that this was not a focus for OpenJFX. There are a huge amount of outstanding issues in JBS that can only be fixed in the OpenJFX "core". Developers (of custom components/controls) rely on the core OpenJFX development to address those issues. That is what this group (the openjfx-dev list) is supposed to do. I highly encourage developers to create custom components and controls, but not as part of OpenJFX. As others noted as well, we have many other things to fix that can only be fixed in OpenJFX, and that is where the priorities of OpenJFX should be, imho. - Johan On Fri, Feb 23, 2024 at 2:48?AM John Hendrikx wrote: > Hi, > > Far be it from me to tell the FX team what it should do, I am still > wondering the following: > > - A 3rd party control, RichTextFX already exists -- what is this new > proposal adding that RichTextFX does not have? > - What (if anything) is stopping a 3rd party from building a RichTextArea > themselves? > > In other words, I think the FX team ought to focus on **facilitating** the > building of complex controls like RichTextArea, by identifying gaps in the > current Control API that is **stopping** 3rd parties from doing this > themselves in the same integrated manner as a "native" FX control. > > Enabling thousands or tens of thousand of developers to build more > complicated controls seems to me like a much better investment than what I > think will be a significant investment in one of the most complex controls > imaginable. RichTextFX was actively developed over a 4 year period, with > 45 contributors and over 1400 commits (for comparison, JavaFX had 250 > commits in the past year). If it will be significantly less complicated, > then what does it offer over RichTextFX? > > --John > On 21/02/2024 19:07, Andy Goryachev wrote: > > Dear JavaFX developers: > > > > We would like to propose a new feature - rich text control, RichTextArea, > intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane. The main design goal is to provide a control > that is complete enough to be useful out-of-the box, as well as open to > extension by the application developers. > > > > This is a complex feature with a large API surface that would be nearly > impossible to get right the first time, even after an extensive review. We > are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*. This will allow us to evolve the API in > future releases without the strict compatibility constraints that other > JavaFX modules have. > > > > Please take a look at the proposal [0], a list of discussion points [1], > and the API Specification (javadoc) [2]. While the proposed API is ready > for review, it isn't complete nor set in stone. We are looking for > feedback, and will update the proposal based on the suggestions we receive > from the community. We encourage you to comment either in the mailing > list, or by leaving comments inline in a draft pull request [3]. For > context, the links to the original RFE [4] and a list of missing APIs > related to rich text [5] are provided below. > > > > Sincerely, > > Your friendly JavaFX development team. > > > > > > References > > > > > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Fri Feb 23 10:47:30 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 23 Feb 2024 11:47:30 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Wed, Feb 21, 2024 at 7:09?PM Andy Goryachev wrote: > Dear JavaFX developers: > ... > Sincerely, > > Your friendly JavaFX development team. > Not sure I understand that signature. I believe everyone on this list is part of the JavaFX development team. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quizynox at gmail.com Fri Feb 23 11:26:42 2024 From: quizynox at gmail.com (mkpaz) Date: Fri, 23 Feb 2024 15:26:42 +0400 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Message-ID: Hello, >> A 3rd party control, RichTextFX already exists -- what is this new proposal adding that RichTextFX does not have? It uses the standard JavaFX VirtualFlow API and and does not need to work with reactive streams. RichtextFX depends on several long unmaintained libs: ReactFX (last commit 8 years ago), WellBehavedFX (last commit 6 years ago), UndoFX (last commit 3 years ago). To say it's actively maintained is a big exaggeration. >> What (if anything) is stopping a 3rd party from building a RichTextArea themselves? - The lack of a standard API. The Behavior API has been discussed for ages, but is still not implemented. Moreover, WellBehavedFX is literally a rejected JEP/CSR implementation. - The closedness of JavaFX in general. All internals are explicitly private and final. A few simple examples. The date picker popup uses a private API to calculate its width based on text size, but you're forbidden to do the same thing. All i18n resources are not exported, you're forbidden to use them to create a context menu. You're not encouraging 3rd party libs, you're going in the opposite direction (for the sake of stability of course). - The JavaFX community is very small. The "tens of thousands of developers" you talk about don't exist. Even famous projects are poorly maintained or not maintained at all, including ControlsFX and ScenicView. You have fewer features -> you have fewer users/market share -> you have less promotion -> you have fewer committers -> you have fewer features. It's that simple. - There's literally no docs about creating new controls. Even Skin API is badly documented. You can only learn from existing control libs. This particular feature would be a HUGE step forward. I'm really glad to see it. Hopefully it won't get buried under a bunch of pointless abstract discussions like the CSS theme CSR. Just get some feedback and implement it the way you want. It's a million times better than doing nothing. On 23/02/2024 14.45, Johan Vos wrote: > I fully agree with John on this. > > A RichTextArea is something that can "easily" be developed outside > OpenJFX . > There are a number of examples already, e.g. RichTextFX, and our > (Gluon) RichTextArea at > https://github.com/gluonhq/rich-text-area > > In the past, we clearly said that this was not a focus for OpenJFX. > > There are a huge amount of outstanding issues in JBS that can only be > fixed in the OpenJFX "core". Developers (of custom > components/controls) rely on the core OpenJFX development to address > those issues. That is what this group (the openjfx-dev list) is > supposed to do. > > I highly encourage developers to create custom components and > controls, but not as part of OpenJFX. As others noted as well, we have > many other things to fix that can only be fixed in OpenJFX, and that > is where the priorities of OpenJFX should be, imho. > > - Johan > > On Fri, Feb 23, 2024 at 2:48?AM John Hendrikx > wrote: > > Hi, > > Far be it from me to tell the FX team what it should do, I am > still wondering the following: > > - A 3rd party control, RichTextFX already exists -- what is this > new proposal adding that RichTextFX does not have? > - What (if anything) is stopping a 3rd party from building a > RichTextArea themselves? > > In other words, I think the FX team ought to focus on > **facilitating** the building of complex controls like > RichTextArea, by identifying gaps in the current Control API that > is **stopping** 3rd parties from doing this themselves in the same > integrated manner as a "native" FX control. > > Enabling thousands or tens of thousand of developers to build more > complicated controls seems to me like a much better investment > than what I think will be a significant investment in one of the > most complex controls imaginable.? RichTextFX was actively > developed over a 4 year period, with 45 contributors and over 1400 > commits (for comparison, JavaFX had 250 commits in the past > year).? If it will be significantly less complicated, then what > does it offer over RichTextFX? > > --John > > On 21/02/2024 19:07, Andy Goryachev wrote: >> >> Dear JavaFX developers: >> >> We would like to propose a new feature - rich text control, >> RichTextArea, intended to bridge the functional gap with Swing >> and its StyledEditorKit/JEditorPane.? The main design goal is to >> provide a control that is complete enough to be useful out-of-the >> box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be >> nearly impossible to get right the first time, even after an >> extensive review.? We are, therefore, introducing this in an >> incubating module, *javafx.incubator.richtext*. This will allow >> us to evolve the API in future releases without the strict >> compatibility constraints that other JavaFX modules have. >> >> Please take a look at the proposal [0], a list of discussion >> points [1], and the API Specification (javadoc) [2]. While the >> proposed API is ready for review, it isn't complete nor set in >> stone. We are looking for feedback, and will update the proposal >> based on the suggestions we receive from the community.? We >> encourage you to comment either in the mailing list, or by >> leaving comments inline in a draft pull request [3].? For >> context, the links to the original RFE [4] and a list of missing >> APIs related to rich text [5] are provided below. >> >> Sincerely, >> >> Your friendly JavaFX development team. >> >> References >> >> [0] Proposal: >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md >> >> [1] Discussion points: >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md >> >> [2] API specification (javadoc): >> https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> >> [3] Draft Pull Request for API comments and feedback: >> https://github.com/openjdk/jfx/pull/1374 >> >> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> >> [5] Missing APIs related to rich text control: >> https://bugs.openjdk.org/browse/JDK-8300569 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Fri Feb 23 12:34:48 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 23 Feb 2024 13:34:48 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Message-ID: Hi, Interesting remarks. > Hello, > > >> A 3rd party control, RichTextFX already exists -- what is this new > proposal adding that RichTextFX does not have? > > It uses the standard JavaFX VirtualFlow API and and does not need to work > with reactive streams. RichtextFX depends on several long unmaintained > libs: ReactFX (last commit 8 years ago), WellBehavedFX (last commit 6 years > ago), UndoFX (last commit 3 years ago). To say it's actively maintained is > a big exaggeration. > What do you think about our Rich Text Area project? https://github.com/gluonhq/rich-text-area I hear your concerns about depending on unmaintained libs, and it is one of my own primary filter criteria to either use or not use software >> What (if anything) is stopping a 3rd party from building a RichTextArea > themselves? > > - The lack of a standard API. The Behavior API has been discussed for > ages, but is still not implemented. Moreover, WellBehavedFX is literally a > rejected JEP/CSR implementation. > I agree a standard behavior API would be helpful, but I don't think it is needed for a third party control. I rather hope to see more third party controls being developed using different approaches, so that the community in general gets more experience with the different approaches, as that would give useful feedback on an approach to standardize it in OpenJFX. You know how it goes with projects in OpenJDK: once something is in, it has to be maintained and supported for a very long time and it is really hard to change it. > - The closedness of JavaFX in general. All internals are explicitly > private and final. A few simple examples. The date picker popup uses a > private API to calculate its width based on text size, but you're forbidden > to do the same thing. All i18n resources are not exported, you're forbidden > to use them to create a context menu. You're not encouraging 3rd party > libs, you're going in the opposite direction (for the sake of stability of > course). > Valid point. And it should be addressed. I wasn't part of the discussions where the decision was to close as much as possible, but I believe the idea was to close almost everything, and then to open API's when needed, after it was clear that opening the API would benefit the ecosystem without giving up stability. This happened a number of times in the past years, but I agree there is still much room for improvements. > - The JavaFX community is very small. The "tens of thousands of > developers" you talk about don't exist. Even famous projects are poorly > maintained or not maintained at all, including ControlsFX and ScenicView. > You have fewer features -> you have fewer users/market share -> you have > less promotion -> you have fewer committers -> you have fewer features. > It's that simple. > I think this is partly true, but it's more nuanced I believe. I am aware of a number of real large JavaFX projects, with many developers working on them. Most of these large projects are developed after closed walls, with lots of duplicated code that could go in a library. For the ecosystem as a whole, that's not good. It would be much better if we were in a situation where individual developers or companies would create and maintain libraries that would then be used in those big projects. For non-technical reasons, this is unfortunately not the case. > - There's literally no docs about creating new controls. Even Skin API is > badly documented. You can only learn from existing control libs. > This is a very valid concern. And I believe it is more important for us (openjfx-dev) to fix this, rather than do everything ourselves in the OpenJFX core. We need to encourage developers to create new controls, and provide more documentation, tutorials etc,... In the early days of JavaFX, there was a big team (it would now be called devrel I guess) that was working on this, helping developers and the ecosystem, but we know what happened next. That gap is not yet filled, and this is the price we are still paying for it. > This particular feature would be a HUGE step forward. I'm really glad to > see it. Hopefully it won't get buried under a bunch of pointless abstract > discussions like the CSS theme CSR. Just get some feedback and implement it > the way you want. It's a million times better than doing nothing. > Well, it's not that we're doing nothing. We are doing a number of things: 1. inside openjfx: keep it working. This should not be underestimated. With the fast and not always logical changes in platforms/OS code, there is lots of code under the hood that needs to be maintained and improved. A number of people on this list are extremely active on this, and spending lots of time on it. Unfortunately, this doesn't make headlines as the result of the hard work is often that "existing things keep working". Apart from keeping it working, I feel we are moving forward and making gradual progress. Over the past year, I saw more people contributing to OpenJFX and to this list, resulting in improvements in specific directions, and I am optimistic about that evolution. 2. outside openjfx: as I said, with Gluon we created this RTA ( https://github.com/gluonhq/rich-text-area). Because people wanted it, and because it would be good to experiment with it, without jeopardizing the OpenJFX stability. As for the pointless abstract discussions: we are somehow linked to the OpenJDK umbrella, where quality is valued much higher than adding hip features, and we try to stick to that principle as well (granted, I wouldn't call things like "tray support" a hip feature, so we are definitely not yet where we need to be). As a consequence, we do have lots of discussions before something gets in. For projects that deliver the foundations to an ecosystem, it is often better to not do something than to do it wrong. I know this is often unpopular, but being on the first row to fix things that were wrong from the beginning, I learned the hard way that this statement makes sense. That is not to say that we should not do anything. On the contrary, I'd love it if we could do more. But in the right place. Stability and basic features inside OpenJFX, experiments and libraries in the ecosystem. - Johan > On 23/02/2024 14.45, Johan Vos wrote: > > I fully agree with John on this. > > A RichTextArea is something that can "easily" be developed outside OpenJFX > . > There are a number of examples already, e.g. RichTextFX, and our (Gluon) > RichTextArea at > https://github.com/gluonhq/rich-text-area > > In the past, we clearly said that this was not a focus for OpenJFX. > > There are a huge amount of outstanding issues in JBS that can only be > fixed in the OpenJFX "core". Developers (of custom components/controls) > rely on the core OpenJFX development to address those issues. That is what > this group (the openjfx-dev list) is supposed to do. > > I highly encourage developers to create custom components and controls, > but not as part of OpenJFX. As others noted as well, we have many other > things to fix that can only be fixed in OpenJFX, and that is where the > priorities of OpenJFX should be, imho. > > - Johan > > On Fri, Feb 23, 2024 at 2:48?AM John Hendrikx > wrote: > >> Hi, >> >> Far be it from me to tell the FX team what it should do, I am still >> wondering the following: >> >> - A 3rd party control, RichTextFX already exists -- what is this new >> proposal adding that RichTextFX does not have? >> - What (if anything) is stopping a 3rd party from building a RichTextArea >> themselves? >> >> In other words, I think the FX team ought to focus on **facilitating** >> the building of complex controls like RichTextArea, by identifying gaps in >> the current Control API that is **stopping** 3rd parties from doing this >> themselves in the same integrated manner as a "native" FX control. >> >> Enabling thousands or tens of thousand of developers to build more >> complicated controls seems to me like a much better investment than what I >> think will be a significant investment in one of the most complex controls >> imaginable. RichTextFX was actively developed over a 4 year period, with >> 45 contributors and over 1400 commits (for comparison, JavaFX had 250 >> commits in the past year). If it will be significantly less complicated, >> then what does it offer over RichTextFX? >> >> --John >> On 21/02/2024 19:07, Andy Goryachev wrote: >> >> Dear JavaFX developers: >> >> >> >> We would like to propose a new feature - rich text control, RichTextArea, >> intended to bridge the functional gap with Swing and its >> StyledEditorKit/JEditorPane. The main design goal is to provide a control >> that is complete enough to be useful out-of-the box, as well as open to >> extension by the application developers. >> >> >> >> This is a complex feature with a large API surface that would be nearly >> impossible to get right the first time, even after an extensive review. We >> are, therefore, introducing this in an incubating module, >> *javafx.incubator.richtext*. This will allow us to evolve the API in >> future releases without the strict compatibility constraints that other >> JavaFX modules have. >> >> >> >> Please take a look at the proposal [0], a list of discussion points [1], >> and the API Specification (javadoc) [2]. While the proposed API is ready >> for review, it isn't complete nor set in stone. We are looking for >> feedback, and will update the proposal based on the suggestions we receive >> from the community. We encourage you to comment either in the mailing >> list, or by leaving comments inline in a draft pull request [3]. For >> context, the links to the original RFE [4] and a list of missing APIs >> related to rich text [5] are provided below. >> >> >> >> Sincerely, >> >> Your friendly JavaFX development team. >> >> >> >> >> >> References >> >> >> >> >> >> [0] Proposal: >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md >> >> [1] Discussion points: >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md >> >> [2] API specification (javadoc): >> https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> >> [3] Draft Pull Request for API comments and feedback: >> https://github.com/openjdk/jfx/pull/1374 >> >> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> >> [5] Missing APIs related to rich text control: >> https://bugs.openjdk.org/browse/JDK-8300569 >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Fri Feb 23 13:14:21 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 23 Feb 2024 13:14:21 +0000 Subject: Proposal: RichTextArea Control (Incubator) Message-ID: Hi, I agree with what others are saying that perhaps creating and adding this control is not a priority now for the JavaFX team. In an ideal world where the JavaFX team had more resources to implement things (like the team JavaFX had at the time of JavaFX 8 and before), this would make sense. Given the limited resources, IMHO time would be perhaps better spent elsewhere, adding much needed features to the core of JavaFX. Things that can only be implemented by the developers working on the SDK. Given this is a control that can be implemented by library developers and given there are already third parties that provide this I don't think creating this should be a priority. Providing more hooks for developers to extend javafx functionality (to counteract the fact that JavaFX is so closed up for extension), implementing missing features in the JavaFX SDK, perhaps even things that would make it easier for library developers to implement a RichTextArea, would IMHO be more of a priority. My 2 cents, 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 martin.desruisseaux at geomatys.com Fri Feb 23 13:31:39 2024 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Fri, 23 Feb 2024 14:31:39 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Message-ID: Le 2024-02-23 ? 13 h 34, Johan Vos a ?crit?: > That is not to say that we should not do anything. On the contrary, > I'd love it if we could do more. But in the right place. Stability and > basic features inside OpenJFX, experiments and libraries in the ecosystem. > JavaFX could have a "basic" Rich Text Area (RTA) for common needs such as syntax coloration, underlining errors, etc., and external projects such as Gluon could have more sophisticated controls for more advanced needs. I would appreciate a lot to have a Rich Text Area included in JavaFX for "basic" needs, because it would avoid adding another dependency. I'm always very reluctant to do the latter, because few projects are economical in their own dependencies. Many projects bring ton of dependencies, often outdated, often conflicting with other projects bringing different versions of the same dependencies. So I do not see a JavaFX RTA and a Gluon RTA as mutually exclusive. I would use the JavaFX one for e.g., syntax coloration, and if I need something more advanced I would look at the alternatives. This is the same situation as other controls such as DatePicker or ColorPicker: they are sufficient for "basic" needs, more elaborated alternatives may exist in other projects. ??? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Feb 23 15:03:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 15:03:03 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: afa206b5 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/afa206b546a580a784d830712be174bb84f09ee9 Stats: 8 lines in 3 files changed: 0 ins; 3 del; 5 mod 8321603: Bump minimum JDK version for JavaFX to JDK 21 Reviewed-by: angorya, jvos, prr ------------- PR: https://git.openjdk.org/jfx/pull/1370 From thiago.sayao at gmail.com Fri Feb 23 15:03:26 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 23 Feb 2024 12:03:26 -0300 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: <8ff2e472-65a8-5dac-f532-dc73a0cc7380@gmail.com> Message-ID: This is a good point, Martin. I would expect the JavaFX RTA to be basic, but extendable - to allow companies to offer commercial options for particular needs based on it. I don't see a single RTA component that would be useful for every need. Use case examples (that I could think of): - An IDE code editor; - A text message writer/viewer that would have emoticons, gifs; - Maybe a collaborative app where multiple users write; -- Thiago Em sex., 23 de fev. de 2024 ?s 10:31, Martin Desruisseaux < martin.desruisseaux at geomatys.com> escreveu: > Le 2024-02-23 ? 13 h 34, Johan Vos a ?crit : > > That is not to say that we should not do anything. On the contrary, I'd > love it if we could do more. But in the right place. Stability and basic > features inside OpenJFX, experiments and libraries in the ecosystem. > > JavaFX could have a "basic" Rich Text Area (RTA) for common needs such as > syntax coloration, underlining errors, etc., and external projects such as > Gluon could have more sophisticated controls for more advanced needs. I > would appreciate a lot to have a Rich Text Area included in JavaFX for > "basic" needs, because it would avoid adding another dependency. I'm always > very reluctant to do the latter, because few projects are economical in > their own dependencies. Many projects bring ton of dependencies, often > outdated, often conflicting with other projects bringing different versions > of the same dependencies. > > So I do not see a JavaFX RTA and a Gluon RTA as mutually exclusive. I > would use the JavaFX one for e.g., syntax coloration, and if I need > something more advanced I would look at the alternatives. This is the same > situation as other controls such as DatePicker or ColorPicker: they are > sufficient for "basic" needs, more elaborated alternatives may exist in > other projects. > > Martin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Fri Feb 23 17:36:59 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 23 Feb 2024 17:36:59 GMT Subject: [jfx21u] RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 10:52:08 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Jose Pereda on 21 Dec 2023 and was reviewed by Andy Goryachev. > > Thanks! Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/44#pullrequestreview-1898620272 From kcr at openjdk.org Fri Feb 23 17:42:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 17:42:01 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:13:26 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? > - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop > - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen I see the same failure with the most recent patch as I did yesterday. I looked over the changes, and I'm not convinced that this is the right approach. One comment on your proposal: > 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. This changes one of the fundamental aspects of entering and exiting a nested event loop. This will need a lot more analysis to show why this is the right approach. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1961735156 From nlisker at openjdk.org Fri Feb 23 17:56:09 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 23 Feb 2024 17:56:09 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc Message-ID: Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jfx/pull/1379/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1379&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325550 Stats: 41 lines in 3 files changed: 4 ins; 6 del; 31 mod Patch: https://git.openjdk.org/jfx/pull/1379.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1379/head:pull/1379 PR: https://git.openjdk.org/jfx/pull/1379 From thiago.sayao at gmail.com Fri Feb 23 18:29:13 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 23 Feb 2024 15:29:13 -0300 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: Christopher, -Dglass.gtk.uiScale=`gsettings get org.gnome.desktop.interface text-scaling-factor` Probably works. Em qua., 21 de fev. de 2024 ?s 01:57, Christopher Schnick < crschnick at xpipe.io> escreveu: > 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 Fri Feb 23 18:38:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Feb 2024 18:38:01 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote: > Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. > > Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. looks good (with minor suggestion) however, this change adds 2 javadoc warnings which need to be addressed, I would think . modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 6465: > 6463: * of text in both worlds. > 6464: * > 6465: * @defaultValue {@code NodeOrientation.INHERIT} adds a javadoc warning: /Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/src/main/java/javafx/scene/Node.java:6468: warning: no @return public final ObjectProperty nodeOrientationProperty() { ^ modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6273: > 6271: * > 6272: * @defaultValue if the system property {@code javafx.scene.nodeOrientation.RTL} is {@code true}, > 6273: * {@code NodeOrientation.RIGHT_TO_LEFT}, otherwise {@code NodeOrientation.INHERIT} adds a javadoc warning: /Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java:6276: warning: no @return public final ObjectProperty nodeOrientationProperty() { ^ modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 187: > 185: * Returns the child's bottom anchor constraint, if set. > 186: * @param child the child node of an anchor pane > 187: * @return the offset from the bottom of the anchor pane, or {@code null} if no bottom anchor was set minor suggestion: move explanation of when it returns null to the description, i.e.: Returns the child's bottom anchor constraint, if set, otherwise returns {@code null}. @return the offset from the bottom of the anchor pane, or {@code null} modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 209: > 207: * Returns the child's right anchor constraint, if set. > 208: * @param child the child node of an anchor pane > 209: * @return the offset from the right of the anchor pane, or {@code null} if no right anchor was set and here ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1898708803 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501034793 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501035303 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501033228 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501033642 From nlisker at gmail.com Fri Feb 23 19:12:55 2024 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 23 Feb 2024 21:12:55 +0200 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: Hi all, I don't use RT controls, so I can't comment about the specifics of this or other implementations. However, people raised some good points that I would like to be more specific about. 1. Can the "components" of the RTA be separated out so that other controls can use them? For example, colored text segments and highlights can be useful in any text control, like Label and TextField. 2. About creating new controls and the difficulty involved, aren't the long discussions about splitting the behavior, skin, input etc. and John's proposal in that regard addressing exactly that, giving the ability to compose "facets" into controls? 3. It's obvious that the bar for what goes into a library (JavaFX, JDK and all other GUI toolkits) is fluid. We don't *have* to provide a Button because any 3rd party library can make one, but we all agree that it's a good idea. More complex controls, like color picker and date picker could be more controversial as they are not entirely standardized, but I think it's OK to have them. The question is, how far does this go? Perhaps what can help here is to look at various GUI toolkits and see what they provide so we know what users expect. It also matters if they are intended for use on mobile, in which case the set of controls is somewhat different. - Nir On Wed, Feb 21, 2024 at 8:07?PM Andy Goryachev wrote: > Dear JavaFX developers: > > > > We would like to propose a new feature - rich text control, RichTextArea, > intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane. The main design goal is to provide a control > that is complete enough to be useful out-of-the box, as well as open to > extension by the application developers. > > > > This is a complex feature with a large API surface that would be nearly > impossible to get right the first time, even after an extensive review. We > are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*. This will allow us to evolve the API in > future releases without the strict compatibility constraints that other > JavaFX modules have. > > > > Please take a look at the proposal [0], a list of discussion points [1], > and the API Specification (javadoc) [2]. While the proposed API is ready > for review, it isn't complete nor set in stone. We are looking for > feedback, and will update the proposal based on the suggestions we receive > from the community. We encourage you to comment either in the mailing > list, or by leaving comments inline in a draft pull request [3]. For > context, the links to the original RFE [4] and a list of missing APIs > related to rich text [5] are provided below. > > > > Sincerely, > > Your friendly JavaFX development team. > > > > > > References > > > > > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Feb 23 19:44:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 19:44:00 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote: > Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. > > Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. The changes to the docs look fine, although I note the same additional warnings that Andy saw (restoring the `@return` will fix it; the text after the `@return` doesn't matter, since it is unused). Also, I think it would be better to revert all code changes, even though they look harmless. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 6449: > 6447: EFFECTIVE_ORIENTATION_LTR | AUTOMATIC_ORIENTATION_LTR; > 6448: > 6449: private static final NodeOrientation DEFAULT_NODE_ORIENTATION = NodeOrientation.INHERIT; This is unrelated to the doc change (and the addition of a static final const makes it not strictly a doc-only change). Presuming that you want to backport this to jfx22, I recommend to revert this change. Especially since the RC deadline is next week. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 6465: > 6463: * of text in both worlds. > 6464: * > 6465: * @defaultValue {@code NodeOrientation.INHERIT} The `@return` is still needed (although unused) to avoid a warning. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6245: > 6243: > 6244: @SuppressWarnings("removal") > 6245: private static final NodeOrientation DEFAULT_NODE_ORIENTATION = Same comment as in Node.java -- I recommend reverting this change if you intend to backport it to jfx22. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272: > 6270: * of text in both worlds. > 6271: * > 6272: * @defaultValue if the system property {@code javafx.scene.nodeOrientation.RTL} is {@code true}, Restore the `@return` to avoid a warning. ------------- PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1898671234 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501010198 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501010794 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501011782 PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501093086 From kcr at openjdk.org Fri Feb 23 19:44:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 19:44:01 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 18:31:10 GMT, Andy Goryachev wrote: >> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. >> >> Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. > > modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 187: > >> 185: * Returns the child's bottom anchor constraint, if set. >> 186: * @param child the child node of an anchor pane >> 187: * @return the offset from the bottom of the anchor pane, or {@code null} if no bottom anchor was set > > minor suggestion: move explanation of when it returns null to the description, i.e.: > > > Returns the child's bottom anchor constraint, if set, otherwise returns {@code null}. > > @return the offset from the bottom of the anchor pane, or {@code null} I don't mind either way. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501096059 From kcr at openjdk.org Fri Feb 23 19:46:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 19:46:00 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: <913plAftcxWiC85gCdIo7abQwXUTuFxUwaUNVbFxj7I=.65ac4999-4962-496b-9f26-5fa70debf1d4@github.com> 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. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1351#pullrequestreview-1898820773 From angorya at openjdk.org Fri Feb 23 19:46:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Feb 2024 19:46:58 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 19:34:41 GMT, Kevin Rushforth wrote: >> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. >> >> Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272: > >> 6270: * of text in both worlds. >> 6271: * >> 6272: * @defaultValue if the system property {@code javafx.scene.nodeOrientation.RTL} is {@code true}, > > Restore the `@return` to avoid a warning. it seems that placing javadoc at the property declaration instead of the method which returns said property eliminates the warning. See for example Stage:1329 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501100898 From nlisker at openjdk.org Fri Feb 23 20:19:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 23 Feb 2024 20:19:57 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 19:44:06 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272: >> >>> 6270: * of text in both worlds. >>> 6271: * >>> 6272: * @defaultValue if the system property {@code javafx.scene.nodeOrientation.RTL} is {@code true}, >> >> Restore the `@return` to avoid a warning. > > it seems that placing javadoc at the property declaration instead of the method which returns said property eliminates the warning. > See for example Stage:1329 Yes, this is why I was surprised that new warnings showed up. The `@return` text is auto-generated for properties, so why would a return tag be needed? I guess the doc tool doesn't understand that when the doc is placed on the property getter instead of on the field, which I think is a bug. I suggest to move the doc to the field. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501126942 From kcr at openjdk.org Fri Feb 23 20:21:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 20:21:00 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 Looks good with one minor formatting suggestion (but I'll approve it as is). modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 483: > 481: > 482: if (!AWT_SYSTEM_APPEARANCE.equals(awtAppearanceProperty)) { > 483: Logging.getJavaFXLogger().warning(String.format( Minor: Maybe add newlines to break this message into two or three separate lines? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1367#pullrequestreview-1898861689 PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1501125311 From kcr at openjdk.org Fri Feb 23 20:26:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 20:26:56 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 20:16:55 GMT, Nir Lisker wrote: > I suggest to move the doc to the field. Yeah that's even better. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501132703 From mstrauss at openjdk.org Fri Feb 23 21:58:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 23 Feb 2024 21:58:37 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v4] 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: Break warning message into separate lines ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1367/files - new: https://git.openjdk.org/jfx/pull/1367/files/5c743df7..8fdbc624 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1367&range=02-03 Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 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 nlisker at openjdk.org Fri Feb 23 22:01:06 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 23 Feb 2024 22:01:06 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 19:38:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 187: >> >>> 185: * Returns the child's bottom anchor constraint, if set. >>> 186: * @param child the child node of an anchor pane >>> 187: * @return the offset from the bottom of the anchor pane, or {@code null} if no bottom anchor was set >> >> minor suggestion: move explanation of when it returns null to the description, i.e.: >> >> >> Returns the child's bottom anchor constraint, if set, otherwise returns {@code null}. >> >> @return the offset from the bottom of the anchor pane, or {@code null} > > I don't mind either way. `@return` statements usually state this condition explicitly, like `Map#get`: "the value to which the specified key is mapped, or `null` if this map contains no mapping for the key". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501214852 From mstrauss at openjdk.org Fri Feb 23 22:02:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 23 Feb 2024 22:02:16 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 20:14:43 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 483: > >> 481: >> 482: if (!AWT_SYSTEM_APPEARANCE.equals(awtAppearanceProperty)) { >> 483: Logging.getJavaFXLogger().warning(String.format( > > Minor: Maybe add newlines to break this message into two or three separate lines? Done. I've also moved the `checkSystemAppearance` assignment out of the if branch (it should be unconditionally set to `false` after the first call). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1501215285 From mstrauss at openjdk.org Fri Feb 23 22:12:56 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 23 Feb 2024 22:12:56 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3] In-Reply-To: References: Message-ID: On Mon, 19 Feb 2024 17:13:58 GMT, Anirvan Sarkar wrote: > 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 I haven?t tested this in combination with SWT, have you? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1962068535 From nlisker at openjdk.org Fri Feb 23 22:32:16 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 23 Feb 2024 22:32:16 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2] In-Reply-To: References: Message-ID: > Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. > > Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1379/files - new: https://git.openjdk.org/jfx/pull/1379/files/dac77a49..a3c375df Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1379&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1379&range=00-01 Stats: 53 lines in 2 files changed: 21 ins; 25 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1379.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1379/head:pull/1379 PR: https://git.openjdk.org/jfx/pull/1379 From nlisker at openjdk.org Fri Feb 23 22:32:16 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 23 Feb 2024 22:32:16 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote: > Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. > > Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. By the way, is the difference in the default values between `Node` and `Scene` intentional? Only `Scene` has the RTL system property checked. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1379#issuecomment-1962085277 From angorya at openjdk.org Fri Feb 23 22:35:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Feb 2024 22:35:03 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2] In-Reply-To: References: Message-ID: <3eFY8L379Yj-nlJGauSL9r6Jcb2dMqmdAyCC-7C5qxE=.c75b0b54-5413-4ff8-ab9c-23cdf7f28244@github.com> On Fri, 23 Feb 2024 21:58:30 GMT, Nir Lisker wrote: >> I don't mind either way. > > `@return` statements usually state this condition explicitly, like `Map#get`: "the value to which the specified key is mapped, or `null` if this map contains no mapping for the key". My point is that it should be mentioned in the first paragraph then. It can be repeated in @return later, if you prefer. Map.get() does indeed mention this in the first paragraph: ![Screenshot 2024-02-23 at 14 30 02](https://github.com/openjdk/jfx/assets/107069028/977a6dbc-c0b0-4a00-a14d-8ff40353c365) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501237620 From mfox at openjdk.org Fri Feb 23 22:43:04 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 23 Feb 2024 22:43:04 GMT Subject: Integrated: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline In-Reply-To: References: Message-ID: <6V-SNdk3DnQPAgBVDJuEDQQCKshpGilWUEzKoxSk0Fs=.24cbc996-8381-4df5-b642-064ed35ad5ce@github.com> On Fri, 26 Jan 2024 17:32:02 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. This pull request has now been integrated. Changeset: d9263ab2 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/d9263ab268d33104279755dc1de139bd0835fdd7 Stats: 60 lines in 3 files changed: 35 ins; 10 del; 15 mod 8301900: TextArea: Committing text with ENTER in an IME window inserts newline 8088172: Mac: On German keyboard, pressing <+> inserts two apostrophes instead of one 8089803: [Mac, TextArea] Japanese IME, caret moves to the next line when pressing Return to select a candidate. Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1351 From angorya at openjdk.org Fri Feb 23 22:43:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Feb 2024 22:43:15 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 22:28:59 GMT, Nir Lisker wrote: > Only `Scene` has the RTL system property checked. I suppose because Scene must INHERIT this value from the system? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1379#issuecomment-1962094000 From kcr at openjdk.org Fri Feb 23 23:42:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 23:42:03 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2] In-Reply-To: References: Message-ID: <-5XrCOmOi9cUQByv2v4FHyMmUCbt5MpWnzw2byBZ57w=.5ada85bd-625f-4c40-8a6d-1d50b99355e6@github.com> On Fri, 23 Feb 2024 22:32:16 GMT, Nir Lisker wrote: >> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. >> >> Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1899088659 From angorya at openjdk.org Fri Feb 23 23:42:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Feb 2024 23:42:04 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 22:32:16 GMT, Nir Lisker wrote: >> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. >> >> Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1899094754 From kcr at openjdk.org Fri Feb 23 23:42:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Feb 2024 23:42:04 GMT Subject: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2] In-Reply-To: <3eFY8L379Yj-nlJGauSL9r6Jcb2dMqmdAyCC-7C5qxE=.c75b0b54-5413-4ff8-ab9c-23cdf7f28244@github.com> References: <3eFY8L379Yj-nlJGauSL9r6Jcb2dMqmdAyCC-7C5qxE=.c75b0b54-5413-4ff8-ab9c-23cdf7f28244@github.com> Message-ID: On Fri, 23 Feb 2024 22:32:23 GMT, Andy Goryachev wrote: >> `@return` statements usually state this condition explicitly, like `Map#get`: "the value to which the specified key is mapped, or `null` if this map contains no mapping for the key". > > My point is that it should be mentioned in the first paragraph then. It can be repeated in @return later, if you prefer. Map.get() does indeed mention this in the first paragraph: > > ![Screenshot 2024-02-23 at 14 30 02](https://github.com/openjdk/jfx/assets/107069028/977a6dbc-c0b0-4a00-a14d-8ff40353c365) Given that the changes are so far limited to spelling and formatting (code style for null), I think it would be fine to limit the changes in this PR to what he has already done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501267342 From kcr at openjdk.org Sat Feb 24 00:38:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 24 Feb 2024 00:38:07 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v3] In-Reply-To: References: Message-ID: <1EzGsCno1c9r8Jvcd-u3RD9TyDnRzZU7iRrEi0dEJ2A=.d56caf09-074b-4f2f-a88d-04dbf9b39173@github.com> On Thu, 22 Feb 2024 22:28:40 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Revert unintended formatting I did a first pass of the updated PhongMaterial docs. Nice work! I'll need more time to go through it in detail (and definitely will want Ambarish and Lukasz to review it as well), but I like the structure, the explanations, and the illustrations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1962177376 From kcr at openjdk.org Sat Feb 24 00:51:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 24 Feb 2024 00:51:09 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v4] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 21:58:37 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: > > Break warning message into separate lines Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1367#pullrequestreview-1899133239 From kcr at openjdk.org Sat Feb 24 00:51:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 24 Feb 2024 00:51:10 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 22:10:02 GMT, Michael Strau? wrote: > > 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 > > I haven?t tested this in combination with SWT, have you? I just did and it works as expected (so no special-casing of an SWT application is needed). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1962183229 From jpereda at openjdk.org Sat Feb 24 01:33:58 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Sat, 24 Feb 2024 01:33:58 GMT Subject: [jfx21u] Integrated: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 10:52:08 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Jose Pereda on 21 Dec 2023 and was reviewed by Andy Goryachev. > > Thanks! This pull request has now been integrated. Changeset: f83dfdd4 Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/f83dfdd4ee6e7c87551a9be70dcdebbd6b3ad403 Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView Reviewed-by: jvos Backport-of: ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd ------------- PR: https://git.openjdk.org/jfx21u/pull/44 From crschnick at xpipe.io Sat Feb 24 04:50:03 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 24 Feb 2024 05:50:03 +0100 Subject: ImageView has artifacts when uiScale is set on Linux Message-ID: <8cc1722f-be6a-4511-8d35-3920ff124ac5@xpipe.io> Hello, due to the scaling problems on Linux with https://bugs.openjdk.org/browse/JDK-8326428, I tried to implement a workaround by manually setting glass.gtk.uiScale to the appropriate value. However, when this value is not 100%, small images, in this case 40x40, often have artifacts around the borders: Original image: The same does not happen when using the same uiScale on Windows. This was done with the latest ea build on Ubuntu 23.10. The exact scale does not matter as long it is not 100%. This is the code I used: |public class ImageSize extends Application { ??? public static void main(String[] args) { ??????? System.setProperty("glass.gtk.uiScale", "400%"); ??????? Application.launch(ImageSize.class, args); ??? } ??? @Override ??? public void start(Stage primaryStage) throws Exception { ??????? var img = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAACXBIWXMAAAEuAAABLgF7cRpNAAAAGXRFWHRTb2Z0d2FyZQB3d3cuaW5rc2NhcGUub3Jnm+48GgAACJhJREFUWIXNmHt0VNUVxn/n3nkmE/KCZDJBkCBIxRBIgqBBEKSAi2i7ZAG1tauCheUjARUp6lpW66K11CICoViLq7TlYZ9YFaGtlYfSKJiglPAQwQWBSUzIa5JJ5nlP/7hhXplMEnF1+f01c+539vnO2fvsve+FrznEV2GkcJmzCMlTwM0CPMB2TKyvWuu4fLW2r0pgcdmlEk3hCaSYG8eWW8KrQbQXjm0cevH/KrBouXOKlHIVUpT2g+4D/hjUtNWfbBr66UDXGoBAKQrLnaXAUyAmD3QhQEPIt0VQPFO1yVH91Ql8ViqFTc65IJ4BihJRjaogKCWaltCiRMjdQqirq9bbP/zSAouWSqNmrr9HIJ8ExvRlCOC3j2bS3KGx4jct/aEj4ZBArqnemPtmbxxD7MD8+VI9Z69fKqlbJWB4v1bqRmqygi/Qf76AEhBvTCh3HhKC1dUbHHtjOUrswFm7c4dE/ooBigNobte43BYc6DRdqGTPhDLnzxIKLHi4biyIBQNeoRs2q8Bq/vKZSwhWFS+/dH3kWJSLVUWbPpCLbTUJpow1M3mMmRF2A6McRkZkG3lxSTqnLwY4cNzDqVr/QDQqmlRmAqfjCkQqJQgZuSMenzeI/5zwcuiEN7wrFe6dYeP7M5JJS46OEoMK0/ItTMuHpXfYqLngZ/PudipPeqN4swutpCQJ/vJ+Z9S4kLIE2BRSHPO0JPKv0SCYU2TlxSUZzCq0ApCdprL1scGU35lCWrKClFBzwc+/jnpC894+0sWlJj0Wxw4zUvFgBk/fk4pR1b1z74xkfvqDNEpvSupxhFIyNUrSlR8Fj9bmqgG1R0nKTld55FspzJxg5Z9VXYwfacKergKw56MuXtnTwYXGABNHm3i5LBOAqT+qp9MrKbzORPmdg8i/1gjAB6e8BIJwyw1m/vSem1f2dNDm7pk0hcLwqvWOCxDhYiWo3NqDCXzREuTJra04m4Lc900bAD6/5OltrbwTcWop1rAzbFYFtydI1Rkfi9Zd5sG5Kdw/y8bkMWYAfvyHVnYf6Yq3HACaJkuACxDhYiGVkl5nAC0ROzUYBNfnGlEjAsQWKdASvmgpVoUR2dGhfr4hcbLU86OOCIFySm8TksyCRd2n52wOoghYPMvGluWZODLUbiFhUVfEFo8y8doTg5lRYEFKqGvW4/Kh0pSEAkGEtCgAYx9qsEnBjb3Rp4+zkJas0N6l8b1fXGb7PjcA40aY2LlqCN+9LZnZ3ZcIYMGUJFbOG8Tmskyy01Q0DVa/1sbjr+olcNL1ZnIz1UQK84uWNqeGBFqF/2bilL0ruPVGCwD//tiDq1PjxV0u1u1yoUk9Oa+4exBjhxtD/DnFVr4zLRlFgNcvWflqC69XdnKq1s/pi3pevH28JZFARZo8k0MCNZWE8Zdn17V/eNoXGtu2z81zO1qjeJ85A1y8HC51Pr/koU3N7P9v+DJ9cErPh6McRhJBKromPVikSCgwK02nxQZ3fUtYzN6qLhb+vJEFzzdyxqmfUqdP0tAaXZtruzeQk5HQxQjJFADD/PlSPUvdpERknx+wgkHR42fqjWamj7OQnR5e5MoF8PolDa0aoxyQlqzw5rNZnKsPcPC4h8OnfQPpkCeNfbbGZDiXVVcA9HqtHBkqotvq1scGo/Tof3TcfUsSbW6NtGSFiaNNUc/y7Aby7Dbum0momU2yCJLMgk6vjGNNpxhbMgrEhGWXyoUUGyKfzCiwMLvQyjVZKnl2Q6hEAUipp5qzdX7O1QUYnKpSepO1h/VAEDbvbifJIsizGxiZY2BopiFqg00ujZO1fs43BHjrcBefXoppLCSPGYQUebHGF8+yMXSwyqEaL39+r5OJo03MLrTibA6y8PnGqF2PG2GKK9Djk2zf58YfDHPTbQpv/yQLk1Hw1uEuKk95mTjKxB3FVkbnGnmgoinaiMJwA0J8how+5sUvNSE1Qsbf/cTD9HwLjgyVwutMvF8T7kzumhQWt+51F4UjTUzLt2CzCmZOsLDno3BJmzclCZNR0OWTrP2bC1enxt6PulCUth4b7D7BGiVgEluJ6L9ATw+RO29za+w8oCfnJxekMihJ95PNKphTrAs8dMLLtnfdrH6tDbdHn7vg1nC3Mj7PxJLZeqjv2O/G1RkunZpGjxctATVmQ3CbcuyXdndQ0+4CopNaDLb8o4PzDQHs6SobHsggxapQelMSVpNA02DDGy5Ab/t/904HoLt/zDVGbhhm5IX70zGocLYuwJa9HYmWAmiRweC3K9dd0xWK/sIy52wEu4FeE9S12Qa2LM8k3aZQ2xhAUQS5mSp//6CT53aE3WQxCXY9PYSsVJWTtX5G2g2YjIIvWoMsWd8U6hV7gSalKD1akbOHSDF1h9eezZm0IgDc3tvMVrfG/mNebv6GmWFZhpCr3+0ugVLCoCSFa7MNZKfpGWBIqoqqCs44/Sx7uSWq0sSDQKysrsj5ffh/FKQoLK/fCXJhIiMWk+CV8syo+psIx8/7WbKhCZ+/15x3BdurNzrujRyISbtCmg2BRUBVIisen0RR4LJL44W/ujh43ENDWxB/UOLzSy40Bqg86aXizXaa2zU0TfYpTkg+Fl6W9hiPR57wsHO4UDgCDIn3/LZxFtb+MJ0VW1rYf8wTjxLCzPEW1ixOZ/mvm6PSUwyaAlKZeKzC/nnsg7iF6+gmx3lgHtDjndGg6qmmoS3IweOJxQHsO+ahuV3jqYWpoZIZA79EzIsnrleBANUbHe8JycrYcYHg9EU/L+1q7+sjEQBBDV563cXn9YG4AqVk2dGNOQd6m99nc1G0zLlFSu7vW8qXgdxavTF3USJGryd4BSkubxmSPj+TDRyi0kXnA32y+mOq6JHGHBnwH0GQe/XCAKiTMlB8tGKYsy9iv/tH/WaLNSCnAglfKPrAyaAmln6yKafmKmx8ffA/40AyV2Na31IAAAAASUVORK5CYII="; ??????? var r = new ImageView(img); ??????? r.setFitWidth(40); ??????? r.setFitHeight(40); ??????? var s = new StackPane(r); ??????? s.setBackground(Background.fill(Color.BLACK)); ??????? var scene = new Scene(s, 100, 100); ??????? primaryStage.setScene(scene); ??????? primaryStage.setTitle("Test"); ??????? primaryStage.show(); ??? } }| Is this a bug or a limitation in the renderer? Best Christopher Schnick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jXZ2l5i0uMKGQvOp.png Type: image/png Size: 39042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: k8sCluster_icon-40.png Type: image/png Size: 2315 bytes Desc: not available URL: From duke at openjdk.org Sat Feb 24 07:26:59 2024 From: duke at openjdk.org (duke) Date: Sat, 24 Feb 2024 07:26:59 GMT Subject: Withdrawn: 8092272: [D3D 3D] Need a robust 3D states management for texture In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 22:30:34 GMT, Nir Lisker wrote: > Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. > > Summary of the changes: > * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. > * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. > * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. > > The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1281 From nlisker at openjdk.org Sat Feb 24 09:51:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 24 Feb 2024 09:51:57 GMT Subject: Integrated: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote: > Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in `Node` and `Scene`. > > Note that the default value for a `Scene`'s `NodeOrientation` depends on a system property, while for `Node` it isn't (which means `SubScene` will be different from `Scene`). Not sure if this is intended. This pull request has now been integrated. Changeset: b43c4edf Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/b43c4edf7590429fd051d1b0e2ccb6dd49a10b8b Stats: 66 lines in 3 files changed: 19 ins; 25 del; 22 mod 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc 8318624: API docs specify incorrect default value for nodeOrientation property Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1379 From nlisker at openjdk.org Sat Feb 24 09:58:16 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 24 Feb 2024 09:58:16 GMT Subject: [jfx22] RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc Message-ID: Backport of commit [b43c4edf](https://github.com/openjdk/jfx/commit/b43c4edf7590429fd051d1b0e2ccb6dd49a10b8b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. ------------- Commit messages: - Backport b43c4edf7590429fd051d1b0e2ccb6dd49a10b8b Changes: https://git.openjdk.org/jfx/pull/1380/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325550 Stats: 66 lines in 3 files changed: 19 ins; 25 del; 22 mod Patch: https://git.openjdk.org/jfx/pull/1380.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1380/head:pull/1380 PR: https://git.openjdk.org/jfx/pull/1380 From nlisker at openjdk.org Sat Feb 24 12:10:23 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 24 Feb 2024 12:10:23 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v4] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Clarifications for the diffuse component ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/0130d0f5..e367c882 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From kcr at openjdk.org Sat Feb 24 14:04:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 24 Feb 2024 14:04:57 GMT Subject: [jfx22] RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: <7gxNVXyTKwCrUtH2NoWeKgi3s5iJhbIRPadCHnqB59Q=.a94bd9bd-2b7d-407e-9b2d-9ecd06b5ec38@github.com> On Sat, 24 Feb 2024 09:53:01 GMT, Nir Lisker wrote: > Backport of commit [b43c4edf](https://github.com/openjdk/jfx/commit/b43c4edf7590429fd051d1b0e2ccb6dd49a10b8b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. I note that this is a clean backport of a doc-only fix. Approved to go into jfx22. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1380#pullrequestreview-1899492670 From nlisker at openjdk.org Sat Feb 24 14:40:25 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 24 Feb 2024 14:40:25 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v5] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Remove redundant image copies ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/e367c882..83bf2eb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=03-04 Stats: 65 lines in 3 files changed: 0 ins; 65 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From nlisker at openjdk.org Sat Feb 24 15:17:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 24 Feb 2024 15:17:57 GMT Subject: [jfx22] Integrated: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 09:53:01 GMT, Nir Lisker wrote: > Backport of commit [b43c4edf](https://github.com/openjdk/jfx/commit/b43c4edf7590429fd051d1b0e2ccb6dd49a10b8b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. This pull request has now been integrated. Changeset: 6e1246e8 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/6e1246e870aa6dafe05a3f544bb283aa90a0c078 Stats: 66 lines in 3 files changed: 19 ins; 25 del; 22 mod 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc 8318624: API docs specify incorrect default value for nodeOrientation property Reviewed-by: kcr Backport-of: b43c4edf7590429fd051d1b0e2ccb6dd49a10b8b ------------- PR: https://git.openjdk.org/jfx/pull/1380 From mhanl at openjdk.org Sat Feb 24 17:26:57 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 24 Feb 2024 17:26:57 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 17:39:44 GMT, Kevin Rushforth wrote: > This changes one of the fundamental aspects of entering and exiting a nested event loop. This will need a lot more analysis to show why this is the right approach. Yes, this is right and I also thought about documenting that as soon as we think that this is the right approach. I completely agree that we need to analyse this. This is not a simple change but will affect Dialogs and every custom code that uses nested event loops (e.g. I used it for blocking the UI without freezing it for data loading purposes, where we want to wait until the code returns in a non UI blicking way). Maybe there is a better way as well, I just don't figured out one. As described, right now we rely that `enterNestedEventLoop` returns always, which is not happening immediately for ALL platforms, even though Platform has another implementation. Which makes me think the current approach has a flaw, resulting in this behaviour. > I see the same failure with the most recent patch as I did yesterday. I looked over the changes, and I'm not convinced that this is the right approach. Thanks for testing. As soon as my colleague is available, I will debug this issue. I don't get why only MacOS is failing, since the low level code is pretty much the same, we just continue right after we left the nested event loop. I agree that we should find out the root cause why MacOS behaves different. > I don't know of any supported way to run macOS in a VM on a Windows host, but perhaps others will be able to help. That was also my understanding the last time I checked. AFAIK, think there is no official way from Apple, but VirtualBox may offer that. Will check as soon as I have more time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1962428672 From tsayao at openjdk.org Sat Feb 24 17:37:58 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 24 Feb 2024 17:37:58 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 Tue, 20 Feb 2024 12:13:31 GMT, Jose Pereda wrote: >> 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. @jperedadnr Would you confirm that scroll on a touch screen still works on Xorg ? My tests looks all good (manual and system/robot). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1962431721 From mhanl at openjdk.org Sat Feb 24 17:38:11 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 24 Feb 2024 17:38:11 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations [v2] In-Reply-To: References: 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` 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). Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: - JDK-8325402: remove labeled if - JDK-8325402: Unit test improvements ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1360/files - new: https://git.openjdk.org/jfx/pull/1360/files/947b4153..a7584d81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1360&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1360&range=00-01 Stats: 29 lines in 10 files changed: 11 ins; 12 del; 6 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 jhendrikx at openjdk.org Sat Feb 24 22:48:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 24 Feb 2024 22:48:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 10:01:37 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 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/02e8b6ba...e3812732 I'm confused by this part: > we will not have information to decide if the character index should be calculated relative to Text node or TextFlow The character index, even in your example image above, seems to be relative to the `Text`, not to the `TextFlow` (it is 0, even though there are clearly 10 characters before it belonging to another `Text`), so what exactly do you mean with this? What I find it confusing further more is that if I request the `HitInfo` of the `TextFlow` container (which I think would make more sense to do) that these values are subtly different. Take this modification to your test program: if (n instanceof Text t) { Point3D p3 = pick.getIntersectedPoint(); Point2D p = new Point2D(p3.getX(), p3.getY()); HitInfo h = t.getParent() instanceof TextFlow tf ? tf.hitTest(p) : t.hitTest(p); hitInfo2.setText("TextFlow: " + h + "\nText: " + t.hitTest(p)); } When used with these two texts: t("Arabic**"), t("ABCD") You'll find that the values perfectly match for the first `Text` in the flow, but for the 2nd `Text` in the flow they're subtly different. Somehow I think that's already very strange. The reported character indices are always relative to the `Text`s though, which is why I'm confused about your earlier statement. Your fix however does mean that the `HitInfo` for `Text` seems to be more accurate, but it doesn't match with what `TextFlow` reports (in other words, the `hitTest` of `TextFlow` was and is broken still, your fix didn't change that). I'm still looking into why `PrismTextLayout` needs to be "aware" of texts being nested into `TextFlow` -- this seems like such an odd thing to me that I find it tough to let it go. I think that if we know why `hitTest` of `TextFlow` is broken, then that it will also make clear why it currently must be aware of the nesting; and I think once fixed, it won't need to know this anymore. In its current form, the `hitTest` method on `TextFlow` seems completely useless. The reported `HitInfo` can't be made sense of without knowing which child we're talking about. I think it may make sense to extend `HitInfo` with the `Node` involved. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1962749265 From jhendrikx at openjdk.org Sat Feb 24 23:03:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 24 Feb 2024 23:03:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 10:01:37 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 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/98fd3ec3...e3812732 modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 606: > 604: boolean addLtrIdx = run.getTextSpan().getText().length() != run.length; > 605: if (r.getStart() != curRunStart && !r.isLinebreak() && addLtrIdx > 606: && r.getTextSpan().getText().equals(text)) { I'm concerned about this check: `r.getTextSpan().getText().equals(text)` -- it seems to me that it either must be irrelevant, or it if is relevant, what if I have many `Text` nodes in a `TextFlow` that happen to have the same text? Let's say I have an English text, where I give each word its own `Text` node in a `TextFlow`. There would be many duplicates... so I find it hard to believe this check could accomplish anything. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1501710956 From jhendrikx at openjdk.org Sun Feb 25 13:19:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 25 Feb 2024 13:19:01 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> On Wed, 21 Feb 2024 10:01:37 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 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/72fd0ef9...e3812732 tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 238: > 236: > 237: @Test > 238: public void testTextAndTextFlowHitInfoForRTLEnglishText() throws Exception { I just replaced `PrismTextLayout#getHitInfo` with `return new Hit(0, 0, true);` and this test, and all the others still pass. I think the tests should check for a given range of x values if the correct character is being returned as the hit, perhaps more inspired by the tests in https://github.com/openjdk/jfx/pull/1236 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1501819474 From jpereda at openjdk.org Sun Feb 25 19:47:59 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 25 Feb 2024 19:47:59 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 Sat, 24 Feb 2024 17:34:54 GMT, Thiago Milczarek Sayao wrote: >> I've just reverted the previous changes, and just applied the touch mask to the `gdk_pointer_grab` function. Tests should be green now. > > @jperedadnr Would you confirm that scroll on a touch screen still works on Xorg ? > > My tests looks all good (manual and system/robot). @tsayao yes, I've double checked again. On Wayland and Xorg, I can scroll with touch events on a touch screen with this fix. The only issue I still see on Wayland: the mouse cursor location doesn't get updated from touch events, only from mouse events (I guess this can be a follow-up issue). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1963041414 From jhendrikx at openjdk.org Sun Feb 25 21:58:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 25 Feb 2024 21:58:11 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v4] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Fix docs - Add missing override annotation - Merge remote-tracking branch 'upstream/master' into feature/selector-performance-improvement - Fix wrong exception name in javadoc - Merge branch 'master' into feature/selector-performance-improvement - Add since tag to new API - Add deprecated annotation and fixed deprecation descriptions - Use copyOf instead of Collections.unmodifiableList(new ArrayList<>(x)) - Pull up frozen field to abstract FixedCapacitySet class - Add copyright header - ... and 2 more: https://git.openjdk.org/jfx/compare/b43c4edf...a33f797a ------------- Changes: https://git.openjdk.org/jfx/pull/1316/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=03 Stats: 887 lines in 8 files changed: 643 ins; 172 del; 72 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From jhendrikx at openjdk.org Sun Feb 25 21:58:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 25 Feb 2024 21:58:11 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v4] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 15 Jan 2024 20:48:54 GMT, Michael Strau? wrote: >> @mstr2 I've created #1333 to show how it would look when we move `SimpleSelector` and `CompoundSelector` to internal packages. I think that should alleviate most concerns, and we can either integrate this first with a new public method, which will later be internal anyway, or integrate the other change first. > > Thanks for the detailed explanation. I agree that moving `SimpleSelector` and `CompoundSelector` to an internal package would be the best choice, and would also make the question of new API a non-issue. A new method `getStyleClassNames` was now added as part of #1340 -- we can use that now for the optimization. Eventually, the `SimpleSelector` and `CompoundSelector` classes will move to internal packages (probably in JFX 24) via #1333 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1501905042 From jhendrikx at openjdk.org Sun Feb 25 22:28:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 25 Feb 2024 22:28:12 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > 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: Optimize performance of OpenAddressed Set just in case it is ever used ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/a33f797a..c388f23d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=03-04 Stats: 30 lines in 1 file changed: 20 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From kpk at openjdk.org Mon Feb 26 07:54:02 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 26 Feb 2024 07:54:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 22:44:05 GMT, John Hendrikx wrote: > The character index, even in your example image above, seems to be relative to the `Text`, not to the `TextFlow` (it is 0, even though there are clearly 10 characters before it belonging to another `Text`), so what exactly do you mean with this? > Yes it is relative to Text. We can calculate it relative to Text because of all the information we have now in PrismTextLayout after the modification that has been done in this PR. The character index is relative to Text because it is requested on Text embedded in TextFlow rather than on TextFlow. Without the parameters added to `getHitInfo` it is not possible to know if the character index needs to be relative to Text or TextFlow. Since the x y coordinates will be relative to Text node when hit test is requested on Text node embedded in TextFlow, we will not know that the HitTest is requested on second Text node without the parameters added in this PR. Im not sure what is the confusion here. Please let me know if it is not clear. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1963504711 From r.lichtenberger at gmail.com Mon Feb 26 08:04:27 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 26 Feb 2024 09:04:27 +0100 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: <8d09bd13-21a5-471d-97d2-c9b0f0bd1685@gmail.com> Having read the interesting posts following this announcement, let me add a few points from my perspective: I understand and agree we Johan Vos that there are a lot of open issues in JBS that should be addressed. At the same time I would very much appreciate if a RichTextArea were implemented in core JavaFX as opposed to a library. Having good controls implemented within JavaFX makes it more attractive to application developers. To that end I don't think it good to develop all kinds of controls outside of JavaFX. The current TextArea makes us laughing stock: If you load any kind of medium-sized text in it, you're application will stop to work, because there are too many elements in the scene graph. We're currently using RichTextFX in our application and it gives us some headaches (Can't wrap my head around the API, graphic errors under Windows, etc.). I haven't known about Gluon's RichTextArea before. May well be giving it a try (but will have to check if commercial licensing is viable for us). I have some editor building background myself: About 25 years ago, I built the editor for a commercial IDE (SNiFF+ by TakeFive, then Windriver, now Intel ...), which was written in C++ with ET++. This editor was then ported to Java / Swing (called RED Editor)? which was already open sourced. About 6 years ago, I tried to "port" the RED Editor from Swing to JavaFX (https://github.com/effad/rtefx). The attempt failed for two reasons: I did not have the time to do it properly (Implementing a rich text control is a lot of work) and JavaFX was just too closed at that time. Robert From kpk at openjdk.org Mon Feb 26 10:43:06 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 26 Feb 2024 10:43:06 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 23:00:43 GMT, John Hendrikx wrote: >> 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/05c327e9...e3812732 > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 606: > >> 604: boolean addLtrIdx = run.getTextSpan().getText().length() != run.length; >> 605: if (r.getStart() != curRunStart && !r.isLinebreak() && addLtrIdx >> 606: && r.getTextSpan().getText().equals(text)) { > > I'm concerned about this check: `r.getTextSpan().getText().equals(text)` -- it seems to me that it either must be irrelevant, or it if is relevant, what if I have many `Text` nodes in a `TextFlow` that happen to have the same text? Let's say I have an English text, where I give each word its own `Text` node in a `TextFlow`. There would be many duplicates... so I find it hard to believe this check could accomplish anything. You are right. It fails when there are repeated text nodes. I will look into this ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1502392096 From kpk at openjdk.org Mon Feb 26 11:38:06 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 26 Feb 2024 11:38:06 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> Message-ID: On Sun, 25 Feb 2024 13:16:06 GMT, John Hendrikx wrote: >> 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/993c5e2e...e3812732 > > tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 238: > >> 236: >> 237: @Test >> 238: public void testTextAndTextFlowHitInfoForRTLEnglishText() throws Exception { > > I just replaced `PrismTextLayout#getHitInfo` with `return new Hit(0, 0, true);` and this test, and all the others still pass. > > I think the tests should check for a given range of x values if the correct character is being returned as the hit, perhaps more inspired by the tests in https://github.com/openjdk/jfx/pull/1236 I'm not sure if we could write headless test for this. Could you please point me to a test which could be helpful for me? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1502469288 From tsayao at openjdk.org Mon Feb 26 12:55:01 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 26 Feb 2024 12:55:01 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v4] In-Reply-To: References: Message-ID: <8Vo5u10X3Y96pzEqwuVI_-6-gML04wiRkFUDK0hBIUQ=.c96a5188-5a0a-4d73-aabe-e0ac3baef81f@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 All ok. ------------- Marked as reviewed by tsayao (Committer). PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1900802532 From jhendrikx at openjdk.org Mon Feb 26 14:02:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 26 Feb 2024 14:02:05 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 10:01:37 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 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/579ce0f7...e3812732 Okay, I've been looking into this myself. First, I've limited myself to the simple case of LTR text with standard English text. I used 5 Text Nodes containing `The quick brown fox jumped over the lazy dog`. Using the "old" `getHitInfo(float, float)` code from JavaFX 21. This code does not use the extra 3 parameters it is given. This is what I got initially: ![image](https://github.com/openjdk/jfx/assets/995917/56dae0e5-4abd-4341-b249-1348258bd46b) In the above image, there are two lines drawn below each character. The first line is the `character index % 6` returned by `TextFlow` for each possible `x` position. It's correct everywhere and returns the correct character offset. The second line is the `character index` returned for the `Text` at the same location. There are two things standing out here: - The `Text` character index is based on the first line, even for each subsequent line. The character widths therefore don't match properly. - The `Text` character index does not reset to dark blue for the first character (The `T` of the second `The` is colored Orange, while if the character index resets it should have been Dark Blue). The reason this is all incorrect is because the `TextLayout` used by the `Text` is the one from its parent. So it must pass coordinates in the parents coordinate system. If fix that, I get this: ![image](https://github.com/openjdk/jfx/assets/995917/dd4da7b0-dbbd-46ba-8133-ea3495c4a449) Note that one of the two problems has disappeared. The returned character index is still incorrect (The `T` of the second `The` is colored Orange, while if the character index resets it should have been Dark Blue), but the widths now match perfectly. So, I now also fix the character index by subtracting `textRunStart` from the returned `TextLayout.Hit`, and now it looks like this: ![image](https://github.com/openjdk/jfx/assets/995917/273243b8-680c-41a5-9d3f-f6d69d4b3c0c) Note that now the character index for each `T` of `The` starts as Dark Blue. So, I used the `getHitInfo` code from JavaFX 21 + this code in `Text`: public final HitInfo hitTest(Point2D point) { if (point == null) return null; TextLayout layout = getTextLayout(); double x = point.getX() - getX(); double y = point.getY() - getY() + getYRendering(); GlyphList[] runs = getRuns(); int runIndex = findRunIndex(x, y, runs); int textRunStart = 0; int curRunStart = 0; if (runs.length != 0) { textRunStart = findFirstRunStart(runs); curRunStart = ((TextRun) runs[runIndex]).getStart(); } double px = x; double py = y; if(isSpan()) { Point2D ppoint = localToParent(point); px = ppoint.getX(); py = ppoint.getY(); } TextLayout.Hit h = layout.getHitInfo((float)px, (float)py, getTextInternal(), textRunStart, curRunStart); return new HitInfo(h.getCharIndex() - textRunStart, h.getInsertionIndex(), h.isLeading()); } >From this "base" code I think the next step is to look how to fix mirrored text. Here's the test program I used: import javafx.animation.Animation; import javafx.animation.KeyFrame; import javafx.animation.Timeline; import javafx.application.Application; import javafx.application.Platform; import javafx.geometry.Point2D; import javafx.geometry.Point3D; import javafx.scene.Node; import javafx.scene.Scene; import javafx.scene.canvas.Canvas; import javafx.scene.canvas.GraphicsContext; import javafx.scene.control.Label; import javafx.scene.input.MouseEvent; import javafx.scene.input.PickResult; import javafx.scene.layout.StackPane; import javafx.scene.layout.VBox; import javafx.scene.paint.Color; import javafx.scene.text.Font; import javafx.scene.text.HitInfo; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javafx.stage.Stage; import javafx.util.Duration; public class TextFlowRTLSample { public static void main(String[] args) { Application.launch(App.class); } private static final Color[] COLORS = new Color[] {Color.DARKBLUE, Color.YELLOW, Color.ORANGE, Color.GREEN, Color.BLUEVIOLET, Color.RED}; public static class App extends Application { TextFlow control = new TextFlow(); Label hitInfo2 = new Label("Empty\nEmpty"); Label pickResult = new Label("Empty"); @Override public void start(Stage primaryStage) throws Exception { Node[] ts = createRTLText(); Canvas canvas = new Canvas(850, 500); control.getChildren().addAll(ts); control.addEventHandler(MouseEvent.ANY, this::handleMouseEvent); VBox root = new VBox(hitInfo2, pickResult, new StackPane(canvas, control)); Scene scene = new Scene(root, 850, 600); // scene.setNodeOrientation(NodeOrientation.RIGHT_TO_LEFT); primaryStage.setScene(scene); primaryStage.show(); Timeline timeline = new Timeline( new KeyFrame(Duration.seconds(0.1), e -> { canvas.getGraphicsContext2D().clearRect(0, 0, 1000, 1000); for(int y = 50; y < 600; y += 64) { for(int x = 0; x < 850; x++) { HitInfo hitTest = control.hitTest(new Point2D(x, y)); GraphicsContext g2d = canvas.getGraphicsContext2D(); g2d.setStroke(COLORS[hitTest.getCharIndex() % COLORS.length]); g2d.strokeLine(x, y, x, y + 5); for (Node text : control.getChildren()) { Point2D local = text.parentToLocal(x, y); if (text.contains(local) && text instanceof Text t) { hitTest = t.hitTest(local); g2d.setStroke(COLORS[hitTest.getCharIndex() % COLORS.length]); g2d.strokeLine(x, y + 8, x, y + 13); } } } } }) ); timeline.setCycleCount(Animation.INDEFINITE); timeline.play(); } 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("The quick brown fox jumped over the lazy dog"), t("The quick brown fox jumped over the lazy dog"), t("The quick brown fox jumped over the lazy dog"), t("The quick brown fox jumped over the lazy dog"), t("The quick brown fox jumped over the lazy dog"), // t("??????????"), }; } protected void handleMouseEvent(MouseEvent ev) { PickResult pick = ev.getPickResult(); Node n = pick.getIntersectedNode(); hitInfo2.setText("-\n-"); if (n == null) { pickResult.setText("null"); } else { Point3D p3 = pick.getIntersectedPoint(); Point2D p = new Point2D(p3.getX(), p3.getY()); pickResult.setText(n.getClass().getSimpleName() + "." + n.hashCode()); if (n instanceof Text t) { HitInfo h = t.getParent() instanceof TextFlow tf ? tf.hitTest(t.localToParent(p)) : t.hitTest(p); hitInfo2.setText("TextFlow: " + h + "\nText: " + t.hitTest(p)); } else { hitInfo2.setText("TextFlow: " + control.hitTest(control.sceneToLocal(new Point2D(ev.getSceneX(), ev.getSceneY()))) + "\n-"); } } } } } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1964213756 From kcr at openjdk.org Mon Feb 26 15:20:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Feb 2024 15:20:12 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v9] In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 20:34:50 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add additional test for IOOBE detection. > This test comes from JDK-8323787 Getting back to this.... I ran the test on macOS and it now works as expected. However, one of the new tests fails on Linux: SystemMenuBarTest > testFocusMemoryLeak FAILED org.opentest4j.AssertionFailedError: expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40) at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35) at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227) at app//test.com.sun.javafx.tk.quantum.SystemMenuBarTest.testFocusMemoryLeak(SystemMenuBarTest.java:198) Btw, all of my tests were done in a local branch with the latest upstream master merged in. @johanvos since the source branch is now a bit out of date, can you merge in the latest upstream master? Also, I think there are still some unaddressed questions from John and Andy. Regarding the following: > All tests now pass, but I noticed that in some cases, the systemtests do not correctly work with the application lifecycle management (see https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044516.html). For now, I consider this anomaly to be independent from JDK-8319779 Yes, this is unrelated to the memory leak being fixed by this PR. We should file a bug for the activation problem. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1964373792 From lkostyra at openjdk.org Mon Feb 26 15:55:53 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 26 Feb 2024 15:55:53 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v5] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 14:40:25 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant image copies This is a great docs update and exhaustive explanation of how Phong model works. I found one typo to iron out, otherwise LGTM (I will do a second pass once backgrounds are updated). modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 227: > 225: * the total specular component contribution is S * CSM. > 226: * > 227: *

Slef-Illumination

Typo - `s/Slef/Self` ------------- Changes requested by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1378#pullrequestreview-1901233188 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1502832050 From jpereda at openjdk.org Mon Feb 26 16:04:52 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 26 Feb 2024 16:04:52 GMT Subject: Integrated: 8320965: Scrolling on a touch enabled display fails on Wayland In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 11:19:23 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. This pull request has now been integrated. Changeset: df3707d7 Author: Jose Pereda URL: https://git.openjdk.org/jfx/commit/df3707d7444c542ba55a8e76a8ed7e8f0637e874 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8320965: Scrolling on a touch enabled display fails on Wayland Reviewed-by: kcr, tsayao ------------- PR: https://git.openjdk.org/jfx/pull/1305 From angorya at openjdk.org Mon Feb 26 16:25:51 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 26 Feb 2024 16:25:51 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: Message-ID: <4-OC42lT4hCTI13Be3J2PrXiSOJN-Fo9qk0FAANyElM=.d1285d26-5a17-47a7-a97e-8b2105f5019f@github.com> On Mon, 26 Feb 2024 10:40:03 GMT, Karthik P K wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 606: >> >>> 604: boolean addLtrIdx = run.getTextSpan().getText().length() != run.length; >>> 605: if (r.getStart() != curRunStart && !r.isLinebreak() && addLtrIdx >>> 606: && r.getTextSpan().getText().equals(text)) { >> >> I'm concerned about this check: `r.getTextSpan().getText().equals(text)` -- it seems to me that it either must be irrelevant, or it if is relevant, what if I have many `Text` nodes in a `TextFlow` that happen to have the same text? Let's say I have an English text, where I give each word its own `Text` node in a `TextFlow`. There would be many duplicates... so I find it hard to believe this check could accomplish anything. > > You are right. It fails when there are repeated text nodes. I will look into this yes, this bothered me from the start. I did have a test case in the MT with two text nodes with the same text, and it seemed to work correctly. or did I miss something? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1502940731 From nlisker at openjdk.org Mon Feb 26 16:41:05 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 26 Feb 2024 16:41:05 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v6] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/83bf2eb1..60d45bc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From mhanl at openjdk.org Mon Feb 26 20:56:53 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 26 Feb 2024 20:56:53 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window Message-ID: This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). ------------- Commit messages: - JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window Changes: https://git.openjdk.org/jfx/pull/1382/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326619 Stats: 179 lines in 3 files changed: 179 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1382.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1382/head:pull/1382 PR: https://git.openjdk.org/jfx/pull/1382 From kcr at openjdk.org Tue Feb 27 00:49:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 27 Feb 2024 00:49:47 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:51:56 GMT, Marius Hanl wrote: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Since this involved changing the specified behavior it will need a CSR. If we agree that this is the right behavior, then the CSR will be trivial. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-1965592210 From kpk at openjdk.org Tue Feb 27 05:11:51 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Feb 2024 05:11:51 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: <4-OC42lT4hCTI13Be3J2PrXiSOJN-Fo9qk0FAANyElM=.d1285d26-5a17-47a7-a97e-8b2105f5019f@github.com> References: <4-OC42lT4hCTI13Be3J2PrXiSOJN-Fo9qk0FAANyElM=.d1285d26-5a17-47a7-a97e-8b2105f5019f@github.com> Message-ID: On Mon, 26 Feb 2024 16:22:56 GMT, Andy Goryachev wrote: >> You are right. It fails when there are repeated text nodes. I will look into this > > yes, this bothered me from the start. I did have a test case in the MT with two text nodes with the same text, and it seemed to work correctly. or did I miss something? Actually most of the repeating text cases are handled. I saw failure in only one case where a Text node containing mix of LTR and RTL text is repeated. For example if we have a Text node with content like "????Arabic" repeated, then it fails. If the Text node contains only LTR or RTL text then no issues are seen. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1503644403 From jvos at openjdk.org Tue Feb 27 09:30:14 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 27 Feb 2024 09:30:14 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos 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 11 additional commits since the last revision: - Merge branch 'master' into 8319779-systemmenu - Add additional test for IOOBE detection. This test comes from JDK-8323787 - Revert some of the conditional bindings. Clear menu construction when an menuitem that is a menu needs to be removed Add a test for the latter - Merge remote-tracking branch 'upstream/master' into 8319779-systemmenu - Cleanup test - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. Add a test to make sure those references are gone. - Revert WeakInvalidationListeners and use new listener resource management approach. - Fix more memoryleaks due to listeners never being unregistered. - These changes are related to JBS-8318841 so we want to have that code in as well. Merge branch 'master' into 8319779-systemmenu - process reviewers comments - ... and 1 more: https://git.openjdk.org/jfx/compare/fc461323...ec7308df ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/5f2070fb..ec7308df Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=08-09 Stats: 295029 lines in 6634 files changed: 173988 ins; 83982 del; 37059 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Tue Feb 27 09:30:14 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 27 Feb 2024 09:30:14 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v9] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 15:10:33 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add additional test for IOOBE detection. >> This test comes from JDK-8323787 > > Getting back to this.... I ran the test on macOS and it now works as expected. However, one of the new tests fails on Linux: > > > SystemMenuBarTest > testFocusMemoryLeak FAILED > org.opentest4j.AssertionFailedError: expected: but was: > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40) > at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35) > at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227) > at app//test.com.sun.javafx.tk.quantum.SystemMenuBarTest.testFocusMemoryLeak(SystemMenuBarTest.java:198) > > > Btw, all of my tests were done in a local branch with the latest upstream master merged in. > > @johanvos since the source branch is now a bit out of date, can you merge in the latest upstream master? > > Also, I think there are still some unaddressed questions from John and Andy. > > Regarding the following: > >> All tests now pass, but I noticed that in some cases, the systemtests do not correctly work with the application lifecycle management (see https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044516.html). For now, I consider this anomaly to be independent from JDK-8319779 > > Yes, this is unrelated to the memory leak being fixed by this PR. We should file a bug for the activation problem. @kevinrushforth thanks for the feedback. I merged master and I see the failing test on Linux now as well. That is very interesting. I'll investigate and fix, and address the other comments as well. Also, I got some offline feedback about edge cases that I'm still trying to reproduce. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1966126023 From kpk at openjdk.org Tue Feb 27 10:02:58 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Feb 2024 10:02:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> Message-ID: On Mon, 26 Feb 2024 11:35:06 GMT, Karthik P K wrote: >> tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 238: >> >>> 236: >>> 237: @Test >>> 238: public void testTextAndTextFlowHitInfoForRTLEnglishText() throws Exception { >> >> I just replaced `PrismTextLayout#getHitInfo` with `return new Hit(0, 0, true);` and this test, and all the others still pass. >> >> I think the tests should check for a given range of x values if the correct character is being returned as the hit, perhaps more inspired by the tests in https://github.com/openjdk/jfx/pull/1236 > > I'm not sure if we could write headless test for this. Could you please point me to a test which could be helpful for me? I believe the tests added in this PR are helpful in making sure that the HitInfo calculation does not give results like character index less than 0 or character index greater than total length of the text or out of bound values. Since each character width is different and we have to check multiple scenarios, it is difficult to write generalised test for each case. Hence a combination of manual test using MonkeyTester and the automated tests added in this PR would be helpful in validating the changes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1503962024 From kpk at openjdk.org Tue Feb 27 13:51:08 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Feb 2024 13:51:08 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v14] 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 repeating text node issue ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/e3812732..f36199fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=12-13 Stats: 4 lines in 1 file changed: 2 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 kpk at openjdk.org Tue Feb 27 13:51:09 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Feb 2024 13:51:09 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: <4-OC42lT4hCTI13Be3J2PrXiSOJN-Fo9qk0FAANyElM=.d1285d26-5a17-47a7-a97e-8b2105f5019f@github.com> Message-ID: <6_Bl_a5SVsLGf9_xGvvwVI2dOkRJc9w82gKhiyNWgtM=.2e8e4ebb-1186-414e-ab6f-2e7920084f1e@github.com> On Tue, 27 Feb 2024 05:09:20 GMT, Karthik P K wrote: >> yes, this bothered me from the start. I did have a test case in the MT with two text nodes with the same text, and it seemed to work correctly. or did I miss something? > > Actually most of the repeating text cases are handled. I saw failure in only one case where a Text node containing mix of LTR and RTL text is repeated. For example if we have a Text node with content like "????Arabic" repeated, then it fails. > If the Text node contains only LTR or RTL text then no issues are seen. Fixed this issue ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1504263571 From arapte at openjdk.org Tue Feb 27 15:10:59 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 27 Feb 2024 15:10:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v6] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 16:41:05 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typo Nice work @nlisker Providing few comments, shall continue reviewing. modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 66: > 64: * reflective metals, water, and reflective ceramics. Neither does light refract (bend) when passing through transparent > 65: * or translucnet materials such as water, glass, or ice. These materials rely on Fresnel effects that are not > 66: * implemented for this material. Suggestion: Please check if it can be rephrased into something like below, not exact though: PhongMaterial is not suitable for surfaces that reflect or refract the incident light. Few examples of reflective material are mirror, water, reflective metals, reflective ceramics Few examples of refractive material are water, glass, or ice. These materials rely on Fresnel effects that are not implemented for the PhongMaterial. modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 78: > 76: * directions via scattering (purple) depend on the diffuse component; rays that are reflected (orange), which depend on > 77: * the incident angle, are controlled by the specular component. > 78: *

`

` here causes a warning message:- `warning: empty

tag` Moving `

` to after line#92 resolves the warning and achieves same formatting as current. modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 104: > 102: * that is not reflected directly from the surface and instead enters the material.
> 103: * The alpha channel of the diffuse component controls the light that passes through it (transmitted). Decreasing this > 104: * value increases the transparency of the material and causes the object to appear translucent, and ultimately makes Decreasing this value -> Decreasing the alpha value (?) modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 115: > 113: *

> 114: * Important: there is currently a bug that causes objects with 0 opacity to not render at all (despite having a > 115: * specular or a self-illumination component). Setting the opacity to 1/255 instead will give the desirable result. Is there is JBS issue to track this? The JBS issue should have a pointer for this comment to be removed when fixed. modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 132: > 130: * > 131: * A larger specular power simulates a smoother object, which > 132: * results in a smaller reflection. Could be combined in one line. modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 135: > 133: *

> 134: * The specular component interacts only with lights that have directionality (not {@code AmbientLight}) as it depends > 135: * on the incident ray direction, and also on the viewer position since it depends on the reflectance direction. viewer position -> viewer **(camera)** position modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 170: > 168: * V - the vector from the surface to the viewer (camera);
> 169: * R - the reflection vector of L from the surface. R can be calculated from L and N: > 170: * R=2(L?N)N - L. Should these values be described as respect to point instead of surface ? for example: the vector from the surface to the light source -> the vector from the **point** to the light source modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 172: > 170: * R=2(L?N)N - L. > 171: *

> 172: * The diffuse and and specular components are comprised of 3 factors: the geometry, the light's color, and the Typo: please remove extra _and_ : diffuse and and specular ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1378#pullrequestreview-1901677984 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504072545 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1503102040 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504075363 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504106529 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504111786 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504112992 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504129159 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504131458 From arapte at openjdk.org Tue Feb 27 15:26:55 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 27 Feb 2024 15:26:55 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v6] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 16:41:05 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typo Noticed a couple typos. modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 65: > 63: * {@code PhongMaterial} is not suitable for surfaces that act like mirrors and reflect their environment, such as > 64: * reflective metals, water, and reflective ceramics. Neither does light refract (bend) when passing through transparent > 65: * or translucnet materials such as water, glass, or ice. These materials rely on Fresnel effects that are not Typo: translucnet-> translucent modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 211: > 209: * the interaction between the reflected light and the viewer position: R?V. As similarly explained in the > 210: * diffuse component section, the geometric contribution is strongest when the viewer is aligned with the reflection > 211: * vector and is non-existant when they are perpendicular. Typo: non-existant -> non-existent ------------- PR Review: https://git.openjdk.org/jfx/pull/1378#pullrequestreview-1903833417 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504425654 PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1504429803 From jhendrikx at openjdk.org Tue Feb 27 16:20:54 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 27 Feb 2024 16:20:54 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v14] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 13:51:08 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 repeating text node issue So, I looked into the mirroring problem as well. I had to remove a single line from the original `getHitInfo` code to get it to work correctly. Here's the image that shows the positions are all correct: ![image](https://github.com/openjdk/jfx/assets/995917/2946a339-c2cd-4dcd-9ae7-95b212eb7bb8) Here's the `getHitInfo` I'm using: @Override public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart) { int charIndex = -1; int insertionIndex = -1; boolean leading = false; ensureLayout(); int lineIndex = getLineIndex(y); if (lineIndex >= getLineCount()) { charIndex = getCharCount(); insertionIndex = charIndex + 1; } else { if (isMirrored()) { // x = getMirroringWidth() - x; } TextLine line = lines[lineIndex]; TextRun[] runs = line.getRuns(); RectBounds bounds = line.getBounds(); TextRun run = null; x -= bounds.getMinX(); //TODO binary search for (int i = 0; i < runs.length; i++) { run = runs[i]; if (x < run.getWidth()) break; if (i + 1 < runs.length) { if (runs[i + 1].isLinebreak()) break; x -= run.getWidth(); } } if (run != null) { int[] trailing = new int[1]; charIndex = run.getStart() + run.getOffsetAtX(x, trailing); leading = (trailing[0] == 0); insertionIndex = charIndex; if (getText() != null && insertionIndex < getText().length) { if (!leading) { BreakIterator charIterator = BreakIterator.getCharacterInstance(); charIterator.setText(new String(getText())); int next = charIterator.following(insertionIndex); if (next == BreakIterator.DONE) { insertionIndex += 1; } else { insertionIndex = next; } } } else if (!leading) { insertionIndex += 1; } } else { //empty line, set to line break leading charIndex = line.getStart(); leading = true; insertionIndex = charIndex; } } return new Hit(charIndex, insertionIndex, leading); } Note that I removed the line that mirrors the X coordinate. The reason: mouse supplied coordinates are not mirrored -- even in a mirrored scene, they have (0,0) as the top left. @karthikpandelu Can you have a look if this simplified solution solves all cases? Note that I don't need the 3 extra parameters `text`, `textRunStart` and `curRunStart`, although I do use `textRunStart` in `Text#hitTest` to "fix" the char index and insertion index (the returned one will be in terms of the `TextLayout`, and substracting `textRunStart` will fix it back to insertion index relative to the `Text`). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1966928582 From asarkar at openjdk.org Tue Feb 27 18:02:04 2024 From: asarkar at openjdk.org (Anirvan Sarkar) Date: Tue, 27 Feb 2024 18:02:04 GMT Subject: RFR: 8326618 : Replace usage of deprecated method getId() in Thread Message-ID: Replace Thread.currentThread().getId() with Thread.currentThread().threadId() ------------- Commit messages: - Replace Thread.currentThread().getId() with Thread.currentThread().threadId() Changes: https://git.openjdk.org/jfx/pull/1383/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326618 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1383.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1383/head:pull/1383 PR: https://git.openjdk.org/jfx/pull/1383 From jhendrikx at openjdk.org Tue Feb 27 18:26:54 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 27 Feb 2024 18:26:54 GMT Subject: RFR: 8326618 : Replace usage of deprecated method getId() in Thread In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:58:13 GMT, Anirvan Sarkar wrote: > Replace Thread.currentThread().getId() with Thread.currentThread().threadId() Looks okay. `threadId` was added in JDK 19, but since we're on 21 now that should be fine. ------------- Marked as reviewed by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1383#pullrequestreview-1904467291 From mfox at openjdk.org Tue Feb 27 21:19:54 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 27 Feb 2024 21:19:54 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:13:26 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? > - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop > - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen The Mac is failing on the simplest NestedEventLoop test, the one that verifies that we can enter and exit a nested loop and correctly retrieve the return value. I started looking into this but find what's happening in Glass a bit confusing. I'll take a closer look in the next day or two. I don't understand the original failure case. Events aren't blocked and you can type into the modal's text field, it just doesn't repaint. If you resize the window you will see your edits. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1967605288 From jdv at openjdk.org Wed Feb 28 05:19:06 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 28 Feb 2024 05:19:06 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v2] In-Reply-To: References: 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. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1372/files - new: https://git.openjdk.org/jfx/pull/1372/files/c3d40ab9..5df260c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=00-01 Stats: 13 lines in 1 file changed: 2 ins; 10 del; 1 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 kpk at openjdk.org Wed Feb 28 12:18:08 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 28 Feb 2024 12:18:08 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v14] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:18:31 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix repeating text node issue > > So, I looked into the mirroring problem as well. I had to remove a single line from the original `getHitInfo` code to get it to work correctly. Here's the image that shows the positions are all correct: > > ![image](https://github.com/openjdk/jfx/assets/995917/2946a339-c2cd-4dcd-9ae7-95b212eb7bb8) > > Here's the `getHitInfo` I'm using: > > > @Override > public Hit getHitInfo(float x, float y, String text, int textRunStart, int curRunStart) { > int charIndex = -1; > int insertionIndex = -1; > boolean leading = false; > > ensureLayout(); > int lineIndex = getLineIndex(y); > if (lineIndex >= getLineCount()) { > charIndex = getCharCount(); > insertionIndex = charIndex + 1; > } else { > if (isMirrored()) { > // x = getMirroringWidth() - x; > } > TextLine line = lines[lineIndex]; > TextRun[] runs = line.getRuns(); > RectBounds bounds = line.getBounds(); > TextRun run = null; > x -= bounds.getMinX(); > //TODO binary search > for (int i = 0; i < runs.length; i++) { > run = runs[i]; > if (x < run.getWidth()) break; > if (i + 1 < runs.length) { > if (runs[i + 1].isLinebreak()) break; > x -= run.getWidth(); > } > } > if (run != null) { > int[] trailing = new int[1]; > charIndex = run.getStart() + run.getOffsetAtX(x, trailing); > leading = (trailing[0] == 0); > > insertionIndex = charIndex; > if (getText() != null && insertionIndex < getText().length) { > if (!leading) { > BreakIterator charIterator = BreakIterator.getCharacterInstance(); > charIterator.setText(new String(getText())); > int next = charIterator.following(insertionIndex); > if (next == BreakIterator.DONE) { > insertionIndex += 1; > } else { > insertionIndex = next; > } > } > } else if (!leading) { > insertionIndex += 1; > } > } else { > //empty line, set to line break leading > charIndex = line.getStart(); > leading = true; > insertionIndex ... The simplified solution works for all the cases. Thanks @hjohn for suggesting this code change. I have simplified the function and removed extra parameters. I had to make same correction for insertion index similar to character index in Text class after getting hit info. @andy-goryachev-oracle and @hjohn please re-review the changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1968857485 From kpk at openjdk.org Wed Feb 28 12:18:08 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 28 Feb 2024 12:18:08 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v15] In-Reply-To: References: Message-ID: <-4NgfbTauFOOdBXBc2P3YwGEU2Lht0Vhl4iGqYXUau0=.f1dca7c4-d449-488a-bdb3-921620845c5a@github.com> > 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: Simplified approach ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/f36199fd..1376441b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=13-14 Stats: 284 lines in 5 files changed: 14 ins; 227 del; 43 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 kcr at openjdk.org Wed Feb 28 13:03:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 13:03:55 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 05:19:06 GMT, Jayathirth D V wrote: >> 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. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update Looks good. All testing is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1372#pullrequestreview-1906212513 From nlisker at openjdk.org Wed Feb 28 13:50:38 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 13:50:38 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update images ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/60d45bc8..2989624d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=05-06 Stats: 28 lines in 20 files changed: 4 ins; 1 del; 23 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From nlisker at openjdk.org Wed Feb 28 13:55:54 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 13:55:54 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 13:50:38 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update images I generated the new background is an engine. I also enlarged the images a bit and added another one in the transparency section with not highlight for comparison. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969032540 From nlisker at openjdk.org Wed Feb 28 14:09:55 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 14:09:55 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v6] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:53:35 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typo > > modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 115: > >> 113: *

>> 114: * Important: there is currently a bug that causes objects with 0 opacity to not render at all (despite having a >> 115: * specular or a self-illumination component). Setting the opacity to 1/255 instead will give the desirable result. > > Is there is JBS issue to track this? The JBS issue should have a pointer for this comment to be removed when fixed. No, not yet. There a few oddities in the shader that I intend to look at for jfx23, this will be one of them. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1506020787 From kcr at openjdk.org Wed Feb 28 14:24:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 14:24:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 13:50:38 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update images Thank you for generating new images. Some of the new files are quite large, and the total added storage is 35 Mbytes, which is a lot for binary image files stored in the repo. I haven't generated the docs and looked at them yet (doing that now), but it might be better to use lower resolution images. One other thing I noticed is that the file names have spaces in them, which is not a best practice and causes problems for scripts. Can you change all spaces to `_` in the names of the newly-added files? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969088841 From kcr at openjdk.org Wed Feb 28 14:49:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 14:49:55 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: <2alYXTv_PJmKUMEWbBF5f3YT-mYkp9DQC7r0x9Qr7yU=.7bbb91bb-a43a-4ad4-88bd-9204883992f5@github.com> On Wed, 28 Feb 2024 13:50:38 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update images I looked at the images in the javadoc-generated web page, and the rendered image size looks good. I recommend scaling most of the images down by at least a factor of 4 (at least a factor of 2 in both width and height), since they are much higher resolution than needed for the size they are rendered at in the page. I see that the animated gif for the writeable image is 6 Mbytes, and could probably be scaled down even more without losing quality. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969143245 From kcr at openjdk.org Wed Feb 28 15:27:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 15:27:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 13:50:38 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update images Btw, if this ends up missing the deadline for JavaFX 22 (about 24 hours from now) it can go into 22u for JavaFX 22.0.1. The release date for 22.0.1 is only a few weeks after 22, and the deadline to get fixes into 22.0.1 is almost 2 weeks away. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969223783 From nlisker at openjdk.org Wed Feb 28 15:49:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 15:49:59 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v6] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:24:08 GMT, Ambarish Rapte wrote: > PhongMaterial is not suitable for surfaces that reflect or refract the incident light. But it does reflect the incident light as explained in the paragraphs before. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1506179403 From nlisker at openjdk.org Wed Feb 28 15:54:54 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 15:54:54 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v6] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 12:13:09 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typo > > modules/javafx.graphics/src/main/java/javafx/scene/paint/PhongMaterial.java line 170: > >> 168: * V - the vector from the surface to the viewer (camera);
>> 169: * R - the reflection vector of L from the surface. R can be calculated from L and N: >> 170: * R=2(L?N)N - L. > > Should these values be described as respect to point instead of surface ? > for example: the vector from the surface to the light source -> the vector from the **point** to the light source The sentence above says "Four normalized vectors are considered for each point on the surface", so I think this is clear. The problem with looking at points is that they have no direction, unlike a surface, so you can't have a "normal of a point", you can only have "normal of a surface", and the reflection vector also depends on the directionality of the surface. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1378#discussion_r1506187511 From nlisker at openjdk.org Wed Feb 28 15:58:29 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 15:58:29 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v8] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed typos from review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/2989624d..d586d748 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=06-07 Stats: 15 lines in 1 file changed: 1 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From nlisker at openjdk.org Wed Feb 28 16:03:55 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 16:03:55 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 14:21:55 GMT, Kevin Rushforth wrote: > One other thing I noticed is that the file names have spaces in them, which is not a best practice and causes problems for scripts. Can you change all spaces to _ in the names of the newly-added files? Yes. What about folders? Also, do you prefer camelCase or the `_` naming? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969301404 From kevin.rushforth at oracle.com Wed Feb 28 16:20:47 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Feb 2024 08:20:47 -0800 Subject: JavaFX 22.0.1 will be closed for fixes on March 11th Message-ID: <024e7686-b6d5-465d-99b8-941df1dc00eb@oracle.com> All, If you have backports that you want to get into jfx22u for JavaFX 22.0.1, please do so by Monday, March 11th. Note that approval from one of the project leads is needed as outlined in this message [1]. Thanks. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044659.html From kcr at openjdk.org Wed Feb 28 16:26:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 16:26:55 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v7] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 16:01:15 GMT, Nir Lisker wrote: > > One other thing I noticed is that the file names have spaces in them, which is not a best practice and causes problems for scripts. Can you change all spaces to _ in the names of the newly-added files? > > Yes. What about folders? Also, do you prefer camelCase or the `_` naming? Generally we use all lower case for directory names, but as long as it isn't used as a package name, it isn't as important. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969357960 From nlisker at openjdk.org Wed Feb 28 18:24:30 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 18:24:30 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v9] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Rename and resize images ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/d586d748..e5466476 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=07-08 Stats: 32 lines in 50 files changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From nlisker at openjdk.org Wed Feb 28 18:31:53 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 18:31:53 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v9] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:24:30 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Rename and resize images I think I got all the images' sizes reduced. Except for a few small points in discussion with Ambarish, I think that this is ready to go in in time for 22. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969586936 From kcr at openjdk.org Wed Feb 28 18:31:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 18:31:53 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v9] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:24:30 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Rename and resize images The images look good. I'll do a final pass on the docs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969590760 From kcr at openjdk.org Wed Feb 28 18:38:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 18:38:57 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v9] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:24:30 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Rename and resize images Actually, there are still 5 files that could use to be resized: modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/specular_color/copper_high.png: PNG image data, 820 x 820, 8-bit/color RGB, non-interlaced modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/specular_color/copper_low.png: PNG image data, 820 x 820, 8-bit/color RGB, non-interlaced modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/specular_color/copper_medium.png: PNG image data, 820 x 820, 8-bit/color RGB, non-interlaced modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/specular_color/gold_high.png: PNG image data, 820 x 820, 8-bit/color RGB, non-interlaced modules/javafx.graphics/src/main/docs/javafx/scene/paint/doc-files/specular_color/gold_low.png: PNG image data, 820 x 820, 8-bit/color RGB, non-interlaced ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1969600849 From nlisker at openjdk.org Wed Feb 28 18:48:21 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 28 Feb 2024 18:48:21 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v10] In-Reply-To: References: Message-ID: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Resize specular color images ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1378/files - new: https://git.openjdk.org/jfx/pull/1378/files/e5466476..60b41ca7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1378&range=08-09 Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1378.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1378/head:pull/1378 PR: https://git.openjdk.org/jfx/pull/1378 From kcr at openjdk.org Wed Feb 28 18:59:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 18:59:55 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v10] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:48:21 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Resize specular color images Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1378#pullrequestreview-1907046997 From mfox at openjdk.org Wed Feb 28 20:22:53 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 28 Feb 2024 20:22:53 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 23:13:26 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? > - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop > - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen I don't think this is a problem with the nested event loop bookkeeping. It looks like a much simpler bug in the invokeLaterDispatcher. When exitNestedEventLoop is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will be wedged. If you're already in a nested loop you can get into the wedged state with just two lines of code: `exitNestedEventLoop(innermost, retVal); enterNestedEventLoop(newLoop);` When the invokeLaterDispatcher is told that the innermost loop is exiting it currently sets `leavingNestedEventLoop` to true. When the dispatcher is told that a new event loop has started it is *not* clearing `leavingNestedEventLoop` but it should. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1969844034 From kcr at openjdk.org Wed Feb 28 21:49:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 21:49:51 GMT Subject: RFR: 8326618 : Replace usage of deprecated method getId() in Thread In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:58:13 GMT, Anirvan Sarkar wrote: > Replace Thread.currentThread().getId() with Thread.currentThread().threadId() Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1383#pullrequestreview-1907489547 From kcr at openjdk.org Wed Feb 28 21:49:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 21:49:52 GMT Subject: RFR: 8326618 : Replace usage of deprecated method getId() in Thread In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 18:24:02 GMT, John Hendrikx wrote: > Looks okay. `threadId` was added in JDK 19, but since we're on 21 now that should be fine. Exactly. And as I noted in the JBS issue, this fix must not be backported to earlier versions of JavaFX (it would fail to compile anyway, since we use `--release 17` for JavaFX 21 and 22). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1383#issuecomment-1969972185 From mhanl at openjdk.org Wed Feb 28 22:01:54 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 28 Feb 2024 22:01:54 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 20:20:35 GMT, Martin Fox wrote: > I don't think this is a problem with the nested event loop bookkeeping. It looks like a much simpler bug in the invokeLaterDispatcher. Well, yes and no. My testing was showing that `notifyLeftNestedEventLoop` was not even called in the finally block, so there is that. We may still have a problem at the `InvokeLaterDispatcher`, although not 100% sure since it worked good for me on Windows. But I will test it more as soon as I have more time, since I want to really check everything, so I do not miss anything here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1969990780 From angorya at openjdk.org Wed Feb 28 22:36:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Feb 2024 22:36:01 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues Message-ID: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) - adds missing information in `@param` tags - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) - fixed an empty `

` in `Subscription` - cleaned up unnecessary `@throws` in Filtered/SortedList Q: Does this PR need a CSR? ------------- Commit messages: - cleanup - 8325073: javadoc warnings: missing @param tags and other issues Changes: https://git.openjdk.org/jfx/pull/1384/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325073 Stats: 203 lines in 68 files changed: 108 ins; 9 del; 86 mod Patch: https://git.openjdk.org/jfx/pull/1384.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1384/head:pull/1384 PR: https://git.openjdk.org/jfx/pull/1384 From kcr at openjdk.org Wed Feb 28 23:45:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Feb 2024 23:45:51 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: References: Message-ID: <7LjY-L_C524gn6wWz8zJYWbzRQKZNz2SxKK8QFcLYN8=.f17c8e93-dc9b-4c76-878a-39bcdbc7768f@github.com> On Mon, 26 Feb 2024 20:51:56 GMT, Marius Hanl wrote: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). This seems like a reasonable fix and spec change. Have you tested the case of calling sizeToScene before setting full-screen or maximzed? Since the pending flag will still be set in that case, I want to make sure that case is tested as well. Also, if this fixed [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425), then that bug should be closed as a duplicate of this one. @lukostyra @arapte can you also review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-1970103785 From kcr at openjdk.org Thu Feb 29 00:02:50 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Feb 2024 00:02:50 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues In-Reply-To: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Wed, 28 Feb 2024 21:48:38 GMT, Andy Goryachev wrote: > Q: Does this PR need a CSR? Not if all of the changes are just clarification or documenting missing parameters. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1384#issuecomment-1970132810 From kcr at openjdk.org Thu Feb 29 00:27:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Feb 2024 00:27:53 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:51:56 GMT, Marius Hanl wrote: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Btw, I get the following test failures on our headful Linux test systems: SizeToSceneFullscreenTest > testInitialSizeFullscreen FAILED java.lang.AssertionError: Stage height expected:<1080.0> but was:<1117.0> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:555) at test.javafx.stage.SizeToSceneFullscreenTest.testInitialSizeFullscreen(SizeToSceneFullscreenTest.java:78) This seems unrelated to your fix. I think the problem might be that in full-screen mode the stage can be bigger than the visible screen size or maybe the decorations are just larger on that system. You might either need to increase the tolerance values or instead check for >= visible width / height (possibly with some small tolerance). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-1970158754 From angorya at openjdk.org Thu Feb 29 00:29:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 00:29:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v15] In-Reply-To: <-4NgfbTauFOOdBXBc2P3YwGEU2Lht0Vhl4iGqYXUau0=.f1dca7c4-d449-488a-bdb3-921620845c5a@github.com> References: <-4NgfbTauFOOdBXBc2P3YwGEU2Lht0Vhl4iGqYXUau0=.f1dca7c4-d449-488a-bdb3-921620845c5a@github.com> Message-ID: On Wed, 28 Feb 2024 12:18:08 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: > > Simplified approach Tested with the MonkeyTester, using different justification (left, right, center, justify) and node orientation, for both Text and TextFlow. Multiple Text instances, rich text, inline nodes, bidi, various line breaking scenarios. I could not find any issues! The new code also looks much cleaner and much, much easier to understand. I left a few non-essential suggestions inline. Overall, thank you @karthikpandelu and @hjohn. Good job guys! P.S. Tested on on macOS 14.3.1. The results on Windows/Linux should be identical, but if we can get some testing done on these two platforms that would be nice. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 212: > 210: * and non-null in the case of {@link javafx.scene.text.Text} > 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. please remove these three parameters (text, textRunStart, curRunStart) modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 440: > 438: TextRun run = null; > 439: x -= bounds.getMinX(); > 440: //TODO binary search we can remove this TODO because the new approach is incompatible with the binary search modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 443: > 441: for (int i = 0; i < runs.length; i++) { > 442: run = runs[i]; > 443: if (x < run.getWidth()) break; I would strongly recommend placing `break`s on separate lines for convenience during debugging. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 445: > 443: if (x < run.getWidth()) break; > 444: if (i + 1 < runs.length) { > 445: if (runs[i + 1].isLinebreak()) break; same here modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 710: > 708: while (index < lineCount) { > 709: bottom += lines[index].getBounds().getHeight() + spacing; > 710: if (index + 1 == lineCount) bottom -= lines[index].getLeading(); please keep one statement per line, if possible if (index + 1 == lineCount) { bottom -= lines[index].getLeading(); } modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 711: > 709: bottom += lines[index].getBounds().getHeight() + spacing; > 710: if (index + 1 == lineCount) bottom -= lines[index].getLeading(); > 711: if (bottom > y) break; same here modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1036: > 1034: double py = y; > 1035: > 1036: if(isSpan()) { please insert a space between `if` and `(` ------------- PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1907661966 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506809039 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506822747 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506822242 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506822301 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506825343 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506825604 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1506827456 From kpk at openjdk.org Thu Feb 29 05:38:05 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 29 Feb 2024 05:38:05 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v16] In-Reply-To: References: Message-ID: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> > 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/1376441b..130587c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=14-15 Stats: 19 lines in 3 files changed: 8 ins; 6 del; 5 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 Thu Feb 29 05:40:55 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 29 Feb 2024 05:40:55 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v15] In-Reply-To: References: <-4NgfbTauFOOdBXBc2P3YwGEU2Lht0Vhl4iGqYXUau0=.f1dca7c4-d449-488a-bdb3-921620845c5a@github.com> Message-ID: On Thu, 29 Feb 2024 00:27:33 GMT, Andy Goryachev wrote: > P.S. Tested on on macOS 14.3.1. The results on Windows/Linux should be identical, but if we can get some testing done on these two platforms that would be nice. I tested the changes in windows and do not see any issues. I have executed the headful test using our headful test machines, no failures found in all platforms. Addressed inline comments. Please check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1970444433 From arapte at openjdk.org Thu Feb 29 06:32:53 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 29 Feb 2024 06:32:53 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v10] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:48:21 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Resize specular color images Looks good. Very well explained docs. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1378#pullrequestreview-1908063245 From kumaranbus at hotmail.com Thu Feb 29 07:16:06 2024 From: kumaranbus at hotmail.com (Krishna Kumar) Date: Thu, 29 Feb 2024 07:16:06 +0000 Subject: NullPointer this.layoutCache is null Message-ID: I am encountering the following Null Pointer exception during runtime, however the application keeps working as intended. Exception posted at the end to declutter the mail. Google search for this exception took me to this thread https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044343.html but in my case the JVM doesn't crash, neither does the application crash. The application continues to work as intended. I am unable to identify the node that causes this as the stack trace doesn't originate from the Application code, could anyone throw some light. I am running the code on /usr/lib/jvm/bellsoft-java21-full-amd64/bin/java tion in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot read field "advances" because "this.layoutCache" is null at javafx.graphics/com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:919) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1113) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) at javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) at javafx.graphics/javafx.scene.text.Text.doComputeLayoutBounds(Text.java:1137) at javafx.graphics/javafx.scene.text.Text$1.doComputeLayoutBounds(Text.java:143) at javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeLayoutBoundsImpl(TextHelper.java:95) at javafx.graphics/com.sun.javafx.scene.NodeHelper.computeLayoutBounds(NodeHelper.java:108) at javafx.graphics/javafx.scene.Node$13.computeBounds(Node.java:3474) at javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9749) at javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9740) at javafx.graphics/javafx.scene.Node.getLayoutBounds(Node.java:3489) at javafx.graphics/javafx.scene.Node.prefWidth(Node.java:2989) at javafx.graphics/javafx.scene.Node.minWidth(Node.java:2930) at javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:462) at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:549) at javafx.graphics/javafx.scene.layout.HBox.computeMinWidth(HBox.java:409) at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) at javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) at javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) at javafx.graphics/javafx.scene.layout.Region.getMaxAreaWidth(Region.java:2227) at javafx.graphics/javafx.scene.layout.Region.computeMaxMinAreaWidth(Region.java:2064) at javafx.graphics/javafx.scene.layout.VBox.computeMinWidth(VBox.java:399) at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) at javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) at javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:462) at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:549) at javafx.graphics/javafx.scene.layout.HBox.computeMinWidth(HBox.java:409) at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) at javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) at javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) at javafx.graphics/javafx.scene.layout.Region.getMaxAreaWidth(Region.java:2227) at javafx.graphics/javafx.scene.layout.Region.computeMaxMinAreaWidth(Region.java:2064) at javafx.graphics/javafx.scene.layout.VBox.computeMinWidth(VBox.java:399) at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) at javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) at javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:462) at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:549) at javafx.graphics/javafx.scene.layout.HBox.computeMinWidth(HBox.java:409) at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) at javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) at javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1959) at javafx.graphics/javafx.scene.layout.Region.getMaxAreaWidth(Region.java:2228) at javafx.graphics/javafx.scene.layout.Region.computeMaxPrefAreaWidth(Region.java:2092) at javafx.graphics/javafx.scene.layout.VBox.computePrefWidth(VBox.java:420) at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1021) at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1536) at javafx.graphics/javafx.scene.Node.autosize(Node.java:3138) at javafx.graphics/javafx.scene.Parent.layoutChildren(Parent.java:1239) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:594) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2600) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$10(GtkApplication.java:263) at java.base/java.lang.Thread.run(Thread.java:1583) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wookey.dean at gmail.com Thu Feb 29 08:28:57 2024 From: wookey.dean at gmail.com (Dean Wookey) Date: Thu, 29 Feb 2024 10:28:57 +0200 Subject: NullPointer this.layoutCache is null In-Reply-To: References: Message-ID: Hi Krishna, Usually these are caused by doing something on the wrong thread in my experience. In our application we've had to be very careful about doing things on the right thread. Mostly it's fine to create things off the app thread and add them on the app thread, but that's not always the case. Things that create popup windows like tooltips and context menus need to be created on the app thread. What you can do is set a conditional breakpoint in the parent class to catch changes to the children list which happen off the application thread. Something like: this.getScene() != null && !Platform.isApplicationThread() If that's too slow, then you'll have to modify javafx itself with an assert or an if statement in the children change listener: if (this.getScene() != null && !Platform.isApplicationThread()) { System.out.println("Adding a node to the scene on the wrong thread");//set break point on this line and view the stack to see what's causing it } This might not be the cause of your problem, but if you have instances where things are done in the wrong thread, you'll definitely hit sporadic issues. Dean On Thu, Feb 29, 2024 at 9:16?AM Krishna Kumar wrote: > I am encountering the following Null Pointer exception during runtime, > however the application keeps working as intended. > > Exception posted at the end to declutter the mail. > > Google search for this exception took me to this thread > > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044343.html > > but in my case the JVM doesn't crash, neither does the application crash. > The application continues to work as intended. I am unable to identify the > node that causes this as the stack trace doesn't originate from the > Application code, could anyone throw some light. I am running the code on > /usr/lib/jvm/bellsoft-java21-full-amd64/bin/java > > > tion in thread "JavaFX Application Thread" java.lang.NullPointerException: > Cannot read field "advances" because "this.layoutCache" is null > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:919) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1113) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) > at > javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) > at > javafx.graphics/javafx.scene.text.Text.doComputeLayoutBounds(Text.java:1137) > at > javafx.graphics/javafx.scene.text.Text$1.doComputeLayoutBounds(Text.java:143) > at > javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeLayoutBoundsImpl(TextHelper.java:95) > at > javafx.graphics/com.sun.javafx.scene.NodeHelper.computeLayoutBounds(NodeHelper.java:108) > at > javafx.graphics/javafx.scene.Node$13.computeBounds(Node.java:3474) > at > javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9749) > at > javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9740) > at > javafx.graphics/javafx.scene.Node.getLayoutBounds(Node.java:3489) > at javafx.graphics/javafx.scene.Node.prefWidth(Node.java:2989) > at javafx.graphics/javafx.scene.Node.minWidth(Node.java:2930) > at > javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) > at > javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:462) > at > javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:549) > at > javafx.graphics/javafx.scene.layout.HBox.computeMinWidth(HBox.java:409) > at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) > at > javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) > at > javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) > at > javafx.graphics/javafx.scene.layout.Region.getMaxAreaWidth(Region.java:2227) > at > javafx.graphics/javafx.scene.layout.Region.computeMaxMinAreaWidth(Region.java:2064) > at > javafx.graphics/javafx.scene.layout.VBox.computeMinWidth(VBox.java:399) > at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) > at > javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) > at > javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) > at > javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:462) > at > javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:549) > at > javafx.graphics/javafx.scene.layout.HBox.computeMinWidth(HBox.java:409) > at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) > at > javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) > at > javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) > at > javafx.graphics/javafx.scene.layout.Region.getMaxAreaWidth(Region.java:2227) > at > javafx.graphics/javafx.scene.layout.Region.computeMaxMinAreaWidth(Region.java:2064) > at > javafx.graphics/javafx.scene.layout.VBox.computeMinWidth(VBox.java:399) > at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) > at > javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) > at > javafx.graphics/javafx.scene.layout.Region.computeChildMinAreaWidth(Region.java:1898) > at > javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:462) > at > javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:549) > at > javafx.graphics/javafx.scene.layout.HBox.computeMinWidth(HBox.java:409) > at javafx.graphics/javafx.scene.Parent.minWidth(Parent.java:1049) > at > javafx.graphics/javafx.scene.layout.Region.minWidth(Region.java:1500) > at > javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1959) > at > javafx.graphics/javafx.scene.layout.Region.getMaxAreaWidth(Region.java:2228) > at > javafx.graphics/javafx.scene.layout.Region.computeMaxPrefAreaWidth(Region.java:2092) > at > javafx.graphics/javafx.scene.layout.VBox.computePrefWidth(VBox.java:420) > at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1021) > at > javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1536) > at javafx.graphics/javafx.scene.Node.autosize(Node.java:3138) > at > javafx.graphics/javafx.scene.Parent.layoutChildren(Parent.java:1239) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) > at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:594) > at > javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2600) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > at > javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) > at > javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$10(GtkApplication.java:263) > at java.base/java.lang.Thread.run(Thread.java:1583) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Thu Feb 29 08:29:53 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 29 Feb 2024 08:29:53 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v2] In-Reply-To: References: Message-ID: <3neZF4H0XFIOLRuJIGhJlF7dQ-RGqgd7o2QLfovOQeQ=.307b59af-e1eb-46c0-b364-3902563a8128@github.com> On Wed, 28 Feb 2024 05:19:06 GMT, Jayathirth D V wrote: >> 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. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update Looks good, just a minor query. modules/javafx.graphics/src/main/native-iio/libjpeg/UPDATING.txt line 12: > 10: 3) OpenJFX imports only the JPEG library source with some exceptions. > 11: OpenJFX does not need any other applications or tools provided by IJG libjpeg. > 12: Copy only the same 49 .c and 9 .h files as are already there. I could see only _41_ _.c_ files in this directory: `modules/javafx.graphics/src/main/native-iio/libjpeg` Could you please recheck. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1372#pullrequestreview-1908052543 PR Review Comment: https://git.openjdk.org/jfx/pull/1372#discussion_r1507068044 From jpereda at openjdk.org Thu Feb 29 09:27:05 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 29 Feb 2024 09:27:05 GMT Subject: [jfx21u] RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Message-ID: <8Tj7J0Hj19rtUYgcqh20vS7pWxq0KQ5DPQk4sHyKuu8=.93bea3ad-c871-474a-aeed-f53e44ebf2bd@github.com> Hi all, This pull request contains a clean backport of commit [40809a3f](https://github.com/openjdk/jfx/commit/40809a3f84d5f9f91b265f455a95d045e5b4f692) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Kevin Rushforth on 30 Jan 2024 and was reviewed by Jay Bhaskar and Ambarish Rapte. Thanks! ------------- Commit messages: - Backport 40809a3f84d5f9f91b265f455a95d045e5b4f692 Changes: https://git.openjdk.org/jfx21u/pull/45/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=45&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322703 Stats: 62 lines in 1 file changed: 33 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jfx21u/pull/45.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/45/head:pull/45 PR: https://git.openjdk.org/jfx21u/pull/45 From jdv at openjdk.org Thu Feb 29 09:28:04 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 29 Feb 2024 09:28:04 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v3] In-Reply-To: References: 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. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update proper number for files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1372/files - new: https://git.openjdk.org/jfx/pull/1372/files/5df260c7..b43a51e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 jdv at openjdk.org Thu Feb 29 09:28:05 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 29 Feb 2024 09:28:05 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v2] In-Reply-To: <3neZF4H0XFIOLRuJIGhJlF7dQ-RGqgd7o2QLfovOQeQ=.307b59af-e1eb-46c0-b364-3902563a8128@github.com> References: <3neZF4H0XFIOLRuJIGhJlF7dQ-RGqgd7o2QLfovOQeQ=.307b59af-e1eb-46c0-b364-3902563a8128@github.com> Message-ID: On Thu, 29 Feb 2024 06:21:34 GMT, Ambarish Rapte wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Update > > modules/javafx.graphics/src/main/native-iio/libjpeg/UPDATING.txt line 12: > >> 10: 3) OpenJFX imports only the JPEG library source with some exceptions. >> 11: OpenJFX does not need any other applications or tools provided by IJG libjpeg. >> 12: Copy only the same 49 .c and 9 .h files as are already there. > > I could see only _41_ _.c_ files in this directory: `modules/javafx.graphics/src/main/native-iio/libjpeg` > Could you please recheck. Thanks for noticing it, i have updated the number of .c files back to 41 but changed .h files to 8. Because jconfig.h file is not part of upstream IJG. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1372#discussion_r1507267316 From arapte at openjdk.org Thu Feb 29 09:47:53 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 29 Feb 2024 09:47:53 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v3] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 09:28:04 GMT, Jayathirth D V wrote: >> 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. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update proper number for files Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1372#pullrequestreview-1908412114 From jvos at openjdk.org Thu Feb 29 11:32:51 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 29 Feb 2024 11:32:51 GMT Subject: [jfx21u] RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS In-Reply-To: <8Tj7J0Hj19rtUYgcqh20vS7pWxq0KQ5DPQk4sHyKuu8=.93bea3ad-c871-474a-aeed-f53e44ebf2bd@github.com> References: <8Tj7J0Hj19rtUYgcqh20vS7pWxq0KQ5DPQk4sHyKuu8=.93bea3ad-c871-474a-aeed-f53e44ebf2bd@github.com> Message-ID: On Thu, 29 Feb 2024 09:22:38 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [40809a3f](https://github.com/openjdk/jfx/commit/40809a3f84d5f9f91b265f455a95d045e5b4f692) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Kevin Rushforth on 30 Jan 2024 and was reviewed by Jay Bhaskar and Ambarish Rapte. > > Thanks! Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/45#pullrequestreview-1908628636 From jpereda at openjdk.org Thu Feb 29 11:32:51 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 29 Feb 2024 11:32:51 GMT Subject: [jfx21u] Integrated: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS In-Reply-To: <8Tj7J0Hj19rtUYgcqh20vS7pWxq0KQ5DPQk4sHyKuu8=.93bea3ad-c871-474a-aeed-f53e44ebf2bd@github.com> References: <8Tj7J0Hj19rtUYgcqh20vS7pWxq0KQ5DPQk4sHyKuu8=.93bea3ad-c871-474a-aeed-f53e44ebf2bd@github.com> Message-ID: On Thu, 29 Feb 2024 09:22:38 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [40809a3f](https://github.com/openjdk/jfx/commit/40809a3f84d5f9f91b265f455a95d045e5b4f692) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Kevin Rushforth on 30 Jan 2024 and was reviewed by Jay Bhaskar and Ambarish Rapte. > > Thanks! This pull request has now been integrated. Changeset: 61d9c36e Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/61d9c36ece644a4a17e018588833ef0aea8b6743 Stats: 62 lines in 1 file changed: 33 ins; 18 del; 11 mod 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Reviewed-by: jvos Backport-of: 40809a3f84d5f9f91b265f455a95d045e5b4f692 ------------- PR: https://git.openjdk.org/jfx21u/pull/45 From nlisker at openjdk.org Thu Feb 29 11:47:58 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 29 Feb 2024 11:47:58 GMT Subject: Integrated: 8314147: Updated the PhongMaterial documentation In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 20:38:00 GMT, Nir Lisker wrote: > Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. > > The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). > > The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. This pull request has now been integrated. Changeset: d9645730 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/d9645730f1e76e95e0bb93ceaeb5550390bf95c1 Stats: 521 lines in 39 files changed: 461 ins; 13 del; 47 mod 8314147: Updated the PhongMaterial documentation Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1378 From nlisker at openjdk.org Thu Feb 29 11:50:19 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 29 Feb 2024 11:50:19 GMT Subject: [jfx22] RFR: 8314147: Updated the PhongMaterial documentation Message-ID: This pull request contains a backport of commit [d9645730](https://github.com/openjdk/jfx/commit/d9645730f1e76e95e0bb93ceaeb5550390bf95c1) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. ------------- Commit messages: - Backport d9645730f1e76e95e0bb93ceaeb5550390bf95c1 Changes: https://git.openjdk.org/jfx/pull/1385/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314147 Stats: 521 lines in 39 files changed: 461 ins; 13 del; 47 mod Patch: https://git.openjdk.org/jfx/pull/1385.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1385/head:pull/1385 PR: https://git.openjdk.org/jfx/pull/1385 From asarkar at openjdk.org Thu Feb 29 11:51:52 2024 From: asarkar at openjdk.org (Anirvan Sarkar) Date: Thu, 29 Feb 2024 11:51:52 GMT Subject: Integrated: 8326618 : Replace usage of deprecated method getId() in Thread In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:58:13 GMT, Anirvan Sarkar wrote: > Replace Thread.currentThread().getId() with Thread.currentThread().threadId() This pull request has now been integrated. Changeset: 5512a5ad Author: Anirvan Sarkar Committer: John Hendrikx URL: https://git.openjdk.org/jfx/commit/5512a5add0b5ce4a41e6c377c274b9518ee68489 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8326618: Replace usage of deprecated method getId() in Thread Reviewed-by: jhendrikx, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1383 From kcr at openjdk.org Thu Feb 29 12:14:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Feb 2024 12:14:53 GMT Subject: [jfx22] RFR: 8314147: Updated the PhongMaterial documentation In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 11:46:11 GMT, Nir Lisker wrote: > This pull request contains a backport of commit [d9645730](https://github.com/openjdk/jfx/commit/d9645730f1e76e95e0bb93ceaeb5550390bf95c1) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. Clean backport of doc-only fixed approved for `jfx22` ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1385#pullrequestreview-1908709976 From nlisker at openjdk.org Thu Feb 29 12:38:00 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 29 Feb 2024 12:38:00 GMT Subject: [jfx22] Integrated: 8314147: Updated the PhongMaterial documentation In-Reply-To: References: Message-ID: <3ON4VxKz8Xav_0dy-YsJMV0KRl6Vwn838V-p54gnsVA=.91b9c768-bc52-435f-96f7-90d7bc1e9f65@github.com> On Thu, 29 Feb 2024 11:46:11 GMT, Nir Lisker wrote: > This pull request contains a backport of commit [d9645730](https://github.com/openjdk/jfx/commit/d9645730f1e76e95e0bb93ceaeb5550390bf95c1) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. This pull request has now been integrated. Changeset: 3b925780 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/3b925780ab87c4987bd35a0d5dbcb66e8a2a5b31 Stats: 521 lines in 39 files changed: 461 ins; 13 del; 47 mod 8314147: Updated the PhongMaterial documentation Reviewed-by: kcr Backport-of: d9645730f1e76e95e0bb93ceaeb5550390bf95c1 ------------- PR: https://git.openjdk.org/jfx/pull/1385 From nlisker at openjdk.org Thu Feb 29 12:38:58 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 29 Feb 2024 12:38:58 GMT Subject: RFR: 8314147: Updated the PhongMaterial documentation [v10] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:48:21 GMT, Nir Lisker wrote: >> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass `Material`). Except for the introduction, I divided the documentation into 3 sections: qualitative explanation, mathematical model (I wouldn't think it necessary, but the current doc explains it), and examples. >> >> The reason for the verbosity of the doc is that I envisioned 2 target audiences for this class. One is a Java developer who wants to understand the terminology and workings of computer graphics or of the artists who are already familiar with this domain. (How many Java developers know what diffuse, specular and normal maps are?) The other is an artist who is already familiar with the domain, but wants to see how this class compares with other renderers. For this reason, I looked at the terminology used by engines like Blender, Maya, UE4 and Unity and tried to mention the comparisons (like bump vs. height vs. normal maps, or specular vs. roughness/smoothness). >> >> The examples I chose and some of the schematics are not the best, looking at it retroactively, but I want to give enough time for reviewers and get this into 22. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Resize specular color images Thanks everyone for the quick and detailed review! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1971049164 From kcr at openjdk.org Thu Feb 29 13:13:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Feb 2024 13:13:53 GMT Subject: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v3] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 09:28:04 GMT, Jayathirth D V wrote: >> 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. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update proper number for files Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1372#pullrequestreview-1908835099 From jhendrikx at openjdk.org Thu Feb 29 13:26:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 29 Feb 2024 13:26:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v16] In-Reply-To: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> References: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> Message-ID: On Thu, 29 Feb 2024 05:38:05 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 Please add a JUnit test. Example included. modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1031: > 1029: if (runs.length != 0) { > 1030: textRunStart = findFirstRunStart(runs); > 1031: } Can you rewrite this to be: int textRunStart = findFirstRunStart(); The `runs` parameter doesn't need to be passed (`findFirstRunStart` can access it just as easily), and the length check can be moved inside that method as well. modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1049: > 1047: for (GlyphList r: runs) { > 1048: if (((TextRun) r).getStart() < start) { > 1049: start = ((TextRun) r).getStart(); minor: you can extract a new local here instead of casting and calling `getStart` twice. ------------- Changes requested by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1908709396 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1507478198 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1507480047 From jhendrikx at openjdk.org Thu Feb 29 13:26:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 29 Feb 2024 13:26:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> Message-ID: On Tue, 27 Feb 2024 10:00:41 GMT, Karthik P K wrote: >> I'm not sure if we could write headless test for this. Could you please point me to a test which could be helpful for me? > > I believe the tests added in this PR are helpful in making sure that the HitInfo calculation does not give results like character index less than 0 or character index greater than total length of the text or out of bound values. Since each character width is different and we have to check multiple scenarios, it is difficult to write generalised test for each case. Hence a combination of manual test using MonkeyTester and the automated tests added in this PR would be helpful in validating the changes. I disagree on this. The code is complicated and full of branches. Manual testing is very error prone. However, since you restored most of the code to its original (which wasn't tested either) I could live with it. Still, here's a small test that you could use to verify correct hits: /* * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ package test.com.sun.javafx.text; import static org.junit.Assume.assumeTrue; import static org.junit.jupiter.api.Assertions.assertEquals; import org.junit.jupiter.api.Test; import com.sun.javafx.font.PGFont; import com.sun.javafx.geom.RectBounds; import com.sun.javafx.scene.text.FontHelper; import com.sun.javafx.scene.text.TextLayout.Hit; import com.sun.javafx.scene.text.TextSpan; import com.sun.javafx.text.PrismTextLayout; import javafx.scene.text.Font; public class TextLayoutTest { private final PrismTextLayout layout = new PrismTextLayout(); private final PGFont arialFont = (PGFont) FontHelper.getNativeFont(Font.font("Arial", 12)); record TestSpan(String text, Object font) implements TextSpan { @Override public String getText() { return text; } @Override public Object getFont() { return font; } @Override public RectBounds getBounds() { return null; } } @Test void getHitInfoTest() { assumeArialFontAvailable(); /* * Empty line: */ layout.setContent("", arialFont); // Checks that hits above the line results in first character: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, -30)); // Checks before start of line: assertEquals(new Hit(0, 0, true), layout.getHitInfo(-50, 0)); // Checks position of empty string: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, 0)); // Checks past end of line: assertEquals(new Hit(0, 0, true), layout.getHitInfo(250, 0)); // TODO is insertion index correct here? // Checks that hits below the line results in last character + 1: assertEquals(new Hit(0, 1, false), layout.getHitInfo(0, 30)); /* * Single line: */ // 01234567890123456789012345678901234567890123 layout.setContent("The quick brown fox jumps over the lazy dog", arialFont); // Checks that hits above the line results in first character: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, -30)); // Checks before start of line: assertEquals(new Hit(0, 0, true), layout.getHitInfo(-50, 0)); // Checks positions of a few characters: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, 0)); // Start of "T" assertEquals(new Hit(0, 1, false), layout.getHitInfo(5, 0)); // Past halfway of "T" assertEquals(new Hit(1, 1, true), layout.getHitInfo(10, 0)); // Start of "h" // Checks past end of line: assertEquals(new Hit(42, 43, false), layout.getHitInfo(250, 0)); // TODO is insertion index correct here? // Checks that hits below the line results in last character + 1: assertEquals(new Hit(43, 44, false), layout.getHitInfo(0, 30)); /* * Multi line: */ layout.setContent("The\nquick\nbrown\nfox\n", arialFont); // Checks that hits above the first line results in first character: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, -30)); // Checks before start of first line: assertEquals(new Hit(0, 0, true), layout.getHitInfo(-50, 0)); // Checks positions of a few characters on first line: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, 0)); // Start of "T" assertEquals(new Hit(0, 1, false), layout.getHitInfo(5, 0)); // Halfway past "T" assertEquals(new Hit(1, 1, true), layout.getHitInfo(10, 0)); // Start of "h" // Checks past end of first line: assertEquals(new Hit(2, 3, false), layout.getHitInfo(250, 0)); // Checks before start of second line: assertEquals(new Hit(4, 4, true), layout.getHitInfo(-50, 15)); // Check second line: assertEquals(new Hit(4, 4, true), layout.getHitInfo(0, 15)); // Start of "q" // Checks past end of second line: assertEquals(new Hit(8, 9, false), layout.getHitInfo(250, 15)); /* * Test with two spans: */ layout.setContent(new TestSpan[] {new TestSpan("Two", arialFont), new TestSpan("Spans", arialFont)}); // Checks that hits above the line results in first character: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, -30)); // Checks before start of line: assertEquals(new Hit(0, 0, true), layout.getHitInfo(-50, 0)); // Checks positions of a few characters: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, 0)); // Start of "T" assertEquals(new Hit(0, 1, false), layout.getHitInfo(5, 0)); // Past halfway of "T" assertEquals(new Hit(1, 1, true), layout.getHitInfo(10, 0)); // Start of "w" assertEquals(new Hit(7, 8, false), layout.getHitInfo(60, 0)); // Past halfway of "s" // Checks past end of line: assertEquals(new Hit(7, 8, false), layout.getHitInfo(250, 0)); // TODO is insertion index correct here? // Checks that hits below the line results in last character + 1: assertEquals(new Hit(8, 9, false), layout.getHitInfo(0, 30)); /* * Test with zero spans: */ layout.setContent(new TestSpan[] {}); // Checks that hits above the line results in first character: assertEquals(new Hit(0, 0, true), layout.getHitInfo(0, -30)); // Checks before start of line: assertEquals(new Hit(0, 1, false), layout.getHitInfo(-50, 0)); // Checks positions of center: assertEquals(new Hit(0, 1, false), layout.getHitInfo(0, 0)); // Start of "T" // Checks past end of line: assertEquals(new Hit(0, 1, false), layout.getHitInfo(250, 0)); // TODO is insertion index correct here? // Checks that hits below the line results in last character + 1: assertEquals(new Hit(0, 1, false), layout.getHitInfo(0, 30)); } private void assumeArialFontAvailable() { assumeTrue("Arial font missing", arialFont.getName().equals("Arial")); } } Also add equals/hashCode/toString to `Hit`: public static class Hit { int charIndex; int insertionIndex; boolean leading; public Hit(int charIndex, int insertionIndex, boolean leading) { this.charIndex = charIndex; this.insertionIndex = insertionIndex; this.leading = leading; } public int getCharIndex() { return charIndex; } public int getInsertionIndex() { return insertionIndex; } public boolean isLeading() { return leading; } @Override public int hashCode() { return Objects.hash(charIndex, insertionIndex, leading); } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (getClass() != obj.getClass()) return false; Hit other = (Hit) obj; return charIndex == other.charIndex && insertionIndex == other.insertionIndex && leading == other.leading; } @Override public String toString() { return "Hit[charIndex=" + charIndex + ", insertionIndex=" + insertionIndex + ", leading=" + leading + "]"; } } Now, I noticed that there are several code paths in `getHitInfo` can't be covered. This probably is either a lack of imagination on my part with my test, or (since I did try) these code paths are dead and can't be hit. The use of `BreakIterator` with the default `Locale` is also worrying -- I don't see how that could possibly do the correct thing. Here's the coverage I did manage to get. I'm pretty sure the bottom `else` is dead code. The `BreakIterator` may still work when given special characters. ![image](https://github.com/openjdk/jfx/assets/995917/8c51cb34-cdef-496b-ac7f-4a46dbac185e) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1507567984 From jdv at openjdk.org Thu Feb 29 13:30:53 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 29 Feb 2024 13:30:53 GMT Subject: Integrated: 8324233: Update JPEG Image Decoding Software to 9f In-Reply-To: References: Message-ID: On Tue, 20 Feb 2024 05:50:19 GMT, Jayathirth D V wrote: > 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. This pull request has now been integrated. Changeset: b99eb458 Author: Jayathirth D V Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/b99eb45828317e4c195b46eb0c9371d4645f2c6c Stats: 463 lines in 28 files changed: 174 ins; 96 del; 193 mod 8324233: Update JPEG Image Decoding Software to 9f Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1372 From angorya at openjdk.org Thu Feb 29 15:52:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 15:52:54 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v16] In-Reply-To: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> References: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> Message-ID: On Thu, 29 Feb 2024 05:38:05 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 > FontHelper.getNativeFont( perhaps we could pick a suitable font based on the platform? to make sure we always get a valid font? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1971428499 From jpereda at openjdk.org Thu Feb 29 15:53:07 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 29 Feb 2024 15:53:07 GMT Subject: [jfx17u] RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Message-ID: <5V1EU6Z5EenPAMGemJUTVi82QO0ezfcrmf1L0dJRINo=.521d2331-4029-48f4-94c7-09bf74947f9a@github.com> Almost clean backport of 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Reviewed-by: jbhaskar, arapte ------------- Commit messages: - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Changes: https://git.openjdk.org/jfx17u/pull/179/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322703 Stats: 63 lines in 1 file changed: 34 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jfx17u/pull/179.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/179/head:pull/179 PR: https://git.openjdk.org/jfx17u/pull/179 From angorya at openjdk.org Thu Feb 29 16:02:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 16:02:57 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> Message-ID: On Thu, 29 Feb 2024 13:23:40 GMT, John Hendrikx wrote: >> I believe the tests added in this PR are helpful in making sure that the HitInfo calculation does not give results like character index less than 0 or character index greater than total length of the text or out of bound values. Since each character width is different and we have to check multiple scenarios, it is difficult to write generalised test for each case. Hence a combination of manual test using MonkeyTester and the automated tests added in this PR would be helpful in validating the changes. > > I disagree on this. The code is complicated and full of branches. Manual testing is very error prone. However, since you restored most of the code to its original (which wasn't tested either) I could live with it. Still, here's a small test that you could use to verify correct hits: > > > /* > * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > > package test.com.sun.javafx.text; > > import static org.junit.Assume.assumeTrue; > import static org.junit.jupiter.api.Assertions.assertEquals; > > import org.junit.jupiter.api.Test; > > import com.sun.javafx.font.PGFont; > import com.sun.javafx.geom.RectBounds; > import com.sun.javafx.scene.text.FontHelper; > import com.sun.javafx.scene.text.TextLayout.Hit; > import com.sun.javafx.scene.text.TextSpan; > import com.sun.javafx.text.PrismTextLayout; > > import javafx.scene.text.Font; > > public class TextLayoutTest { > private final PrismTextLayout layout = new PrismTextLayout(); > private final PGFont arialFont = (PGFont) FontHelper.getNativeFont(Font.font("Arial", 12)); > > record TestSpan(String text, Object font) implements TextSpan { > @Override > public String getText() { > return text; > } > > @Override > public Object getFont() { > return font; > } > > @Override > public RectBounds getBounds() { > return null; > } > ... @hjohn how do you get this coverage diagram? The BreakIterator is a part of the existing code, we should probably have this discussion outside of this PR. I agree, there might be a situation when the app wants to select a specific locale for the text component instead of relying on the default locale. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1507819707 From jdv at openjdk.org Thu Feb 29 16:18:03 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 29 Feb 2024 16:18:03 GMT Subject: [jfx22u] RFR: 8324233: Update JPEG Image Decoding Software to 9f Message-ID: <17LGt77MsEGKOpNIIV37t37A2B7jVoZ-UZqogf4WQ4Q=.c61df07c-a7a9-4ee2-9364-74848f255b2a@github.com> This is 22u backport for updating libjpeg version to 9f. Original bug : https://bugs.openjdk.org/browse/JDK-8324233 ------------- Commit messages: - Backport b99eb45828317e4c195b46eb0c9371d4645f2c6c Changes: https://git.openjdk.org/jfx22u/pull/15/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=15&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324233 Stats: 463 lines in 28 files changed: 174 ins; 96 del; 193 mod Patch: https://git.openjdk.org/jfx22u/pull/15.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/15/head:pull/15 PR: https://git.openjdk.org/jfx22u/pull/15 From jdv at openjdk.org Thu Feb 29 17:13:55 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 29 Feb 2024 17:13:55 GMT Subject: [jfx22u] Integrated: 8324233: Update JPEG Image Decoding Software to 9f In-Reply-To: <17LGt77MsEGKOpNIIV37t37A2B7jVoZ-UZqogf4WQ4Q=.c61df07c-a7a9-4ee2-9364-74848f255b2a@github.com> References: <17LGt77MsEGKOpNIIV37t37A2B7jVoZ-UZqogf4WQ4Q=.c61df07c-a7a9-4ee2-9364-74848f255b2a@github.com> Message-ID: On Thu, 29 Feb 2024 16:09:47 GMT, Jayathirth D V wrote: > This is 22u backport for updating libjpeg version to 9f. > Original bug : https://bugs.openjdk.org/browse/JDK-8324233 This pull request has now been integrated. Changeset: e54102ca Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/e54102cad7432dbef11d156947ae0e41bc530fd7 Stats: 463 lines in 28 files changed: 174 ins; 96 del; 193 mod 8324233: Update JPEG Image Decoding Software to 9f Backport-of: b99eb45828317e4c195b46eb0c9371d4645f2c6c ------------- PR: https://git.openjdk.org/jfx22u/pull/15 From angorya at openjdk.org Thu Feb 29 17:16:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 17:16:09 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes Message-ID: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Adding `@SuppressWarnings("doclint")` to Serializable classes to silence the javadoc "missing comments" warning. (There is no javadoc command group for serialization like doclint:missing) Pros: - the classes are fairly stable, we can ask the reviewers to pay extra attention to any javadoc changes Cons: - all javadoc warnings will be suppressed ------------- Commit messages: - 8270996: JavaFX serialized classes get javadoc warnings for missing comments Changes: https://git.openjdk.org/jfx/pull/1386/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8270996 Stats: 54 lines in 25 files changed: 33 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/1386.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1386/head:pull/1386 PR: https://git.openjdk.org/jfx/pull/1386 From jhendrikx at openjdk.org Thu Feb 29 17:29:55 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 29 Feb 2024 17:29:55 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v16] In-Reply-To: References: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> Message-ID: <2aZZ5L6Zz0maC2VoLHAS8yLO6TkUzNUABL8Sim9M4CY=.cc499565-539d-4d6b-91ab-7747d4f2db89@github.com> On Thu, 29 Feb 2024 15:49:47 GMT, Andy Goryachev wrote: > > FontHelper.getNativeFont( > > perhaps we could pick a suitable font based on the platform? to make sure we always get a valid font? The points tested will be specific to the font used, similar to the problems with the #1236 PR. So, it would have to be a font that has very similar widths for the characters. Arial is one of the most available fonts across platforms. Options are: - Include some open source freely distributable font as part of `src/test/resources` that we can load easily - Simulate a font, perhaps using a mocking framework - Use a very common font (Arial) and just make sure you have it installed - Just accept that it is a system test and it's enough to have it run on one of the platforms :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1971618522 From kcr at openjdk.org Thu Feb 29 17:31:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Feb 2024 17:31:54 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes In-Reply-To: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Message-ID: <0Zi2qQp7O0fYIXB--KUa8tWFtqtgBuEouVkmy4SJyEg=.f5f06151-ed04-4c66-9bd7-f297c01a1a3f@github.com> On Thu, 29 Feb 2024 16:53:26 GMT, Andy Goryachev wrote: > Adding `@SuppressWarnings("doclint")` to Serializable classes to silence the javadoc "missing comments" warning. > (There is no javadoc command group for serialization like doclint:missing) > > Pros: > - the classes are fairly stable, we can ask the reviewers to pay extra attention to any javadoc changes > > Cons: > - all javadoc warnings will be suppressed I am not in favor of suppressing all javadoc warnings, especially at the class level. Is there no way to suppress just the serial warnings? If we want to suppress the warnings (rather than providing actual docs for the fields, which may have little value), I think they should be moved down to the individual elements. I'd like a second pair of eyes on this. modules/javafx.base/src/main/java/javafx/event/Event.java line 45: > 43: */ > 44: @SuppressWarnings("doclint") > 45: public class Event extends EventObject implements Cloneable { I don't think we should suppress all warnings, especially at the class level. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1386#pullrequestreview-1909468036 PR Comment: https://git.openjdk.org/jfx/pull/1386#issuecomment-1971620958 PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1507936053 From jhendrikx at openjdk.org Thu Feb 29 17:36:00 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 29 Feb 2024 17:36:00 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> Message-ID: <4r1fucmfdeNqsxxe_8yvXCcZRVFsWX9UystBKTcpc9c=.4c783286-55db-46ff-a497-8e6c63991c27@github.com> On Thu, 29 Feb 2024 15:59:58 GMT, Andy Goryachev wrote: >> I disagree on this. The code is complicated and full of branches. Manual testing is very error prone. However, since you restored most of the code to its original (which wasn't tested either) I could live with it. Still, here's a small test that you could use to verify correct hits: >> >> >> /* >> * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. Oracle designates this >> * particular file as subject to the "Classpath" exception as provided >> * by Oracle in the LICENSE file that accompanied this code. >> * >> * This code is distributed in the hope that it will be useful, but WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ >> >> package test.com.sun.javafx.text; >> >> import static org.junit.Assume.assumeTrue; >> import static org.junit.jupiter.api.Assertions.assertEquals; >> >> import org.junit.jupiter.api.Test; >> >> import com.sun.javafx.font.PGFont; >> import com.sun.javafx.geom.RectBounds; >> import com.sun.javafx.scene.text.FontHelper; >> import com.sun.javafx.scene.text.TextLayout.Hit; >> import com.sun.javafx.scene.text.TextSpan; >> import com.sun.javafx.text.PrismTextLayout; >> >> import javafx.scene.text.Font; >> >> public class TextLayoutTest { >> private final PrismTextLayout layout = new PrismTextLayout(); >> private final PGFont arialFont = (PGFont) FontHelper.getNativeFont(Font.font("Arial", 12)); >> >> record TestSpan(String text, Object font) implements TextSpan { >> @Override >> public String getText() { >> return text; >> } >> >> @Override >> public Object getFont() { >> retur... > > @hjohn how do you get this coverage diagram? > > The BreakIterator is a part of the existing code, we should probably have this discussion outside of this PR. I agree, there might be a situation when the app wants to select a specific locale for the text component instead of relying on the default locale. @andy-goryachev-oracle The coverage comes from EclEmma, an Eclipse plugin. Once installed, there is another way to run tests called `Coverage as...` just above `Run as...`. It's very useful to use it on a JUnit test to see if there are major branches you missed in testing that may require additional cases. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1507945798 From angorya at openjdk.org Thu Feb 29 18:39:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 18:39:03 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v2] In-Reply-To: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Message-ID: > Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: missing ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1386/files - new: https://git.openjdk.org/jfx/pull/1386/files/b7daad62..2a5a0775 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1386&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1386&range=00-01 Stats: 117 lines in 25 files changed: 91 ins; 25 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1386.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1386/head:pull/1386 PR: https://git.openjdk.org/jfx/pull/1386 From angorya at openjdk.org Thu Feb 29 18:39:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 18:39:03 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v2] In-Reply-To: <0Zi2qQp7O0fYIXB--KUa8tWFtqtgBuEouVkmy4SJyEg=.f5f06151-ed04-4c66-9bd7-f297c01a1a3f@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <0Zi2qQp7O0fYIXB--KUa8tWFtqtgBuEouVkmy4SJyEg=.f5f06151-ed04-4c66-9bd7-f297c01a1a3f@github.com> Message-ID: On Thu, 29 Feb 2024 17:24:53 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> missing > > modules/javafx.base/src/main/java/javafx/event/Event.java line 45: > >> 43: */ >> 44: @SuppressWarnings("doclint") >> 45: public class Event extends EventObject implements Cloneable { > > I don't think we should suppress all warnings, especially at the class level. for some reason I though it did not work -- corrected, fixed by suppressing the offending lines only with `@SuppressWarnings("doclint:missing")` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1508015767 From angorya at openjdk.org Thu Feb 29 18:48:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 18:48:55 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: <4r1fucmfdeNqsxxe_8yvXCcZRVFsWX9UystBKTcpc9c=.4c783286-55db-46ff-a497-8e6c63991c27@github.com> References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> <4r1fucmfdeNqsxxe_8yvXCcZRVFsWX9UystBKTcpc9c=.4c783286-55db-46ff-a497-8e6c63991c27@github.com> Message-ID: On Thu, 29 Feb 2024 17:33:14 GMT, John Hendrikx wrote: >> @hjohn how do you get this coverage diagram? >> >> The BreakIterator is a part of the existing code, we should probably have this discussion outside of this PR. I agree, there might be a situation when the app wants to select a specific locale for the text component instead of relying on the default locale. > > @andy-goryachev-oracle The coverage comes from EclEmma, an Eclipse plugin. Once installed, there is another way to run tests called `Coverage as...` just above `Run as...`. It's very useful to use it on a JUnit test to see if there are major branches you missed in testing that may require additional cases. thank you @hjohn good to know about EclEmma you might be right about dead code: I could not hit the break points in L461 or L471 with the MT. There might be a scenario which we are not testing. I'd say leave it as is perhaps? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1508028426 From angorya at openjdk.org Thu Feb 29 18:59:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 18:59:55 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v16] In-Reply-To: <2aZZ5L6Zz0maC2VoLHAS8yLO6TkUzNUABL8Sim9M4CY=.cc499565-539d-4d6b-91ab-7747d4f2db89@github.com> References: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> <2aZZ5L6Zz0maC2VoLHAS8yLO6TkUzNUABL8Sim9M4CY=.cc499565-539d-4d6b-91ab-7747d4f2db89@github.com> Message-ID: On Thu, 29 Feb 2024 17:27:28 GMT, John Hendrikx wrote: > Arial is one of the most available fonts across platforms. No it is not, as we can see from https://github.com/openjdk/jfx/pull/1236#issuecomment-1939005318 so perhaps we check and pick an alternative if Arial is not present? What is the most common font on Linux that's guaranteed to be present? Georgia? Sentury Schoolbook L? https://apaddedcell.com/wp-content/uploads/2022/04/web-fonts.png ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1971773397 From angorya at openjdk.org Thu Feb 29 19:34:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 19:34:53 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations [v2] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 17:38:11 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). > > Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8325402: remove labeled if > - JDK-8325402: Unit test improvements Tested in MT on macOS 14.3.1 Looks good, thank you for making the changes! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1360#pullrequestreview-1909680339 From angorya at openjdk.org Thu Feb 29 19:34:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 19:34:54 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations [v2] In-Reply-To: References: Message-ID: <81hctBLahaRrQ3Olb6UxJJP514nlXjdiSCH82J1RJXQ=.1538313b-d677-4a94-9e25-0d47255084a7@github.com> On Wed, 14 Feb 2024 20:53:46 GMT, Marius Hanl wrote: >> 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. :) okay ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1360#discussion_r1508074943 From angorya at openjdk.org Thu Feb 29 19:44:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 19:44:19 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v10] 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 29 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8299753.resize - 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 - ... and 19 more: https://git.openjdk.org/jfx/compare/ef8e9cc5...48a1bb5d ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/9105b009..48a1bb5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=08-09 Stats: 4044 lines in 272 files changed: 2669 ins; 474 del; 901 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 angorya at openjdk.org Thu Feb 29 23:01:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 23:01:52 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v2] In-Reply-To: References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Message-ID: On Thu, 29 Feb 2024 18:39:03 GMT, Andy Goryachev wrote: >> Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > missing @arapte or @prsadhuk could you please take a look? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1386#issuecomment-1972115716 From angorya at openjdk.org Thu Feb 29 23:01:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 23:01:55 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues In-Reply-To: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Wed, 28 Feb 2024 21:48:38 GMT, Andy Goryachev wrote: > This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) > > - adds missing information in `@param` tags > - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) > - fixed an empty `

` in `Subscription` > - cleaned up unnecessary `@throws` in Filtered/SortedList > > Q: Does this PR need a CSR? @arapte @prsadhuk or @kevinrushforth could you please take a look? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1384#issuecomment-1972115470 From kcr at openjdk.org Thu Feb 29 23:13:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Feb 2024 23:13:53 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v2] In-Reply-To: References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Message-ID: On Thu, 29 Feb 2024 18:39:03 GMT, Andy Goryachev wrote: >> Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > missing This now looks good to me, except for a couple of comments on the added docs to `JFXPanel`. @prsadhuk Can you also review the changes to `JFXPanel`? modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 140: > 138: * Warning: > 139: * Serialized objects of this class will not be compatible with > 140: * future Swing releases. The current serialization support is I would reword this to add "or future JavaFX releases". modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 142: > 140: * future Swing releases. The current serialization support is > 141: * appropriate for short term storage or RMI between applications running > 142: * the same version of Swing. As of 1.4, support for long term storage Add "and the same version of JavaFX" after Swing. I would remove everything after the "As of 1.4 ..." since that isn't really relevant for JavaFX components and could be confusing. ------------- PR Review: https://git.openjdk.org/jfx/pull/1386#pullrequestreview-1910029656 PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1508294034 PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1508295633 From angorya at openjdk.org Thu Feb 29 23:56:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Feb 2024 23:56:06 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Message-ID: <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> > Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1386/files - new: https://git.openjdk.org/jfx/pull/1386/files/2a5a0775..5852f84f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1386&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1386&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1386.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1386/head:pull/1386 PR: https://git.openjdk.org/jfx/pull/1386