From michaelstrau2 at gmail.com Wed Feb 1 00:22:20 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 1 Feb 2023 01:22:20 +0100 Subject: Style themes API In-Reply-To: References: Message-ID: On Tue, Jan 31, 2023 at 6:14 PM Pedro Duque Vieira wrote: > Thinking of existing themes migrating to this StyleTheme API (90% are implemented as author stylesheets), some visual glitches may start appearing for users of those themes once they start using the migrated versions (since they will go from being author stylesheets to user agent stylesheets). > So, 2 things to think about: > 2.1 - How important is it that we think about this use case: existing themes migrating to this new API. I'd say we should probably think about it when designing this new API. > 2.2 - The second thing then is, how problematic will it be for programmers using these themes to have their apps start having visual glitches because of these themes changing from author stylesheets to user agent style sheets? > Perhaps we simply don't bother with this last point and simply have it be the price of innovation. And so programmers will have to adapt their applications and remove any code that is overriding the styles defined in the StyleThemes (which are likely causing these visual glitches when migrating to Themes using this new StyleTheme API). The same for any styles already defined in custom author stylesheets that are being used by the application and that might be NOW overriding the styles of the theme. 1) Ease of migration should be an important consideration, but there are also other considerations. I'd argue that getting the feature stacking and mental model right is more important, and giving themes a way to individually select if the stylesheets are user-agent or user stylesheets makes it hard to understand why my locally-set property value is being ignored by JavaFX in one theme, but not in the other. 2) The scenario you describe occurs when an application sets the value of styleable properties from code, but the values are overridden by an author stylesheet. Yes, that might happen, and I think it's up to the application developers to fix that. The reason why I think we should only support `Application.userAgentStyleTheme` in the first version of this new feature is quite simple: I'd rather have the feature actually make it into JavaFX than be stuck in review because it's too large and too complex of a change. User-agent style themes are pretty easy to implement (most of the code is already in place), while author style themes are not. We can add author style themes as a follow-up enhancement. > I don't think we should put having StyleTheme be just a collection of stylesheets and nothing else as a requirement. I'd rather think of StyleTheme as being the concept of a Theme and all the possible properties and definitions of what a Theme is. This is one of the strengths of this new feature you've proposed, i.e. > having the concept of a Theme exist in JavaFX whereas in the past there was no such concept and a "Theme" was just a collection of stylesheets. Added through the getStylesheets() method or through the setUserAgentStylesheet method. > > I'll just note that we don't just want the applications to be light or dark depending on what is set in the Operating System. You'll also want the ability to set whether the app is in dark or light mode on a per application level irrespective of what is defined in the OS (this already happens on many existing applications out there). So I think that DarkModeAware interface would have to have a method like: > ThemeMode getMode(); > Where ThemeMode can either be LIGHT, DARK or OS_DEFINED (I've named it ThemeMode just as an example). > > So I think we could do it in 2 ways: one way would be to do it as you say (though DarkModeAware interface would need the getMode() method that I suggested, I think) or add a method in the StyleTheme interface itself in a future release: > ThemeMode getMode(); > That method would probably need to have a default implementation that simply returns LIGHT because of retro compatibility. > > So, ThemeMode could be one of 3 possible values: LIGHT, DARK or OS_DEFINED. Where OS_DEFINED means that the app will honor whatever is defined at the OS level. > JavaFX Window decorations would need to respect whatever is returned in this getMode() method and change their decorations to either LIGHT or DARK depending on its value. This would also remove the need for boilerplate code that for every Window that is created sets it to be LIGHT or DARK depending on whether the Theme is LIGHT or DARK. > > Of course, we can also simply support this from the get go and have this method exist in StyleTheme from the start. I'll point you to this document, which describes the latest version of this feature: https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 What do you think about the interaction between the various parts of the new API, especially in regards to the appearance of native platform decorations? I'm not convinced that it is a good idea to make either `StyleTheme` or `Stage.appearance` more complicated by automatically inferring the value of one from the other. From hmeda at openjdk.org Wed Feb 1 04:11:48 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 1 Feb 2023 04:11:48 GMT Subject: RFR: JDK-8299977 : Update WebKit to 615.1 [v3] In-Reply-To: References: Message-ID: > Update JavaFX WebKit to GTK WebKit 2.38 (615.1). > > Verified the updated version build, sanity tests and stability. > This does not cause any issues except one unit test failure. > Also, there are some artifacts observed while playing youtube > > The above issues are recorded and ignored using below bugs: > [JDK-8300954](https://bugs.openjdk.org/browse/JDK-8300954) > [JDK-8301022](https://bugs.openjdk.org/browse/JDK-8301022) Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Remove the log added for testing purpose ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1011/files - new: https://git.openjdk.org/jfx/pull/1011/files/66237d46..a804a6ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1011&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1011&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1011.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1011/head:pull/1011 PR: https://git.openjdk.org/jfx/pull/1011 From kpk at openjdk.org Wed Feb 1 06:37:21 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 1 Feb 2023 06:37:21 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: References: Message-ID: > In `selectIndices` method, zero length array is not considered while ignoring row number given as parameter. > > Updated the code to consider both null and zero length array in the condition before ignoring the row value given as parameter. > > Added unit test to validate the fix Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix first index selection issue in TreeTableView ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1018/files - new: https://git.openjdk.org/jfx/pull/1018/files/06c1950b..4f623477 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1018&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1018&range=00-01 Stats: 23 lines in 3 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1018.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1018/head:pull/1018 PR: https://git.openjdk.org/jfx/pull/1018 From kpk at openjdk.org Wed Feb 1 06:37:21 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 1 Feb 2023 06:37:21 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 14:40:00 GMT, Karthik P K wrote: > In `selectIndices` method, zero length array is not considered while ignoring row number given as parameter. > > Updated the code to consider both null and zero length array in the condition before ignoring the row value given as parameter. > > Added unit test to validate the fix Yes similar change can be applied to `TreeTableView`. Updated the code. ------------- PR: https://git.openjdk.org/jfx/pull/1018 From kpk at openjdk.org Wed Feb 1 09:02:03 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 1 Feb 2023 09:02:03 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 17:05:01 GMT, Nir Lisker wrote: > I recently looked at https://bugs.openjdk.org/browse/JDK-8120635. Is it related? I managed to reproduce it, so I think it should be reopened. This is kind of similar issue but not related. This issue is because of the bug in `selectLast` method of MultipleSelectionModelBase class. I couldn't reproduce the issue with `select` and `selectFirst` methods as mentioned in the bug, I could reproduce only with `selectLast` method. ------------- PR: https://git.openjdk.org/jfx/pull/1018 From kpk at openjdk.org Wed Feb 1 09:20:06 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 1 Feb 2023 09:20:06 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 19:41:20 GMT, John Hendrikx wrote: >> Well it's legal Java code, but that doesn't mean that leaving something `null` is allowed. At the very least it is undocumented behavior: >> >> /** >> *

This method allows for one or more selections to be set at the same time. >> * It will ignore any value that is not within the valid range (i.e. greater >> * than or equal to zero, and less than the total number of items in the >> * underlying data model). Any duplication of indices will be ignored. >> * >> *

If there is already one or more indices selected in this model, calling >> * this method will not clear these selections - to do so it is >> * necessary to first call clearSelection. >> * >> *

The last valid value given will become the selected index / selected >> * item. >> * @param index the first index to select >> * @param indices zero or more additional indices to select >> */ >> public abstract void selectIndices(int index, int... indices); > > I think it is also pretty clear the original author intended to check `rows.length == 0` and made the mistake that it would be called with `rows == null` when there are no further indices specified, which is incorrect. I believe no code change is required as of now. Hence not making any changes now. ------------- PR: https://git.openjdk.org/jfx/pull/1018 From fkirmaier at openjdk.org Wed Feb 1 10:01:42 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:01:42 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v8] In-Reply-To: References: Message-ID: <5eYiHTW5ZMtHCHjUauI5AoMseka55PzIUFkwFLIC1EQ=.8e2c5bff-3f74-439b-9de3-596bad623d9e@github.com> > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8269907 changes based on code review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/584/files - new: https://git.openjdk.org/jfx/pull/584/files/c5c5e080..7e47e060 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=06-07 Stats: 27 lines in 3 files changed: 3 ins; 1 del; 23 mod Patch: https://git.openjdk.org/jfx/pull/584.diff Fetch: git fetch https://git.openjdk.org/jfx pull/584/head:pull/584 PR: https://git.openjdk.org/jfx/pull/584 From fkirmaier at openjdk.org Wed Feb 1 10:01:46 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:01:46 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 10:51:00 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 420: >> >>> 418: new WeakHashMap<>(); >>> 419: final Map cleanupList = >>> 420: new WeakHashMap<>(); >> >> I wonder why we need `WeakHashMap` here. These maps are short-lived anyway, since they're local variables. > > These should not be `WeakHashMap` at all; even if it is was necessary for some reason, there is no guarantee GC will run and potential keys that should have been removed may still be there in many situations. Using weak maps here only serves to make the process unpredictable, making it harder to find bugs if there ever is a situation where a key should have been removed. > > I would be in favor of changing these to normal maps. I've changed it now to a normal HashMap. >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 494: >> >>> 492: public void addCleanupListener(TKPulseListener listener) { >>> 493: AccessControlContext acc = AccessController.getContext(); >>> 494: cleanupListeners.put(listener,acc); >> >> Access to `cleanupListeners` is not synchronized on `this` here, but it is synchronized in L426. >> You should either synchronize each and every access, or none of it. > > It should not be removed everywhere, it has to be synchronized (all the other listener lists are as well). This is probably because listeners can be added on different threads. I've added a synchronized now. ------------- PR: https://git.openjdk.org/jfx/pull/584 From fkirmaier at openjdk.org Wed Feb 1 10:01:56 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:01:56 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 18:12:23 GMT, Michael Strau? wrote: >> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - JDK-8269907 >> Added missing changes after merge >> - Merge remote-tracking branch 'origjfx/master' into JDK-8269907-dirty-and-removed >> >> # Conflicts: >> # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java >> # modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> - Merge remote-tracking branch 'origin/master' >> - JDK-8269907 >> Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. >> - JDK-8269907 >> Fixed rare bug, causing bounds to be out of sync. >> - JDK-8269907 >> We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. >> - JDK-8269907 >> The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks. >> - JDK-8269907 >> Fixing dirty nodes and parent removed, when a window is no longer showing. This typically happens with context menus. > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 745: > >> 743: private void checkCleanDirtyNodes() { >> 744: if(!cleanupAdded) { >> 745: if((window.get() == null || !window.get().isShowing()) && dirtyNodesSize > 0) { > > Minor: space after `if`. > You could also reduce nesting by consolidating the two separate conditions. I've merged it now to 1 if, with a space! > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2112: > >> 2110: **************************************************************************/ >> 2111: >> 2112: private void windowForSceneChanged(Window oldWindow, Window window) { > > This change doesn't seem necessary. I've reverted the variable name. > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2129: > >> 2127: } >> 2128: >> 2129: private final ChangeListener sceneWindowShowingListener = (p, o, n) -> {checkCleanDirtyNodes(); } ; > > Minor: should be no space before `;`. > You could also remove the curly braces. I've removed now the curly braces. > tests/system/src/test/java/test/javafx/scene/DirtyNodesLeakTest.java line 35: > >> 33: import junit.framework.Assert; >> 34: import org.junit.BeforeClass; >> 35: import org.junit.Test; > > Since this is a new class, you should use the JUnit5 API. I'm now using the junit5 api. ------------- PR: https://git.openjdk.org/jfx/pull/584 From fkirmaier at openjdk.org Wed Feb 1 10:15:36 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:15:36 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v9] In-Reply-To: References: Message-ID: > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8269907 renamed testclass, based on code review, readded acidentally removed import ------------- Changes: - all: https://git.openjdk.org/jfx/pull/584/files - new: https://git.openjdk.org/jfx/pull/584/files/7e47e060..dfb34701 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=07-08 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/584.diff Fetch: git fetch https://git.openjdk.org/jfx pull/584/head:pull/584 PR: https://git.openjdk.org/jfx/pull/584 From fkirmaier at openjdk.org Wed Feb 1 10:18:04 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:18:04 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 18:20:52 GMT, Michael Strau? wrote: >> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - JDK-8269907 >> Added missing changes after merge >> - Merge remote-tracking branch 'origjfx/master' into JDK-8269907-dirty-and-removed >> >> # Conflicts: >> # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java >> # modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> - Merge remote-tracking branch 'origin/master' >> - JDK-8269907 >> Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. >> - JDK-8269907 >> Fixed rare bug, causing bounds to be out of sync. >> - JDK-8269907 >> We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. >> - JDK-8269907 >> The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks. >> - JDK-8269907 >> Fixing dirty nodes and parent removed, when a window is no longer showing. This typically happens with context menus. > > tests/system/src/test/java/test/javafx/scene/DirtyNodesLeakTest.java line 44: > >> 42: import static test.util.Util.TIMEOUT; >> 43: >> 44: public class DirtyNodesLeakTest { > > Since this tests dirty nodes of a `Scene`, maybe you could use a name like `Scene_dirtyNodesLeakTest`? I like the name you've suggested. I've changed it now to your suggestion. ------------- PR: https://git.openjdk.org/jfx/pull/584 From fkirmaier at openjdk.org Wed Feb 1 10:24:11 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:24:11 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:30:59 GMT, John Hendrikx wrote: >> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - JDK-8269907 >> Added missing changes after merge >> - Merge remote-tracking branch 'origjfx/master' into JDK-8269907-dirty-and-removed >> >> # Conflicts: >> # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java >> # modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> - Merge remote-tracking branch 'origin/master' >> - JDK-8269907 >> Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. >> - JDK-8269907 >> Fixed rare bug, causing bounds to be out of sync. >> - JDK-8269907 >> We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. >> - JDK-8269907 >> The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks. >> - JDK-8269907 >> Fixing dirty nodes and parent removed, when a window is no longer showing. This typically happens with context menus. > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 746: > >> 744: if(!cleanupAdded) { >> 745: if((window.get() == null || !window.get().isShowing()) && dirtyNodesSize > 0) { >> 746: Toolkit.getToolkit().addCleanupListener(cleanupListener); > > This adds a listener to be run on the next pulse, yet no pulse is being requested. Probably something else will request a pulse, but seems like you may not want to rely on that. Specifically, `addToDirtyList` won't request a pulse if the stage is already closed (peer is `null`), and only then do you remove some nodes. It still works though in that case, probably because something else in JavaFX is requesting a pulse (nothing in `Scene` does though when peer is `null`). I assume that these methods are just called all the time - independent of whether there is an open window. I would like to leave it like this - unless there is an issue and an idea on how to do it differently. ------------- PR: https://git.openjdk.org/jfx/pull/584 From zjx001202 at gmail.com Wed Feb 1 10:24:36 2023 From: zjx001202 at gmail.com (Glavo) Date: Wed, 1 Feb 2023 18:24:36 +0800 Subject: Replace Collections.unmodifiableList with List.of Message-ID: I opened a PR to clean up the code. Can someone help me open an Issue in JBS? https://github.com/openjdk/jfx/pull/1012 With best regards, Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Wed Feb 1 10:35:06 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 1 Feb 2023 10:35:06 GMT Subject: RFR: 8088998: LineChart: duplicate child added exception when remove & add a series In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 12:21:38 GMT, Karthik P K wrote: > While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run. > > Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted. > > This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/1015 From fkirmaier at openjdk.org Wed Feb 1 10:35:07 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 1 Feb 2023 10:35:07 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7] In-Reply-To: References: Message-ID: <3TTxFCCxTlKztCaKRHc6RYtUGuiiU4nG0oFeq--SH0I=.07c3f51d-156f-4ea9-bd66-08b49694ef5a@github.com> On Fri, 27 Jan 2023 14:51:59 GMT, John Hendrikx wrote: >> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - JDK-8269907 >> Added missing changes after merge >> - Merge remote-tracking branch 'origjfx/master' into JDK-8269907-dirty-and-removed >> >> # Conflicts: >> # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java >> # modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> - Merge remote-tracking branch 'origin/master' >> - JDK-8269907 >> Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. >> - JDK-8269907 >> Fixed rare bug, causing bounds to be out of sync. >> - JDK-8269907 >> We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. >> - JDK-8269907 >> The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks. >> - JDK-8269907 >> Fixing dirty nodes and parent removed, when a window is no longer showing. This typically happens with context menus. > > I took another good look at this solution, and I would like to offer an alternative as I think this solution is more dealing with symptoms of the underlying problem. > > I think the underlying problem is: > > 1) `Parent` is tracking a `removed` list, which is a list of `Node`. However, it only requires the peer for the dirty area calculation. This is a classic case of not being specific enough with the information you need. If `Parent` is modified to store `NGNode` in its `removed` list, then the problem of `removed` keeping references to old nodes disappears as `NGNode` does not refer back to `Node`. Note: there is a test method currently in `Parent` that returns the list of removed nodes -- these tests would need to be modified to work with a list of `NGNode` or some other way should be found to check these cases. > > 2) `Scene` keeps tracking dirty nodes even when it is not visible. The list of dirty nodes could (before this fix) become as big as you want as it was never cleared as the pulse listener that synchronizes the nodes never runs when `peer == null` -- keep adding and removing new nodes while the scene is not shown, and the list of dirty nodes grows indefinitely. This only happens if the scene has been shown at least once before, as before that time special code kicks in that tries to avoid keeping track of all scene nodes in the dirty list. > > I think the better solution here would be to reset the scene to go back to its initial state (before it was shown) and sync all nodes when it becomes visible again. This can be achieved by setting the dirty node list to `null` to trigger the logic that normally only triggers on the first show. `addToDirtyList` should simply do nothing when `peer == null` . > > I believe the `syncPeer` call is smart enough not to update the peer in the situation where a scene is hidden and then reshown, even if `Scene` calls it again on all its nodes (`syncPeer` in `Node` will check `dirtyBits.isEmpty()`). > > I'd also highly recommend using `ArrayList` instead of a manual `Node[] dirtyNodes` in `Scene`. @hjohn The Parent is tracking a removed list, which is a list of Node. However, it only requires the peer for the dirty area calculation. This is a classic case of not being specific enough with the information you need. If Parent is modified to store NGNode in its removed list, then the problem of removed keeping references to old nodes disappears as NGNode does not refer back to Node. Note: there is a test method currently in Parent that returns the list of removed nodes -- these tests would need to be modified to work with a list of NGNode or some other way should be found to check these cases. This would just end in an leak of the NGNode, instead of the Node? There are also some leaks related to NGNode, bug guess I'll have to fix the more obvious bugs first. Also, NGNode sometimes refers to the Node. There are a lot of issues in this area. ## Resetting the Scene This approach has one problem - it would change the complexity of showing/hiding a window. This issue typically happened with Popups, which are regularly shown/hidden. I guess changing the complexity to O() might be ok - but I'm not sure about it. I don't want to change the dirtyNodes to ArrayList in this PR, i don't want to mix this kind of refactoring into the Bugfix-PR. > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 492: > >> 490: } >> 491: >> 492: public void addCleanupListener(TKPulseListener listener) { > > This name is misleading. It adds a listener which gets auto removed when called (and hence why there is no `removeCleanupListener` counterpart). In effect, it works a bit like `runLater`, a one time action to be run on the next pulse. > > In general, I would like to see more comments/docs to explain what is going on. I've changed it to addCleanupTask ------------- PR: https://git.openjdk.org/jfx/pull/584 From aghaisas at openjdk.org Wed Feb 1 10:40:09 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 1 Feb 2023 10:40:09 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 06:56:57 GMT, Karthik P K wrote: >> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. >> >> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. >> >> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight The fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/996 From aghaisas at openjdk.org Wed Feb 1 10:52:00 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 1 Feb 2023 10:52:00 GMT Subject: RFR: 8251862: Wrong position of Popup windows at the intersection of 2 screens [v4] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 19:01:33 GMT, Kevin Rushforth wrote: >> On Windows platforms with more than one screen, a PopupWindow created for a Stage that straddles two windows will be drawn with an incorrect position and screen scale if the majority of the Stage is on one screen, and the popup is positioned on the other screen. In this case, the Stage is drawn using the screen scale of the screen that most of the window is on, while the popup is drawn using the scale of the screen that it is (typically entirely) on. >> >> The most common way this can happen is when you have two screens of a different scale with the secondary screen on the left or above the primary screen. If you position the Stage such that most of it is still on the primary screen (thus the Stage is drawn using the scale of the primary screen), with a menu, a control with a context menu, or a control with a Tooltip now on the secondary screen, the popup window for the menu or Tooltip will be drawn using the screen scale of the secondary window and thus won't be positioned or sized correctly relative to the menu bar, or control in the main window. >> >> The fix implemented by this PR is to always use the screen of the owner window, including the screen scales, when rendering a popup window. This matches the behavior of native Windows apps, such as Notepad. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2023 I confirm that this fixes the reported issue. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/971 From duke at openjdk.org Wed Feb 1 11:25:48 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Feb 2023 11:25:48 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of Message-ID: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. Because `List.of` can only store non-null elements, I have only replaced a few usage. Can someone open an Issue on JBS for me? ------------- Commit messages: - cleanup Changes: https://git.openjdk.org/jfx/pull/1012/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1012&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301604 Stats: 18 lines in 3 files changed: 0 ins; 9 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1012.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1012/head:pull/1012 PR: https://git.openjdk.org/jfx/pull/1012 From aoqi at openjdk.org Wed Feb 1 11:25:48 2023 From: aoqi at openjdk.org (Ao Qi) Date: Wed, 1 Feb 2023 11:25:48 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: On Thu, 26 Jan 2023 05:30:56 GMT, Glavo wrote: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? Filed: https://bugs.openjdk.org/browse/JDK-8301604. Please let me know if the issue is not reported correctly. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From duke at openjdk.org Wed Feb 1 11:25:50 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Feb 2023 11:25:50 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: <3w4B3WB7LR8jkX2yvLCYGcMFWp6BJ8nTKriGJ5QmNxc=.31147d2a-383b-4092-9138-6dd0e661aa0c@github.com> On Wed, 1 Feb 2023 11:03:32 GMT, Ao Qi wrote: >> `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. >> >> Because `List.of` can only store non-null elements, I have only replaced a few usage. >> >> Can someone open an Issue on JBS for me? > > Filed: https://bugs.openjdk.org/browse/JDK-8301604. Please let me know if the issue is not reported correctly. @theaoqi Thank you very much! ------------- PR: https://git.openjdk.org/jfx/pull/1012 From nlisker at openjdk.org Wed Feb 1 12:30:00 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Feb 2023 12:30:00 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: References: Message-ID: <7tGd0c5ljhxGEE0x05lz0zPbFcAIO72cLrArnpmaYXI=.67cc120b-912d-4a2a-b5ec-876c3f5ff593@github.com> On Wed, 1 Feb 2023 09:17:33 GMT, Karthik P K wrote: >> I think it is also pretty clear the original author intended to check `rows.length == 0` and made the mistake that it would be called with `rows == null` when there are no further indices specified, which is incorrect. > > I believe no code change is required as of now. Hence not making any changes now. I also think that `null` should throw unless otherwise specified. ------------- PR: https://git.openjdk.org/jfx/pull/1018 From kcr at openjdk.org Wed Feb 1 12:48:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Feb 2023 12:48:04 GMT Subject: RFR: JDK-8299977 : Update WebKit to 615.1 [v3] In-Reply-To: References: Message-ID: On Wed, 1 Feb 2023 04:11:48 GMT, Hima Bindu Meda wrote: >> Update JavaFX WebKit to GTK WebKit 2.38 (615.1). >> >> Verified the updated version build, sanity tests and stability. >> This does not cause any issues except one unit test failure. >> Also, there are some artifacts observed while playing youtube >> >> The above issues are recorded and ignored using below bugs: >> [JDK-8300954](https://bugs.openjdk.org/browse/JDK-8300954) >> [JDK-8301022](https://bugs.openjdk.org/browse/JDK-8301022) > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove the log added for testing purpose Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/1011 From kcr at openjdk.org Wed Feb 1 13:16:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Feb 2023 13:16:58 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: <7tGd0c5ljhxGEE0x05lz0zPbFcAIO72cLrArnpmaYXI=.67cc120b-912d-4a2a-b5ec-876c3f5ff593@github.com> References: <7tGd0c5ljhxGEE0x05lz0zPbFcAIO72cLrArnpmaYXI=.67cc120b-912d-4a2a-b5ec-876c3f5ff593@github.com> Message-ID: On Wed, 1 Feb 2023 12:27:22 GMT, Nir Lisker wrote: >> I believe no code change is required as of now. Hence not making any changes now. > > I also think that `null` should throw unless otherwise specified. Since the null check is preexisting, I don't think we should make the change to throw NPE on null as part of a simple bug fix. If we decide to change this, I would want to see a spec change in the docs with an accompanying CSR, which should be done as a separate bug. ------------- PR: https://git.openjdk.org/jfx/pull/1018 From kcr at openjdk.org Wed Feb 1 13:19:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Feb 2023 13:19:08 GMT Subject: RFR: JDK-8299977 : Update WebKit to 615.1 [v2] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 18:49:21 GMT, Joeri Sykora wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add blank lines > > Building and testing succeeded on linux, mac and windows x86_64. @tiainen Can you re-review following Hima's removal of the print statement? ------------- PR: https://git.openjdk.org/jfx/pull/1011 From kcr at openjdk.org Wed Feb 1 13:20:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Feb 2023 13:20:04 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: <0I38lx2zHaW7yiflXcrK5wz3u9UfrWUPThBYi8k461M=.5ceecf74-f360-4efd-b6d0-234b3de370a0@github.com> On Thu, 26 Jan 2023 05:30:56 GMT, Glavo wrote: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? For a refactoring / cleanup fix like this, the question is whether it is worth the effort to test and review it. I don't know that it is, but if you can convince a Reviewer to test and review it, and then sponsor the fix for you, I won't object. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From sykora at openjdk.org Wed Feb 1 13:22:03 2023 From: sykora at openjdk.org (Joeri Sykora) Date: Wed, 1 Feb 2023 13:22:03 GMT Subject: RFR: JDK-8299977 : Update WebKit to 615.1 [v3] In-Reply-To: References: Message-ID: On Wed, 1 Feb 2023 04:11:48 GMT, Hima Bindu Meda wrote: >> Update JavaFX WebKit to GTK WebKit 2.38 (615.1). >> >> Verified the updated version build, sanity tests and stability. >> This does not cause any issues except one unit test failure. >> Also, there are some artifacts observed while playing youtube >> >> The above issues are recorded and ignored using below bugs: >> [JDK-8300954](https://bugs.openjdk.org/browse/JDK-8300954) >> [JDK-8301022](https://bugs.openjdk.org/browse/JDK-8301022) > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Remove the log added for testing purpose Marked as reviewed by sykora (Author). ------------- PR: https://git.openjdk.org/jfx/pull/1011 From nlisker at openjdk.org Wed Feb 1 13:27:05 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Feb 2023 13:27:05 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <3w4B3WB7LR8jkX2yvLCYGcMFWp6BJ8nTKriGJ5QmNxc=.31147d2a-383b-4092-9138-6dd0e661aa0c@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> <3w4B3WB7LR8jkX2yvLCYGcMFWp6BJ8nTKriGJ5QmNxc=.31147d2a-383b-4092-9138-6dd0e661aa0c@github.com> Message-ID: On Wed, 1 Feb 2023 11:21:04 GMT, Glavo wrote: >> Filed: https://bugs.openjdk.org/browse/JDK-8301604. Please let me know if the issue is not reported correctly. > > @theaoqi Thank you very much! @Glavo If you can't access JBS, you can submit a report via bugreport.java.com. @theaoqi If you create a JBS issue, fill in the affected version and fix version (`tbd` is fine) fields. The subcomponent is also not only graphics because there are changes to media as well. Use `other` for overarching changes like these (e.g., https://bugs.openjdk.org/browse/JDK-8208761). I can sponsor this fix, but it will need some more changes. Just a drop-in replacement with `List.of` doesn't result in good code. I will review it shortly. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From hmeda at openjdk.org Wed Feb 1 13:29:12 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 1 Feb 2023 13:29:12 GMT Subject: Integrated: JDK-8299977 : Update WebKit to 615.1 In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 19:51:02 GMT, Hima Bindu Meda wrote: > Update JavaFX WebKit to GTK WebKit 2.38 (615.1). > > Verified the updated version build, sanity tests and stability. > This does not cause any issues except one unit test failure. > Also, there are some artifacts observed while playing youtube > > The above issues are recorded and ignored using below bugs: > [JDK-8300954](https://bugs.openjdk.org/browse/JDK-8300954) > [JDK-8301022](https://bugs.openjdk.org/browse/JDK-8301022) This pull request has now been integrated. Changeset: 301bbd64 Author: Hima Bindu Meda Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/301bbd6409d463c4f789e2b3dcb6b2ea200d7373 Stats: 197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod 8299977: Update WebKit to 615.1 Co-authored-by: Jay Bhaskar Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1011 From kevin.rushforth at oracle.com Wed Feb 1 13:45:32 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 05:45:32 -0800 Subject: CFV: New OpenJFX Committer: Jay Bhaskar Message-ID: I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. Jay is a member of the JavaFX team at Oracle who has contributed 11 commits [2] to OpenJFX. Votes are due by February 15, 2023 at 14:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#jbhaskar [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Jay+Bhaskar%22&s=author-date&type=commits https://github.com/openjdk/jfx/search?q=%22Jay+Bhaskar%22&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [5] https://openjdk.org/projects#project-committer From kevin.rushforth at oracle.com Wed Feb 1 13:45:40 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 05:45:40 -0800 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda Message-ID: I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. Hima is a member of the JavaFX team at Oracle who has contributed 10 commits [2] to OpenJFX. Votes are due by February 15, 2023 at 14:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#hmeda [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [5] https://openjdk.org/projects#project-committer From kevin.rushforth at oracle.com Wed Feb 1 13:47:17 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 05:47:17 -0800 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: Vote: YES -- Kevin On 2/1/2023 5:45 AM, Kevin Rushforth wrote: > I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. From kevin.rushforth at oracle.com Wed Feb 1 13:47:40 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 05:47:40 -0800 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: Vote: YES -- Kevin On 2/1/2023 5:45 AM, Kevin Rushforth wrote: > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. From thiago.sayao at gmail.com Wed Feb 1 14:35:27 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 1 Feb 2023 11:35:27 -0300 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: Vote: YES Em qua., 1 de fev. de 2023 ?s 10:45, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. > > Jay is a member of the JavaFX team at Oracle who has contributed 11 > commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#jbhaskar > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Jay+Bhaskar%22&s=author-date&type=commits > https://github.com/openjdk/jfx/search?q=%22Jay+Bhaskar%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Wed Feb 1 14:36:19 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 1 Feb 2023 11:36:19 -0300 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: Vote: YES Em qua., 1 de fev. de 2023 ?s 10:45, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. > > Hima is a member of the JavaFX team at Oracle who has contributed 10 > commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#hmeda > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Wed Feb 1 14:47:07 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 1 Feb 2023 11:47:07 -0300 Subject: Some classes could be sealed Message-ID: Hi, NodeHelper.java has this: throw new UnsupportedOperationException( "Applications should not extend the " + nodeType + " class directly."); I think it's replaceable with selead classes. Am I right? The benefit will be compile time error instead of runtime. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Wed Feb 1 14:52:06 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Feb 2023 14:52:06 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: On Thu, 26 Jan 2023 05:30:56 GMT, Glavo wrote: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? ### FileChooser `List.of` and `List.copyOf` already check for a `null` argument and `null` elements. This means that `validateArgs` only needs to check the `length` of `extensions` and for an empty element. Since the only difference between the constructors is taking an array vs. taking a list, once a list is created from the array, the array constructor can call the list constructor. I suggest the following refactoring: public ExtensionFilter(String description, String... extensions) { this(description, List.of(extensions)); } public ExtensionFilter(String description, List extensions) { var extensionsList = List.copyOf(extensions); validateArgs(description, extensionsList); this.description = description; this.extensions = extensionsList; } Note that `List.copyOf` will not create another copy if it was called from the array constructor that already created an unmodifiable `List.of`. Now validation can be reduced to private static void validateArgs(String description, List extensions) { Objects.requireNonNull(description, "Description must not be null"); if (description.isEmpty()) { throw new IllegalArgumentException("Description must not be empty"); } if (extensions.isEmpty()) { throw new IllegalArgumentException("At least one extension must be defined"); } for (String extension : extensions) { if (extension.isEmpty()) { throw new IllegalArgumentException("Extension must not be empty"); } } } Aditionally, please add empty lines after the class declarations of `FileChooser` and `ExtensionFilter`. Also please correct the typo in `getTracks`: "The returned List **is** unmodifiable." modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageDescriptor.java line 41: > 39: this.extensions = List.of(extensions); > 40: this.signatures = List.of(signatures); > 41: this.mimeSubtypes = List.of(mimeSubtypes); While this is not equivalent since changing the backing array will not change the resulting list anymore, I would consider the old code a bug and this the correct fix. Note that in `FileChooser` care is taken to create a copy of the supplied array before using it to create a list. Additionally, care must be taken that all the callers don't have `null` elements in the arrays they pass. I checked it and it's fine (and should probably be disallowed, which is good now). By the way, this class should be a `record`, and all its subtypes, which are not really subtypes but just configured instances, should be modified accordingly. This is out of scope though. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/Media.java line 100: > 98: returnValue = null; > 99: } else { > 100: returnValue = List.copyOf(tracks); This is fine because `addTrack` checks for `null` elements. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/Media.java line 103: > 101: } > 102: } > 103: return returnValue; This method can be reduced to public List getTracks() { synchronized (tracks) { return tracks.isEmpty() ? null : List.copyOf(tracks); } } though I find it highly questionable that it returns `null` for an empty list instead of just an empty list. There are 2 use cases of this method and both would do better with just an empty list. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/1012 From johan.vos at gluonhq.com Wed Feb 1 15:07:26 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 1 Feb 2023 16:07:26 +0100 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: Vote: YES On Wed, Feb 1, 2023 at 2:46 PM Kevin Rushforth wrote: > I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. > > Jay is a member of the JavaFX team at Oracle who has contributed 11 > commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#jbhaskar > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Jay+Bhaskar%22&s=author-date&type=commits > https://github.com/openjdk/jfx/search?q=%22Jay+Bhaskar%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Wed Feb 1 15:10:34 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 1 Feb 2023 16:10:34 +0100 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: Vote: YES On Wed, Feb 1, 2023 at 2:46 PM Kevin Rushforth wrote: > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. > > Hima is a member of the JavaFX team at Oracle who has contributed 10 > commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#hmeda > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Feb 1 15:15:03 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Feb 2023 15:15:03 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: On Thu, 26 Jan 2023 05:30:56 GMT, Glavo wrote: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? > ### FileChooser > `List.of` and `List.copyOf` already check for a `null` argument and `null` elements. This means that `validateArgs` only needs to check the `length` of `extensions` and for an empty element. Since the only difference between the constructors is taking an array vs. taking a list, once a list is created from the array, the array constructor can call the list constructor. > > I suggest the following refactoring: > > ```java > public ExtensionFilter(String description, String... extensions) { > this(description, List.of(extensions)); > } > > public ExtensionFilter(String description, List extensions) { > var extensionsList = List.copyOf(extensions); > validateArgs(description, extensionsList); > this.description = description; > this.extensions = extensionsList; > } > ``` > > Note that `List.copyOf` will not create another copy if it was called from the array constructor that already created an unmodifiable `List.of`. > > Now validation can be reduced to > > ```java > private static void validateArgs(String description, List extensions) { > Objects.requireNonNull(description, "Description must not be null"); > > if (description.isEmpty()) { > throw new IllegalArgumentException("Description must not be empty"); > } > > if (extensions.isEmpty()) { > throw new IllegalArgumentException("At least one extension must be defined"); > } > > for (String extension : extensions) { > if (extension.isEmpty()) { > throw new IllegalArgumentException("Extension must not be empty"); > } > } > } > ``` > > Aditionally, please add empty lines after the class declarations of `FileChooser` and `ExtensionFilter`. > > Also please correct the typo in `getTracks`: "The returned `List` **is** unmodifiable." I have considered this, but I didn't make this change because I was worried that there would be less descriptive information when null was encountered. If this is not a problem, I am very happy to be able to carry out such refactoring. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From andy.goryachev at oracle.com Wed Feb 1 16:00:54 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 1 Feb 2023 16:00:54 +0000 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: Vote: YES -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, February 1, 2023 at 05:45 To: openjfx-dev , Hima Bindu Meda Subject: CFV: New OpenJFX Committer: Hima Bindu Meda I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. Hima is a member of the JavaFX team at Oracle who has contributed 10 commits [2] to OpenJFX. Votes are due by February 15, 2023 at 14:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#hmeda [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [5] https://openjdk.org/projects#project-committer -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Feb 1 16:01:02 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 1 Feb 2023 16:01:02 +0000 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: Vote: YES -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, February 1, 2023 at 05:45 To: openjfx-dev , Jay Bhaskar Subject: CFV: New OpenJFX Committer: Jay Bhaskar I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. Jay is a member of the JavaFX team at Oracle who has contributed 11 commits [2] to OpenJFX. Votes are due by February 15, 2023 at 14:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#jbhaskar [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Jay+Bhaskar%22&s=author-date&type=commits https://github.com/openjdk/jfx/search?q=%22Jay+Bhaskar%22&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [5] https://openjdk.org/projects#project-committer -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Feb 1 16:12:07 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Feb 2023 16:12:07 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: References: Message-ID: <3nFtvzsM4DbwLXSgO8qGrjeEomvOLSNXd_acSJ7RNQE=.85bf456b-227e-4717-b336-91a37e294e80@github.com> On Wed, 1 Feb 2023 06:37:21 GMT, Karthik P K wrote: >> In `selectIndices` method, zero length array is not considered while ignoring row number given as parameter. >> >> Updated the code to consider both null and zero length array in the condition before ignoring the row value given as parameter. >> >> Added unit test to validate the fix > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix first index selection issue in TreeTableView I don't think null should throw an NPE in this case. Thank you Karthik for writing unit tests. LGTM ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/1018 From john at status6.com Wed Feb 1 16:32:24 2023 From: john at status6.com (John Neffenger) Date: Wed, 1 Feb 2023 08:32:24 -0800 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: <1c08031b-d1a1-b15a-855b-79643570e10c@status6.com> Vote: YES John On 2/1/23 5:45 AM, Kevin Rushforth wrote: > I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. From john at status6.com Wed Feb 1 16:32:44 2023 From: john at status6.com (John Neffenger) Date: Wed, 1 Feb 2023 08:32:44 -0800 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: <69374f7a-2386-6a0c-ea6a-83e0b49e2dc2@status6.com> Vote: YES John On 2/1/23 5:45 AM, Kevin Rushforth wrote: > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. From john.hendrikx at gmail.com Wed Feb 1 16:39:40 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 1 Feb 2023 17:39:40 +0100 Subject: Some classes could be sealed In-Reply-To: References: Message-ID: I think this may be a bit unclear from this post, but you're proposing I think to make `Node`, `Shape` and `Shape3D` sealed. For those unaware, you're not allowed to extend these classes (despite being public).? For example Node says in its documentation: ?? * An application should not extend the Node class directly. Doing so may lead to ?? * an UnsupportedOperationException being thrown. Currently this is enforced at runtime in NodeHelper. --John On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: > Hi, > > NodeHelper.java has this: > throw new UnsupportedOperationException( > "Applications should not extend the " + nodeType +" class directly."); > > I think it's replaceable with selead classes. Am I right? > > The benefit will be compile time error instead of runtime. > > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Wed Feb 1 16:48:26 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 1 Feb 2023 17:48:26 +0100 Subject: Some classes could be sealed In-Reply-To: References: Message-ID: I don't think that's what Thiago is proposing. Only `Node` would be sealed. The following subclasses would be non-sealed: Parent, SubScene, Camera, LightBase, Shape, Shape3D, Canvas, ImageView. And then there are additional subclasses, which don't fit into this idea since they are in other modules: SwingNode (in javafx.swing), MediaView (in javafx.media), Printable (in javafx.web). On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx wrote: > > I think this may be a bit unclear from this post, but you're proposing I think to make `Node`, `Shape` and `Shape3D` sealed. For those unaware, you're not allowed to extend these classes (despite being public). For example Node says in its documentation: > > * An application should not extend the Node class directly. Doing so may lead to > * an UnsupportedOperationException being thrown. > > Currently this is enforced at runtime in NodeHelper. > > --John > > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: > > Hi, > > NodeHelper.java has this: > > throw new UnsupportedOperationException( > "Applications should not extend the " > + nodeType + " class directly."); > > > I think it's replaceable with selead classes. Am I right? > > The benefit will be compile time error instead of runtime. > > > -- Thiago. > From jhendrikx at openjdk.org Wed Feb 1 16:57:05 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Feb 2023 16:57:05 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: <-qVG6eVzBeaqMRMZoIDI3dZh1lBd9fJx8gkuxivjSQY=.47dc740b-a871-4702-819a-491118c885c1@github.com> On Wed, 1 Feb 2023 14:36:51 GMT, Nir Lisker wrote: >> `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. >> >> Because `List.of` can only store non-null elements, I have only replaced a few usage. >> >> Can someone open an Issue on JBS for me? > > modules/javafx.media/src/main/java/com/sun/media/jfxmedia/Media.java line 103: > >> 101: } >> 102: } >> 103: return returnValue; > > This method can be reduced to > > public List getTracks() { > synchronized (tracks) { > return tracks.isEmpty() ? null : List.copyOf(tracks); > } > } > > though I find it highly questionable that it returns `null` for an empty list instead of just an empty list. There are 2 use cases of this method and both would do better with just an empty list. Yeah, I noticed this as well right away, it is documented to do this though. The documentation however does seem to suggest it might be possible that there are three results: 1. Tracks haven't been scanned yet -> `null` 2. Tracks have been scanned, but none where found -> empty list 3. Tracks have been scanned and some were found -> list Whether case 2 can ever happen is unclear, but distinguishing it from the case where nothing has been scanned yet with `null` does not seem unreasonable. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From thiago.sayao at gmail.com Wed Feb 1 16:59:08 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 1 Feb 2023 13:59:08 -0300 Subject: Some classes could be sealed In-Reply-To: References: Message-ID: Yes, sorry, I made the email title in plural, but I meant what Michael said, Node would be sealed permitting only what is needed for JavaFx internally. -- Thiago Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? escreveu: > I don't think that's what Thiago is proposing. Only `Node` would be sealed. > The following subclasses would be non-sealed: Parent, SubScene, > Camera, LightBase, Shape, Shape3D, Canvas, ImageView. > And then there are additional subclasses, which don't fit into this > idea since they are in other modules: SwingNode (in javafx.swing), > MediaView (in javafx.media), Printable (in javafx.web). > > > > On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx > wrote: > > > > I think this may be a bit unclear from this post, but you're proposing I > think to make `Node`, `Shape` and `Shape3D` sealed. For those unaware, > you're not allowed to extend these classes (despite being public). For > example Node says in its documentation: > > > > * An application should not extend the Node class directly. Doing so > may lead to > > * an UnsupportedOperationException being thrown. > > > > Currently this is enforced at runtime in NodeHelper. > > > > --John > > > > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: > > > > Hi, > > > > NodeHelper.java has this: > > > > throw new UnsupportedOperationException( > > "Applications should not extend the " > > + nodeType + " class directly."); > > > > > > I think it's replaceable with selead classes. Am I right? > > > > The benefit will be compile time error instead of runtime. > > > > > > -- Thiago. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Feb 1 17:06:26 2023 From: philip.race at oracle.com (Philip Race) Date: Wed, 1 Feb 2023 09:06:26 -0800 Subject: Some classes could be sealed In-Reply-To: References: Message-ID: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> In the JDK we've only sealed? existing classes which provably could not have been extended by application classes, so I'm not sure about this .. also I think that might be the first change that absolutely means FX 21 can only be built with JDK 17 and later .. -phil On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: > Yes, sorry, I made the email title in plural, but I meant what Michael > said, Node would be sealed permitting only what is needed for JavaFx > internally. > > > -- Thiago > > > Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? > escreveu: > > I don't think that's what Thiago is proposing. Only `Node` would > be sealed. > The following subclasses would be non-sealed: Parent, SubScene, > Camera, LightBase, Shape, Shape3D, Canvas, ImageView. > And then there are additional subclasses, which don't fit into this > idea since they are in other modules: SwingNode (in javafx.swing), > MediaView (in javafx.media), Printable (in javafx.web). > > > > On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx > wrote: > > > > I think this may be a bit unclear from this post, but you're > proposing I think to make `Node`, `Shape` and `Shape3D` sealed.? > For those unaware, you're not allowed to extend these classes > (despite being public).? For example Node says in its documentation: > > > >? ? * An application should not extend the Node class directly. > Doing so may lead to > >? ? * an UnsupportedOperationException being thrown. > > > > Currently this is enforced at runtime in NodeHelper. > > > > --John > > > > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: > > > > Hi, > > > > NodeHelper.java has this: > > > > throw new UnsupportedOperationException( > >? ? ? ? ?"Applications should not extend the " > >? ? ? ? ?+ nodeType + " class directly."); > > > > > > I think it's replaceable with selead classes. Am I right? > > > > The benefit will be compile time error instead of runtime. > > > > > > -- Thiago. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Feb 1 17:26:01 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 09:26:01 -0800 Subject: Some classes could be sealed In-Reply-To: References: Message-ID: <33bd931b-777e-042f-ba0d-e4316c845502@oracle.com> Yes, now that JDK 17 is the minimum we can consider doing this. As you mentioned, it would provide earlier notification of the error: compile-time versus runtime. One thing to add is that in addition to sealing Node, we would leave at least Shape, Shape3D, Camera, and LightBase sealed, since they are also not extensible and throw a similar runtime exception. -- Kevin On 2/1/2023 8:59 AM, Thiago Milczarek Say?o wrote: > Yes, sorry, I made the email title in plural, but I meant what Michael > said, Node would be sealed permitting only what is needed for JavaFx > internally. > > > -- Thiago > > > Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? > escreveu: > > I don't think that's what Thiago is proposing. Only `Node` would > be sealed. > The following subclasses would be non-sealed: Parent, SubScene, > Camera, LightBase, Shape, Shape3D, Canvas, ImageView. > And then there are additional subclasses, which don't fit into this > idea since they are in other modules: SwingNode (in javafx.swing), > MediaView (in javafx.media), Printable (in javafx.web). > > > > On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx > wrote: > > > > I think this may be a bit unclear from this post, but you're > proposing I think to make `Node`, `Shape` and `Shape3D` sealed.? > For those unaware, you're not allowed to extend these classes > (despite being public).? For example Node says in its documentation: > > > >? ? * An application should not extend the Node class directly. > Doing so may lead to > >? ? * an UnsupportedOperationException being thrown. > > > > Currently this is enforced at runtime in NodeHelper. > > > > --John > > > > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: > > > > Hi, > > > > NodeHelper.java has this: > > > > throw new UnsupportedOperationException( > >? ? ? ? ?"Applications should not extend the " > >? ? ? ? ?+ nodeType + " class directly."); > > > > > > I think it's replaceable with selead classes. Am I right? > > > > The benefit will be compile time error instead of runtime. > > > > > > -- Thiago. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Wed Feb 1 17:31:11 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Feb 2023 17:31:11 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 14:51:59 GMT, John Hendrikx wrote: >> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - JDK-8269907 >> Added missing changes after merge >> - Merge remote-tracking branch 'origjfx/master' into JDK-8269907-dirty-and-removed >> >> # Conflicts: >> # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java >> # modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> - Merge remote-tracking branch 'origin/master' >> - JDK-8269907 >> Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. >> - JDK-8269907 >> Fixed rare bug, causing bounds to be out of sync. >> - JDK-8269907 >> We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. >> - JDK-8269907 >> The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks. >> - JDK-8269907 >> Fixing dirty nodes and parent removed, when a window is no longer showing. This typically happens with context menus. > > I took another good look at this solution, and I would like to offer an alternative as I think this solution is more dealing with symptoms of the underlying problem. > > I think the underlying problem is: > > 1) `Parent` is tracking a `removed` list, which is a list of `Node`. However, it only requires the peer for the dirty area calculation. This is a classic case of not being specific enough with the information you need. If `Parent` is modified to store `NGNode` in its `removed` list, then the problem of `removed` keeping references to old nodes disappears as `NGNode` does not refer back to `Node`. Note: there is a test method currently in `Parent` that returns the list of removed nodes -- these tests would need to be modified to work with a list of `NGNode` or some other way should be found to check these cases. > > 2) `Scene` keeps tracking dirty nodes even when it is not visible. The list of dirty nodes could (before this fix) become as big as you want as it was never cleared as the pulse listener that synchronizes the nodes never runs when `peer == null` -- keep adding and removing new nodes while the scene is not shown, and the list of dirty nodes grows indefinitely. This only happens if the scene has been shown at least once before, as before that time special code kicks in that tries to avoid keeping track of all scene nodes in the dirty list. > > I think the better solution here would be to reset the scene to go back to its initial state (before it was shown) and sync all nodes when it becomes visible again. This can be achieved by setting the dirty node list to `null` to trigger the logic that normally only triggers on the first show. `addToDirtyList` should simply do nothing when `peer == null` . > > I believe the `syncPeer` call is smart enough not to update the peer in the situation where a scene is hidden and then reshown, even if `Scene` calls it again on all its nodes (`syncPeer` in `Node` will check `dirtyBits.isEmpty()`). > > I'd also highly recommend using `ArrayList` instead of a manual `Node[] dirtyNodes` in `Scene`. > @hjohn > > ``` > The Parent is tracking a removed list, which is a list of Node. However, it only requires the peer for the dirty area calculation. This is a classic case of not being specific enough with the information you need. If Parent is modified to store NGNode in its removed list, then the problem of removed keeping references to old nodes disappears as NGNode does not refer back to Node. Note: there is a test method currently in Parent that returns the list of removed nodes -- these tests would need to be modified to work with a list of NGNode or some other way should be found to check these cases. > ``` > > This would just end in an leak of the NGNode, instead of the Node? There are also some leaks related to NGNode, bug guess I'll have to fix the more obvious bugs first. Also, NGNode sometimes refers to the Node. There are a lot of issues in this area. Why not fix the root causes? This PR introduces several new things to fix a bug in a round about way that would not be needed at all if the root causes are fixed. I'm happy to help out here, as I prefer fixing the underlying problems (which probably solves multiple problems at once) rather than having to deal with each symptom and making things even more inscrutable in places where these symptoms appear. If you know the root causes, then please explain them so they can be dealt with. I've only taken a short look, and I agree that `NGNode` probably would be leaked instead. However, the end goal is to track how big the dirty area is. If keeping a list of nodes/ngnodes is bad, then how about keeping a rectangle instead and tracking the dirty area immediately? That would also solve problems related to NGNode pointing back to Node. This would likely solve multiple problems, not just related to stages -- I suppose nodes can be detached and this removed list could cause problems then as well. > ## Resetting the Scene > This approach has one problem - it would change the complexity of showing/hiding a window. This issue typically happened with Popups, which are regularly shown/hidden. I guess changing the complexity to O() might be ok - but I'm not sure about it. I think that the resulting code would be simpler, with less special cases (why should a stage that was shown before act differently from a fresh one). The O(n) loop to sync all peers should not be an issue when doing a relatively heavy action like showing a window as `syncPeer` will do nothing for nodes that haven't become dirty. Also, it has benefits as well. Changes to nodes on a shown then hidden stage would now be more performant, and would eliminate any performance differences between a fresh stage and one that was shown before. ------------- PR: https://git.openjdk.org/jfx/pull/584 From kevin.rushforth at oracle.com Wed Feb 1 17:37:25 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 09:37:25 -0800 Subject: Some classes could be sealed In-Reply-To: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> Message-ID: <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> I agree that we should only seal existing classes that could not have been extended by application classes. The ones I listed in my previous email fit that bill, since an attempt to subclass them will throw an exception when it is used in a scene graph. Each documents that subclassing is disallowed. Btw, we've already started making use of pattern-matching instanceof in the implementation anyway. It would be the first API change that relies on a JDK 17 feature, but for JavaFX 21, I see no problem in doing that. -- Kevin On 2/1/2023 9:06 AM, Philip Race wrote: > In the JDK we've only sealed? existing classes which provably could > not have been extended by application classes, > so I'm not sure about this .. > > also I think that might be the first change that absolutely means FX > 21 can only be built with JDK 17 and later .. > > -phil > > On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: >> Yes, sorry, I made the email title in plural, but I meant what >> Michael said, Node would be sealed permitting only what is needed for >> JavaFx internally. >> >> >> -- Thiago >> >> >> Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? >> escreveu: >> >> I don't think that's what Thiago is proposing. Only `Node` would >> be sealed. >> The following subclasses would be non-sealed: Parent, SubScene, >> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >> And then there are additional subclasses, which don't fit into this >> idea since they are in other modules: SwingNode (in javafx.swing), >> MediaView (in javafx.media), Printable (in javafx.web). >> >> >> >> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >> wrote: >> > >> > I think this may be a bit unclear from this post, but you're >> proposing I think to make `Node`, `Shape` and `Shape3D` sealed.? >> For those unaware, you're not allowed to extend these classes >> (despite being public).? For example Node says in its documentation: >> > >> >? ? * An application should not extend the Node class directly. >> Doing so may lead to >> >? ? * an UnsupportedOperationException being thrown. >> > >> > Currently this is enforced at runtime in NodeHelper. >> > >> > --John >> > >> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >> > >> > Hi, >> > >> > NodeHelper.java has this: >> > >> > throw new UnsupportedOperationException( >> >? ? ? ? ?"Applications should not extend the " >> >? ? ? ? ?+ nodeType + " class directly."); >> > >> > >> > I think it's replaceable with selead classes. Am I right? >> > >> > The benefit will be compile time error instead of runtime. >> > >> > >> > -- Thiago. >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Feb 1 17:45:15 2023 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 1 Feb 2023 19:45:15 +0200 Subject: Some classes could be sealed In-Reply-To: <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> Message-ID: I'll add that internal classes, mostly NG___ peers, can also benefit from sealing. NGLightBase is an example. Material is another public class that can be sealed. On Wed, Feb 1, 2023 at 7:37 PM Kevin Rushforth wrote: > I agree that we should only seal existing classes that could not have been > extended by application classes. The ones I listed in my previous email fit > that bill, since an attempt to subclass them will throw an exception when > it is used in a scene graph. Each documents that subclassing is disallowed. > > Btw, we've already started making use of pattern-matching instanceof in > the implementation anyway. It would be the first API change that relies on > a JDK 17 feature, but for JavaFX 21, I see no problem in doing that. > > -- Kevin > > > On 2/1/2023 9:06 AM, Philip Race wrote: > > In the JDK we've only sealed existing classes which provably could not > have been extended by application classes, > so I'm not sure about this .. > > also I think that might be the first change that absolutely means FX 21 > can only be built with JDK 17 and later .. > > -phil > > On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: > > Yes, sorry, I made the email title in plural, but I meant what Michael > said, Node would be sealed permitting only what is needed for JavaFx > internally. > > > -- Thiago > > > Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? < > michaelstrau2 at gmail.com> escreveu: > >> I don't think that's what Thiago is proposing. Only `Node` would be >> sealed. >> The following subclasses would be non-sealed: Parent, SubScene, >> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >> And then there are additional subclasses, which don't fit into this >> idea since they are in other modules: SwingNode (in javafx.swing), >> MediaView (in javafx.media), Printable (in javafx.web). >> >> >> >> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >> wrote: >> > >> > I think this may be a bit unclear from this post, but you're proposing >> I think to make `Node`, `Shape` and `Shape3D` sealed. For those unaware, >> you're not allowed to extend these classes (despite being public). For >> example Node says in its documentation: >> > >> > * An application should not extend the Node class directly. Doing so >> may lead to >> > * an UnsupportedOperationException being thrown. >> > >> > Currently this is enforced at runtime in NodeHelper. >> > >> > --John >> > >> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >> > >> > Hi, >> > >> > NodeHelper.java has this: >> > >> > throw new UnsupportedOperationException( >> > "Applications should not extend the " >> > + nodeType + " class directly."); >> > >> > >> > I think it's replaceable with selead classes. Am I right? >> > >> > The benefit will be compile time error instead of runtime. >> > >> > >> > -- Thiago. >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Wed Feb 1 17:45:46 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 1 Feb 2023 17:45:46 GMT Subject: RFR: 8300705: Update boot JDK to 19.0.2 Message-ID: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Updating boot JDK to 19.0.2. ------------- Commit messages: - boot jdk 19.0.2b7 Changes: https://git.openjdk.org/jfx/pull/1019/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300705 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1019.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1019/head:pull/1019 PR: https://git.openjdk.org/jfx/pull/1019 From philip.race at oracle.com Wed Feb 1 18:56:20 2023 From: philip.race at oracle.com (Philip Race) Date: Wed, 1 Feb 2023 10:56:20 -0800 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: <0595fa1c-aee2-c01f-658e-611e02f1ae24@oracle.com> Vote: yes -phil. From philip.race at oracle.com Wed Feb 1 18:56:36 2023 From: philip.race at oracle.com (Philip Race) Date: Wed, 1 Feb 2023 10:56:36 -0800 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: <0840cb87-26d2-df07-1cc4-d132f12f8f2c@oracle.com> Vote: yes -phil. From kcr at openjdk.org Wed Feb 1 18:59:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Feb 2023 18:59:07 GMT Subject: RFR: 8300705: Update boot JDK to 19.0.2 In-Reply-To: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> References: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Message-ID: On Wed, 1 Feb 2023 17:39:55 GMT, Ambarish Rapte wrote: > Updating boot JDK to 19.0.2. Looks good. Since it is just updating to a new update in the JDK 19 family (from 19.0.1 to 19.0.2), a single reviewer should be sufficient. You might wait until tomorrow (as long as it is before RDP2) to integrate it in case @johanvos has any concerns. Actually, I just noticed that this is targeted to `master`. It should be targeted to `jfx20`. And since it is based off of master, you will need to rebase on top of `jfx20` and force-push. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/1019Changes requested by kcr (Lead). From angorya at openjdk.org Wed Feb 1 19:37:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Feb 2023 19:37:20 GMT Subject: RFR: 8088998: LineChart: duplicate child added exception when remove & add a series In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 12:21:38 GMT, Karthik P K wrote: > While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run. > > Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted. > > This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix. @karthikpandelu are you going to fix the remaining charts as a part of https://bugs.openjdk.org/browse/JDK-8301445 or continue with this PR? ------------- PR: https://git.openjdk.org/jfx/pull/1015 From kevin.rushforth at oracle.com Wed Feb 1 19:37:35 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 11:37:35 -0800 Subject: [External] : Re: Some classes could be sealed In-Reply-To: References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> Message-ID: <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> I read the spec for sealed classes more carefully, and it turns out we can't make Node sealed. At least not without API changes to SwingNode and MediaView (and implementation changes to Printable in the javafx.web module). All of the classes listed in the "permits" clause must be in the same module, and SwingNode (javafx.swing) and MediaView (javafx.media) extend Node directly they would need to be "permitted" subtypes, but there is no way to specify that. We would also need to do something about the tests that extend Node and run in the unnamed module. So this doesn't seem feasible. We could still seal Shape, Shape3D, LightBase, and Material, since all permitted implementation are in the javafx.graphics module. It may or may not be worth doing that. -- Kevin On 2/1/2023 9:45 AM, Nir Lisker wrote: > I'll add that internal classes, mostly NG___ peers, can also benefit > from sealing. NGLightBase is an example. > > Material is another public class that can be sealed. > > On Wed, Feb 1, 2023 at 7:37 PM Kevin Rushforth > wrote: > > I agree that we should only seal existing classes that could not > have been extended by application classes. The ones I listed in my > previous email fit that bill, since an attempt to subclass them > will throw an exception when it is used in a scene graph. Each > documents that subclassing is disallowed. > > Btw, we've already started making use of pattern-matching > instanceof in the implementation anyway. It would be the first API > change that relies on a JDK 17 feature, but for JavaFX 21, I see > no problem in doing that. > > -- Kevin > > > On 2/1/2023 9:06 AM, Philip Race wrote: >> In the JDK we've only sealed existing classes which provably >> could not have been extended by application classes, >> so I'm not sure about this .. >> >> also I think that might be the first change that absolutely means >> FX 21 can only be built with JDK 17 and later .. >> >> -phil >> >> On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: >>> Yes, sorry, I made the email title in plural, but I meant what >>> Michael said, Node would be sealed permitting only what is >>> needed for JavaFx internally. >>> >>> >>> -- Thiago >>> >>> >>> Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? >>> escreveu: >>> >>> I don't think that's what Thiago is proposing. Only `Node` >>> would be sealed. >>> The following subclasses would be non-sealed: Parent, SubScene, >>> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >>> And then there are additional subclasses, which don't fit >>> into this >>> idea since they are in other modules: SwingNode (in >>> javafx.swing), >>> MediaView (in javafx.media), Printable (in javafx.web). >>> >>> >>> >>> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >>> wrote: >>> > >>> > I think this may be a bit unclear from this post, but >>> you're proposing I think to make `Node`, `Shape` and >>> `Shape3D` sealed.? For those unaware, you're not allowed to >>> extend these classes (despite being public).? For example >>> Node says in its documentation: >>> > >>> >? ? * An application should not extend the Node class >>> directly. Doing so may lead to >>> >? ? * an UnsupportedOperationException being thrown. >>> > >>> > Currently this is enforced at runtime in NodeHelper. >>> > >>> > --John >>> > >>> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >>> > >>> > Hi, >>> > >>> > NodeHelper.java has this: >>> > >>> > throw new UnsupportedOperationException( >>> >? ? ? ? ?"Applications should not extend the " >>> >? ? ? ? ?+ nodeType + " class directly."); >>> > >>> > >>> > I think it's replaceable with selead classes. Am I right? >>> > >>> > The benefit will be compile time error instead of runtime. >>> > >>> > >>> > -- Thiago. >>> > >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Feb 1 19:56:35 2023 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 1 Feb 2023 21:56:35 +0200 Subject: [External] : Re: Some classes could be sealed In-Reply-To: <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> Message-ID: I held on proposing sealed class changes because they will be more beneficial once switch patterns are introduced. I also held on refactoring to records (of which I have a branch in my fork) for the reason that record patterns are not out yet. I think that once we have more pieces of the algebraic data types puzzle it will be very beneficial to do a decent amount of refactoring. There's nothing stopping us from starting with what we have for the purpose of upgrading errors from runtime to compile time, but we will need a second iteration anyway in some of these cases. On Wed, Feb 1, 2023 at 9:37 PM Kevin Rushforth wrote: > I read the spec for sealed classes more carefully, and it turns out we > can't make Node sealed. At least not without API changes to SwingNode and > MediaView (and implementation changes to Printable in the javafx.web > module). All of the classes listed in the "permits" clause must be in the > same module, and SwingNode (javafx.swing) and MediaView (javafx.media) > extend Node directly they would need to be "permitted" subtypes, but there > is no way to specify that. We would also need to do something about the > tests that extend Node and run in the unnamed module. So this doesn't seem > feasible. > > We could still seal Shape, Shape3D, LightBase, and Material, since all > permitted implementation are in the javafx.graphics module. It may or may > not be worth doing that. > > -- Kevin > > > On 2/1/2023 9:45 AM, Nir Lisker wrote: > > I'll add that internal classes, mostly NG___ peers, can also benefit from > sealing. NGLightBase is an example. > > Material is another public class that can be sealed. > > On Wed, Feb 1, 2023 at 7:37 PM Kevin Rushforth > wrote: > >> I agree that we should only seal existing classes that could not have >> been extended by application classes. The ones I listed in my previous >> email fit that bill, since an attempt to subclass them will throw an >> exception when it is used in a scene graph. Each documents that subclassing >> is disallowed. >> >> Btw, we've already started making use of pattern-matching instanceof in >> the implementation anyway. It would be the first API change that relies on >> a JDK 17 feature, but for JavaFX 21, I see no problem in doing that. >> >> -- Kevin >> >> >> On 2/1/2023 9:06 AM, Philip Race wrote: >> >> In the JDK we've only sealed existing classes which provably could not >> have been extended by application classes, >> so I'm not sure about this .. >> >> also I think that might be the first change that absolutely means FX 21 >> can only be built with JDK 17 and later .. >> >> -phil >> >> On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: >> >> Yes, sorry, I made the email title in plural, but I meant what Michael >> said, Node would be sealed permitting only what is needed for JavaFx >> internally. >> >> >> -- Thiago >> >> >> Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? < >> michaelstrau2 at gmail.com> escreveu: >> >>> I don't think that's what Thiago is proposing. Only `Node` would be >>> sealed. >>> The following subclasses would be non-sealed: Parent, SubScene, >>> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >>> And then there are additional subclasses, which don't fit into this >>> idea since they are in other modules: SwingNode (in javafx.swing), >>> MediaView (in javafx.media), Printable (in javafx.web). >>> >>> >>> >>> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >>> wrote: >>> > >>> > I think this may be a bit unclear from this post, but you're proposing >>> I think to make `Node`, `Shape` and `Shape3D` sealed. For those unaware, >>> you're not allowed to extend these classes (despite being public). For >>> example Node says in its documentation: >>> > >>> > * An application should not extend the Node class directly. Doing >>> so may lead to >>> > * an UnsupportedOperationException being thrown. >>> > >>> > Currently this is enforced at runtime in NodeHelper. >>> > >>> > --John >>> > >>> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >>> > >>> > Hi, >>> > >>> > NodeHelper.java has this: >>> > >>> > throw new UnsupportedOperationException( >>> > "Applications should not extend the " >>> > + nodeType + " class directly."); >>> > >>> > >>> > I think it's replaceable with selead classes. Am I right? >>> > >>> > The benefit will be compile time error instead of runtime. >>> > >>> > >>> > -- Thiago. >>> > >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Feb 1 22:38:34 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 1 Feb 2023 23:38:34 +0100 Subject: [External] : Re: Some classes could be sealed In-Reply-To: <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> Message-ID: <92a4ad76-6b0e-3327-ad51-27ba5f030cad@gmail.com> I'm curious to know why these classes are not allowed to be subclassed directly, as that may be important in order to decide whether these classes should really be sealed. --John On 01/02/2023 20:37, Kevin Rushforth wrote: > I read the spec for sealed classes more carefully, and it turns out we > can't make Node sealed. At least not without API changes to SwingNode > and MediaView (and implementation changes to Printable in the > javafx.web module). All of the classes listed in the "permits" clause > must be in the same module, and SwingNode (javafx.swing) and MediaView > (javafx.media) extend Node directly they would need to be "permitted" > subtypes, but there is no way to specify that. We would also need to > do something about the tests that extend Node and run in the unnamed > module. So this doesn't seem feasible. > > We could still seal Shape, Shape3D, LightBase, and Material, since all > permitted implementation are in the javafx.graphics module. It may or > may not be worth doing that. > > -- Kevin > > > On 2/1/2023 9:45 AM, Nir Lisker wrote: >> I'll add that internal classes, mostly NG___ peers, can also benefit >> from sealing. NGLightBase is an example. >> >> Material is another public class that can be sealed. >> >> On Wed, Feb 1, 2023 at 7:37 PM Kevin Rushforth >> wrote: >> >> I agree that we should only seal existing classes that could not >> have been extended by application classes. The ones I listed in >> my previous email fit that bill, since an attempt to subclass >> them will throw an exception when it is used in a scene graph. >> Each documents that subclassing is disallowed. >> >> Btw, we've already started making use of pattern-matching >> instanceof in the implementation anyway. It would be the first >> API change that relies on a JDK 17 feature, but for JavaFX 21, I >> see no problem in doing that. >> >> -- Kevin >> >> >> On 2/1/2023 9:06 AM, Philip Race wrote: >>> In the JDK we've only sealed existing classes which provably >>> could not have been extended by application classes, >>> so I'm not sure about this .. >>> >>> also I think that might be the first change that absolutely >>> means FX 21 can only be built with JDK 17 and later .. >>> >>> -phil >>> >>> On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: >>>> Yes, sorry, I made the email title in plural, but I meant what >>>> Michael said, Node would be sealed permitting only what is >>>> needed for JavaFx internally. >>>> >>>> >>>> -- Thiago >>>> >>>> >>>> Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? >>>> escreveu: >>>> >>>> I don't think that's what Thiago is proposing. Only `Node` >>>> would be sealed. >>>> The following subclasses would be non-sealed: Parent, SubScene, >>>> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >>>> And then there are additional subclasses, which don't fit >>>> into this >>>> idea since they are in other modules: SwingNode (in >>>> javafx.swing), >>>> MediaView (in javafx.media), Printable (in javafx.web). >>>> >>>> >>>> >>>> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >>>> wrote: >>>> > >>>> > I think this may be a bit unclear from this post, but >>>> you're proposing I think to make `Node`, `Shape` and >>>> `Shape3D` sealed.? For those unaware, you're not allowed to >>>> extend these classes (despite being public).? For example >>>> Node says in its documentation: >>>> > >>>> >? ? * An application should not extend the Node class >>>> directly. Doing so may lead to >>>> >? ? * an UnsupportedOperationException being thrown. >>>> > >>>> > Currently this is enforced at runtime in NodeHelper. >>>> > >>>> > --John >>>> > >>>> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >>>> > >>>> > Hi, >>>> > >>>> > NodeHelper.java has this: >>>> > >>>> > throw new UnsupportedOperationException( >>>> >? ? ? ? ?"Applications should not extend the " >>>> >? ? ? ? ?+ nodeType + " class directly."); >>>> > >>>> > >>>> > I think it's replaceable with selead classes. Am I right? >>>> > >>>> > The benefit will be compile time error instead of runtime. >>>> > >>>> > >>>> > -- Thiago. >>>> > >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Feb 1 22:48:28 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 2 Feb 2023 00:48:28 +0200 Subject: [External] : Re: Some classes could be sealed In-Reply-To: <92a4ad76-6b0e-3327-ad51-27ba5f030cad@gmail.com> References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> <92a4ad76-6b0e-3327-ad51-27ba5f030cad@gmail.com> Message-ID: For Material and LightBase it's because they are just facades whose implementation is in native code. You can't extend these without tampering with internals. I think that Camera and Shape3D also requires modifying internal stuff, though not at the native level. On Thu, Feb 2, 2023 at 12:38 AM John Hendrikx wrote: > I'm curious to know why these classes are not allowed to be subclassed > directly, as that may be important in order to decide whether these classes > should really be sealed. > > --John > On 01/02/2023 20:37, Kevin Rushforth wrote: > > I read the spec for sealed classes more carefully, and it turns out we > can't make Node sealed. At least not without API changes to SwingNode and > MediaView (and implementation changes to Printable in the javafx.web > module). All of the classes listed in the "permits" clause must be in the > same module, and SwingNode (javafx.swing) and MediaView (javafx.media) > extend Node directly they would need to be "permitted" subtypes, but there > is no way to specify that. We would also need to do something about the > tests that extend Node and run in the unnamed module. So this doesn't seem > feasible. > > We could still seal Shape, Shape3D, LightBase, and Material, since all > permitted implementation are in the javafx.graphics module. It may or may > not be worth doing that. > > -- Kevin > > > On 2/1/2023 9:45 AM, Nir Lisker wrote: > > I'll add that internal classes, mostly NG___ peers, can also benefit from > sealing. NGLightBase is an example. > > Material is another public class that can be sealed. > > On Wed, Feb 1, 2023 at 7:37 PM Kevin Rushforth > wrote: > >> I agree that we should only seal existing classes that could not have >> been extended by application classes. The ones I listed in my previous >> email fit that bill, since an attempt to subclass them will throw an >> exception when it is used in a scene graph. Each documents that subclassing >> is disallowed. >> >> Btw, we've already started making use of pattern-matching instanceof in >> the implementation anyway. It would be the first API change that relies on >> a JDK 17 feature, but for JavaFX 21, I see no problem in doing that. >> >> -- Kevin >> >> >> On 2/1/2023 9:06 AM, Philip Race wrote: >> >> In the JDK we've only sealed existing classes which provably could not >> have been extended by application classes, >> so I'm not sure about this .. >> >> also I think that might be the first change that absolutely means FX 21 >> can only be built with JDK 17 and later .. >> >> -phil >> >> On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: >> >> Yes, sorry, I made the email title in plural, but I meant what Michael >> said, Node would be sealed permitting only what is needed for JavaFx >> internally. >> >> >> -- Thiago >> >> >> Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? < >> michaelstrau2 at gmail.com> escreveu: >> >>> I don't think that's what Thiago is proposing. Only `Node` would be >>> sealed. >>> The following subclasses would be non-sealed: Parent, SubScene, >>> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >>> And then there are additional subclasses, which don't fit into this >>> idea since they are in other modules: SwingNode (in javafx.swing), >>> MediaView (in javafx.media), Printable (in javafx.web). >>> >>> >>> >>> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >>> wrote: >>> > >>> > I think this may be a bit unclear from this post, but you're proposing >>> I think to make `Node`, `Shape` and `Shape3D` sealed. For those unaware, >>> you're not allowed to extend these classes (despite being public). For >>> example Node says in its documentation: >>> > >>> > * An application should not extend the Node class directly. Doing >>> so may lead to >>> > * an UnsupportedOperationException being thrown. >>> > >>> > Currently this is enforced at runtime in NodeHelper. >>> > >>> > --John >>> > >>> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >>> > >>> > Hi, >>> > >>> > NodeHelper.java has this: >>> > >>> > throw new UnsupportedOperationException( >>> > "Applications should not extend the " >>> > + nodeType + " class directly."); >>> > >>> > >>> > I think it's replaceable with selead classes. Am I right? >>> > >>> > The benefit will be compile time error instead of runtime. >>> > >>> > >>> > -- Thiago. >>> > >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Wed Feb 1 23:01:37 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Feb 2023 23:01:37 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: <2YalxYadN7ierihdltqj0BzduaX0O3suZS-QalMC93E=.2f86aa92-72db-4470-b5d1-4954314ad65d@github.com> On Wed, 1 Feb 2023 15:11:57 GMT, Glavo wrote: > I have considered this, but I didn't make this change because I was worried that there would be less descriptive information when null was encountered. I think it's fine. The method is documented to throw and it happens immediately on entry. NPEs don't always have a message since they are straightforward. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From nlisker at openjdk.org Wed Feb 1 23:08:34 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Feb 2023 23:08:34 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <-qVG6eVzBeaqMRMZoIDI3dZh1lBd9fJx8gkuxivjSQY=.47dc740b-a871-4702-819a-491118c885c1@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> <-qVG6eVzBeaqMRMZoIDI3dZh1lBd9fJx8gkuxivjSQY=.47dc740b-a871-4702-819a-491118c885c1@github.com> Message-ID: On Wed, 1 Feb 2023 16:54:30 GMT, John Hendrikx wrote: >> modules/javafx.media/src/main/java/com/sun/media/jfxmedia/Media.java line 103: >> >>> 101: } >>> 102: } >>> 103: return returnValue; >> >> This method can be reduced to >> >> public List getTracks() { >> synchronized (tracks) { >> return tracks.isEmpty() ? null : List.copyOf(tracks); >> } >> } >> >> though I find it highly questionable that it returns `null` for an empty list instead of just an empty list. There are 2 use cases of this method and both would do better with just an empty list. > > Yeah, I noticed this as well right away, it is documented to do this though. The documentation however does seem to suggest it might be possible that there are three results: > > 1. Tracks haven't been scanned yet -> `null` > 2. Tracks have been scanned, but none where found -> empty list > 3. Tracks have been scanned and some were found -> list > > Whether case 2 can ever happen is unclear, but distinguishing it from the case where nothing has been scanned yet with `null` does not seem unreasonable. It's an internal class and no calling class makes this distinction. I don't think it's meant to function in the way you described. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From pedro.duquevieira at gmail.com Wed Feb 1 23:14:09 2023 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 1 Feb 2023 23:14:09 +0000 Subject: Style themes API In-Reply-To: References: Message-ID: > > 1) Ease of migration should be an important consideration, but there > are also other considerations. I'd argue that getting the feature > stacking and mental model right is more important, and giving themes a > way to individually select if the stylesheets are user-agent or user > stylesheets makes it hard to understand why my locally-set property > value is being ignored by JavaFX in one theme, but not in the other. 2) The scenario you describe occurs when an application sets the value > of styleable properties from code, but the values are overridden by an > author stylesheet. Yes, that might happen, and I think it's up to the > application developers to fix that. The reason why I think we should > only support `Application.userAgentStyleTheme` in the first version of > this new feature is quite simple: I'd rather have the feature actually > make it into JavaFX than be stuck in review because it's too large and > too complex of a change. User-agent style themes are pretty easy to > implement (most of the code is already in place), while author style > themes are not. We can add author style themes as a follow-up > enhancement. Author stylesheets are an inherent feature of JavaFX. It's already a feature that exists so I think developers shouldn't be surprised if author stylesheets override their styles set in code. But anyways, you've convinced me on making this just be a user agent stylesheet for now. Like you say, that way this feature doesn't get too large and we're able to ship it quicker. :-) I'll point you to this document, which describes the latest version of > this feature: > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 > What do you think about the interaction between the various parts of > the new API, especially in regards to the appearance of native > platform decorations? > I'm not convinced that it is a good idea to make either `StyleTheme` > or `Stage.appearance` more complicated by automatically inferring the > value of one from the other. The fact that a theme is either dark or light is strongly correlated to whether you as a developer want all window decorations to be light or dark. I'd say that very few use cases will want to have some windows to be light and others to be dark. As such, this API as it is, will force developers to set the window decorations to either light or dark every time they spawn a new Window (spawning a separate Window, a Dialog, etc). I'd say it would be a good idea to set the window decorations based on what is defined in the StyleTheme with the possibility to override them if you set it on the Window itself. Looking at the doc you created. Some comments: - I like the Preferences API - "Appearance" or "ThemeAppearance"? "Appearance" sounds like a rather generic term that could mean anything.. - perhaps rename the Stage appearance property to something like: "frameDecorations", e.g. "setFrameDecorations(Appearance)"? - " A future enhancement may refactor the built-in themes to make color definitions swappable". This is already possible. Modena has its color definitions given by css variables which can be easily overridden in CSS. That's also a strong part of how I currently switch JMetro to either dark or light version without having to duplicate every style definition. Side note: JMetro is composed of several stylesheets (more than 1) so it would be a nightmare or impossible to make JMetro be a user agent stylesheet with the current state of the JavaFX API (+1 for this new API :-) ). - Perhaps rename "Application.userAgentStylesheetXX" to "Application.styleThemeXX" and keep the semantics? If we make it be "userAgentStylesheetXX" it means we can no longer in a future version make StyleTheme have a property to define whether they are to be user agent stylesheets or author stylesheets. It gives less room for us to be able to change our minds in the future. - Perhaps instead of the section "Goals" being named "Goals" we could name it "Advantages of this API" or something along those lines and have it be the first topic. I think the first question people will ask is: "what's the advantage of this new feature?".. so I think it would be nice if it's the first topic so that we grab people's attention from the start. - instead of "Promote CSS user-agent themes from an implementation detail to a first-class concept.", perhaps something more clear? Something like: "Allow easier creation of themes that are composed of user agent stylesheets (like Modena and Caspian). These themes may be composed of more than 1 user agent stylesheet which isn't possible with the current javafx API". Also perhaps make reference to the fact that 90% (rough estimate) of themes out there are composed of author style sheets and it's difficult for them to be different, which can be problematic for users of those themes: styles set in code will be overridden, styles set in FXML, styles set in author stylesheets created by the developers if the specificity of those styles is lower than the themes styles.. On Wed, Feb 1, 2023 at 12:22 AM Michael Strau? wrote: > On Tue, Jan 31, 2023 at 6:14 PM Pedro Duque Vieira > wrote: > > Thinking of existing themes migrating to this StyleTheme API (90% are > implemented as author stylesheets), some visual glitches may start > appearing for users of those themes once they start using the migrated > versions (since they will go from being author stylesheets to user agent > stylesheets). > > So, 2 things to think about: > > 2.1 - How important is it that we think about this use case: existing > themes migrating to this new API. I'd say we should probably think about it > when designing this new API. > > 2.2 - The second thing then is, how problematic will it be for > programmers using these themes to have their apps start having visual > glitches because of these themes changing from author stylesheets to user > agent style sheets? > > Perhaps we simply don't bother with this last point and simply have it > be the price of innovation. And so programmers will have to adapt their > applications and remove any code that is overriding the styles defined in > the StyleThemes (which are likely causing these visual glitches when > migrating to Themes using this new StyleTheme API). The same for any styles > already defined in custom author stylesheets that are being used by the > application and that might be NOW overriding the styles of the theme. > > 1) Ease of migration should be an important consideration, but there > are also other considerations. I'd argue that getting the feature > stacking and mental model right is more important, and giving themes a > way to individually select if the stylesheets are user-agent or user > stylesheets makes it hard to understand why my locally-set property > value is being ignored by JavaFX in one theme, but not in the other. > > 2) The scenario you describe occurs when an application sets the value > of styleable properties from code, but the values are overridden by an > author stylesheet. Yes, that might happen, and I think it's up to the > application developers to fix that. The reason why I think we should > only support `Application.userAgentStyleTheme` in the first version of > this new feature is quite simple: I'd rather have the feature actually > make it into JavaFX than be stuck in review because it's too large and > too complex of a change. User-agent style themes are pretty easy to > implement (most of the code is already in place), while author style > themes are not. We can add author style themes as a follow-up > enhancement. > > > > > I don't think we should put having StyleTheme be just a collection of > stylesheets and nothing else as a requirement. I'd rather think of > StyleTheme as being the concept of a Theme and all the possible properties > and definitions of what a Theme is. This is one of the strengths of this > new feature you've proposed, i.e. > > having the concept of a Theme exist in JavaFX whereas in the past there > was no such concept and a "Theme" was just a collection of stylesheets. > Added through the getStylesheets() method or through the > setUserAgentStylesheet method. > > > > I'll just note that we don't just want the applications to be light or > dark depending on what is set in the Operating System. You'll also want the > ability to set whether the app is in dark or light mode on a per > application level irrespective of what is defined in the OS (this already > happens on many existing applications out there). So I think that > DarkModeAware interface would have to have a method like: > > ThemeMode getMode(); > > Where ThemeMode can either be LIGHT, DARK or OS_DEFINED (I've named it > ThemeMode just as an example). > > > > So I think we could do it in 2 ways: one way would be to do it as you > say (though DarkModeAware interface would need the getMode() method that I > suggested, I think) or add a method in the StyleTheme interface itself in a > future release: > > ThemeMode getMode(); > > That method would probably need to have a default implementation that > simply returns LIGHT because of retro compatibility. > > > > So, ThemeMode could be one of 3 possible values: LIGHT, DARK or > OS_DEFINED. Where OS_DEFINED means that the app will honor whatever is > defined at the OS level. > > JavaFX Window decorations would need to respect whatever is returned in > this getMode() method and change their decorations to either LIGHT or DARK > depending on its value. This would also remove the need for boilerplate > code that for every Window that is created sets it to be LIGHT or DARK > depending on whether the Theme is LIGHT or DARK. > > > > Of course, we can also simply support this from the get go and have this > method exist in StyleTheme from the start. > > I'll point you to this document, which describes the latest version of > this feature: > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 > What do you think about the interaction between the various parts of > the new API, especially in regards to the appearance of native > platform decorations? > I'm not convinced that it is a good idea to make either `StyleTheme` > or `Stage.appearance` more complicated by automatically inferring the > value of one from the other. > -- Pedro Duque Vieira - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Feb 1 23:38:57 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Feb 2023 23:38:57 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of [v2] In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? Glavo has updated the pull request incrementally with two additional commits since the last revision: - Update FileChooser - Update getTracks ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1012/files - new: https://git.openjdk.org/jfx/pull/1012/files/b7482f9a..33e22df6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1012&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1012&range=00-01 Stats: 33 lines in 2 files changed: 1 ins; 23 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1012.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1012/head:pull/1012 PR: https://git.openjdk.org/jfx/pull/1012 From nlisker at openjdk.org Wed Feb 1 23:45:37 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Feb 2023 23:45:37 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of [v2] In-Reply-To: References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: <11zOoc6-uXhS7LLhhALDcOwtHY7PgASeWtRy_tjCNE0=.c0a655b9-7e92-4710-99e0-2bfc7f6e7599@github.com> On Wed, 1 Feb 2023 23:38:57 GMT, Glavo wrote: >> `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. >> >> Because `List.of` can only store non-null elements, I have only replaced a few usage. >> >> Can someone open an Issue on JBS for me? > > Glavo has updated the pull request incrementally with two additional commits since the last revision: > > - Update FileChooser > - Update getTracks You can put the argument list of the constructors and methods in one line. Also the `IllegalArgumentException` and its message can be in the same line. After you add the empty lines after the `FileChooser` class declaration and the `ExtensionFilter` class declaration this can go in. ------------- PR: https://git.openjdk.org/jfx/pull/1012 From duke at openjdk.org Wed Feb 1 23:50:07 2023 From: duke at openjdk.org (Glavo) Date: Wed, 1 Feb 2023 23:50:07 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of [v3] In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? Glavo has updated the pull request incrementally with one additional commit since the last revision: reformat ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1012/files - new: https://git.openjdk.org/jfx/pull/1012/files/33e22df6..4442eb09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1012&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1012&range=01-02 Stats: 14 lines in 1 file changed: 2 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1012.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1012/head:pull/1012 PR: https://git.openjdk.org/jfx/pull/1012 From kevin.rushforth at oracle.com Wed Feb 1 23:58:54 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Feb 2023 15:58:54 -0800 Subject: [External] : Re: Some classes could be sealed In-Reply-To: References: <54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com> <95f8148a-1827-feb2-052e-cae29dc1964b@oracle.com> <20593394-0e70-dd72-c55e-b493716456b4@oracle.com> <92a4ad76-6b0e-3327-ad51-27ba5f030cad@gmail.com> Message-ID: <01b6882c-816f-a108-2c12-d6d9df5b33d6@oracle.com> > You can't extend these without tampering with internals. Pretty much, yes. Node is an abstract class that requires a concrete implementation to be useful. The set of subclasses that can be used in describing and rendering the scene graph is a finite and known set. The rendering of the scene graph is an implementation detail; each node in the scene graph has a corresponding peer (an NGNode subclass) that is needed to implement various node types (shapes, images, etc). So Node, as well as its abstract subclasses, like Shape, Shape3D, Camera, and LightBase, needs a known concrete subclass in order to do anything. Similarly, Material (which is not a Node) is abstract and has implementation that cannot be provided by an application class. By contrast, Parent can be usefully subclassed. It is a concrete class that is used as a container for other nodes, and has implementation of layout, traversal, bounds computation, etc. --- Kevin On 2/1/2023 2:48 PM, Nir Lisker wrote: > For Material and LightBase it's because they are just facades whose > implementation is in native code. You can't extend these without > tampering with internals. I think that Camera and Shape3D also > requires modifying internal stuff, though not at the native?level. > > On Thu, Feb 2, 2023 at 12:38 AM John Hendrikx > wrote: > > I'm curious to know why these classes are not allowed to be > subclassed directly, as that may be important in order to decide > whether these classes should really be sealed. > > --John > > On 01/02/2023 20:37, Kevin Rushforth wrote: >> I read the spec for sealed classes more carefully, and it turns >> out we can't make Node sealed. At least not without API changes >> to SwingNode and MediaView (and implementation changes to >> Printable in the javafx.web module). All of the classes listed in >> the "permits" clause must be in the same module, and SwingNode >> (javafx.swing) and MediaView (javafx.media) extend Node directly >> they would need to be "permitted" subtypes, but there is no way >> to specify that. We would also need to do something about the >> tests that extend Node and run in the unnamed module. So this >> doesn't seem feasible. >> >> We could still seal Shape, Shape3D, LightBase, and Material, >> since all permitted implementation are in the javafx.graphics >> module. It may or may not be worth doing that. >> >> -- Kevin >> >> >> On 2/1/2023 9:45 AM, Nir Lisker wrote: >>> I'll add that internal classes, mostly NG___ peers, can also >>> benefit from sealing. NGLightBase is an example. >>> >>> Material is another public class that can be sealed. >>> >>> On Wed, Feb 1, 2023 at 7:37 PM Kevin Rushforth >>> wrote: >>> >>> I agree that we should only seal existing classes that could >>> not have been extended by application classes. The ones I >>> listed in my previous email fit that bill, since an attempt >>> to subclass them will throw an exception when it is used in >>> a scene graph. Each documents that subclassing is disallowed. >>> >>> Btw, we've already started making use of pattern-matching >>> instanceof in the implementation anyway. It would be the >>> first API change that relies on a JDK 17 feature, but for >>> JavaFX 21, I see no problem in doing that. >>> >>> -- Kevin >>> >>> >>> On 2/1/2023 9:06 AM, Philip Race wrote: >>>> In the JDK we've only sealed? existing classes which >>>> provably could not have been extended by application classes, >>>> so I'm not sure about this .. >>>> >>>> also I think that might be the first change that absolutely >>>> means FX 21 can only be built with JDK 17 and later .. >>>> >>>> -phil >>>> >>>> On 2/1/23 8:59 AM, Thiago Milczarek Say?o wrote: >>>>> Yes, sorry, I made the email title in plural, but I meant >>>>> what Michael said, Node would be sealed permitting only >>>>> what is needed for JavaFx internally. >>>>> >>>>> >>>>> -- Thiago >>>>> >>>>> >>>>> Em qua., 1 de fev. de 2023 ?s 13:48, Michael Strau? >>>>> escreveu: >>>>> >>>>> I don't think that's what Thiago is proposing. Only >>>>> `Node` would be sealed. >>>>> The following subclasses would be non-sealed: Parent, >>>>> SubScene, >>>>> Camera, LightBase, Shape, Shape3D, Canvas, ImageView. >>>>> And then there are additional subclasses, which don't >>>>> fit into this >>>>> idea since they are in other modules: SwingNode (in >>>>> javafx.swing), >>>>> MediaView (in javafx.media), Printable (in javafx.web). >>>>> >>>>> >>>>> >>>>> On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx >>>>> wrote: >>>>> > >>>>> > I think this may be a bit unclear from this post, >>>>> but you're proposing I think to make `Node`, `Shape` >>>>> and `Shape3D` sealed.? For those unaware, you're not >>>>> allowed to extend these classes (despite being >>>>> public).? For example Node says in its documentation: >>>>> > >>>>> >? ? * An application should not extend the Node class >>>>> directly. Doing so may lead to >>>>> >? ? * an UnsupportedOperationException being thrown. >>>>> > >>>>> > Currently this is enforced at runtime in NodeHelper. >>>>> > >>>>> > --John >>>>> > >>>>> > On 01/02/2023 15:47, Thiago Milczarek Say?o wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > NodeHelper.java has this: >>>>> > >>>>> > throw new UnsupportedOperationException( >>>>> >? ? ? ? ?"Applications should not extend the " >>>>> >? ? ? ? ?+ nodeType + " class directly."); >>>>> > >>>>> > >>>>> > I think it's replaceable with selead classes. Am I >>>>> right? >>>>> > >>>>> > The benefit will be compile time error instead of >>>>> runtime. >>>>> > >>>>> > >>>>> > -- Thiago. >>>>> > >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Feb 2 00:25:36 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 00:25:36 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader In-Reply-To: References: Message-ID: <9LOLZMSxz_hFn4DVf9aGVlLCWp5fv1-Dfd8t9jgOsO0=.e48bd3de-fe79-4aa7-9116-8061d19a193c@github.com> On Tue, 31 Jan 2023 19:51:51 GMT, Alexander Zuev wrote: > > Can you provide an evaluation of the bug and a description of the fix? > > Done. Thanks. Can you enable GitHub actions for your repo? If you click on the "Checks" tab you 'll see a message from Skara with a pointer as to how to do that (the short answer is you go to "Actions" for your personal fork and click the big green button to enable it). Then you can either manually trigger a test run or push a commit (e.g., an empty commit or a merge from master) to trigger a run. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Thu Feb 2 00:49:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 00:49:30 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 21:56:45 GMT, Alexander Zuev wrote: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. My initial testing (on Windows) looks good. I have a general question in addition to the one inline comment. Since you added new i18n resource strings have you verified that it works for other locales to ensure no regression? (it should just speak the English string, since there are no translated strings yet) As for the implementation, I see you've added a (private) shadow property for the x and y axes and the series, as opposed to making them actual properties with only the getter being exposed publicly. As long as the fields are only ever set via the setter method, I think it should work fine the way you have it, but want to take a second look. modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java line 1403: > 1401: Object[] args = {seriesName, xAxisName, getCurrentX(), yAxisName, getCurrentY()}; > 1402: String retVal = mf.format(args); > 1403: System.out.println("result = " + retVal); You'll need to remove this debug print statement. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From nlisker at openjdk.org Thu Feb 2 01:09:35 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 2 Feb 2023 01:09:35 GMT Subject: RFR: 8301604: Replace Collections.unmodifiableList with List.of [v3] In-Reply-To: References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: <1GN8DjRYfzYhNkLvbXeQ9fM436hhln83W8pizo6w3Ps=.2e0a4665-5bff-420e-bf79-de052bb5579f@github.com> On Wed, 1 Feb 2023 23:50:07 GMT, Glavo wrote: >> `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. >> >> Because `List.of` can only store non-null elements, I have only replaced a few usage. >> >> Can someone open an Issue on JBS for me? > > Glavo has updated the pull request incrementally with one additional commit since the last revision: > > reformat Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/1012 From jhendrikx at openjdk.org Thu Feb 2 01:51:41 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 2 Feb 2023 01:51:41 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v9] In-Reply-To: References: Message-ID: <7zwjsVaijETmB5L2hh4mtWeCPu55n59wAwl8mRyefRM=.8a4594cb-e855-433d-8795-1a8c5442fb31@github.com> On Wed, 1 Feb 2023 10:15:36 GMT, Florian Kirmaier wrote: >> After thinking about this issue for some time, I've now got a solution. >> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. >> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8269907 > renamed testclass, based on code review, > readded acidentally removed import Adding to the above, I couldn't find in what cases `Node` might be referred from `NGNode`. Where is this happening? Further, `NGNode` only has a parent pointer, not a full parent/child hierarchy like `Parent` has. This would mean that if you track `NGNode` in `Parent#removed` a big part of the problem is alleviated as only a few parent `NGNode` will be unable to be GC'd, versus entire UI trees when you refer to `Node`. I also did some more digging, and the only thing that the dirty region computation for removed nodes really requires is a `RectBounds`. To do this it accesses only a couple of fields of `NGNode`, no heavy calculations are involved in this part and so this could be done right away -- it's also possible that `Node` may already have this information in some form (basically we need to know the last bounds of the node when it was rendered on screen -- saving a copy in the `doUpdatePeer` call may be sufficient). When the dirty area computation for the parent is performed, you'd only need to apply the transforms and clipping logic that the parent provides on this `RectBounds` -- no further fields of the removed `NGNode` would need to be accessed. ------------- PR: https://git.openjdk.org/jfx/pull/584 From arapte at openjdk.org Thu Feb 2 02:21:44 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 02:21:44 GMT Subject: [jfx20] RFR: 8300705: Update boot JDK to 19.0.2 [v2] In-Reply-To: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> References: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Message-ID: <_xvWUfxKbhayP7Ih6AatYAq6Z0UKd0-3rEqM1ZbMTHY=.68b1721b-a4da-4a31-b156-a7e053e71fb3@github.com> > Updating boot JDK to 19.0.2. Ambarish Rapte 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 eight additional commits since the last revision: - boot jdk 19.0.2b7 - 8299977: Update WebKit to 615.1 Co-authored-by: Jay Bhaskar Reviewed-by: kcr, sykora - 8237505: RadioMenuItem in ToggleGroup: deselected on accelerator Reviewed-by: angorya, aghaisas - Merge - 8275033: Drag and drop a file produces NullPointerException Cannot read field "dragboard" Reviewed-by: kcr, angorya - 8137244: Empty Tree/TableView with CONSTRAINED_RESIZE_POLICY is not properly resized Reviewed-by: aghaisas - Merge - 8299681: Change JavaFX release version to 21 Reviewed-by: arapte, angorya ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1019/files - new: https://git.openjdk.org/jfx/pull/1019/files/d3bd73c3..d3bd73c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1019&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1019&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1019.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1019/head:pull/1019 PR: https://git.openjdk.org/jfx/pull/1019 From arapte at openjdk.org Thu Feb 2 02:41:17 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 02:41:17 GMT Subject: [jfx20] RFR: 8300705: Update boot JDK to 19.0.2 [v3] In-Reply-To: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> References: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Message-ID: > Updating boot JDK to 19.0.2. Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: boot jdk 19.0.2b7 ------------- Changes: https://git.openjdk.org/jfx/pull/1019/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1019&range=02 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1019.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1019/head:pull/1019 PR: https://git.openjdk.org/jfx/pull/1019 From kcr at openjdk.org Thu Feb 2 03:11:36 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 03:11:36 GMT Subject: [jfx20] RFR: 8300705: Update boot JDK to 19.0.2 [v3] In-Reply-To: References: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Message-ID: On Thu, 2 Feb 2023 02:41:17 GMT, Ambarish Rapte wrote: >> Updating boot JDK to 19.0.2. > > Ambarish Rapte 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 one additional commit since the last revision: > > boot jdk 19.0.2b7 All good now. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/1019 From aghaisas at openjdk.org Thu Feb 2 03:52:34 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 2 Feb 2023 03:52:34 GMT Subject: [jfx20] Integrated: 8290863: Update the documentation of Virtualized controls to include the best practice of not using Nodes directly in the item list In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 12:32:53 GMT, Ajit Ghaisas wrote: > This PR adds a warning about inserting Nodes directly into the virtualized containers such as ListView, TreeView, TableView and TreeTableView. It also adds code snippets showing the recommended pattern of using a custom cell factory for each of the virtualized control. This pull request has now been integrated. Changeset: 39d87471 Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/39d874712205f96befe4af07a332f1e747f3ecc2 Stats: 260 lines in 5 files changed: 241 ins; 2 del; 17 mod 8290863: Update the documentation of Virtualized controls to include the best practice of not using Nodes directly in the item list Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/995 From kpk at openjdk.org Thu Feb 2 05:26:38 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 2 Feb 2023 05:26:38 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: Message-ID: <803S1AZhKTwQQl5UT7SUvtLJkUE-wgxYmA2mOy7zTUM=.df03c28f-9c43-4bb7-a440-f00657829954@github.com> On Tue, 17 Jan 2023 11:40:47 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 393: > >> 391: height = graphic.prefHeight(-1) + gap + textHeight; >> 392: } else { >> 393: height = Math.max(textHeight, graphic.prefHeight(-1)); > > The logic of this code seems to have changed more than just the fixing bug. Why are the `prefHeight` functions now called with `-1`? Normally these should respect the content bias of the node involved. > > Also, I notice that you check `graphic == null`, while the `isIgnoreGraphic` function checks quite a bit more: > > boolean isIgnoreGraphic() { > return (graphic == null || > !graphic.isManaged() || > getSkinnable().getContentDisplay() == ContentDisplay.TEXT_ONLY); > } > > Doing all those operations on `graphic` when for example the `ContentDisplay` is `TEXT_ONLY` seems unnecessary. Looking at the rest of the code, `graphicHeight` is only used in one branch in your if/elseif/elseif/else. > > I also wonder if a simple fix like this would have the same result: > > > - final double textHeight = Utils.computeTextHeight(font, cleanText, > + final double textHeight = isIgnoreText() ? 0.0 : Utils.computeTextHeight(font, cleanText, > labeled.isWrapText() ? textWidth : 0, > labeled.getLineSpacing(), text.getBoundsType()); @hjohn please take a look and review the changes made. ------------- PR: https://git.openjdk.org/jfx/pull/996 From kpk at openjdk.org Thu Feb 2 05:30:33 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 2 Feb 2023 05:30:33 GMT Subject: RFR: 8088998: LineChart: duplicate child added exception when remove & add a series In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 12:21:38 GMT, Karthik P K wrote: > While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run. > > Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted. > > This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix. I'll continue with this PR and fix the same issue seen in other charts. ------------- PR: https://git.openjdk.org/jfx/pull/1015 From arapte at openjdk.org Thu Feb 2 06:38:33 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 06:38:33 GMT Subject: [jfx17u] RFR: 8299272: Update copyright header for files modified in 2022 Message-ID: Update copyright year in files modified in year 2022. ------------- Commit messages: - copyright year 2022 Changes: https://git.openjdk.org/jfx17u/pull/105/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299272 Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx17u/pull/105.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/105/head:pull/105 PR: https://git.openjdk.org/jfx17u/pull/105 From arapte at openjdk.org Thu Feb 2 06:40:33 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 06:40:33 GMT Subject: [jfx11u] RFR: 8299272: Update copyright header for files modified in 2022 Message-ID: Update copyright year in files modified in year 2022. ------------- Commit messages: - copyright year 2022 Changes: https://git.openjdk.org/jfx11u/pull/126/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299272 Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jfx11u/pull/126.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/126/head:pull/126 PR: https://git.openjdk.org/jfx11u/pull/126 From arapte at openjdk.org Thu Feb 2 06:51:32 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 06:51:32 GMT Subject: [jfx11u] RFR: 8089986: Menu beeps when mnemonics is used Message-ID: Almost clean backport, with a difference in copyright year. Otherwise clean. ------------- Commit messages: - 8089986: Menu beeps when mnemonics is used Changes: https://git.openjdk.org/jfx11u/pull/127/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8089986 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx11u/pull/127.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/127/head:pull/127 PR: https://git.openjdk.org/jfx11u/pull/127 From arapte at openjdk.org Thu Feb 2 07:01:33 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 07:01:33 GMT Subject: RFR: 8251862: Wrong position of Popup windows at the intersection of 2 screens [v4] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 19:01:33 GMT, Kevin Rushforth wrote: >> On Windows platforms with more than one screen, a PopupWindow created for a Stage that straddles two windows will be drawn with an incorrect position and screen scale if the majority of the Stage is on one screen, and the popup is positioned on the other screen. In this case, the Stage is drawn using the screen scale of the screen that most of the window is on, while the popup is drawn using the scale of the screen that it is (typically entirely) on. >> >> The most common way this can happen is when you have two screens of a different scale with the secondary screen on the left or above the primary screen. If you position the Stage such that most of it is still on the primary screen (thus the Stage is drawn using the scale of the primary screen), with a menu, a control with a context menu, or a control with a Tooltip now on the secondary screen, the popup window for the menu or Tooltip will be drawn using the screen scale of the secondary window and thus won't be positioned or sized correctly relative to the menu bar, or control in the main window. >> >> The fix implemented by this PR is to always use the screen of the owner window, including the screen scales, when rendering a popup window. This matches the behavior of native Windows apps, such as Notepad. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2023 LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/971 From kpk at openjdk.org Thu Feb 2 07:48:44 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 2 Feb 2023 07:48:44 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 06:56:57 GMT, Karthik P K wrote: >> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. >> >> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. >> >> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight @andy-goryachev-oracle please take a look at this PR and let me know if you have any comments on this. ------------- PR: https://git.openjdk.org/jfx/pull/996 From fkirmaier at openjdk.org Thu Feb 2 08:14:07 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 2 Feb 2023 08:14:07 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v10] In-Reply-To: References: Message-ID: > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8269907 more changes based on codereview ------------- Changes: - all: https://git.openjdk.org/jfx/pull/584/files - new: https://git.openjdk.org/jfx/pull/584/files/dfb34701..e8e2f592 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=08-09 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/584.diff Fetch: git fetch https://git.openjdk.org/jfx pull/584/head:pull/584 PR: https://git.openjdk.org/jfx/pull/584 From aoqi at openjdk.org Thu Feb 2 08:24:17 2023 From: aoqi at openjdk.org (Ao Qi) Date: Thu, 2 Feb 2023 08:24:17 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 Message-ID: Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. ------------- Commit messages: - 8293214: Add support for Linux/LoongArch64 Changes: https://git.openjdk.org/jfx17u/pull/102/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=102&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293214 Stats: 26 lines in 4 files changed: 15 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx17u/pull/102.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/102/head:pull/102 PR: https://git.openjdk.org/jfx17u/pull/102 From kcr at openjdk.org Thu Feb 2 08:24:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 08:24:19 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 13:28:51 GMT, Ao Qi wrote: > Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. Backports to `jfx17u` require prior approval. You will need to seek such approval from one of the project leads before taking this PR out of Draft. If it is approved, the timing is such that it needs to wait for about two weeks. It could possibly be slated for JavaFX 17.0.7 (the April CPU release), since it is far too late to make any changes for 17.0.6. ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From aoqi at openjdk.org Thu Feb 2 08:24:20 2023 From: aoqi at openjdk.org (Ao Qi) Date: Thu, 2 Feb 2023 08:24:20 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: <8gqy-L2G6qOKnQwXI2wNEeYv0iCz3V757VKfXFcK4mE=.1b72ec66-08fd-4bbb-aacd-46c180bc1282@github.com> On Mon, 9 Jan 2023 13:41:49 GMT, Kevin Rushforth wrote: >> Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. > > Backports to `jfx17u` require prior approval. You will need to seek such approval from one of the project leads before taking this PR out of Draft. > > If it is approved, the timing is such that it needs to wait for about two weeks. It could possibly be slated for JavaFX 17.0.7 (the April CPU release), since it is far too late to make any changes for 17.0.6. Thanks a lot for the quick advice, @kevinrushforth. I will further learn how to do the backports to `jfx17u`. Also, this backport is not in a hurry. Let's wait for the release of `17.0.6`. I don't want to bother with the new releasing version:) ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From aoqi at openjdk.org Thu Feb 2 08:24:22 2023 From: aoqi at openjdk.org (Ao Qi) Date: Thu, 2 Feb 2023 08:24:22 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 13:28:51 GMT, Ao Qi wrote: > Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. RFC and RFR. Thanks. Should I take this PR out of Draft? ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From jvos at openjdk.org Thu Feb 2 08:24:23 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 2 Feb 2023 08:24:23 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 13:19:56 GMT, Ao Qi wrote: >> Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. > > RFC and RFR. Thanks. Should I take this PR out of Draft? @theaoqi Yes, if you take it out of draft, I'll review it. ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From michaelstrau2 at gmail.com Thu Feb 2 08:42:18 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 2 Feb 2023 09:42:18 +0100 Subject: Style themes API In-Reply-To: References: Message-ID: On Thu, Feb 2, 2023 at 12:14 AM Pedro Duque Vieira wrote: > The fact that a theme is either dark or light is strongly correlated to whether you as a developer want all window decorations to be light or dark. I'd say that very few use cases will want to have some windows to be light and others to be dark. > As such, this API as it is, will force developers to set the window decorations to either light or dark every time they spawn a new Window (spawning a separate Window, a Dialog, etc). I'd say it would be a good idea to set the window decorations based on what is defined in the StyleTheme with the possibility to override them if you set it on the Window itself. I've thought a bit about how we could have such a feature without introducing Stage appearance to the StyleTheme interface (I think the two concepts should remain separate). Here's the updated design document with a proposal: https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#changing-the-default-stage-appearance What do you think? I'm not entirely convinced that the added complexity is worth the benefit that this feature brings. > Looking at the doc you created. Some comments: > - I like the Preferences API > - "Appearance" or "ThemeAppearance"? "Appearance" sounds like a rather generic term that could mean anything.. > - perhaps rename the Stage appearance property to something like: "frameDecorations", e.g. "setFrameDecorations(Appearance)"? I like the term "appearance" precisely because it's rather generic. Apple also likes to call it like that, so there's some precedent for it. > - " A future enhancement may refactor the built-in themes to make color definitions swappable". This is already possible. Modena has its color definitions given by css variables which can be easily overridden in CSS. That's also a strong part of how I currently switch JMetro to either dark or light version without having to duplicate every style definition. Side note: JMetro is composed of several stylesheets (more than 1) so it would be a nightmare or impossible to make JMetro be a user agent stylesheet with the current state of the JavaFX API (+1 for this new API :-) ). > - Perhaps rename "Application.userAgentStylesheetXX" to "Application.styleThemeXX" and keep the semantics? If we make it be "userAgentStylesheetXX" it means we can no longer in a future version make StyleTheme have a property to define whether they are to be user agent stylesheets or author stylesheets. It gives less room for us to be able to change our minds in the future. If we have, at some point in the future, both a `Application.userAgentStyleTheme` and `Application.styleTheme` property, then users can decide whether they want the style theme to have user-agent semantics, or author semantics. Or do you want an option for style themes to decide for each indiviual stylesheet whether it should have user-agent or author semantics? > - Perhaps instead of the section "Goals" being named "Goals" we could name it "Advantages of this API" or something along those lines and have it be the first topic. I think the first question people will ask is: "what's the advantage of this new feature?".. so I think it would be nice if it's the first topic so that we grab people's attention from the start. > - instead of "Promote CSS user-agent themes from an implementation detail to a first-class concept.", perhaps something more clear? Something like: "Allow easier creation of themes that are composed of user agent stylesheets (like Modena and Caspian). These themes may be composed of more than 1 user agent stylesheet which isn't possible with the current javafx API". Also perhaps make reference to the fact that 90% (rough estimate) of themes out there are composed of author style sheets and it's difficult for them to be different, which can be problematic for users of those themes: styles set in code will be overridden, styles set in FXML, styles set in author stylesheets created by the developers if the specificity of those styles is lower than the themes styles.. I've roughly followed the JEP format with this enhancement proposal. Added a clarification like you suggested to the Goals section. From duke at openjdk.org Thu Feb 2 11:41:36 2023 From: duke at openjdk.org (Glavo) Date: Thu, 2 Feb 2023 11:41:36 GMT Subject: Integrated: 8301604: Replace Collections.unmodifiableList with List.of In-Reply-To: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> References: <1s2FStT4Fny7WXlKYezjVULne-n7h9uLJiEaFb9yi2I=.e5d658db-48ef-4c54-a840-be05825ea7c8@github.com> Message-ID: On Thu, 26 Jan 2023 05:30:56 GMT, Glavo wrote: > `List.of` is cleaner, and can slightly reduce the memory footprint for lists of one or two elements. > > Because `List.of` can only store non-null elements, I have only replaced a few usage. > > Can someone open an Issue on JBS for me? This pull request has now been integrated. Changeset: fa4884c3 Author: Glavo Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/fa4884c3c43c43da8dd555441ca5658898e807cb Stats: 61 lines in 3 files changed: 3 ins; 38 del; 20 mod 8301604: Replace Collections.unmodifiableList with List.of Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/1012 From ajit.ghaisas at oracle.com Thu Feb 2 11:43:52 2023 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 2 Feb 2023 11:43:52 +0000 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: <6699272C-3B63-4DDE-83DE-3D218B1B7C43@oracle.com> Vote: Yes Regards, Ajit > On 01-Feb-2023, at 7:15 PM, Kevin Rushforth wrote: > > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. > > Hima is a member of the JavaFX team at Oracle who has contributed 10 commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#hmeda > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > From ajit.ghaisas at oracle.com Thu Feb 2 11:43:53 2023 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 2 Feb 2023 11:43:53 +0000 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: <6699272C-3B63-4DDE-83DE-3D218B1B7C43@oracle.com> Vote: Yes Regards, Ajit > On 01-Feb-2023, at 7:15 PM, Kevin Rushforth wrote: > > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. > > Hima is a member of the JavaFX team at Oracle who has contributed 10 commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#hmeda > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > From ajit.ghaisas at oracle.com Thu Feb 2 11:44:08 2023 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 2 Feb 2023 11:44:08 +0000 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: Vote: Yes Regards, Ajit > On 01-Feb-2023, at 7:15 PM, Kevin Rushforth wrote: > > I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. > > Jay is a member of the JavaFX team at Oracle who has contributed 11 commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#jbhaskar > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Jay+Bhaskar%22&s=author-date&type=commits > https://github.com/openjdk/jfx/search?q=%22Jay+Bhaskar%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer From prasanta.sadhukhan at oracle.com Thu Feb 2 12:49:23 2023 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 2 Feb 2023 18:19:23 +0530 Subject: CFV: New OpenJFX Committer: Jay Bhaskar In-Reply-To: References: Message-ID: <34a00cd7-12bf-259f-cf1e-08ca504fc85d@oracle.com> Vote: yes Regards Prasanta On 01-Feb-23 7:15 PM, Kevin Rushforth wrote: > I hereby nominate Jay Bhaskar [1] to OpenJFX Committer. > > Jay is a member of the JavaFX team at Oracle who has contributed 11 > commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#jbhaskar > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Jay+Bhaskar%22&s=author-date&type=commits > https://github.com/openjdk/jfx/search?q=%22Jay+Bhaskar%22&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer From prasanta.sadhukhan at oracle.com Thu Feb 2 12:50:03 2023 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 2 Feb 2023 18:20:03 +0530 Subject: CFV: New OpenJFX Committer: Hima Bindu Meda In-Reply-To: References: Message-ID: Vote: yes Regards Prasanta On 01-Feb-23 7:15 PM, Kevin Rushforth wrote: > I hereby nominate Hima Bindu Meda [1] to OpenJFX Committer. > > Hima is a member of the JavaFX team at Oracle who has contributed 10 > commits [2] to OpenJFX. > > Votes are due by February 15, 2023 at 14:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#hmeda > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Hima+Bindu+Meda%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > From jvos at openjdk.org Thu Feb 2 12:59:38 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 2 Feb 2023 12:59:38 GMT Subject: [jfx20] RFR: 8300705: Update boot JDK to 19.0.2 [v3] In-Reply-To: References: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Message-ID: On Thu, 2 Feb 2023 02:41:17 GMT, Ambarish Rapte wrote: >> Updating boot JDK to 19.0.2. > > Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > boot jdk 19.0.2b7 Marked as reviewed by jvos (Reviewer). Looks good ------------- PR: https://git.openjdk.org/jfx/pull/1019 From jvos at openjdk.org Thu Feb 2 13:01:48 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 2 Feb 2023 13:01:48 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v46] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 23 Jan 2023 03:51:33 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with four additional commits since the last revision: > > - Fix JDK-8089923 > - Fix JDK-8089923 > - Fix JDK-8089923 > - Fix deiconify regression I'll re-review this week. ------------- PR: https://git.openjdk.org/jfx/pull/915 From arapte at openjdk.org Thu Feb 2 13:41:51 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Feb 2023 13:41:51 GMT Subject: [jfx20] Integrated: 8300705: Update boot JDK to 19.0.2 In-Reply-To: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> References: <-KLlGtodJXcs__tmQdu3w2wxm4bPm_4j4wH9FrHJqO8=.ac40d560-3d40-4098-80a3-e7792b05d3a2@github.com> Message-ID: On Wed, 1 Feb 2023 17:39:55 GMT, Ambarish Rapte wrote: > Updating boot JDK to 19.0.2. This pull request has now been integrated. Changeset: 8f2fac06 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/8f2fac06152d3332e169f5b5389ac2ba84d18bc2 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8300705: Update boot JDK to 19.0.2 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1019 From jhendrikx at openjdk.org Thu Feb 2 14:19:13 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 2 Feb 2023 14:19:13 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 06:56:57 GMT, Karthik P K wrote: >> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. >> >> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. >> >> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight Marked as reviewed by jhendrikx (Committer). ------------- PR: https://git.openjdk.org/jfx/pull/996 From kevin.rushforth at oracle.com Thu Feb 2 16:10:43 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Feb 2023 08:10:43 -0800 Subject: JavaFX 20 is in Rampdown Phase Two (RDP2) Message-ID: <7b39ceb2-4209-e3c0-f5f3-bb41db28f587@oracle.com> To: JavaFX Developers As a reminder, JavaFX 20 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bugs, and test or doc bugs of any priority, can be fixed during RDP2. Explicit approval is needed for bug fixes (except for doc and test fixes), and all enhancements to go in to the jfx20 branch [2]. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. 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 JDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 20 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx20-fix-request", "openjfx20-fix-yes", "openjfx20-fix-no" and "openjfx20-fix-nmi", "openjfx20-enhancement-request", "openjfx20-enhancement-yes", "openjfx20-enhancement-no" and "openjfx20-enhancement-nmi" as corresponding labels. Note that if a fix is approved to integrate into jfx20 (with the appropriate approval label added by a lead), then the PR should be targeted to the jfx20 branch. There is no need to also create a separate PR to integrate it into master -- we will continue to periodically sync jfx20 --> master for the duration of the JavaFX 20 release. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in JavaFX 20. We need to be extremely careful about including anything that introduces risk. 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 21 as of today). This is usually what we want. A PR should be targeted to `jfx20` if, and only if, it is intended for JavaFX 20 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 `jfx20`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 21. Reviewers also need to be extra careful when reviewing PRs targeted to jfx20 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. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2022-November/036404.html [2] https://github.com/openjdk/jfx/tree/jfx20 [3] http://openjdk.java.net/jeps/3 From kcr at openjdk.org Thu Feb 2 16:12:36 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 16:12:36 GMT Subject: RFR: Merge jfx20 Message-ID: Merge `jfx20` into `master`. ------------- Commit messages: - Merge jfx20 - 8300705: Update boot JDK to 19.0.2 - 8290863: Update the documentation of Virtualized controls to include the best practice of not using Nodes directly in the item list - 8300013: Node.focusWithin doesn't account for nested focused nodes The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jfx&pr=1020&range=00.0 - jfx20: https://webrevs.openjdk.org/?repo=jfx&pr=1020&range=00.1 Changes: https://git.openjdk.org/jfx/pull/1020/files Stats: 360 lines in 9 files changed: 314 ins; 2 del; 44 mod Patch: https://git.openjdk.org/jfx/pull/1020.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1020/head:pull/1020 PR: https://git.openjdk.org/jfx/pull/1020 From kcr at openjdk.org Thu Feb 2 16:19:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 16:19:54 GMT Subject: RFR: Merge jfx20 [v2] In-Reply-To: References: Message-ID: > Merge `jfx20` into `master`. 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 10 additional commits since the last revision: - Merge jfx20 - 8251862: Wrong position of Popup windows at the intersection of 2 screens Reviewed-by: aghaisas, arapte - 8301604: Replace Collections.unmodifiableList with List.of Reviewed-by: nlisker - 8299977: Update WebKit to 615.1 Co-authored-by: Jay Bhaskar Reviewed-by: kcr, sykora - 8237505: RadioMenuItem in ToggleGroup: deselected on accelerator Reviewed-by: angorya, aghaisas - Merge - 8275033: Drag and drop a file produces NullPointerException Cannot read field "dragboard" Reviewed-by: kcr, angorya - 8137244: Empty Tree/TableView with CONSTRAINED_RESIZE_POLICY is not properly resized Reviewed-by: aghaisas - Merge - 8299681: Change JavaFX release version to 21 Reviewed-by: arapte, angorya ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1020/files - new: https://git.openjdk.org/jfx/pull/1020/files/01fcdfe6..01fcdfe6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1020&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1020&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1020.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1020/head:pull/1020 PR: https://git.openjdk.org/jfx/pull/1020 From kcr at openjdk.org Thu Feb 2 16:19:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 16:19:56 GMT Subject: Integrated: Merge jfx20 In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 16:07:26 GMT, Kevin Rushforth wrote: > Merge `jfx20` into `master`. This pull request has now been integrated. Changeset: e1f7d0c4 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e1f7d0c42be3839df7679ae45d74907ef33edfbe Stats: 360 lines in 9 files changed: 314 ins; 2 del; 44 mod Merge ------------- PR: https://git.openjdk.org/jfx/pull/1020 From lkostyra at openjdk.org Thu Feb 2 16:44:11 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 2 Feb 2023 16:44:11 GMT Subject: RFR: 8290092: Temporary files are kept when call Clipboard.getSystemClipboard().getImage() [v2] In-Reply-To: References: Message-ID: > Windows implementation of GlassClipboard.cpp uses IStorage interface in `PopImage()` to allocate a temporary file, which is then used to capture Image data from system clipboard and move it to JVM side. In order for temporary file to be removed automatically on `IStorage::Release()`, `StgCreateDocfile` API requires passing STGM_DELETEONRELEASE flag - otherwise the file will be left behind when IStorage is released. Contents of temporary file are immediately copied to a JNI Byte Array after acquiring them from clibpoard, so it is safe to provide this flag and remove the file after `PopImage()` is done. > > Creating a unit test for this case would a bit difficult, as IStorage and its file are created with random temporary name each time, which we cannot easily access. On the other hand, just scouting the temp directory for any leftover .TMP files might prove false results, as other apps or even JFX itself might use IStorage temporary files for some other purposes than managing clipboard images. As such, because this is a simple API change, I did not make a test for this. > > Tested this change on Windows 10 and it doesn't break any existing tests. Calling `Clipboard.getSystemClipboard().getImage()` with an image stored inside the system clipboard now leaves no leftover files. Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: - ClipboardExtImageTest: Add missing copyright notice - Add manual test to check for leftover Clipboard files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/994/files - new: https://git.openjdk.org/jfx/pull/994/files/36a4b483..139b1c4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=994&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=994&range=00-01 Stats: 209 lines in 4 files changed: 208 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/994.diff Fetch: git fetch https://git.openjdk.org/jfx pull/994/head:pull/994 PR: https://git.openjdk.org/jfx/pull/994 From lkostyra at openjdk.org Thu Feb 2 16:45:39 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 2 Feb 2023 16:45:39 GMT Subject: RFR: 8290092: Temporary files are kept when call Clipboard.getSystemClipboard().getImage() In-Reply-To: References: Message-ID: <8831xXyKx0WgOHEPw1HFfXo7Amha1HvsQ9TPogKFKic=.165839dc-4c61-4af1-aee4-0f007c5f5eff@github.com> On Thu, 12 Jan 2023 11:11:23 GMT, Lukasz Kostyra wrote: > Windows implementation of GlassClipboard.cpp uses IStorage interface in `PopImage()` to allocate a temporary file, which is then used to capture Image data from system clipboard and move it to JVM side. In order for temporary file to be removed automatically on `IStorage::Release()`, `StgCreateDocfile` API requires passing STGM_DELETEONRELEASE flag - otherwise the file will be left behind when IStorage is released. Contents of temporary file are immediately copied to a JNI Byte Array after acquiring them from clibpoard, so it is safe to provide this flag and remove the file after `PopImage()` is done. > > Creating a unit test for this case would a bit difficult, as IStorage and its file are created with random temporary name each time, which we cannot easily access. On the other hand, just scouting the temp directory for any leftover .TMP files might prove false results, as other apps or even JFX itself might use IStorage temporary files for some other purposes than managing clipboard images. As such, because this is a simple API change, I did not make a test for this. > > Tested this change on Windows 10 and it doesn't break any existing tests. Calling `Clipboard.getSystemClipboard().getImage()` with an image stored inside the system clipboard now leaves no leftover files. Apologies this took so long, has been dealing with some health issues over the past week. I tried making an automatic test in system tests, however the issue only happens with image copied to system clipboard from an out-of-app source (ex. a web browser). Figured it would be easier to make the test manual and add it to the collection this way. ------------- PR: https://git.openjdk.org/jfx/pull/994 From angorya at openjdk.org Thu Feb 2 16:58:36 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Feb 2023 16:58:36 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 06:56:57 GMT, Karthik P K wrote: >> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. >> >> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. >> >> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 402: > 400: } > 401: > 402: return height + padding; My only comment is possibly reorganize the logic to avoid unnecessary computation. For example, there is no need to compute text width (line 329) if isIgnoreText() is true; Similarly, no need to compute graphicWidth on line 333 if isIgnoreGraphic() is true. (basically, same comment as @hjohn has made earlier) What do you think, @karthikpandelu ? ------------- PR: https://git.openjdk.org/jfx/pull/996 From angorya at openjdk.org Thu Feb 2 17:02:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Feb 2023 17:02:48 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 21:56:45 GMT, Alexander Zuev wrote: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/resources/controls.properties line 149: > 147: > 148: ### Charts ### > 149: XYChart.series.accessibleText={0} {1} is {2} {3} is {4} Do we provide a hint to the translators on how these strings need to be translated, like giving an example of rendered text? I am sure they will have fun translating "A B is C D is E" ------------- PR: https://git.openjdk.org/jfx/pull/1016 From john.hendrikx at gmail.com Thu Feb 2 17:17:58 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 2 Feb 2023 18:17:58 +0100 Subject: Performance considerations of syncing FX Nodes with NG Nodes Message-ID: I have a few questions that maybe some Prism/SceneGraph experts could help me with. 1) Are there any performance tests related to syncing the NGNode peers? Specifically, I'm interested if there are tests that compare the performance of "fresh" FX graphs that have never been displayed before, versus ones that have their peers already created. 2) Does prism code ever refer back to FX Nodes?? I've noticed that NGGroup imports javafx.scene.Node for one of its method signatures, but that seems to be a mistake; it can easily be changed to not require javafx.scene.Node.? Aside from several enums, constants and data classes (like Color) being re-used from the javafx side, it seems the NG Prism nodes are well encapsulated and that references are one way only (FX Nodes refer to NG Nodes via `peer`, but never the other way around). 3) How common is it to re-use FX Nodes that are no longer part of an active scene?? I've found myself that it is unwise to detach/recreate children in high performance controls that reuse cells -- it's often better to just hide cells that are not currently needed instead of removing them from the children list. 4) Are there any (major) performance implications to setting the NG peer to `null` when FX nodes are not part of an active sync cycle (ie, they have no Scene, or the Scene is not currently visible)? My observations on the sync cycle (syncPeer/doUpdatePeer) is that it is highly optimized, and tries to avoid new allocations as much as possible.? However, this seems to come at a price: it leaks memory when not part of a sync cycle. Given a FX Node graph, that has been displayed at least once, a mirrored graph is created consisting of NGNodes. When such a FX Node graph is no longer displayed, any changes to it are no longer synced to the mirror. This means that when I detach a small portion of the FX Node graph (let's say a single Node), and keep a reference to only that Node, that the FX graph can be GC'd. The corresponding NG Node graph however (which still hasn't been updated) can't be GC'd. The single detached FX Node has a peer, and this peer has a parent (and children), keeping not only the detached Node's peer in memory, but also all the other peers in the mirrored graph. Notifying the NG mirrored graph of changes is not easy, as it must be done as part of the sync (locking is involved). Even a detached FX Node can't assume its peer can be modified without locking as it may still be used in an active rendering pass. This leads me to believe that to move to a situation where peers are not being leaked would involve clearing peers as soon as FX nodes becomes detached from the sync cycle. This has no doubt has performance implications, as peers would need to be recreated if nodes are re-used (see Q3).? However, not all data that is part of the peers is a problem, and code that simply clears its peer when detached could be optimized again to be more peformant (optimizing from a correctly working situation, instead of fixing problems working from an optimized situation that has memory leaks). One way to optimize this may be to split the data that is tracked by peers in parts that are just direct copies of FX Node data, and parts that refer to parent/children.? The data that is just copies could be kept ("peerData") while the peer itself is nulled.? When the peer requires recreation, it is constructed as "new NGNode(peerData)".? Because the parent/child linkages are not part of `peerData`, it is no longer possible for large NG node trees to be kept in memory.? Recreation of NGNode would still require work, but these NGNodes are much smaller. --John From kcr at openjdk.org Thu Feb 2 17:20:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 17:20:50 GMT Subject: [jfx17u] RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON In-Reply-To: References: Message-ID: <1ZtE2eMoqLsKzLVQyqIpRTVTocu5VNUPLYo2CwG-ZcU=.767291a7-3972-4157-a934-2f0ad01d3010@github.com> On Mon, 9 Jan 2023 13:29:27 GMT, Ao Qi wrote: > Clean backport. Verified on (after #102): > - Linux/LoongArch64 (`USE_SYSTEM_MALLOC` is `on`, the platform triggering this problem) > - Linux/x64 (`USE_SYSTEM_MALLOC` is `off`) > - Linux/aarch64 (`USE_SYSTEM_MALLOC` is `off`) Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx17u/pull/103 From kcr at openjdk.org Thu Feb 2 17:21:57 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 17:21:57 GMT Subject: [jfx17u] RFR: 8299272: Update copyright header for files modified in 2022 In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 06:32:23 GMT, Ambarish Rapte wrote: > Update copyright year in files modified in year 2022. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx17u/pull/105 From kizune at openjdk.org Thu Feb 2 17:26:32 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 17:26:32 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Removed debug output. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1016/files - new: https://git.openjdk.org/jfx/pull/1016/files/1741c1a2..4dbdb2f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1016.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1016/head:pull/1016 PR: https://git.openjdk.org/jfx/pull/1016 From kizune at openjdk.org Thu Feb 2 17:30:46 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 17:30:46 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 00:46:31 GMT, Kevin Rushforth wrote: > Since you added new i18n resource strings have you verified that it works for other locales to ensure no regression? I did - tested with Japanese VoiceOver on Mac, it correctly constructs the string. > You'll need to remove this debug print statement. Done. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kizune at openjdk.org Thu Feb 2 17:30:49 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 17:30:49 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 17:00:04 GMT, Andy Goryachev wrote: > Do we provide a hint to the translators on how these strings need to be translated, like giving an example of rendered text? And that is why i did not do any "Google translate" translation in this PR - i will raise a new bug to translate the new strings where i will describe their meaning and hints on how to translate. Because even if that will be me who is doing the translation i would like to give a reviewer more information on what and how i translate it. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From thiago.sayao at gmail.com Thu Feb 2 17:25:51 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 2 Feb 2023 14:25:51 -0300 Subject: Toolkit decorations experiment In-Reply-To: References: Message-ID: Hi, This is the current status of the experiment: https://www.youtube.com/watch?v=EJbDVlAp-gA Not looking as I intend yet. To check it out (move/resize currently Linux only): 1) clone https://github.com/tsayao/jfx/tree/toolkit_decoration 2) build 3) java @build/run.args tests/manual/controls/SceneDecorationTest.java To move/resize the window, it uses native API, sketched here: https://github.com/openjdk/jfx/pull/1013 -- Thiago Em ter., 31 de jan. de 2023 ?s 11:15, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > I'm doing some experiments with toolkit decorations (instead of platform > decorations). > > The goal is to allow for modern-looking apps, with "hamburger buttons" or > tabs (like firefox or chrome) on the decoration space. > > It is coming into shape (nowhere near finished). It's CSS styleable. > > Source: > https://github.com/tsayao/jfx/tree/toolkit_decoration > To run: > java @build/run.args tests/manual/controls/SceneDecorationTest.java > > It would depend on a window move + resize API sketched here: > https://github.com/openjdk/jfx/pull/1013 > > -- Thiago > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Feb 2 17:31:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 17:31:44 GMT Subject: [jfx11u] RFR: 8089986: Menu beeps when mnemonics is used In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 06:44:01 GMT, Ambarish Rapte wrote: > Almost clean backport, with a difference in copyright year. Otherwise clean. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx11u/pull/127 From kcr at openjdk.org Thu Feb 2 17:33:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 17:33:44 GMT Subject: [jfx11u] RFR: 8299272: Update copyright header for files modified in 2022 In-Reply-To: References: Message-ID: <9GIqsic6FF8rwpo7qNi6hBgSCHB-dNJ0W3ftPfRL1Zg=.2ae48150-5bfc-4794-95b2-1e4d8c1e2742@github.com> On Thu, 2 Feb 2023 06:32:58 GMT, Ambarish Rapte wrote: > Update copyright year in files modified in year 2022. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx11u/pull/126 From angorya at openjdk.org Thu Feb 2 17:44:34 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Feb 2023 17:44:34 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 17:28:22 GMT, Alexander Zuev wrote: >> modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/resources/controls.properties line 149: >> >>> 147: >>> 148: ### Charts ### >>> 149: XYChart.series.accessibleText={0} {1} is {2} {3} is {4} >> >> Do we provide a hint to the translators on how these strings need to be translated, like giving an example of rendered text? >> I am sure they will have fun translating "A B is C D is E" > >> Do we provide a hint to the translators on how these strings need to be translated, like giving an example of rendered text? > > And that is why i did not do any "Google translate" translation in this PR - i will raise a new bug to translate the new strings where i will describe their meaning and hints on how to translate. Because even if that will be me who is doing the translation i would like to give a reviewer more information on what and how i translate it. one way to do it is to describe the expected result in the comment immediately preceding the string. For example: # "the current execution is complete" Class.runText=The run is run. Also, for testing purposes, we could consider pseudolocalization https://en.wikipedia.org/wiki/Pseudolocalization Better discuss this with Naoto Sato. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Thu Feb 2 18:11:42 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 18:11:42 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 17:41:28 GMT, Andy Goryachev wrote: >>> Do we provide a hint to the translators on how these strings need to be translated, like giving an example of rendered text? >> >> And that is why i did not do any "Google translate" translation in this PR - i will raise a new bug to translate the new strings where i will describe their meaning and hints on how to translate. Because even if that will be me who is doing the translation i would like to give a reviewer more information on what and how i translate it. > > one way to do it is to describe the expected result in the comment immediately preceding the string. For example: > > > # "the current execution is complete" > Class.runText=The run is run. > > Also, for testing purposes, we could consider pseudolocalization > https://en.wikipedia.org/wiki/Pseudolocalization > > Better discuss this with Naoto Sato. Sorry for accidentally editing your comment. I think I restored it correctly. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Thu Feb 2 18:11:43 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Feb 2023 18:11:43 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 18:05:10 GMT, Kevin Rushforth wrote: >> one way to do it is to describe the expected result in the comment immediately preceding the string. For example: >> >> >> # "the current execution is complete" >> Class.runText=The run is run. >> >> Also, for testing purposes, we could consider pseudolocalization >> https://en.wikipedia.org/wiki/Pseudolocalization >> >> Better discuss this with Naoto Sato. > > Sorry for accidentally editing your comment. I think I restored it correctly. > one way to do it is to describe the expected result in the comment immediately preceding the string. > ... > > Also, for testing purposes, we could consider pseudolocalization These are good suggestions that should be captured in the follow-up issue that Alex said he will file. Localization and testing is out of scope for this PR. Alex did the minimum needed to correct the fact that the string wasn't internationalized at all, which makes sense only because he had to modify the string as part of this PR (even then, I would have been OK with no i18n changes in this PR, leaving them for a separate issue as well). > Better discuss this with Naoto Sato. Good idea. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From angorya at openjdk.org Thu Feb 2 18:11:43 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Feb 2023 18:11:43 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 18:06:51 GMT, Kevin Rushforth wrote: >> Sorry for accidentally editing your comment. I think I restored it correctly. > >> one way to do it is to describe the expected result in the comment immediately preceding the string. >> ... >> >> Also, for testing purposes, we could consider pseudolocalization > > These are good suggestions that should be captured in the follow-up issue that Alex said he will file. > > Localization and testing is out of scope for this PR. Alex did the minimum needed to correct the fact that the string wasn't internationalized at all, which makes sense only because he had to modify the string as part of this PR (even then, I would have been OK with no i18n changes in this PR, leaving them for a separate issue as well). > >> Better discuss this with Naoto Sato. > > Good idea. Definitely out of scope for this PR, I just wanted to mention this. @azuev-java please link the follow up JBS ticket for localization. Thank you! ------------- PR: https://git.openjdk.org/jfx/pull/1016 From angorya at openjdk.org Thu Feb 2 18:16:41 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Feb 2023 18:16:41 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 18:09:23 GMT, Andy Goryachev wrote: >>> one way to do it is to describe the expected result in the comment immediately preceding the string. >>> ... >>> >>> Also, for testing purposes, we could consider pseudolocalization >> >> These are good suggestions that should be captured in the follow-up issue that Alex said he will file. >> >> Localization and testing is out of scope for this PR. Alex did the minimum needed to correct the fact that the string wasn't internationalized at all, which makes sense only because he had to modify the string as part of this PR (even then, I would have been OK with no i18n changes in this PR, leaving them for a separate issue as well). >> >>> Better discuss this with Naoto Sato. >> >> Good idea. > > Definitely out of scope for this PR, I just wanted to mention this. > @azuev-java please link the follow up JBS ticket for localization. > Thank you! Still, I would recommend adding a comment (since now is the time when we know all the context, and in the future we might forget or lose the context), may be something like # {seriesName} {xAxisName} is {currentX} {yAxisName} is {currentY} XYChart.series.accessibleText={0} {1} is {2} {3} is {4} ------------- PR: https://git.openjdk.org/jfx/pull/1016 From michaelstrau2 at gmail.com Thu Feb 2 18:56:42 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 2 Feb 2023 19:56:42 +0100 Subject: Toolkit decorations experiment In-Reply-To: <758B484D-8530-403D-919A-2395AD38C35F@gmail.com> References: <758B484D-8530-403D-919A-2395AD38C35F@gmail.com> Message-ID: I have experimented with blurred window backgrounds as well as blur-behind materials within the JavaFX scene graph. Here's a screenshot of a JavaFX application using the effect that you probably want: https://user-images.githubusercontent.com/43553916/216404144-da1cb463-c650-4fc3-ae05-e2b21385d66b.png I've implemented this effect for the Windows toolkit using DirectComposition. Other platforms need their own implementations. Blur-behind materials within JavaFX scene graph can be implemented in a platform-independent way. My solution would extend the effect infrastructure by adding a `Node.backdropEffect` property, which complements the existing `Node.effect` property. `Node.backdropEffect` works similiarly to CSS's `backdrop-filter` (see https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-filter). This is how you would use the backdrop effect: var rect = new Rectangle(); rect.setBackdropEffect(new GaussianBlur()); // looks like a colorless sheet of glass rect.setFill(Color.TRANSPARENT); // looks like a red sheet of glass rect.setFill(Color.web("red", 0.5)); Maybe that could be a useful feature. On Tue, Jan 31, 2023 at 4:13 PM Dirk Lemmermann wrote: > > Since you are venturing into this space ?. would love to be able to create blurred backgrounds in windows. Apple has some apps where the sidebar is semi-transparent with a strong blur effect. > From mstrauss at openjdk.org Thu Feb 2 19:54:33 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Feb 2023 19:54:33 GMT Subject: RFR: 8301302: Platform preferences API [v3] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > **Note:** please also read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) to learn about how the platform preferences API interacts with the proposed `StyleTheme` and `Stage.appearance` features. > > Platform preferences are the preferred UI settings of the operating system. For example, on Windows this includes the color values identified by the `Windows.UI.ViewManagement.UIColorType` enumeration; on macOS this includes the system color values of the `NSColor` class. > > Exposing these dynamic values to JavaFX applications allows developers to create themes that can integrate seamlessly with the color scheme of the operating system. > > Platform preferences are exposed as an `ObservableMap` of platform-specific key-value pairs, which means that the preferences available on Windows are different from macOS or Linux. JavaFX provides a small, curated list of preferences that are available on most platforms, and are therefore exposed with a platform-independent API: > > > public interface Preferences extends ObservableMap { > // Platform-independent API > ReadOnlyObjectProperty appearanceProperty(); > ReadOnlyObjectProperty backgroundColorProperty(); > ReadOnlyObjectProperty foregroundColorProperty(); > ReadOnlyObjectProperty accentColorProperty(); > > // Convenience methods to retrieve platform-specific values from the map > Optional getInteger(String key); > Optional getDouble(String key); > Optional getString(String key); > Optional getBoolean(String key); > Optional getColor(String key); > } > > > The platform appearance is defined by the new `javafx.stage.Appearance` enumeration: > > > public enum Appearance { > LIGHT, > DARK > } > > > An instance of the `Preferences` interface can be retrieved by calling `Platform.getPreferences()`. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into feature/platform-preferences - Use Optional for convenience methods in Preferences - refactored PlatformPreferencesImpl - javadoc - Added appearance and convenience platform properties - Removed StyleTheme implementation - update javadoc - update javadoc - Rename Application.styleTheme to userAgentStyleTheme - Changed GTK preference keys - ... and 21 more: https://git.openjdk.org/jfx/compare/e1f7d0c4...3728cdf0 ------------- Changes: https://git.openjdk.org/jfx/pull/1014/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=02 Stats: 2412 lines in 28 files changed: 2312 ins; 58 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From kizune at openjdk.org Thu Feb 2 21:18:04 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 21:18:04 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v3] In-Reply-To: References: Message-ID: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Added commentary explaining fields ised in parametrized string patterns ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1016/files - new: https://git.openjdk.org/jfx/pull/1016/files/4dbdb2f8..4f28dc04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1016.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1016/head:pull/1016 PR: https://git.openjdk.org/jfx/pull/1016 From kizune at openjdk.org Thu Feb 2 21:18:04 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 21:18:04 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v3] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 18:14:08 GMT, Andy Goryachev wrote: > Still, I would recommend adding a comment (since now is the time when we know all the context, and in the future we might forget or lose the context), may be something like Good idea, let me do it for both strings with parameters ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kizune at openjdk.org Thu Feb 2 21:23:14 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 21:23:14 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v4] In-Reply-To: References: Message-ID: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Trigger test jobs ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1016/files - new: https://git.openjdk.org/jfx/pull/1016/files/4f28dc04..ce66bfbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1016.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1016/head:pull/1016 PR: https://git.openjdk.org/jfx/pull/1016 From pedro.duquevieira at gmail.com Thu Feb 2 21:39:27 2023 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 2 Feb 2023 21:39:27 +0000 Subject: Style themes API In-Reply-To: References: Message-ID: (I made a mistake and only replied to you, resending this email to the mailing list and you) > I've thought a bit about how we could have such a feature without > introducing Stage appearance to the StyleTheme interface (I think the > two concepts should remain separate). > Here's the updated design document with a proposal: > > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#changing-the-default-stage-appearance > What do you think? I'm not entirely convinced that the added > complexity is worth the benefit that this feature brings. Thanks for proposing a new API. I really still think "appearance" should be part of the StyleTheme and I find that API, in the proposal, to be somewhat too complex. :-) I think at the base of our disagreement is that we have 2 distinct opinions of what a StyleTheme is. I see it as the concept of a theme and so anything that defines a theme should go in there (my opinion). Correct me if I'm wrong but you view StyleTheme as a collection of Stylesheets and nothing else. But then what's the advantage of it being just a collection of Stylesheets, why should we have that requirement, what do we gain with it? And why not call it StylesheetCollection instead (or something like that)? Or perhaps we could do it without introducing a new interface since it's just a collection of Stylesheet objects. I still think we should have the StyleTheme interface and my main points to having appearance be in StyleTheme is that: 1 - A theme being either dark or light is part of what a theme is. 2 - 99% of use cases are going to want to have all Windows (Dialogs, Windows, etc) to have either a light or dark appearance and I think we should make that easy to do, whereas with this API we make it more difficult since we force the developer to set the appearance on every Window he creates (plus the possibility of setting one of the windows to the wrong appearance). BTW, I'm not saying we can't have an appearance property in the Window (I think we should have it) but I'm also saying we should have appearance be in StyleTheme. I believe that a good API makes the more common use cases easier to do (and code) and so we should make it easy for developers to switch all Windows to either dark or light appearance. I like the term "appearance" precisely because it's rather generic. > Apple also likes to call it like that, so there's some precedent for > it. Ok that makes sense. If there's a precedent of Apple calling it appearance then we can adopt that! > If we have, at some point in the future, both a > `Application.userAgentStyleTheme` and `Application.styleTheme` > property, then users can decide whether they want the style theme to > have user-agent semantics, or author semantics. > Or do you want an option for style themes to decide for each indiviual > stylesheet whether it should have user-agent or author semantics? I would prefer an option in StyleTheme that says whether it's a user agent stylesheet or author stylesheet.. but my main point is, if we don't name it userAgentStylesheet we can, in the future, either do as you say or do as I say. It'll leave room for us to change our mind. I've roughly followed the JEP format with this enhancement proposal. > Added a clarification like you suggested to the Goals section. Sounds good! Thanks again, On Thu, Feb 2, 2023 at 8:42 AM Michael Strau? wrote: > On Thu, Feb 2, 2023 at 12:14 AM Pedro Duque Vieira > wrote: > > The fact that a theme is either dark or light is strongly correlated to > whether you as a developer want all window decorations to be light or dark. > I'd say that very few use cases will want to have some windows to be light > and others to be dark. > > As such, this API as it is, will force developers to set the window > decorations to either light or dark every time they spawn a new Window > (spawning a separate Window, a Dialog, etc). I'd say it would be a good > idea to set the window decorations based on what is defined in the > StyleTheme with the possibility to override them if you set it on the > Window itself. > > I've thought a bit about how we could have such a feature without > introducing Stage appearance to the StyleTheme interface (I think the > two concepts should remain separate). > Here's the updated design document with a proposal: > > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#changing-the-default-stage-appearance > What do you think? I'm not entirely convinced that the added > complexity is worth the benefit that this feature brings. > > > > > Looking at the doc you created. Some comments: > > - I like the Preferences API > > - "Appearance" or "ThemeAppearance"? "Appearance" sounds like a rather > generic term that could mean anything.. > > - perhaps rename the Stage appearance property to something like: > "frameDecorations", e.g. "setFrameDecorations(Appearance)"? > > I like the term "appearance" precisely because it's rather generic. > Apple also likes to call it like that, so there's some precedent for > it. > > > > > - " A future enhancement may refactor the built-in themes to make color > definitions swappable". This is already possible. Modena has its color > definitions given by css variables which can be easily overridden in CSS. > That's also a strong part of how I currently switch JMetro to either dark > or light version without having to duplicate every style definition. Side > note: JMetro is composed of several stylesheets (more than 1) so it would > be a nightmare or impossible to make JMetro be a user agent stylesheet with > the current state of the JavaFX API (+1 for this new API :-) ). > > - Perhaps rename "Application.userAgentStylesheetXX" to > "Application.styleThemeXX" and keep the semantics? If we make it be > "userAgentStylesheetXX" it means we can no longer in a future version make > StyleTheme have a property to define whether they are to be user agent > stylesheets or author stylesheets. It gives less room for us to be able to > change our minds in the future. > > If we have, at some point in the future, both a > `Application.userAgentStyleTheme` and `Application.styleTheme` > property, then users can decide whether they want the style theme to > have user-agent semantics, or author semantics. > Or do you want an option for style themes to decide for each indiviual > stylesheet whether it should have user-agent or author semantics? > > > > > - Perhaps instead of the section "Goals" being named "Goals" we could > name it "Advantages of this API" or something along those lines and have it > be the first topic. I think the first question people will ask is: "what's > the advantage of this new feature?".. so I think it would be nice if it's > the first topic so that we grab people's attention from the start. > > - instead of "Promote CSS user-agent themes from an implementation > detail to a first-class concept.", perhaps something more clear? Something > like: "Allow easier creation of themes that are composed of user agent > stylesheets (like Modena and Caspian). These themes may be composed of more > than 1 user agent stylesheet which isn't possible with the current javafx > API". Also perhaps make reference to the fact that 90% (rough estimate) of > themes out there are composed of author style sheets and it's difficult for > them to be different, which can be problematic for users of those themes: > styles set in code will be overridden, styles set in FXML, styles set in > author stylesheets created by the developers if the specificity of those > styles is lower than the themes styles.. > > I've roughly followed the JEP format with this enhancement proposal. > Added a clarification like you suggested to the Goals section. > -- Pedro Duque Vieira - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kizune at openjdk.org Thu Feb 2 22:06:53 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Feb 2023 22:06:53 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader In-Reply-To: <9LOLZMSxz_hFn4DVf9aGVlLCWp5fv1-Dfd8t9jgOsO0=.e48bd3de-fe79-4aa7-9116-8061d19a193c@github.com> References: <9LOLZMSxz_hFn4DVf9aGVlLCWp5fv1-Dfd8t9jgOsO0=.e48bd3de-fe79-4aa7-9116-8061d19a193c@github.com> Message-ID: On Thu, 2 Feb 2023 00:22:53 GMT, Kevin Rushforth wrote: > Can you enable GitHub actions for your repo? If you click on the "Checks" tab you 'll see a message from Skara with a pointer as to how to do that (the short answer is you go to "Actions" for your personal fork and click the big green button to enable it). Then you can either manually trigger a test run or push a commit (e.g., an empty commit or a merge from master) to trigger a run. Done and done, tests are passed. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Fri Feb 3 00:03:02 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 00:03:02 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v4] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 21:23:14 GMT, Alexander Zuev wrote: >> Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Trigger test jobs Looks good, apart from the recommendation to remove the one unused method you added. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Fri Feb 3 00:03:05 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 00:03:05 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 17:26:32 GMT, Alexander Zuev wrote: >> Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Removed debug output. modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java line 1271: > 1269: > 1270: Series getSeries() { > 1271: return seriesProperty.get(); This method is unused, so should probably be removed. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kevin.rushforth at oracle.com Fri Feb 3 00:27:59 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Feb 2023 16:27:59 -0800 Subject: Performance considerations of syncing FX Nodes with NG Nodes In-Reply-To: References: Message-ID: A longer answer will take more time than I have at the moment, but here is a quick reply. 1. We don't have a lot of scene graph performance tests, so before making any changes here we would need to do some targeted testing. 2. FX scene graph node --> NGNode peer is intended to be be one-way 3. There are certainly use cases for reusing nodes (attach / detach). VirtualFlow will do this for ListView, TableView, etc., with many rows. I would expect some apps to make use of it as well, since it's cheaper than recreating the FX nodes. There are also cases where nodes are moved from one parent to another and might transiently be "removed" from the graph. 4. Setting the node's peer to null when detached will cause it to be recreated when / if the node is added back into the scene graph, which you touch on later in your email. We wouldn't want the case of a scrolling ListView / TableVIew to have to continually recreate peers as the cells are cycled through. Anything done here would need to be done very carefully to ensure both correctness and performance. Your idea of splitting the peer data from the graph connectivity is interesting, but it also sounds pretty intrusive. Before going down that route I'd want to understand the problem better and see if there was a simpler solution to clear the parent / child relationship in the render graph. -- Kevin On 2/2/2023 9:17 AM, John Hendrikx wrote: > I have a few questions that maybe some Prism/SceneGraph experts could > help me with. > > 1) Are there any performance tests related to syncing the NGNode > peers? Specifically, I'm interested if there are tests that compare > the performance of "fresh" FX graphs that have never been displayed > before, versus ones that have their peers already created. > > 2) Does prism code ever refer back to FX Nodes?? I've noticed that > NGGroup imports javafx.scene.Node for one of its method signatures, > but that seems to be a mistake; it can easily be changed to not > require javafx.scene.Node.? Aside from several enums, constants and > data classes (like Color) being re-used from the javafx side, it seems > the NG Prism nodes are well encapsulated and that references are one > way only (FX Nodes refer to NG Nodes via `peer`, but never the other > way around). > > 3) How common is it to re-use FX Nodes that are no longer part of an > active scene?? I've found myself that it is unwise to detach/recreate > children in high performance controls that reuse cells -- it's often > better to just hide cells that are not currently needed instead of > removing them from the children list. > > 4) Are there any (major) performance implications to setting the NG > peer to `null` when FX nodes are not part of an active sync cycle (ie, > they have no Scene, or the Scene is not currently visible)? > > My observations on the sync cycle (syncPeer/doUpdatePeer) is that it > is highly optimized, and tries to avoid new allocations as much as > possible.? However, this seems to come at a price: it leaks memory > when not part of a sync cycle. Given a FX Node graph, that has been > displayed at least once, a mirrored graph is created consisting of > NGNodes. When such a FX Node graph is no longer displayed, any changes > to it are no longer synced to the mirror. > > This means that when I detach a small portion of the FX Node graph > (let's say a single Node), and keep a reference to only that Node, > that the FX graph can be GC'd. The corresponding NG Node graph however > (which still hasn't been updated) can't be GC'd. The single detached > FX Node has a peer, and this peer has a parent (and children), keeping > not only the detached Node's peer in memory, but also all the other > peers in the mirrored graph. > > Notifying the NG mirrored graph of changes is not easy, as it must be > done as part of the sync (locking is involved). Even a detached FX > Node can't assume its peer can be modified without locking as it may > still be used in an active rendering pass. > > This leads me to believe that to move to a situation where peers are > not being leaked would involve clearing peers as soon as FX nodes > becomes detached from the sync cycle. > > This has no doubt has performance implications, as peers would need to > be recreated if nodes are re-used (see Q3).? However, not all data > that is part of the peers is a problem, and code that simply clears > its peer when detached could be optimized again to be more peformant > (optimizing from a correctly working situation, instead of fixing > problems working from an optimized situation that has memory leaks). > > One way to optimize this may be to split the data that is tracked by > peers in parts that are just direct copies of FX Node data, and parts > that refer to parent/children.? The data that is just copies could be > kept ("peerData") while the peer itself is nulled.? When the peer > requires recreation, it is constructed as "new NGNode(peerData)".? > Because the parent/child linkages are not part of `peerData`, it is no > longer possible for large NG node trees to be kept in memory.? > Recreation of NGNode would still require work, but these NGNodes are > much smaller. > > --John > From angorya at openjdk.org Fri Feb 3 00:41:00 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 00:41:00 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v4] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 21:14:14 GMT, Alexander Zuev wrote: >> Still, I would recommend adding a comment (since now is the time when we know all the context, and in the future we might forget or lose the context), may be something like >> >> >> # {seriesName} {xAxisName} is {currentX} {yAxisName} is {currentY} >> XYChart.series.accessibleText={0} {1} is {2} {3} is {4} > >> Still, I would recommend adding a comment (since now is the time when we know all the context, and in the future we might forget or lose the context), may be something like > > Good idea, let me do it for both strings with parameters sorry to hold up the review - I'll speak to Naoto Sato tomorrow (2/3/23 @ 11:00) regarding the requirements for translation hints, and either approve or let you know what they expect us to do. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From arapte at openjdk.org Fri Feb 3 02:10:02 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 3 Feb 2023 02:10:02 GMT Subject: [jfx11u] Integrated: 8299272: Update copyright header for files modified in 2022 In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 06:32:58 GMT, Ambarish Rapte wrote: > Update copyright year in files modified in year 2022. This pull request has now been integrated. Changeset: a78d6a96 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/a78d6a968b29cba7addb2bbf0337e95e0257bcfd Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 mod 8299272: Update copyright header for files modified in 2022 Reviewed-by: kcr Backport-of: 48f6f5ba5b1f38281b38cd1f29a215f795ba0309 ------------- PR: https://git.openjdk.org/jfx11u/pull/126 From arapte at openjdk.org Fri Feb 3 02:11:04 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 3 Feb 2023 02:11:04 GMT Subject: [jfx17u] Integrated: 8299272: Update copyright header for files modified in 2022 In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 06:32:23 GMT, Ambarish Rapte wrote: > Update copyright year in files modified in year 2022. This pull request has now been integrated. Changeset: a9c4ce0f Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/a9c4ce0f233d54b4864427eb67f4ce5e568c2f3a Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod 8299272: Update copyright header for files modified in 2022 Reviewed-by: kcr Backport-of: 48f6f5ba5b1f38281b38cd1f29a215f795ba0309 ------------- PR: https://git.openjdk.org/jfx17u/pull/105 From arapte at openjdk.org Fri Feb 3 02:12:03 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 3 Feb 2023 02:12:03 GMT Subject: [jfx11u] Integrated: 8089986: Menu beeps when mnemonics is used In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 06:44:01 GMT, Ambarish Rapte wrote: > Almost clean backport, with a difference in copyright year. Otherwise clean. This pull request has now been integrated. Changeset: 509d6cf3 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/509d6cf3f7b92ce7e044fe37412733512dce98d1 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8089986: Menu beeps when mnemonics is used Reviewed-by: kcr Backport-of: c798d07a79debb00abb95a293e576237ee63a3b0 ------------- PR: https://git.openjdk.org/jfx11u/pull/127 From kpk at openjdk.org Fri Feb 3 05:58:57 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 3 Feb 2023 05:58:57 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: Message-ID: <_pKKZHdjgIxQgH-GNcUj6kZuRwGRpZ8PNmH2TBr3org=.6d0eca9f-8331-4b60-aa6e-bdd4a74b0643@github.com> On Thu, 2 Feb 2023 16:54:28 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 402: > >> 400: } >> 401: >> 402: return height + padding; > > My only comment is possibly reorganize the logic to avoid unnecessary computation. > For example, there is no need to compute text width (line 329) if isIgnoreText() is true; > Similarly, no need to compute graphicWidth on line 333 if isIgnoreGraphic() is true. > > (basically, same comment as @hjohn has made earlier) > > What do you think, @karthikpandelu ? Not sure if I didn't understand your comments properly but I'm guessing you are referring to `textHeight` and `graphicHeight` calculation in line 375 and 380 because the line numbers you mentioned are in `computePrefWidth` method and changes are made to height calculation in `computePrefHeight` only. Since `textHeight` and `graphicHeight` each are used in 3 conditions from line no 386 to 394 I have kept the calculation in the beginning itself. On the other hand `textWidth` declared in line 368 might change in line 371, so I can't use `width` directly instead of defining `textWidth` as `width` need to be used while calling other graphic related methods. ------------- PR: https://git.openjdk.org/jfx/pull/996 From jvos at openjdk.org Fri Feb 3 07:53:42 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 07:53:42 GMT Subject: [jfx17u] RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Message-ID: Clean backport for 8277853 Reviewed-by: kcr, mhanl ------------- Commit messages: - 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Changes: https://git.openjdk.org/jfx17u/pull/106/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277853 Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/106.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/106/head:pull/106 PR: https://git.openjdk.org/jfx17u/pull/106 From kizune at openjdk.org Fri Feb 3 08:08:35 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 3 Feb 2023 08:08:35 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v5] In-Reply-To: References: Message-ID: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Removed getSeries() method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1016/files - new: https://git.openjdk.org/jfx/pull/1016/files/ce66bfbf..1358b989 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1016.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1016/head:pull/1016 PR: https://git.openjdk.org/jfx/pull/1016 From kizune at openjdk.org Fri Feb 3 08:08:40 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 3 Feb 2023 08:08:40 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v2] In-Reply-To: References: Message-ID: <9aXpyP6MUcMChJoo-J5RKS3Uqkl4ANVNNtNw-FhLSZw=.4db6a966-e30d-4bcd-aa9e-a65b5616a14f@github.com> On Thu, 2 Feb 2023 23:46:27 GMT, Kevin Rushforth wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed debug output. > > modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java line 1271: > >> 1269: >> 1270: Series getSeries() { >> 1271: return seriesProperty.get(); > > This method is unused, so should probably be removed. Done. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From jvos at openjdk.org Fri Feb 3 08:33:06 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 08:33:06 GMT Subject: [jfx17u] RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 13:29:27 GMT, Ao Qi wrote: > Clean backport. Verified on (after #102): > - Linux/LoongArch64 (`USE_SYSTEM_MALLOC` is `on`, the platform triggering this problem) > - Linux/x64 (`USE_SYSTEM_MALLOC` is `off`) > - Linux/aarch64 (`USE_SYSTEM_MALLOC` is `off`) good to go now ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.org/jfx17u/pull/103 From jvos at openjdk.org Fri Feb 3 08:35:16 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 08:35:16 GMT Subject: [jfx17u] Integrated: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 07:48:19 GMT, Johan Vos wrote: > Clean backport for 8277853 > > Reviewed-by: kcr, mhanl This pull request has now been integrated. Changeset: d0579c35 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/d0579c3536b194ce771acc38d1bfb474b0b58c86 Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Backport-of: 78d922750747517553b101f5ff4af5361b1e7959 ------------- PR: https://git.openjdk.org/jfx17u/pull/106 From jvos at openjdk.org Fri Feb 3 08:39:54 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 08:39:54 GMT Subject: [jfx17u] Integrated: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. Message-ID: clean backport of JDK-8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. Reviewed-by: kcr, angorya, aghaisas ------------- Commit messages: - 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. Changes: https://git.openjdk.org/jfx17u/pull/107/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=107&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8089009 Stats: 56 lines in 2 files changed: 53 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/107.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/107/head:pull/107 PR: https://git.openjdk.org/jfx17u/pull/107 From jvos at openjdk.org Fri Feb 3 08:39:55 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 08:39:55 GMT Subject: [jfx17u] Integrated: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 08:29:41 GMT, Johan Vos wrote: > clean backport of JDK-8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. > > > Reviewed-by: kcr, angorya, aghaisas This pull request has now been integrated. Changeset: 6e7def58 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/6e7def587177cc0d53794895f9292fe5ee0876bb Stats: 56 lines in 2 files changed: 53 ins; 0 del; 3 mod 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. Backport-of: d4ff45af9fbde29f96d80681c7fc3af3ec580d1a ------------- PR: https://git.openjdk.org/jfx17u/pull/107 From aoqi at openjdk.org Fri Feb 3 08:45:16 2023 From: aoqi at openjdk.org (Ao Qi) Date: Fri, 3 Feb 2023 08:45:16 GMT Subject: [jfx17u] Integrated: 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 13:29:27 GMT, Ao Qi wrote: > Clean backport. Verified on (after #102): > - Linux/LoongArch64 (`USE_SYSTEM_MALLOC` is `on`, the platform triggering this problem) > - Linux/x64 (`USE_SYSTEM_MALLOC` is `off`) > - Linux/aarch64 (`USE_SYSTEM_MALLOC` is `off`) This pull request has now been integrated. Changeset: 29f878fc Author: Ao Qi Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/29f878fcc9778798293a2d125a10593f1fe2d6dc Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON Reviewed-by: kcr, jvos Backport-of: 28f8fa9c20363ced9a94787ecfd45735b3e6b82e ------------- PR: https://git.openjdk.org/jfx17u/pull/103 From jvos at openjdk.org Fri Feb 3 08:47:43 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 08:47:43 GMT Subject: [jfx17u] RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. Message-ID: clean backport of JDK-8087673 [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. Reviewed-by: angorya, aghaisas ------------- Commit messages: - 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. Changes: https://git.openjdk.org/jfx17u/pull/108/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=108&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8087673 Stats: 256 lines in 4 files changed: 247 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/108.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/108/head:pull/108 PR: https://git.openjdk.org/jfx17u/pull/108 From jvos at openjdk.org Fri Feb 3 08:48:00 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 08:48:00 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 13:28:51 GMT, Ao Qi wrote: > Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. Marked as reviewed by jvos (Reviewer). I'm ok with this. Apart from the functionality, this BP also makes it easier to backport future changes in build.gradle (because it backports a structural change in the 64-bit "detection") ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From aoqi at openjdk.org Fri Feb 3 08:53:02 2023 From: aoqi at openjdk.org (Ao Qi) Date: Fri, 3 Feb 2023 08:53:02 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 08:44:53 GMT, Johan Vos wrote: >> Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. > > I'm ok with this. > Apart from the functionality, this BP also makes it easier to backport future changes in build.gradle (because it backports a structural change in the 64-bit "detection") Thanks, @johanvos ! Let's wait for a while to see if @kevinrushforth has further comments. ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From jvos at openjdk.org Fri Feb 3 09:02:02 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 3 Feb 2023 09:02:02 GMT Subject: [jfx17u] Integrated: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 08:40:49 GMT, Johan Vos wrote: > clean backport of JDK-8087673 > [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. > > Reviewed-by: angorya, aghaisas This pull request has now been integrated. Changeset: ad397700 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/ad397700b4c0744f5f87b25a46c3cd219dc53399 Stats: 256 lines in 4 files changed: 247 ins; 4 del; 5 mod 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. Backport-of: 2baa10eed777574e40e5104278e8690941911018 ------------- PR: https://git.openjdk.org/jfx17u/pull/108 From john.hendrikx at gmail.com Fri Feb 3 11:44:24 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 3 Feb 2023 12:44:24 +0100 Subject: Performance considerations of syncing FX Nodes with NG Nodes In-Reply-To: References: Message-ID: <9b4898cb-3504-05e8-f0fe-58474f07bc65@gmail.com> On 03/02/2023 01:27, Kevin Rushforth wrote: > A longer answer will take more time than I have at the moment, but > here is a quick reply. > > 1. We don't have a lot of scene graph performance tests, so before > making any changes here we would need to do some targeted testing. I completely agree here, if there are no tests that can be re-used then some will need to be created, that's okay. > > 2. FX scene graph node --> NGNode peer is intended to be be one-way Makes sense. > > 3. There are certainly use cases for reusing nodes (attach / detach). > VirtualFlow will do this for ListView, TableView, etc., with many > rows. I would expect some apps to make use of it as well, since it's > cheaper than recreating the FX nodes. There are also cases where nodes > are moved from one parent to another and might transiently be > "removed" from the graph. Moving nodes is one of the cases that may degrade in performance. Keeping (unused) cell nodes as part of the children list but invisible/unmanaged should not be affected (I'm not 100% sure what VirtualFlow is doing at the moment, I only know that's how I do it in my own ListViewSkin -- I don't think it had a performance reason, more that it could result in visual artifacts in 1 rendered frame before correct colors were applied -- perhaps a bug in itself). > > 4. Setting the node's peer to null when detached will cause it to be > recreated when / if the node is added back into the scene graph, which > you touch on later in your email. We wouldn't want the case of a > scrolling ListView / TableVIew to have to continually recreate peers > as the cells are cycled through. Yeah, not sure if that is what would happen, it depends on how VirtualFlow is handling its cells. > > Anything done here would need to be done very carefully to ensure both > correctness and performance. Your idea of splitting the peer data from > the graph connectivity is interesting, but it also sounds pretty > intrusive. > > Before going down that route I'd want to understand the problem better > and see if there was a simpler solution to clear the parent / child > relationship in the render graph. There are multiple problems it seems in this area. At first I thought it was only the `removed` list in Parent that is a problem, as it can contain old Nodes that don't get cleaned up when not part of a sync cycle.? But any node that is not part of a sync cycle may refer to a peer, and that peer can refer to parent/children in turn, keeping an entire NGNode graph in memory. For the `removed` list in Parent, there is a simple solution I think.? It already has a mechanism to mark itself as "fully" dirty when more than 20 children are removed. This mechanism could be re-used to also mark it as fully dirty when the Parent is no longer part of an active sync cycle. If ever re-attached, it would just fully render instead of trying to calculate a smaller dirty region based on removed children. There is also an odd piece of code in Node, in invalidateScenes. In this code it will call `peer.release()` which does nothing for any of the current NG implementations (even though there are comments that they should do "something").? But because it doesn't set `peer` to `null` it will later use the "released" peer again if re-attached to a scene.? If this is not a mistake, it deserves an explanatory comment I think. --John > > -- Kevin > > > On 2/2/2023 9:17 AM, John Hendrikx wrote: >> I have a few questions that maybe some Prism/SceneGraph experts could >> help me with. >> >> 1) Are there any performance tests related to syncing the NGNode >> peers? Specifically, I'm interested if there are tests that compare >> the performance of "fresh" FX graphs that have never been displayed >> before, versus ones that have their peers already created. >> >> 2) Does prism code ever refer back to FX Nodes?? I've noticed that >> NGGroup imports javafx.scene.Node for one of its method signatures, >> but that seems to be a mistake; it can easily be changed to not >> require javafx.scene.Node.? Aside from several enums, constants and >> data classes (like Color) being re-used from the javafx side, it >> seems the NG Prism nodes are well encapsulated and that references >> are one way only (FX Nodes refer to NG Nodes via `peer`, but never >> the other way around). >> >> 3) How common is it to re-use FX Nodes that are no longer part of an >> active scene?? I've found myself that it is unwise to detach/recreate >> children in high performance controls that reuse cells -- it's often >> better to just hide cells that are not currently needed instead of >> removing them from the children list. >> >> 4) Are there any (major) performance implications to setting the NG >> peer to `null` when FX nodes are not part of an active sync cycle >> (ie, they have no Scene, or the Scene is not currently visible)? >> >> My observations on the sync cycle (syncPeer/doUpdatePeer) is that it >> is highly optimized, and tries to avoid new allocations as much as >> possible.? However, this seems to come at a price: it leaks memory >> when not part of a sync cycle. Given a FX Node graph, that has been >> displayed at least once, a mirrored graph is created consisting of >> NGNodes. When such a FX Node graph is no longer displayed, any >> changes to it are no longer synced to the mirror. >> >> This means that when I detach a small portion of the FX Node graph >> (let's say a single Node), and keep a reference to only that Node, >> that the FX graph can be GC'd. The corresponding NG Node graph >> however (which still hasn't been updated) can't be GC'd. The single >> detached FX Node has a peer, and this peer has a parent (and >> children), keeping not only the detached Node's peer in memory, but >> also all the other peers in the mirrored graph. >> >> Notifying the NG mirrored graph of changes is not easy, as it must be >> done as part of the sync (locking is involved). Even a detached FX >> Node can't assume its peer can be modified without locking as it may >> still be used in an active rendering pass. >> >> This leads me to believe that to move to a situation where peers are >> not being leaked would involve clearing peers as soon as FX nodes >> becomes detached from the sync cycle. >> >> This has no doubt has performance implications, as peers would need >> to be recreated if nodes are re-used (see Q3).? However, not all data >> that is part of the peers is a problem, and code that simply clears >> its peer when detached could be optimized again to be more peformant >> (optimizing from a correctly working situation, instead of fixing >> problems working from an optimized situation that has memory leaks). >> >> One way to optimize this may be to split the data that is tracked by >> peers in parts that are just direct copies of FX Node data, and parts >> that refer to parent/children.? The data that is just copies could be >> kept ("peerData") while the peer itself is nulled.? When the peer >> requires recreation, it is constructed as "new NGNode(peerData)".? >> Because the parent/child linkages are not part of `peerData`, it is >> no longer possible for large NG node trees to be kept in memory.? >> Recreation of NGNode would still require work, but these NGNodes are >> much smaller. >> >> --John >> > From kcr at openjdk.org Fri Feb 3 13:04:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 13:04:08 GMT Subject: [jfx17u] RFR: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: <4p661qn3_JJiuvXaq6QqDFQUaIAOevRYEjeXsouk5Eg=.172768f8-dab9-4224-9bd2-b018d44ce9ee@github.com> On Mon, 9 Jan 2023 13:28:51 GMT, Ao Qi wrote: > Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx17u/pull/102 From kcr at openjdk.org Fri Feb 3 14:12:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 14:12:20 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v5] In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 08:08:35 GMT, Alexander Zuev wrote: >> Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Removed getSeries() method Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Fri Feb 3 14:12:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 14:12:21 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v5] In-Reply-To: References: Message-ID: <2lGPIGGVby3sAza5C2KBgLIflbF8qZ5WhVXfbNo3BDU=.70b52d7d-26aa-4732-8faa-c12093592bbb@github.com> On Fri, 3 Feb 2023 00:37:56 GMT, Andy Goryachev wrote: >>> Still, I would recommend adding a comment (since now is the time when we know all the context, and in the future we might forget or lose the context), may be something like >> >> Good idea, let me do it for both strings with parameters > > sorry to hold up the review - I'll speak to Naoto Sato tomorrow (2/3/23 @ 11:00) regarding the requirements for translation hints, and either approve or let you know what they expect us to do. OK. Presuming that the comment Alex already left is fine, or just needs a slight format change, then that's good. If it's more than that, it would be better to do it in a follow-up issue. ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Fri Feb 3 15:39:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 15:39:58 GMT Subject: [jfx17u] Integrated: 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 Message-ID: Clean backport to jfx17u. ------------- Commit messages: - 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 Changes: https://git.openjdk.org/jfx17u/pull/109/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296654 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/109.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/109/head:pull/109 PR: https://git.openjdk.org/jfx17u/pull/109 From kcr at openjdk.org Fri Feb 3 15:39:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 15:39:59 GMT Subject: [jfx17u] Integrated: 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 15:31:58 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. This pull request has now been integrated. Changeset: a1c4d0a5 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx17u/commit/a1c4d0a5857920b1d09615b4cd43b09b6b2189de Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 Backport-of: 5b96d348ebcabb4b6d2e1d95937de3c82a1f6876 ------------- PR: https://git.openjdk.org/jfx17u/pull/109 From kcr at openjdk.org Fri Feb 3 15:44:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 15:44:19 GMT Subject: [jfx11u] Integrated: 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 Message-ID: Clean backport to jfx11u. ------------- Commit messages: - 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 Changes: https://git.openjdk.org/jfx11u/pull/128/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296654 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx11u/pull/128.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/128/head:pull/128 PR: https://git.openjdk.org/jfx11u/pull/128 From kcr at openjdk.org Fri Feb 3 15:44:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 15:44:20 GMT Subject: [jfx11u] Integrated: 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 15:34:09 GMT, Kevin Rushforth wrote: > Clean backport to jfx11u. This pull request has now been integrated. Changeset: 59fa5322 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx11u/commit/59fa5322625b6f2a0867cf310bc855b183a84e7c Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13 Backport-of: 5b96d348ebcabb4b6d2e1d95937de3c82a1f6876 ------------- PR: https://git.openjdk.org/jfx11u/pull/128 From angorya at openjdk.org Fri Feb 3 18:07:09 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 18:07:09 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: <_pKKZHdjgIxQgH-GNcUj6kZuRwGRpZ8PNmH2TBr3org=.6d0eca9f-8331-4b60-aa6e-bdd4a74b0643@github.com> References: <_pKKZHdjgIxQgH-GNcUj6kZuRwGRpZ8PNmH2TBr3org=.6d0eca9f-8331-4b60-aa6e-bdd4a74b0643@github.com> Message-ID: On Fri, 3 Feb 2023 05:56:32 GMT, Karthik P K wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 402: >> >>> 400: } >>> 401: >>> 402: return height + padding; >> >> My only comment is possibly reorganize the logic to avoid unnecessary computation. >> For example, there is no need to compute text width (line 329) if isIgnoreText() is true; >> Similarly, no need to compute graphicWidth on line 333 if isIgnoreGraphic() is true. >> >> (basically, same comment as @hjohn has made earlier) >> >> What do you think, @karthikpandelu ? > > Not sure if I didn't understand your comments properly but I'm guessing you are referring to `textHeight` and `graphicHeight` calculation in line 375 and 380 because the line numbers you mentioned are in `computePrefWidth` method and changes are made to height calculation in `computePrefHeight` only. > Since `textHeight` and `graphicHeight` each are used in 3 conditions from line no 386 to 394 I have kept the calculation in the beginning itself. > > On the other hand `textWidth` declared in line 368 might change in line 371, so I can't use `width` directly instead of defining `textWidth` as `width` need to be used while calling other graphic related methods. Both `computePrefHeight()` and `computePrefWidth` can be restructured to avoid unnecessary computation (especially since these are very popular objects). My point is that, for example, textWidth on line 375 (used to compute textHeight:375) is not used if isIgnoreText() == true. Similarly, graphicHeight:380 is not used if isIgnoreGraphic() == true, line 386. Same optimization can be applied to computePrefWidth():315 Just a suggestion, really. ------------- PR: https://git.openjdk.org/jfx/pull/996 From angorya at openjdk.org Fri Feb 3 19:25:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 19:25:01 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v5] In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 08:08:35 GMT, Alexander Zuev wrote: >> Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Removed getSeries() method very good, thank you. ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/1016 From angorya at openjdk.org Fri Feb 3 19:25:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 19:25:04 GMT Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader [v5] In-Reply-To: <2lGPIGGVby3sAza5C2KBgLIflbF8qZ5WhVXfbNo3BDU=.70b52d7d-26aa-4732-8faa-c12093592bbb@github.com> References: <2lGPIGGVby3sAza5C2KBgLIflbF8qZ5WhVX fbNo3BDU=.70b52d7d-26aa-4732-8faa-c12093592bbb@github.com> Message-ID: On Fri, 3 Feb 2023 14:09:08 GMT, Kevin Rushforth wrote: >> sorry to hold up the review - I'll speak to Naoto Sato tomorrow (2/3/23 @ 11:00) regarding the requirements for translation hints, and either approve or let you know what they expect us to do. > > OK. Presuming that the comment Alex already left is fine, or just needs a slight format change, then that's good. If it's more than that, it would be better to do it in a follow-up issue. The comment is good. The idea of giving translators hints in the form of comments like this was very warmly welcomed by our i18n lead Naoto Sato. So I think we should follow this approach for every new string we add in jfx (and jdk). The goal is to give the translators more context, by either giving an example of resulting text or by describing the parameters like Alex did in this case (or both). ------------- PR: https://git.openjdk.org/jfx/pull/1016 From angorya at openjdk.org Fri Feb 3 20:37:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 20:37:56 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size Message-ID: Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). Added a test case. Tested with the PaginationDisappear.java and the LeakTest app https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java ------------- Commit messages: - 8301797: fixed pagination initialization Changes: https://git.openjdk.org/jfx/pull/1021/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301797 Stats: 29 lines in 2 files changed: 25 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1021.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1021/head:pull/1021 PR: https://git.openjdk.org/jfx/pull/1021 From kizune at openjdk.org Fri Feb 3 21:40:03 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 3 Feb 2023 21:40:03 GMT Subject: Integrated: 8298382: JavaFX ChartArea Accessibility Reader In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 21:56:45 GMT, Alexander Zuev wrote: > Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized. This pull request has now been integrated. Changeset: 33f1f629 Author: Alexander Zuev Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/33f1f629c5df9f8e03e81e360730536cde0a8f53 Stats: 97 lines in 3 files changed: 90 ins; 0 del; 7 mod 8298382: JavaFX ChartArea Accessibility Reader Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1016 From kcr at openjdk.org Fri Feb 3 21:51:02 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 21:51:02 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size In-Reply-To: References: Message-ID: <0GYirt4JSODZagFrUdFHUzQv4NK6FPKtHuEvUuuJpPQ=.17aad9ff-72cb-41eb-8a2d-32394b261ee4@github.com> On Fri, 3 Feb 2023 20:15:46 GMT, Andy Goryachev wrote: > Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. > > The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). > > Added a test case. > > Tested with the PaginationDisappear.java and the LeakTest app > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java A fix request in JBS is in progress (since we're in RDP2), which I'll review along with the code. @aghaisas Can I ask you to also review it? ------------- PR: https://git.openjdk.org/jfx/pull/1021 From bourges.laurent at gmail.com Fri Feb 3 22:31:03 2023 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 3 Feb 2023 23:31:03 +0100 Subject: Enhance javafx Canvas API Message-ID: Hi, While working with skia & jfree's skijaGraphics2D wrapper, I observed skia offers nice methods in SkCanvas missing in javafx Canvas/GraphicsContext to deal with save/restore state: - int getSaveCount () Returns the number of saved states, each containing: SkMatrix and clip. - void restoreToCount (int saveCount) Restores state to SkMatrix and clip values when save(), returned saveCount. As javafx canvas also maintains s stack of saved states, such methods are trivial to implement to allow resetting completely the canvas state by restoreToCount(0). Moreover, clip(shape) + save/restore are really tricky to allows ensure clip is reset to previous state ... Would you agree to add such methods to have more predictive behaviour than counting all save() calls to ensure to call restore() the same number of times to reset the canvas to its initial state ? See SkijaGraphics2d implementation that saves / restore skCanvas clip using such index property: https://github.com/jfree/skijagraphics2d/blob/main/src/main/java/org/jfree/skija/SkijaGraphics2D.java Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Fri Feb 3 22:39:06 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 3 Feb 2023 22:39:06 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4] In-Reply-To: References: Message-ID: <_j-OSwIVao88Ib7WcdfVnJTogMC03c8ZgNAO73G_Idg=.5c085839-aeb2-46e8-822d-95626e559fcd@github.com> On Sat, 28 Jan 2023 16:24:30 GMT, Michael Strau? wrote: >> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. >> >> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Initialize treeVisible field directly Looks good. I ran the tests and they pass. Left a few optional comments. Maybe @kevinrushforth will want to have a look too before you merge. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1917: > 1915: for (Node child : parent.getChildren()) { > 1916: child.updateDisabled(); > 1917: } If you like this style, you could do `parent.getChildren().forEach(Node::updateDisabled);`. I find these more readable, but it's up to you. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 2608: > 2606: // PerformanceTracker.logEvent("Node.postinit " + > 2607: // "for [{this}, id=\"{id}\"] finished"); > 2608: //} Not sure if these comments are intended to be used for something. I doubt it though. modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 2024: > 2022: > 2023: } > 2024: Since you changed the copyright year on the other files, you might want to do this one too. There is a script that will do it anyway, so it doesn't matter. modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 2039: > 2037: assertTrue(n2.isDisabled()); > 2038: assertTrue(n2.isDisabled()); > 2039: } I suggest to continue this test with a `g.setDisable(false)` to check both directions. The first group of assertions test the initial state, not a change to `false`. Same for the other test. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/841 From kcr at openjdk.org Fri Feb 3 22:47:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 22:47:55 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 20:15:46 GMT, Andy Goryachev wrote: > Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. > > The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). > > Added a test case. > > Tested with the PaginationDisappear.java and the LeakTest app > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java While the fix works for the specific case in the bug report, I don't think it's quite right. In your description you say: > while making sure no properties of the control are touched in the constructor (only in install()). However, the current fix _does_ touch properties of the control in the constructor via the moved `resetIndexes` method. First, the "if" check you added to avoid calling `setCurrentPageIndex` on the control is backwards, meaning that it is being called in the case you were trying to avoid. Second, createPage, which is also called from `resetIndexes` has a code path that also calls `setCurrentPageIndex`. If it really is important that the skin constructor not call any setter on the control, then you will need to rework the solution. Possibly by moving the call to `resetIndexes` back to install, and figuring out why calling it later isn't causing the pref size to be recomputed. modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 197: > 195: nextStackPane.setVisible(false); > 196: > 197: resetIndexes(true); This will end up calling into the control in a couple places, which the PR description says you are trying to avoid. modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 654: > 652: nextStackPane.getChildren().clear(); > 653: > 654: if (usePageIndex) { Shouldn't this be `!usePageIndex`, given the stated intent? The `resetIndexes` method is called twice: once from the constructor with `usePageIndex = true` and once from `resetIndiciesAndNav` with `usePageIndex = false`. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/1021 From angorya at openjdk.org Fri Feb 3 22:59:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 22:59:06 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 20:15:46 GMT, Andy Goryachev wrote: > Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. > > The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). > > Added a test case. > > Tested with the PaginationDisappear.java and the LeakTest app > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java You are right! In fact, the added logic to bypass setting control properties in the constructor is unnecessary - it will be essentially a no-op, since it uses the control's current page index. ------------- PR: https://git.openjdk.org/jfx/pull/1021 From kcr at openjdk.org Fri Feb 3 23:05:03 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 23:05:03 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4] In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 16:24:30 GMT, Michael Strau? wrote: >> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. >> >> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Initialize treeVisible field directly I took a quick look and it seems fine to me. I recommend to wait for a day or two to see if @arapte has any additional comments on the changes (since his review is stale). ------------- PR: https://git.openjdk.org/jfx/pull/841 From angorya at openjdk.org Fri Feb 3 23:09:30 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 23:09:30 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size [v2] In-Reply-To: References: Message-ID: > Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. > > The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). > > Added a test case. > > Tested with the PaginationDisappear.java and the LeakTest app > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8301797: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1021/files - new: https://git.openjdk.org/jfx/pull/1021/files/3fbbfccb..a01348e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1021&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1021&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1021.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1021/head:pull/1021 PR: https://git.openjdk.org/jfx/pull/1021 From kcr at openjdk.org Fri Feb 3 23:09:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 23:09:30 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 20:15:46 GMT, Andy Goryachev wrote: > Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. > > The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). > > Added a test case. > > Tested with the PaginationDisappear.java and the LeakTest app > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java The changes you just made look good to me, since everything is now internally consistent. I'll retest and then finish my review. ------------- PR: https://git.openjdk.org/jfx/pull/1021 From angorya at openjdk.org Fri Feb 3 23:09:31 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 23:09:31 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size [v2] In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 22:28:06 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301797: review comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 197: > >> 195: nextStackPane.setVisible(false); >> 196: >> 197: resetIndexes(true); > > This will end up calling into the control in a couple places, which the PR description says you are trying to avoid. true, but since it sets to the same value it will be a no-op ------------- PR: https://git.openjdk.org/jfx/pull/1021 From angorya at openjdk.org Fri Feb 3 23:09:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Feb 2023 23:09:56 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 23:05:43 GMT, Kevin Rushforth wrote: >> Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. >> >> The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). >> >> Added a test case. >> >> Tested with the PaginationDisappear.java and the LeakTest app >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java > > The changes you just made look good to me, since everything is now internally consistent. I'll retest and then finish my review. Thank you, @kevinrushforth . ------------- PR: https://git.openjdk.org/jfx/pull/1021 From kcr at openjdk.org Fri Feb 3 23:24:01 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 23:24:01 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size [v2] In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 23:09:30 GMT, Andy Goryachev wrote: >> Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. >> >> The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). >> >> Added a test case. >> >> Tested with the PaginationDisappear.java and the LeakTest app >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8301797: review comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/1021 From kcr at openjdk.org Fri Feb 3 23:24:03 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 Feb 2023 23:24:03 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size [v2] In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 23:03:28 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 197: >> >>> 195: nextStackPane.setVisible(false); >>> 196: >>> 197: resetIndexes(true); >> >> This will end up calling into the control in a couple places, which the PR description says you are trying to avoid. > > true, but since it sets to the same value it will be a no-op Right. ------------- PR: https://git.openjdk.org/jfx/pull/1021 From mstrauss at openjdk.org Fri Feb 3 23:31:24 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Feb 2023 23:31:24 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v5] In-Reply-To: References: Message-ID: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> > `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. > > These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: improved tests, changed foreach loop ------------- Changes: - all: https://git.openjdk.org/jfx/pull/841/files - new: https://git.openjdk.org/jfx/pull/841/files/02577bba..316ec939 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=841&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=841&range=03-04 Stats: 14 lines in 2 files changed: 10 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/841.diff Fetch: git fetch https://git.openjdk.org/jfx pull/841/head:pull/841 PR: https://git.openjdk.org/jfx/pull/841 From mstrauss at openjdk.org Fri Feb 3 23:31:24 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Feb 2023 23:31:24 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4] In-Reply-To: <_j-OSwIVao88Ib7WcdfVnJTogMC03c8ZgNAO73G_Idg=.5c085839-aeb2-46e8-822d-95626e559fcd@github.com> References: <_j-OSwIVao88Ib7WcdfVnJTogMC03c8ZgNAO73G_Idg=.5c085839-aeb2-46e8-822d-95626e559fcd@github.com> Message-ID: <7XYTIc0hsLbKpjci5uBVGNV3-SGDGwmrVtjezFFFv8U=.5f0daa0a-e3f5-4d77-a4b5-a41da0439a01@github.com> On Fri, 3 Feb 2023 22:27:26 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize treeVisible field directly > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1917: > >> 1915: for (Node child : parent.getChildren()) { >> 1916: child.updateDisabled(); >> 1917: } > > If you like this style, you could do `parent.getChildren().forEach(Node::updateDisabled);`. I find these more readable, but it's up to you. Done. > modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 2024: > >> 2022: >> 2023: } >> 2024: > > Since you changed the copyright year on the other files, you might want to do this one too. There is a script that will do it anyway, so it doesn't matter. Done. > modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 2039: > >> 2037: assertTrue(n2.isDisabled()); >> 2038: assertTrue(n2.isDisabled()); >> 2039: } > > I suggest to continue this test with a `g.setDisable(false)` to check both directions. The first group of assertions test the initial state, not a change to `false`. > > Same for the other test. Done. ------------- PR: https://git.openjdk.org/jfx/pull/841 From mstrauss at openjdk.org Fri Feb 3 23:34:57 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Feb 2023 23:34:57 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v5] In-Reply-To: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> References: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> Message-ID: On Fri, 3 Feb 2023 23:31:24 GMT, Michael Strau? wrote: >> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. >> >> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > improved tests, changed foreach loop I've extended the tests to check for the other direction as well. @hjohn @nlisker can you re-review? ------------- PR: https://git.openjdk.org/jfx/pull/841 From nlisker at openjdk.org Fri Feb 3 23:43:56 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 3 Feb 2023 23:43:56 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v5] In-Reply-To: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> References: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> Message-ID: On Fri, 3 Feb 2023 23:31:24 GMT, Michael Strau? wrote: >> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. >> >> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > improved tests, changed foreach loop I missed that you can also change the foreach loop on the treeVisible method too, but it's not important. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/841 From aoqi at openjdk.org Sat Feb 4 14:14:03 2023 From: aoqi at openjdk.org (Ao Qi) Date: Sat, 4 Feb 2023 14:14:03 GMT Subject: [jfx17u] Integrated: 8293214: Add support for Linux/LoongArch64 In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 13:28:51 GMT, Ao Qi wrote: > Clean backport. Verified on Linux/LoongArch64, Linux/x64 and Linux/aarch64. This pull request has now been integrated. Changeset: 1b99a5b2 Author: Ao Qi Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx17u/commit/1b99a5b26bcd194d98d97bd7078a6b7fb76d8d93 Stats: 26 lines in 4 files changed: 15 ins; 0 del; 11 mod 8293214: Add support for Linux/LoongArch64 Reviewed-by: jvos, kcr Backport-of: cef583eef41aff3db55542d5e90423eec5601f41 ------------- PR: https://git.openjdk.org/jfx17u/pull/102 From kcr at openjdk.org Sat Feb 4 15:17:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 Feb 2023 15:17:55 GMT Subject: RFR: 8173321: Click on trough has no effect when cell height > viewport [v3] In-Reply-To: References: Message-ID: On Sun, 22 Jan 2023 15:34:25 GMT, JoachimSchriek wrote: >> This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. >> So please be patient with an absolute beginner as contributor ... . >> The work of this pull request was fully done in my spare time. >> >> I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. >> >> The two changes address the two problems mentioned in JDK-8173321: >> - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height >> - The ScrollBar ist displayed with a minimal height. >> >> The changes were tested and ran well with Java 17 and the current master branch of openjfx. > > JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: > > Deleted trailing whitespace Reviewers: @aghaisas @andy-goryachev-oracle I'll add a few comments, but will rely on Ajit and Andy to formally review it. @johanvos might want to take a look as well, since he has recently fixed several VirtualFlow bugs. @JoachimSchriek You will need to change the title of this PR to exactly match the JBS title (see the note from the Skara bot in the Description). ------------- PR: https://git.openjdk.org/jfx/pull/985 From kcr at openjdk.org Sat Feb 4 15:48:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 Feb 2023 15:48:58 GMT Subject: RFR: 8173321: Click on trough has no effect when cell height > viewport [v3] In-Reply-To: References: Message-ID: <_UsiRCTkRHY_72ZH0i7ihIAGr_ppJFscmWgF9iHYPOg=.6dd96ce4-fb28-4b80-bc14-9023c835c115@github.com> On Sun, 22 Jan 2023 15:34:25 GMT, JoachimSchriek wrote: >> This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. >> So please be patient with an absolute beginner as contributor ... . >> The work of this pull request was fully done in my spare time. >> >> I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. >> >> The two changes address the two problems mentioned in JDK-8173321: >> - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height >> - The ScrollBar ist displayed with a minimal height. >> >> The changes were tested and ran well with Java 17 and the current master branch of openjfx. > > JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: > > Deleted trailing whitespace I left a few inline comments. Most are pretty minor, but I am a bit concerned about the change to the computation of the visible amount of the `lengthBar`. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 135: > 133: /** > 134: * JDK-8173321: Click on trough has no effect when cell height > viewport height: > 135: * Solution: Scroll one cell further up resp. down if only one cell is shown. We generally do not refer to specific bug IDs in source code comments. Rather, describe the purpose of this block. Also, please spell out `resp.` -- I can't figure out what it is supposed to mean. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 151: > 149: IndexedCell cell = firstVisibleCell; > 150: if (cell == null) > 151: return; Unless the if statement, including its target, is entirely on one line, you _must_ enclose the target of the `if` with curly braces, like this: if (cell == null) { return; } Since it fits on one line, the prior code is also acceptable: if (cell == null) return; modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 156: > 154: IndexedCell cell = lastVisibleCell; > 155: if (cell == null) > 156: return; Either revert this or enclose in curly braces. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2595: > 2593: if (recreate && (lengthBar.isVisible() || Properties.IS_TOUCH_SUPPORTED)) { > 2594: final int cellCount = getCellCount(); > 2595: float numCellsVisibleOnScreen = 0; Can you explain why this needs to be in floating point? Presuming that it does need to be in floating-point, I recommend making this a double to match `lengthToAdd`. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2602: > 2600: sumCellLength += lengthToAdd; > 2601: if (sumCellLength > flowLength) { > 2602: numCellsVisibleOnScreen += ( 1 - (sumCellLength - flowLength )/ lengthToAdd); Minor: remove the spaces after the `(` and before the `)`, and add a space before the `/` like this: numCellsVisibleOnScreen += (1 - (sumCellLength - flowLength ) / lengthToAdd); modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2611: > 2609: > 2610: lengthBar.setMax(1); > 2611: lengthBar.setVisibleAmount( numCellsVisibleOnScreen / (float) cellCount); I'm concerned with the change to no longer use the estimated size. This will produce very different results for tables with variable row hights. @johanvos will very likely want to comment on this. Also, The cast is unnecessary. Minor: remove the space after the `(` tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewClickOnTroughTest.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2022, Oracle and/or its affiliates. All rights reserved. Update the "last touched year" to 2023. Also, unless this is substantially the same as some other class that you copied, you can change the `2018,` to `2022,`. tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewClickOnTroughTest.java line 99: > 97: } catch (InterruptedException e1) { > 98: e1.printStackTrace(); > 99: } You can change this to `Util.sleep(1000);` and eliminate the try/catch here and below. tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewClickOnTroughTest.java line 108: > 106: latch.countDown(); > 107: }); > 108: Util.waitForLatch(latch, 5, "Timeout while waiting for mouse click"); Suggestion: If you change `Platform.runLater` to `Util.runAndWait` you can eliminate the latch (it will do that for you). ------------- PR: https://git.openjdk.org/jfx/pull/985 From jhendrikx at openjdk.org Sun Feb 5 09:33:58 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 5 Feb 2023 09:33:58 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v5] In-Reply-To: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> References: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> Message-ID: On Fri, 3 Feb 2023 23:31:24 GMT, Michael Strau? wrote: >> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. >> >> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > improved tests, changed foreach loop Marked as reviewed by jhendrikx (Committer). ------------- PR: https://git.openjdk.org/jfx/pull/841 From jhendrikx at openjdk.org Sun Feb 5 09:39:58 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 5 Feb 2023 09:39:58 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:42:05 GMT, John Hendrikx wrote: >> This contains the following: >> - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes >> - This fixes odd change events being produced (with incorrect oldValue) >> - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call >> - A test for ExpressionHelper to verify the new behavior >> - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level). >> - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/delayed-nested-emission > - Delay nested event emission @arapte @nlisker what do you think? ------------- PR: https://git.openjdk.org/jfx/pull/837 From jhendrikx at openjdk.org Sun Feb 5 09:45:54 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 5 Feb 2023 09:45:54 GMT Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings and collections packages [v2] In-Reply-To: <-XmEj7zD3hwuL_pmYIZ91htRrzL2FRKYgrKc5hGP7N0=.09deb870-ebd1-44dd-9cb9-f2c1d922e419@github.com> References: <-XmEj7zD3hwuL_pmYIZ91htRrzL2FRKYgrKc5hGP7N0=.09deb870-ebd1-44dd-9cb9-f2c1d922e419@github.com> Message-ID: <0ENPVJXKLi7al0wGE7SQKA4TAfBAa6NXarvHZjraxP4=.925c5a4d-90bc-4263-bd00-d403aab0f5bb@github.com> On Wed, 4 Jan 2023 05:28:10 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Clean up expression classes repeated null checks >> - Use instanceof with pattern matching in a few spots > > I took a closer look at the sorting-related classes. I think that the design there is not ideal. Fixing it might be out of scope for this PR. I wouldn't mind fixing it myself, by the way. > > The way the JDK treats soring on lists is with a single `sort(Comparable c)` method that, when receiving `null`, assumes that the elements are `Comparable` and throws if not. `Collections` has 2 static sorting methods that help enforce this condition, where the one that doesn't take a `Comparator` passes `null` to the one that does. > > JavaFX tries to emulate this. `FXCollections` has the same 2 methods for `ObservableList`, but one doesn't call the other. The asymmetry comes from `SortableList` (which doesn't live up to its name - non-sortable lists can also implement it). It defines a 0-argument method and a `Comparator`-argument method as different behaviors, instead of one calling the other. This is deferred to its implementations, `ObservableListWrapper` and `ObservableSequentialListWrapper`, which make the differentiation by, again, calling 2 different methods on `SortHelper`. > > I suggest that the argument check be made at the lowest level, like in the JDK (inside `Arrays` sort method). First, `FXCollections` can change to: > > > public static > void sort(ObservableList list) { > sort(list, null); // or Comparator.naturalOrder() instead of null > } > > public static void sort(ObservableList list, Comparator c) { > if (list instanceof SortableList) { > list.sort(c); > } else { > List newContent = new ArrayList<>(list); > newContent.sort(c); > list.setAll(newContent); > } > } > > > `SortableList` then removes its `sort()` method, and now it's just overriding `List::sort(Comparator)` without doing anything with it, so it can be removed too, and it's left as a marker interface for the special sorting in `SortHelper` (I haven't understood yet why it's better , I need to dig there more): > > > public interface SortableList {} > > > Now `ObservableListWrapper` and `ObservableSequentialListWrapper` also remove `sort()`, and override `List::sort(Comparator)` directly and in accordance with its contract, passing the (possibly `null`) comparator to `SortHelper`, which is akin to the JDK's `Arrays::sort` method. > > Now I need to look into `SortHelper` to see what it does exactly and how to change it. I think it doesn't need the `sort(List list)` method too now because it doesn't really enforce that the elements are `Comparable`, it will naturally throw if not. > > --- > > In my opinion, this is the design flaw: `ObservableList` should have overridden `List`'s sort method to specify that its sorting is done as one change: > > > public interface ObservableList extends List, Observable { > > @Override > default void sort(Comparator c) { > var newContent = new ArrayList<>(this); > newContent.sort(c); > setAll(newContent); > } > > > Then we wouldn't need the `SortableList` marker because `FXCollections` could just call this method directly (like `Collections` does, which means that `FXCollections`'s methods are not needed anymore, though we can't remove them), and whichever implementation wants to do a more efficient sorting, like `ObservableListWrapper`, can override again. > This will be a behavioral change, though, because the generated change events differ. @nlisker I think I made all modifications requested, is there anything else that should be done here? Do you want the sort changes to be made or an issue be filed for it? ------------- PR: https://git.openjdk.org/jfx/pull/972 From john.hendrikx at gmail.com Sun Feb 5 09:45:59 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 5 Feb 2023 10:45:59 +0100 Subject: Feedback requested for infrastructure for properties that wish to delay registering listeners In-Reply-To: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com> References: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com> Message-ID: Any comments on this? I think having API to make it easier for both JavaFX and users to create listeners that can delay registration to their own dependencies. This would be an alternative to using weak listeners for these cases. --John On 19/01/2023 16:49, John Hendrikx wrote: > Hi list, > > I've been looking into what it would take to make the design of > properties which only register listeners when needed easier to > implement with JavaFX, both for JavaFX itself as well as for the > user.? This is the result of my investigation into ListProperty (and > other collection properties) and how hard it would be to change their > semantics to only register listeners when they're absolutely required > for the correct functioning of the class. > > Currently, JavaFX doesn't offer the tools one would need to register > listeners in a just-in-time fashion.? This is because there is no > notification mechanism available in its observable values when they > become observed or unobserved. The closest thing there currently > exists is what ObjectBinding and LazyObjectBinding offer: > > From ObjectBinding: > > ??? /** > ???? * Checks if the binding has at least one listener registered on > it. This > ???? * is useful for subclasses which want to conserve resources when > not observed. > ???? * > ???? * @return {@code true} if this binding currently has one or more > ???? *???? listeners registered on it, otherwise {@code false} > ???? * @since 19 > ???? */ > ??? protected final boolean isObserved() { > ??????? return helper != null; > ??? } > > From LazyObjectBinding: > > ??? /** > ???? * Called after a listener was added to start observing inputs if > they're not observed already. > ???? */ > ??? private void updateSubscriptionAfterAdd() { ... } > > ??? /** > ???? * Called after a listener was removed to stop observing inputs if > this was the last listener > ???? * observing this binding. > ???? */ > ??? private void updateSubscriptionAfterRemove() { ... } > > I'm proposing to extend the JavaFX with new methods that can be used > to stay informed about the observable's current observed status. These > methods will facilitate implementations of properties that wish to > delay registering listeners until they are themselves observed. This > can save memory, save unnecessary notifications via events and reduces > the need for weak listener constructs. > > The proposal does not require any new fields, and would default to > reporting observable values as being observed. Most JavaFX observable > values should be retrofitted to support this functionality -- the ones > relying on a form of ExpressionHelper will only require minimal > changes with minimal impact. > > The methods that I would like to see added are the following: > > In ObservableValue: > > ??? /** > ???? * Checks if this ObservableValue is currently observed. If > unknown or unsupported, > ???? * {@code true} is returned. > ???? * > ???? * @return {@code true} if this ObservableValue currently has one > or more > ???? *???? listeners registered on it, otherwise {@code false} > ???? */ > ??? default boolean isObserved() { return true; } > > The above method is useful for debugging, but its primary use is for > complex properties which observed status is determined by not only its > direct listeners but also any child properties it may offer.? > ListProperty is such an example, which offers child properties size > and empty. Its observed status would be determined like this: > > ???? helper != null || (size0 != null && size0.isObserved()) || > (empty0 != null && empty0.isObserved()) > > Further, we need two protected callback methods.? These should be > added in all Binding and Property Base classes (basically all classes > that implement addListener/removeListener methods). These are called > when the observed status of the property changes: > > ??? /** > ???? * Called when this property transitions from unobserved to observed. > ???? */ > ??? protected void observed() {} > > ??? /** > ???? * Called when this property transitions from observed to unobserved. > ???? */ > ??? protected void unobserved() {} > > These methods are implemented by child properties in order to inform > the parent that their observed status has changed, which may require > the parent property to change its status as well. > > When implemented, LazyObjectBinding can be simplified as some or all > of its functionality will be part of ObjectBinding (LazyObjectBinding > is not a public class at the moment).? The isObserved method in > ObjectBinding would go from protected to public (it's already final). > > Implementation for classes that rely on a form of ExpressionHelper is > simple; they can check if the helper is null or not (for isObserved) > and check if the nullity changed during addListener/removeListener > calls to make their call to "observed" or "unobserved".? No additional > fields are required. > > I've added a proof of concept here > (https://github.com/openjdk/jfx/pull/1004) where `ListPropertyBase` > was altered to use these new methods to delay its listener > registration and to remove its listener when no longer observed. This > PoC includes the tests written by Florian Kirmaier which fail on the > current ListProperty implementation (but pass with this version). > > --John > From duke at openjdk.org Sun Feb 5 10:46:57 2023 From: duke at openjdk.org (JoachimSchriek) Date: Sun, 5 Feb 2023 10:46:57 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v3] In-Reply-To: <_UsiRCTkRHY_72ZH0i7ihIAGr_ppJFscmWgF9iHYPOg=.6dd96ce4-fb28-4b80-bc14-9023c835c115@github.com> References: <_UsiRCTkRHY_72ZH0i7ihIAGr_ppJFscmWgF9iHYPOg=.6dd96ce4-fb28-4b80-bc14-9023c835c115@github.com> Message-ID: On Sat, 4 Feb 2023 15:16:28 GMT, Kevin Rushforth wrote: >> JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: >> >> Deleted trailing whitespace > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 135: > >> 133: /** >> 134: * JDK-8173321: Click on trough has no effect when cell height > viewport height: >> 135: * Solution: Scroll one cell further up resp. down if only one cell is shown. > > We generally do not refer to specific bug IDs in source code comments. Rather, describe the purpose of this block. Also, please spell out `resp.` -- I can't figure out what it is supposed to mean. I will change the comment in my next commit to: Scroll one cell further in the direction the user has clicked if only one cell is shown. Otherwise, a click on the trough would have no effect when cell height > viewport height. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 151: > >> 149: IndexedCell cell = firstVisibleCell; >> 150: if (cell == null) >> 151: return; > > Unless the if statement, including its target, is entirely on one line, you _must_ enclose the target of the `if` with curly braces, like this: > > > if (cell == null) { > return; > } > > > Since it fits on one line, the prior code is also acceptable: > > > if (cell == null) return; I will change this to the first alternative in my next commit. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 156: > >> 154: IndexedCell cell = lastVisibleCell; >> 155: if (cell == null) >> 156: return; > > Either revert this or enclose in curly braces. I will change this to the first alternative in my next commit. ------------- PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Sun Feb 5 11:29:57 2023 From: duke at openjdk.org (JoachimSchriek) Date: Sun, 5 Feb 2023 11:29:57 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v3] In-Reply-To: <_UsiRCTkRHY_72ZH0i7ihIAGr_ppJFscmWgF9iHYPOg=.6dd96ce4-fb28-4b80-bc14-9023c835c115@github.com> References: <_UsiRCTkRHY_72ZH0i7ihIAGr_ppJFscmWgF9iHYPOg=.6dd96ce4-fb28-4b80-bc14-9023c835c115@github.com> Message-ID: <5grrFz7SEleu_wH41pJOVf4-hpHgKHAMZrQOoxu2y94=.876215f3-17c2-4bd2-b778-79a01d1a0f5d@github.com> On Sat, 4 Feb 2023 15:27:13 GMT, Kevin Rushforth wrote: >> JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: >> >> Deleted trailing whitespace > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2611: > >> 2609: >> 2610: lengthBar.setMax(1); >> 2611: lengthBar.setVisibleAmount( numCellsVisibleOnScreen / (float) cellCount); > > I'm concerned with the change to no longer use the estimated size. This will produce very different results for tables with variable row hights. @johanvos will very likely want to comment on this. > > Also, The cast is unnecessary. > > Minor: remove the space after the `(` I am very sorry at this point. I have made a mistake here because my changes were based on the code I had seen in 2017 and reported in JDK-8173321. At that time, the size calculation of the ScrollBar was based on the integer value of numCellsVisibleOnScreen. I will revert the changes to VirtualFlow. ------------- PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Sun Feb 5 12:14:10 2023 From: duke at openjdk.org (JoachimSchriek) Date: Sun, 5 Feb 2023 12:14:10 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v4] In-Reply-To: References: Message-ID: > This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. > So please be patient with an absolute beginner as contributor ... . > The work of this pull request was fully done in my spare time. > > I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. > > The two changes address the two problems mentioned in JDK-8173321: > - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height > - The ScrollBar ist displayed with a minimal height. > > The changes were tested and ran well with Java 17 and the current master branch of openjfx. JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: Changes made following findings from review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/985/files - new: https://git.openjdk.org/jfx/pull/985/files/7ad99bde..c35424d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=02-03 Stats: 83 lines in 3 files changed: 39 ins; 23 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/985.diff Fetch: git fetch https://git.openjdk.org/jfx pull/985/head:pull/985 PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Sun Feb 5 12:22:19 2023 From: duke at openjdk.org (JoachimSchriek) Date: Sun, 5 Feb 2023 12:22:19 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v5] In-Reply-To: References: Message-ID: > This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. > So please be patient with an absolute beginner as contributor ... . > The work of this pull request was fully done in my spare time. > > I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. > > The two changes address the two problems mentioned in JDK-8173321: > - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height > - The ScrollBar ist displayed with a minimal height. > > The changes were tested and ran well with Java 17 and the current master branch of openjfx. JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: Delete VirtualFlow.java Revert unintentional changes to VirtualFlow ------------- Changes: - all: https://git.openjdk.org/jfx/pull/985/files - new: https://git.openjdk.org/jfx/pull/985/files/c35424d3..e7e9bc99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=03-04 Stats: 3392 lines in 1 file changed: 0 ins; 3392 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/985.diff Fetch: git fetch https://git.openjdk.org/jfx pull/985/head:pull/985 PR: https://git.openjdk.org/jfx/pull/985 From nlisker at openjdk.org Sun Feb 5 17:09:02 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 5 Feb 2023 17:09:02 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:42:05 GMT, John Hendrikx wrote: >> This contains the following: >> - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes >> - This fixes odd change events being produced (with incorrect oldValue) >> - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call >> - A test for ExpressionHelper to verify the new behavior >> - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level). >> - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/delayed-nested-emission > - Delay nested event emission The fix for the bug with nested events releasing the lock seems fine. I'm still not sure if the behavioral change is what we want the result to be even if it's better than what we have now. I have mentioned this in https://github.com/openjdk/jfx/pull/108#issuecomment-590878643. we need to decide on a spec first, and there are several facets to it as discussed in the mailing list link above (https://github.com/openjdk/jfx/pull/837#pullrequestreview-1233910264). I will re-summarize what I think needs to be defined before implementing a behavior change like the one proposed here: ### Listener order When listeners are registered, they are added to some collection (an array, currently). The add/remove methods hint at an order, but don't guarantee one. Do we specify an order, or say it's unspecified? ### Event dispatch order The order in which listeners are triggered is not necessarily the order of the listeners above. Do we specify a dispatch order, or say it's unspecified? If it's specified, the listener order is probably also specified. We are also dispatching invalidation events before change events arbitrarily. Do we dispatch the event to all listeners of one type and then to the other, or do we want to combine them according to a joint dispatch order? We either say that they are dispatched separately, together in some order (like registration), or that it's unspecified. ### Nested listener modifications If a listener is added/removed during an event dispatch, do we specify it will affect ("be in time for") the nested event chain, the outer event chain, or that it's unspecified? ### Nested value modifications If a listener changes the value of its property during an event dispatch, do we specify that the new event will trigger first, halting the current event dispatch (depth-first approach), or that the new event waits until current one finishes (breadth-first approach), or that it is unspecified? Do we guarantee that when a listener is invoked it sees the new value that was set by the latest nested change, or will it see the value that existed at trigger time, or is it unspecified? If listeners affect each other with nested events, then the dispatch order matters. --- If we answer "unspecified" to the questions above, it allows us more implementation freedom. It will also mean that listeners should be thought of as "lone wolves" - they are not intended to talk to each other or depend on each other; each should do something regardless of what the others are doing and assume its code "territory" is not affected by other listeners. The user takes responsibility for coupling them (nested modifications). On the other hand, no guarantees bring limited usage. The question is, what is the intended usage? ------------- PR: https://git.openjdk.org/jfx/pull/837 From nlisker at openjdk.org Sun Feb 5 18:59:01 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 5 Feb 2023 18:59:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:42:05 GMT, John Hendrikx wrote: >> This contains the following: >> - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes >> - This fixes odd change events being produced (with incorrect oldValue) >> - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call >> - A test for ExpressionHelper to verify the new behavior >> - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level). >> - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/delayed-nested-emission > - Delay nested event emission modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 1: > 1: package test.javafx.beans; You will need to add a license header for a new file. ------------- PR: https://git.openjdk.org/jfx/pull/837 From nlisker at openjdk.org Sun Feb 5 19:12:57 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 5 Feb 2023 19:12:57 GMT Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings and collections packages [v2] In-Reply-To: References: Message-ID: On Sun, 1 Jan 2023 16:08:15 GMT, John Hendrikx wrote: >> Packages fixed: >> - com.sun.javafx.binding >> - com.sun.javafx.collections >> - javafx.beans >> - javafx.beans.binding >> - javafx.collections >> - javafx.collections.transformation > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Clean up expression classes repeated null checks > - Use instanceof with pattern matching in a few spots I looked at it again. I think it would be best to do the sorting-related changes separately. The rest looks good. ------------- PR: https://git.openjdk.org/jfx/pull/972 From jhendrikx at openjdk.org Sun Feb 5 20:13:59 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 5 Feb 2023 20:13:59 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:42:05 GMT, John Hendrikx wrote: >> This contains the following: >> - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes >> - This fixes odd change events being produced (with incorrect oldValue) >> - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call >> - A test for ExpressionHelper to verify the new behavior >> - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level). >> - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/delayed-nested-emission > - Delay nested event emission > The fix for the bug with nested events releasing the lock seems fine. I'm still not sure if the behavioral change is what we want the result to be even if it's better than what we have now. I have mentioned this in [#108 (comment)](https://github.com/openjdk/jfx/pull/108#issuecomment-590878643). we need to decide on a spec first, and there are several facets to it as discussed in the mailing list link above ([#837 (review)](https://github.com/openjdk/jfx/pull/837#pullrequestreview-1233910264)). Is there any doubt as to what the old value should be? I think this is a bug fix only, and although I think it is good to discuss the whole listener system, I think we shouldn't delay this fix too much. After all, it is a very common pattern to use the old value for unregistering listeners when listening to a property chain (like node -> scene), and if the "old property" is ever incorrect, then the `removeListener` call will silently fail (shame we can't change that any more). > I will re-summarize what I think needs to be defined before implementing a behavior change like the one proposed here: I don't think this is a behavior change, it is a bug fix, unless we document that `ChangeListener` old value is a "best effort value" that cannot be trusted to contain anything useful when nested changes occur. Nested changes can easily occur in the huge web of properties that are sometimes woven (take the layout code for example). > ### Listener order > When listeners are registered, they are added to some collection (an array, currently). The add/remove methods hint at an order, but don't guarantee one. Do we specify an order, or say it's unspecified? I think it is too late to change anything significant here. Also the primary reason we've been pushing for a change here is I think the poor (remove) performance when there are many listeners. However, I think having many listeners on a single property is always an unwanted situation. The remove performance is simply the first problem you'll encounter. The next problem you'll encounter is when 10.000+ listeners need to be notified of a change... it will quickly become unworkable. Furthermore, there are data structures that have `O(1)` add(end) + remove(T) performance and `O(n)` iterate performance, while still being sequential and allowing duplicates. The remove "problem" could be solved that way without breaking existing code, but that will not speed up notification (which will be your next problem). I've mostly abandoned fixes in this area as I think it is **never** a good idea to have so many listeners that remove performance becomes an issue. So, if it were up to me, and I'm pretty convinced this is going to break quite some code out there, I'd say it should be: - listeners are called in the order they're registered - duplicates are allowed - removing a listener removes the first instance of that listener (not the last or a random one) Since there are data structures that can handle the requirements we need (we only need add-at-end, remove(T) and iteration) I think we're not locking ourselves into too much problems (the cost of such a data structure is slower get(index) and remove(index) performance, but we don't need these). > ### Event dispatch order > The order in which listeners are triggered is not necessarily the order of the listeners above. Do we specify a dispatch order, or say it's unspecified? If it's specified, the listener order is probably also specified. I'll consider this the same problem, with the same risks, see above. > We are also dispatching invalidation events before change events arbitrarily. Do we dispatch the event to all listeners of one type and then to the other, or do we want to combine them according to a joint dispatch order? We either say that they are dispatched separately, together in some order (like registration), or that it's unspecified. I think there may be good reasons to do invalidation first, but we don't need to specify it. An experiment where these orders are changed and running all the tests probably can give some insights here. Either leave unspecified or specify as it works currently as. I think here it is less likely things will break though. > ### Nested listener modifications > If a listener is added/removed during an event dispatch, do we specify it will affect ("be in time for") the nested event chain, the outer event chain, or that it's unspecified? > > ### Nested value modifications > If a listener changes the value of its property during an event dispatch, do we specify that the new event will trigger first, halting the current event dispatch (depth-first approach), or that the new event waits until current one finishes (breadth-first approach), or that it is unspecified? Do we guarantee that when a listener is invoked it sees the new value that was set by the latest nested change, or will it see the value that existed at trigger time, or is it unspecified? I don't think we should care about depth-first, breadth-first. The only thing that I think is important here is that the contract of `ChangeListener` is respected. I think that that contract should be: - `oldValue` and `newValue` should always be different values - a subsequent notification should have `newValue` as `oldValue` as that's almost a requirement to do anything sensible with `oldValue`, and also implied (it is the old value, aka. the previous value, the value that this property held since its last change) So when I change something form A to B, and a nested listener changes it from B to C, then any of these change events are fine: - A -> B + B -> C - A -> C But not: - A -> B + A -> C [listener not unregistered on B] - A -> B + C -> C [listener not unregistered on B] - A -> C + B -> C [listener registered twice on C] > If listeners affect each other with nested events, then the dispatch order matters. > > If we answer "unspecified" to the questions above, it allows us more implementation freedom. It will also mean that listeners should be thought of as "lone wolves" - they are not intended to talk to each other or depend on each other; each should do something regardless of what the others are doing and assume its code "territory" is not affected by other listeners. The user takes responsibility for coupling them (nested modifications). On the other hand, no guarantees bring limited usage. The question is, what is the intended usage? This PR does not make listeners more/less dependent than they are. It fixes one major bug that can cause `ConcurrentModificationException` and it ensures a useful old value in the face of nested changes. Since we probably can't disallow duplicate listeners at this stage, any new implementation needs to support this. This makes simple map based solutions a lot trickier (they'd need a counter). We'd also be going against years of standard practices for UI frameworks that work with listeners and which are using the add/remove pattern (Swing, AWT). They all are ordered and allow duplicates. I think that at this stage, it would be best to document it as it works currently, leaving maybe a few small areas unspecified still. Any performance problems can be tackled within these restrictions. It is certainly possible to make a structure that has all of these qualities: - sequential - allows duplicates - fast add-at-end - fast remove(T), removing the first match - fast iteration - low memory use (no wrapper needed per listener), although you'll never beat `ArrayList` - no need for copying Again though, not sure what problem that will solve exactly... 10.000 listeners on a single property is going to perform badly no matter what you do. ------------- PR: https://git.openjdk.org/jfx/pull/837 From michaelstrau2 at gmail.com Mon Feb 6 05:00:06 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 6 Feb 2023 06:00:06 +0100 Subject: Feedback requested for infrastructure for properties that wish to delay registering listeners In-Reply-To: References: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com> Message-ID: I like your proposal in general, since it may result in a performance improvement in some cases. If we can avoid to eagerly registering listeners that aren't needed, that's great. However, it is not an alternative to using weak listeners. Consider the following test, which is taken from Florian's PR (https://github.com/openjdk/jfx/pull/689): @Test public void testListPropertyLeak2() { JMemoryBuddy.memoryTest(checker -> { ObservableList list = FXCollections.observableArrayList(); ListProperty listProperty = new SimpleListProperty<>(list); checker.setAsReferenced(list); checker.assertCollectable(listProperty); }); } This test only passes with your PR because `listProperty` doesn't register a listener on `list` (that's what you are proposing, after all). As soon as you do that, for example by adding the following line, the test fails: listProperty.addListener((ListChangeListener) change -> {}); But the test shouldn't ever fail, because the ObservableList that is wrapped by ListProperty should never keep a strong reference to the ListProperty, even if the ListProperty is itself observed. That's a bug in the current implementation, and hiding it by making it contingent upon the presence of observers doesn't fix the underlying issue. On Sun, Feb 5, 2023 at 10:46 AM John Hendrikx wrote: > > Any comments on this? > > I think having API to make it easier for both JavaFX and users to create > listeners that can delay registration to their own dependencies. This > would be an alternative to using weak listeners for these cases. > > --John From aghaisas at openjdk.org Mon Feb 6 06:30:57 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 6 Feb 2023 06:30:57 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: References: Message-ID: On Wed, 1 Feb 2023 06:37:21 GMT, Karthik P K wrote: >> In `selectIndices` method, zero length array is not considered while ignoring row number given as parameter. >> >> Updated the code to consider both null and zero length array in the condition before ignoring the row value given as parameter. >> >> Added unit test to validate the fix > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix first index selection issue in TreeTableView Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/1018 From john.hendrikx at gmail.com Mon Feb 6 06:39:32 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 6 Feb 2023 07:39:32 +0100 Subject: Feedback requested for infrastructure for properties that wish to delay registering listeners In-Reply-To: References: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com> Message-ID: On 06/02/2023 06:00, Michael Strau? wrote: > I like your proposal in general, since it may result in a performance > improvement in some cases. If we can avoid to eagerly registering > listeners that aren't needed, that's great. Thanks. It would probably simplify some cases that now require custom property implementations. > However, it is not an alternative to using weak listeners. Consider > the following test, which is taken from Florian's PR > (https://github.com/openjdk/jfx/pull/689): > > @Test > public void testListPropertyLeak2() { > JMemoryBuddy.memoryTest(checker -> { > ObservableList list = FXCollections.observableArrayList(); > ListProperty listProperty = new SimpleListProperty<>(list); > > checker.setAsReferenced(list); > checker.assertCollectable(listProperty); > }); > } > > This test only passes with your PR because `listProperty` doesn't > register a listener on `list` (that's what you are proposing, after > all). Yes, when creating a new instance of something (in this case `SimpleListProperty`) there shouldn't be any weird side effects. Registering a listener to something else in the constructor is passing on a reference to the instance (SimpleListProperty) before it is fully constructed, which is a bad practice.? Because it is bad practice, it is very rare to see an object creation have side effects, like it being registered somewhere, that would block its immediate garbage collection. A call to `new` without an assignment to a variable, will in almost all cases result in that object being immediately eligible for GC. This is what users expect, the only one that has a reference to the object resulting from a `new` operator is the caller.? The cases where this doesn't happen are likely bugs or not idiomatic Java.? This escapes are problematic for various reasons (see recent discussions in amber-dev and the new this-escape warning).? In the strictly threaded environment of JavaFX you can get away with it usually, but not always.? It is still a huge surprise for users that expect the `new` operator to be side effect free. This is why I applaud the effort which we're doing for Skins at the moment, moving all listener registration to the `install` method, preventing the instance from escaping before it is fully constructed.? It means that just constructing the Skin does not tie it to a control already.? Similarly, just constructing a ListProperty should not tie it to an ObservableList; it doesn't matter if that tie is strong or weak. > As soon as you do that, for example by adding the following line, the > test fails: > > listProperty.addListener((ListChangeListener) change -> {}); > > But the test shouldn't ever fail, because the ObservableList that is > wrapped by ListProperty should never keep a strong reference to the > ListProperty, even if the ListProperty is itself observed. Why should it work that way?? The alternative is that my listener is discarded without my knowledge.? There is no warning in my IDE, in my logs, or anywhere.? It just seems to work, and then breaks at some point in the future. The fact that it seems to work, but then doesn't is a huge problem for debugging, testing and reproducing user problems. That last one is nasty, because it may work on my machine; when weak references get cleared can depend on JVM used, JVM parameters, memory available, hardware platform, etc.. -- they're fine for low level work like caching, but using them in a high level mechanism like a UI is making JavaFX far more complex than it should be. > That's a bug in the current implementation, and hiding it by making it > contingent upon the presence of observers doesn't fix the underlying > issue. I don't think it's a bug.? I took an action to register a listener.? It is on me to take action to unregister it.? And until that time it should keep working. I mean, what if Java were to decide that a `Thread` which I started is not doing relevant work because it determined that the objects the thread is using are not referenced by any other threads?? Should it be allowed to kill this `Thread`? And if that's allowed, should it do this silently without warning? What if I added an important listener like this: permissionsListProperty.addListener(AuditingService::auditLogPermissionChanges); Do you think JavaFX should decide that this is not relevant because only the property still has a reference to this listener, but nothing else has? Also, do you think it should keep working until a garbage collection occurs, but then stop working after one occurs?? When will that be? I feel there is fundamental misunderstanding of how listeners are normally working in Java. JavaFX is the only system that decides that a listener is irrelevant based on how it is being referenced.? Nothing else does this.? Beans don't do this (PropertyChangeListener), other UI frameworks don't do this (Swing, AWT, SWT), event frameworks I worked with don't -- in fact, I can't think of a single example that does listener management the way JavaFX does. I'm trying to get JavaFX to a state where it is more predictable, and for this certain tools are needed.? ObservableValue#when was one of those, it allows users to do their listener management upfront (no need to save a reference to the listener for later removal). Subscriptions are another useful tool so you don't have to save the lambda or method reference for later removal: ?????? Subscription combinedSubscription = ????????????? propertyA.subscribe(xyz) ????????????????? .and(propertyB.subscribe(abc)); ?????? // dispose of all listeneres with one line: ?????? combinedSubscription.unsubscribe(); Method references are not unique (or don't have to be) so doing "property.removeListener(this::myMethod)" will not do anything (and removeListener will silently ignore listeners it doesn't know about making this problem worse).? Subscriptions solve this problem. These (and other patterns) are currently hand rolled by many -- many however simply get it wrong, from which many "memory leak", "unpredictable" or "bug" complaints arise. ObservableValue#when addresses many of these already, and exposing Subscriptions is useful as they're a bit lighter (I think it would be useful for Skins, although you could use `when` if you're careful). Note that weak listeners don't solve the problem adequately because the pattern breaks when the involved property has a different life cycle than its listener.? Weak listeners promise (or seem to promise) that manual removal of listeners is never needed, but nothing is further from the truth.? Since manual removal is still required, even with weak listeners, investing in API and patterns that make this burden easier and less error prone is a good thing. With this proposal I'm trying to help property implementators to not hold onto resources when they're not needed.? The idea here being that you can override observed/unobserved to register/unregister listeners when there's an actual need.? It's also constructed in such a way that it is easy to do this for sub properties. For example, if you have the subproperties "size" and "empty", then you can register listeners by having all of these sub properties forward to a general "observed" method: ????? private void subPropertyWasObserved() { ???????????? if (!isAnySubPropertyObserved()) { ????????????????? // register listeners ???????????? } ????? } ????? // reusable helper to determine observation state: ????? private boolean isAnySubPropertyObserved() { ???????????? return size.isObserved() || empty.isObserved(); ????? } And it's counter part: ????? private void subPropertyWasUnobserved() { ???????????? if (!isAnySubPropertyObserved()) { ????????????????? // unregister listeners ???????????? } ????? } The observed/unobserved calls happen just before the first registration and just after the last unregistration, making this a very simple pattern to use when multiple properties are involved. --John > > > On Sun, Feb 5, 2023 at 10:46 AM John Hendrikx wrote: >> Any comments on this? >> >> I think having API to make it easier for both JavaFX and users to create >> listeners that can delay registration to their own dependencies. This >> would be an alternative to using weak listeners for these cases. >> >> --John From kpk at openjdk.org Mon Feb 6 06:42:56 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 6 Feb 2023 06:42:56 GMT Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 [v2] In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 06:28:39 GMT, Ajit Ghaisas wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix first index selection issue in TreeTableView > > Looks good to me. @aghaisas please sponsor this PR. ------------- PR: https://git.openjdk.org/jfx/pull/1018 From kpk at openjdk.org Mon Feb 6 08:28:05 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 6 Feb 2023 08:28:05 GMT Subject: Integrated: 8138842: TableViewSelectionModel.selectIndices does not select index 0 In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 14:40:00 GMT, Karthik P K wrote: > In `selectIndices` method, zero length array is not considered while ignoring row number given as parameter. > > Updated the code to consider both null and zero length array in the condition before ignoring the row value given as parameter. > > Added unit test to validate the fix This pull request has now been integrated. Changeset: ef9f0664 Author: Karthik P K Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/ef9f0664484f7a3c2a9ebfbd81e1d23ef65218ed Stats: 37 lines in 4 files changed: 35 ins; 0 del; 2 mod 8138842: TableViewSelectionModel.selectIndices does not select index 0 Reviewed-by: angorya, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1018 From aghaisas at openjdk.org Mon Feb 6 08:35:58 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 6 Feb 2023 08:35:58 GMT Subject: [jfx20] RFR: 8301797: Pagination control has the wrong size [v2] In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 23:09:30 GMT, Andy Goryachev wrote: >> Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. >> >> The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). >> >> Added a test case. >> >> Tested with the PaginationDisappear.java and the LeakTest app >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8301797: review comments The simplified fix looks good to me! Thanks for fixing this regression. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/1021 From aghaisas at openjdk.org Mon Feb 6 08:50:00 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 6 Feb 2023 08:50:00 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v5] In-Reply-To: References: Message-ID: On Sun, 5 Feb 2023 12:22:19 GMT, JoachimSchriek wrote: >> This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. >> So please be patient with an absolute beginner as contributor ... . >> The work of this pull request was fully done in my spare time. >> >> I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. >> >> The two changes address the two problems mentioned in JDK-8173321: >> - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height >> - The ScrollBar ist displayed with a minimal height. >> >> The changes were tested and ran well with Java 17 and the current master branch of openjfx. > > JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: > > Delete VirtualFlow.java > > Revert unintentional changes to VirtualFlow In your last commit- instead of only reverting your changes to the file`VirtualFlow.java`, you have deleted the entire file itself. Please restore this file. ------------- PR: https://git.openjdk.org/jfx/pull/985 From kpk at openjdk.org Mon Feb 6 13:33:20 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 6 Feb 2023 13:33:20 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v3] In-Reply-To: References: Message-ID: > Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. > > Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. > > Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Code optimization ------------- Changes: - all: https://git.openjdk.org/jfx/pull/996/files - new: https://git.openjdk.org/jfx/pull/996/files/c2a2afa6..1d20f756 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=01-02 Stats: 55 lines in 1 file changed: 21 ins; 23 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/996.diff Fetch: git fetch https://git.openjdk.org/jfx pull/996/head:pull/996 PR: https://git.openjdk.org/jfx/pull/996 From kcr at openjdk.org Mon Feb 6 13:40:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Feb 2023 13:40:59 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v2] In-Reply-To: References: Message-ID: On Sun, 22 Jan 2023 15:19:48 GMT, JoachimSchriek wrote: >> JoachimSchriek has updated the pull request incrementally with one additional commit since the last revision: >> >> Committed Test Case for [openjdk/jfx] 8173321: Click on trough has no >> effect when cell height > viewport (PR #985): > > It was not feasible for me -at least as i saw it- to integrate the tests in the existing tests without using a robot because I think the behavior reported in the bug report mostly relates to the reaction of the UI to mouse clicks. @JoachimSchriek In addition to restoring the mistakenly-deleted file, I noticed that you don't have GitHub actions enabled (else you would have discovered this problem right away). Also, your branch is fairly out of date with respect to the upstream master. To that end, I recommend doing the following: 1. Merge the latest upstream master into your branch 2. Enable GitHub actions in your repo (follow the instructions listed above in the details of "Pre-submit test status Skipped ? Testing is not configured" -- the short version is that you need to click the big green button in the "Actions" tab of your repo) 3. Restore VirtualFlow.java such that it is identical to the upstream master. ------------- PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Mon Feb 6 13:59:13 2023 From: duke at openjdk.org (JoachimSchriek) Date: Mon, 6 Feb 2023 13:59:13 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v6] In-Reply-To: References: Message-ID: > This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. > So please be patient with an absolute beginner as contributor ... . > The work of this pull request was fully done in my spare time. > > I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. > > The two changes address the two problems mentioned in JDK-8173321: > - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height > - The ScrollBar ist displayed with a minimal height. > > The changes were tested and ran well with Java 17 and the current master branch of openjfx. JoachimSchriek has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Restore original VirtualFlow.java ------------- Changes: - all: https://git.openjdk.org/jfx/pull/985/files - new: https://git.openjdk.org/jfx/pull/985/files/e7e9bc99..a316200e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=04-05 Stats: 3396 lines in 1 file changed: 3396 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/985.diff Fetch: git fetch https://git.openjdk.org/jfx pull/985/head:pull/985 PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Mon Feb 6 14:15:17 2023 From: duke at openjdk.org (JoachimSchriek) Date: Mon, 6 Feb 2023 14:15:17 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v7] In-Reply-To: References: Message-ID: > This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. > So please be patient with an absolute beginner as contributor ... . > The work of this pull request was fully done in my spare time. > > I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. > > The two changes address the two problems mentioned in JDK-8173321: > - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height > - The ScrollBar ist displayed with a minimal height. > > The changes were tested and ran well with Java 17 and the current master branch of openjfx. JoachimSchriek 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: - Merge branch 'openjdk:master' into master - Restore original VirtualFlow.java - Changes made following findings from review - Deleted trailing whitespace - Committed Test Case for [openjdk/jfx] 8173321: Click on trough has no effect when cell height > viewport (PR #985): - Replaces Tabs with Spaces - JDK-8173321: Click on trough has no effect when cell height > viewport height ------------- Changes: - all: https://git.openjdk.org/jfx/pull/985/files - new: https://git.openjdk.org/jfx/pull/985/files/a316200e..62606f41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=05-06 Stats: 202484 lines in 5685 files changed: 120624 ins; 43383 del; 38477 mod Patch: https://git.openjdk.org/jfx/pull/985.diff Fetch: git fetch https://git.openjdk.org/jfx pull/985/head:pull/985 PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Mon Feb 6 14:15:21 2023 From: duke at openjdk.org (JoachimSchriek) Date: Mon, 6 Feb 2023 14:15:21 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v6] In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 13:59:13 GMT, JoachimSchriek wrote: >> This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. >> So please be patient with an absolute beginner as contributor ... . >> The work of this pull request was fully done in my spare time. >> >> I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. >> >> The two changes address the two problems mentioned in JDK-8173321: >> - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height >> - The ScrollBar ist displayed with a minimal height. >> >> The changes were tested and ran well with Java 17 and the current master branch of openjfx. > > JoachimSchriek has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Restore original VirtualFlow.java @ kevinrushforth I will need some time to correct the state of VirtualFlow.java. I will leave a notice when it is ready. ------------- PR: https://git.openjdk.org/jfx/pull/985 From duke at openjdk.org Mon Feb 6 14:23:10 2023 From: duke at openjdk.org (JoachimSchriek) Date: Mon, 6 Feb 2023 14:23:10 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v2] In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 13:38:21 GMT, Kevin Rushforth wrote: >> It was not feasible for me -at least as i saw it- to integrate the tests in the existing tests without using a robot because I think the behavior reported in the bug report mostly relates to the reaction of the UI to mouse clicks. > > @JoachimSchriek In addition to restoring the mistakenly-deleted file, I noticed that you don't have GitHub actions enabled (else you would have discovered this problem right away). Also, your branch is fairly out of date with respect to the upstream master. > > To that end, I recommend doing the following: > > 1. Merge the latest upstream master into your branch > 2. Enable GitHub actions in your repo (follow the instructions listed above in the details of "Pre-submit test status Skipped ? Testing is not configured" -- the short version is that you need to click the big green button in the "Actions" tab of your repo) > 3. Restore VirtualFlow.java such that it is identical to the upstream master. @kevinrushforth the merge did the work. Now, there are only the two files that should be changed. ------------- PR: https://git.openjdk.org/jfx/pull/985 From kpk at openjdk.org Mon Feb 6 14:26:15 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 6 Feb 2023 14:26:15 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v2] In-Reply-To: References: <_pKKZHdjgIxQgH-GNcUj6kZuRwGRpZ8PNmH2TBr3org=.6d0eca9f-8331-4b60-aa6e-bdd4a74b0643@github.com> Message-ID: On Fri, 3 Feb 2023 18:04:09 GMT, Andy Goryachev wrote: >> Not sure if I didn't understand your comments properly but I'm guessing you are referring to `textHeight` and `graphicHeight` calculation in line 375 and 380 because the line numbers you mentioned are in `computePrefWidth` method and changes are made to height calculation in `computePrefHeight` only. >> Since `textHeight` and `graphicHeight` each are used in 3 conditions from line no 386 to 394 I have kept the calculation in the beginning itself. >> >> On the other hand `textWidth` declared in line 368 might change in line 371, so I can't use `width` directly instead of defining `textWidth` as `width` need to be used while calling other graphic related methods. > > Both `computePrefHeight()` and `computePrefWidth` can be restructured to avoid unnecessary computation (especially since these are very popular objects). > > My point is that, for example, textWidth on line 375 (used to compute textHeight:375) is not used if isIgnoreText() == true. > > Similarly, graphicHeight:380 is not used if isIgnoreGraphic() == true, line 386. > > Same optimization can be applied to computePrefWidth():315 > > Just a suggestion, really. Understood. I have optimized the code. Please take a look. Did following optimizations in the code: - Optimized `if else` conditions by moving the `graphicHeight` and `graphicWidth` value calculation inside the else statement in `computePrefHeight` and `computePrefWidth` methods respectively. - Removed unused `graphic` variable. - In `computePrefHeight` method, since a `if` condition was already present which was same as the one used for `padding` calculation, moved `padding` calculation code to the same location. - In `computePrefWidth` method, replaced multiple return statements with single statement for better readability and did minor optimizations. ------------- PR: https://git.openjdk.org/jfx/pull/996 From angorya at openjdk.org Mon Feb 6 16:19:00 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Feb 2023 16:19:00 GMT Subject: [jfx20] Integrated: 8301797: Pagination control has the wrong size In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 20:15:46 GMT, Andy Goryachev wrote: > Fixed regression introduced by JDK-8295754, targeting upstream **jfx20 branch**. > > The method PaginationSkin.resetIndexes(true) has been moved to the original position in the constructor, fixing the initialization, while making sure no properties of the control are touched in the constructor (only in install()). > > Added a test case. > > Tested with the PaginationDisappear.java and the LeakTest app > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTestApp.java This pull request has now been integrated. Changeset: 192ba4fc Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/192ba4fc71b585d9ff5a81c75499187944f548dc Stats: 25 lines in 2 files changed: 22 ins; 1 del; 2 mod 8301797: Pagination control has the wrong size Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1021 From angorya at openjdk.org Mon Feb 6 19:07:40 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Feb 2023 19:07:40 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls Message-ID: A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877). For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242. The fix involves changing the code back to setting the control properties and doing so in the install() method. Thank you Martin Fox (@beldenfox ?) for noticing the issue! ------------- Commit messages: - 8301832: InputMethodEvents are not enabled for text input controls Changes: https://git.openjdk.org/jfx/pull/1024/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301832 Stats: 14 lines in 1 file changed: 10 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1024.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1024/head:pull/1024 PR: https://git.openjdk.org/jfx/pull/1024 From kcr at openjdk.org Mon Feb 6 19:28:01 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Feb 2023 19:28:01 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 18:45:10 GMT, Andy Goryachev wrote: > **Targeting jfx20 branch** > > A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877). > > For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242. > > The fix involves changing the code back to setting the control properties and doing so in the install() method. > > Thank you Martin Fox for noticing the issue! Note that this will need approval (in JBS) to go into jfx20. ------------- PR: https://git.openjdk.org/jfx/pull/1024 From kcr at openjdk.org Mon Feb 6 20:05:05 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Feb 2023 20:05:05 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 18:45:10 GMT, Andy Goryachev wrote: > **Targeting jfx20 branch** > > A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877). > > For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242. > > The fix involves changing the code back to setting the control properties and doing so in the install() method. > > Thank you Martin Fox for noticing the issue! Looks good. I confirm that this fixes the regression. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/1024 From nmrview at mac.com Mon Feb 6 21:17:27 2023 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 6 Feb 2023 16:17:27 -0500 Subject: Enhance javafx Canvas API In-Reply-To: References: Message-ID: > On Feb 3, 2023, at 5:31 PM, Laurent Bourg?s wrote: > > Hi, > > While working with skia & jfree's skijaGraphics2D wrapper, I observed skia offers nice methods in SkCanvas missing in javafx Canvas/GraphicsContext to deal with save/restore state: > > - int getSaveCount () > Returns the number of saved states, each containing: SkMatrix and clip. > > - void restoreToCount (int saveCount) > Restores state to SkMatrix and clip values when save(), returned saveCount. > > As javafx canvas also maintains s stack of saved states, such methods are trivial to implement to allow resetting completely the canvas state by restoreToCount(0). > > Moreover, clip(shape) + save/restore are really tricky to allows ensure clip is reset to previous state ... > > Would you agree to add such methods to have more predictive behaviour than counting all save() calls to ensure to call restore() the same number of times to reset the canvas to its initial state ? > > See SkijaGraphics2d implementation that saves / restore skCanvas clip using such index property: > https://github.com/jfree/skijagraphics2d/blob/main/src/main/java/org/jfree/skija/SkijaGraphics2D.java > > Cheers, > Laurent I?d love to see this. I find keeping track of the state of clipping and getting it restored to a specific state can be painful. Swing let you clear the clip with setClip(null) which was definitely useful and I was somewhat surprised to see that I couldn?t do that in JavaFX. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Mon Feb 6 22:59:59 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 6 Feb 2023 22:59:59 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v3] In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 13:33:20 GMT, Karthik P K wrote: >> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. >> >> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. >> >> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Code optimization Marked as reviewed by jhendrikx (Committer). modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 331: > 329: > 330: double width; > 331: if(isIgnoreGraphic()) { minor: missed a space here after `if` modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 393: > 391: if (isIgnoreText()) { > 392: height = graphicHeight; > 393: } else if (contentDisplay == TOP || contentDisplay == BOTTOM){ minor: missing space before `{` ------------- PR: https://git.openjdk.org/jfx/pull/996 From nlisker at openjdk.org Mon Feb 6 23:05:32 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 6 Feb 2023 23:05:32 GMT Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs Message-ID: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> Fixes and cleanup in the areas in the linked issue. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jfx/pull/1025/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293587 Stats: 50 lines in 6 files changed: 3 ins; 4 del; 43 mod Patch: https://git.openjdk.org/jfx/pull/1025.diff Fetch: git fetch https://git.openjdk.org/jfx pull/1025/head:pull/1025 PR: https://git.openjdk.org/jfx/pull/1025 From nlisker at openjdk.org Mon Feb 6 23:05:34 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 6 Feb 2023 23:05:34 GMT Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> Message-ID: On Mon, 6 Feb 2023 23:00:17 GMT, Nir Lisker wrote: > Fixes and cleanup in the areas in the linked issue. Integrating can wait until a bit before the release to allow for more mistakes to be included. ------------- PR: https://git.openjdk.org/jfx/pull/1025 From kpk at openjdk.org Tue Feb 7 05:25:08 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 Feb 2023 05:25:08 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v4] In-Reply-To: References: Message-ID: > Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. > > Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. > > Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/996/files - new: https://git.openjdk.org/jfx/pull/996/files/1d20f756..1b868a6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/996.diff Fetch: git fetch https://git.openjdk.org/jfx pull/996/head:pull/996 PR: https://git.openjdk.org/jfx/pull/996 From kpk at openjdk.org Tue Feb 7 05:25:10 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 Feb 2023 05:25:10 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v3] In-Reply-To: References: Message-ID: <_3Kc56QXjuk_upsAcCW6KulMYE52na_A-Igexa0Vgzk=.e2381d95-df39-4b86-a3c9-b071c8968c2c@github.com> On Mon, 6 Feb 2023 22:50:30 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Code optimization > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 331: > >> 329: >> 330: double width; >> 331: if(isIgnoreGraphic()) { > > minor: missed a space here after `if` Updated code. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 393: > >> 391: if (isIgnoreText()) { >> 392: height = graphicHeight; >> 393: } else if (contentDisplay == TOP || contentDisplay == BOTTOM){ > > minor: missing space before `{` Updated code. ------------- PR: https://git.openjdk.org/jfx/pull/996 From arapte at openjdk.org Tue Feb 7 08:58:04 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 7 Feb 2023 08:58:04 GMT Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v5] In-Reply-To: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> References: <3r3DlvN5m3qu0iW4ZzzSe2IpuoR1oVI3wmiCJDCzf8k=.98179692-eb48-4754-88be-49f3af83f7ca@github.com> Message-ID: On Fri, 3 Feb 2023 23:31:24 GMT, Michael Strau? wrote: >> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change. >> >> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > improved tests, changed foreach loop Looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/841 From aghaisas at openjdk.org Tue Feb 7 10:10:15 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 7 Feb 2023 10:10:15 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 18:45:10 GMT, Andy Goryachev wrote: > **Targeting jfx20 branch** > > A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877). > > For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242. > > The fix involves changing the code back to setting the control properties and doing so in the install() method. > > Thank you Martin Fox for noticing the issue! This fixes the regression. Can you add an unit or automated system test? ------------- PR: https://git.openjdk.org/jfx/pull/1024 From aghaisas at openjdk.org Tue Feb 7 11:54:57 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 7 Feb 2023 11:54:57 GMT Subject: RFR: 8290092: Temporary files are kept when call Clipboard.getSystemClipboard().getImage() [v2] In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 16:44:11 GMT, Lukasz Kostyra wrote: >> Windows implementation of GlassClipboard.cpp uses IStorage interface in `PopImage()` to allocate a temporary file, which is then used to capture Image data from system clipboard and move it to JVM side. In order for temporary file to be removed automatically on `IStorage::Release()`, `StgCreateDocfile` API requires passing STGM_DELETEONRELEASE flag - otherwise the file will be left behind when IStorage is released. Contents of temporary file are immediately copied to a JNI Byte Array after acquiring them from clibpoard, so it is safe to provide this flag and remove the file after `PopImage()` is done. >> >> Creating a unit test for this case would a bit difficult, as IStorage and its file are created with random temporary name each time, which we cannot easily access. On the other hand, just scouting the temp directory for any leftover .TMP files might prove false results, as other apps or even JFX itself might use IStorage temporary files for some other purposes than managing clipboard images. As such, because this is a simple API change, I did not make a test for this. >> >> Tested this change on Windows 10 and it doesn't break any existing tests. Calling `Clipboard.getSystemClipboard().getImage()` with an image stored inside the system clipboard now leaves no leftover files. > > Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: > > - ClipboardExtImageTest: Add missing copyright notice > - Add manual test to check for leftover Clipboard files On Windows - the test fails without the fix and passes with it. On Mac - (as expected) the test passes with or without fix. I have a minor comment on the test. Also, the PR should contain only 2 files - 1. Modified file - modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp 2. Newly added test file - tests/manual/clipboard/ClipboardExtImageTest.java Please remove all other files. They are not needed to be checked in. tests/manual/clipboard/ClipboardExtImageTest.java line 193: > 191: public void start(Stage primaryStage) throws Exception { > 192: try { > 193: /*if (!isWindows()) { This test can be only Windows specific. I would enable this check and get rid of `isWindows()` check everywhere. ------------- Changes requested by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/994 From kcr at openjdk.org Tue Feb 7 12:11:02 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Feb 2023 12:11:02 GMT Subject: RFR: 8173321: TableView: Click on right trough has no effect when cell height is higher than viewport height [v7] In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 14:15:17 GMT, JoachimSchriek wrote: >> This is my (Joachim.Schriek at gmx.de) first contribution to openjfx. My Contributor Agreement is signed but still in review. >> So please be patient with an absolute beginner as contributor ... . >> The work of this pull request was fully done in my spare time. >> >> I first filed the bug myself in 2017. I had begun working with JavaFX in 2014. >> >> The two changes address the two problems mentioned in JDK-8173321: >> - Using a JavaFX TableView, a click on the right trough has no effect when the cell height of the cell currently displayed is higher than viewport height >> - The ScrollBar ist displayed with a minimal height. >> >> The changes were tested and ran well with Java 17 and the current master branch of openjfx. > > JoachimSchriek 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: > > - Merge branch 'openjdk:master' into master > - Restore original VirtualFlow.java > - Changes made following findings from review > - Deleted trailing whitespace > - Committed Test Case for [openjdk/jfx] 8173321: Click on trough has no > effect when cell height > viewport (PR #985): > - Replaces Tabs with Spaces > - JDK-8173321: Click on trough has no effect when cell height > viewport > height Can you enable GitHub actions and then do a test run (either manually or by pushing an empty commit)? ------------- PR: https://git.openjdk.org/jfx/pull/985 From kcr at openjdk.org Tue Feb 7 12:14:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Feb 2023 12:14:52 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 18:45:10 GMT, Andy Goryachev wrote: > **Targeting jfx20 branch** > > A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877). > > For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242. > > The fix involves changing the code back to setting the control properties and doing so in the install() method. > > Thank you Martin Fox for noticing the issue! This is the same category of bug fix as many accessibility fixes, in that it requires entering a special mode on your computer to test it using an existing test program like `HelloTextArea`. For this reason, I added a `noreg-hard` keyword to the JBS bug. ------------- PR: https://git.openjdk.org/jfx/pull/1024 From aghaisas at openjdk.org Tue Feb 7 12:31:03 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 7 Feb 2023 12:31:03 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls In-Reply-To: References: Message-ID: On Tue, 7 Feb 2023 12:11:58 GMT, Kevin Rushforth wrote: > This is the same category of bug fix as many accessibility fixes, in that it requires entering a special mode on your computer to test it using an existing test program like `HelloTextArea`. For this reason, I added a `noreg-hard` keyword to the JBS bug. OK! ------------- PR: https://git.openjdk.org/jfx/pull/1024 From aghaisas at openjdk.org Tue Feb 7 12:31:01 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 7 Feb 2023 12:31:01 GMT Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text input controls In-Reply-To: References: Message-ID: On Mon, 6 Feb 2023 18:45:10 GMT, Andy Goryachev wrote: > **Targeting jfx20 branch** > > A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877). > > For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242. > > The fix involves changing the code back to setting the control properties and doing so in the install() method. > > Thank you Martin Fox for noticing the issue! Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/1024 From jhendrikx at openjdk.org Tue Feb 7 12:37:05 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 7 Feb 2023 12:37:05 GMT Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> Message-ID: On Mon, 6 Feb 2023 23:00:17 GMT, Nir Lisker wrote: > Fixes and cleanup in the areas in the linked issue. Looks good to me, I added some more minor suggestions as well. modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 467: > 465: /** > 466: * The {@code Node} to show to the user when the {@code ListView} has no content to show. > 467: * This happens when the table model has no data or when a filter has been applied to the list model, resulting in Suggestion: * This happens when the list model has no data or when a filter has been applied to the list model, resulting in modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 62: > 60: > 61: /** > 62: * A special layout designed to lay out rich text. What's "special" about it? :-) Suggestion: * A layout designed to lay out rich text. modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 81: > 79: * width in the {@code Text} node is ignored since the width used for wrapping > 80: * is the {@code TextFlow}'s width. The value of the {@code pickOnBounds} property > 81: * of a {@code Text} is set to {@code false} when it is laid out by the Suggestion: * of a {@code Text} node is set to {@code false} when it is laid out by the modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 83: > 81: * of a {@code Text} is set to {@code false} when it is laid out by the > 82: * {@code TextFlow}. This happens because the content of a single {@code Text} node can be > 83: * divided and placed in different locations in the {@code TextFlow} (usually due to Suggestion: * split and placed in different locations in the {@code TextFlow} (usually due to modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 90: > 88: * It can be specified by the application by setting the {@code TextFlow}'s preferred > 89: * width. If no wrapping is desired, the application can either set the preferred > 90: * with to {@code Double.MAX_VALUE} or {@code Region.USE_COMPUTED_SIZE}. Should these be links? They're the first mention in this doc. modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 133: > 131: * top/bottom insets plus the height of the text content > 132: * maximum > 133: * Double.MAX_VALUEDouble.MAX_VALUE Suggestion: * {@code Double.MAX_VALUE}{@code Double.MAX_VALUE} ------------- Marked as reviewed by jhendrikx (Committer). PR: https://git.openjdk.org/jfx/pull/1025 From jhendrikx at openjdk.org Tue Feb 7 12:43:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 7 Feb 2023 12:43:03 GMT Subject: RFR: 8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY [v4] In-Reply-To: References: Message-ID: On Tue, 7 Feb 2023 05:25:08 GMT, Karthik P K wrote: >> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height. >> >> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height. >> >> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments Marked as reviewed by jhendrikx (Committer). ------------- PR: https://git.openjdk.org/jfx/pull/996 From kcr at openjdk.org Tue Feb 7 13:09:00 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Feb 2023 13:09:00 GMT Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com> Message-ID: On Mon, 6 Feb 2023 23:00:17 GMT, Nir Lisker wrote: > Fixes and cleanup in the areas in the linked issue. Other than John's comments, this looks good to me. I noted one more possible formatting change and an unrelated follow-up cleanup issue I plan to file. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3277: > 3275: private void processDropEnd(DragEvent de) { > 3276: if (source == null) { > 3277: System.out.println("Scene.DnDGesture.processDropEnd() - UNEXPECTED - source is NULL"); This reminds me... I see that this warning is printed to `System.out`. I plan to file a follow-up cleanup bug (not for `jfx20`) to fix this, here and in other places, since runtime warnings should be printed to `System.err` (or else logged using the platform logger, but that would be a larger change, so I expect we'll opt for the simple substitution). modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 143: > 141: * application may set them to other values as needed: > 142: *

> 143:  *     textflow.setMaxWidth(500);

Maybe remove the `` tag while you are at it?

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

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

From john.hendrikx at gmail.com  Tue Feb  7 14:43:08 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 7 Feb 2023 15:43:08 +0100
Subject: Feedback requested for infrastructure for properties that wish to
 delay registering listeners
In-Reply-To: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com>
References: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com>
Message-ID: <396a7239-130f-a6ef-3ab8-7f6035b61671@gmail.com>

I've made a draft PR which shows the changes I'm proposing below.

For those interested, it can be found here: 
https://github.com/openjdk/jfx/pull/1023

--John

On 19/01/2023 16:49, John Hendrikx wrote:
> Hi list,
>
> I've been looking into what it would take to make the design of 
> properties which only register listeners when needed easier to 
> implement with JavaFX, both for JavaFX itself as well as for the 
> user.? This is the result of my investigation into ListProperty (and 
> other collection properties) and how hard it would be to change their 
> semantics to only register listeners when they're absolutely required 
> for the correct functioning of the class.
>
> Currently, JavaFX doesn't offer the tools one would need to register 
> listeners in a just-in-time fashion.? This is because there is no 
> notification mechanism available in its observable values when they 
> become observed or unobserved. The closest thing there currently 
> exists is what ObjectBinding and LazyObjectBinding offer:
>
> From ObjectBinding:
>
> ??? /**
> ???? * Checks if the binding has at least one listener registered on 
> it. This
> ???? * is useful for subclasses which want to conserve resources when 
> not observed.
> ???? *
> ???? * @return {@code true} if this binding currently has one or more
> ???? *???? listeners registered on it, otherwise {@code false}
> ???? * @since 19
> ???? */
> ??? protected final boolean isObserved() {
> ??????? return helper != null;
> ??? }
>
> From LazyObjectBinding:
>
> ??? /**
> ???? * Called after a listener was added to start observing inputs if 
> they're not observed already.
> ???? */
> ??? private void updateSubscriptionAfterAdd() { ... }
>
> ??? /**
> ???? * Called after a listener was removed to stop observing inputs if 
> this was the last listener
> ???? * observing this binding.
> ???? */
> ??? private void updateSubscriptionAfterRemove() { ... }
>
> I'm proposing to extend the JavaFX with new methods that can be used 
> to stay informed about the observable's current observed status. These 
> methods will facilitate implementations of properties that wish to 
> delay registering listeners until they are themselves observed. This 
> can save memory, save unnecessary notifications via events and reduces 
> the need for weak listener constructs.
>
> The proposal does not require any new fields, and would default to 
> reporting observable values as being observed. Most JavaFX observable 
> values should be retrofitted to support this functionality -- the ones 
> relying on a form of ExpressionHelper will only require minimal 
> changes with minimal impact.
>
> The methods that I would like to see added are the following:
>
> In ObservableValue:
>
> ??? /**
> ???? * Checks if this ObservableValue is currently observed. If 
> unknown or unsupported,
> ???? * {@code true} is returned.
> ???? *
> ???? * @return {@code true} if this ObservableValue currently has one 
> or more
> ???? *???? listeners registered on it, otherwise {@code false}
> ???? */
> ??? default boolean isObserved() { return true; }
>
> The above method is useful for debugging, but its primary use is for 
> complex properties which observed status is determined by not only its 
> direct listeners but also any child properties it may offer.? 
> ListProperty is such an example, which offers child properties size 
> and empty. Its observed status would be determined like this:
>
> ???? helper != null || (size0 != null && size0.isObserved()) || 
> (empty0 != null && empty0.isObserved())
>
> Further, we need two protected callback methods.? These should be 
> added in all Binding and Property Base classes (basically all classes 
> that implement addListener/removeListener methods). These are called 
> when the observed status of the property changes:
>
> ??? /**
> ???? * Called when this property transitions from unobserved to observed.
> ???? */
> ??? protected void observed() {}
>
> ??? /**
> ???? * Called when this property transitions from observed to unobserved.
> ???? */
> ??? protected void unobserved() {}
>
> These methods are implemented by child properties in order to inform 
> the parent that their observed status has changed, which may require 
> the parent property to change its status as well.
>
> When implemented, LazyObjectBinding can be simplified as some or all 
> of its functionality will be part of ObjectBinding (LazyObjectBinding 
> is not a public class at the moment).? The isObserved method in 
> ObjectBinding would go from protected to public (it's already final).
>
> Implementation for classes that rely on a form of ExpressionHelper is 
> simple; they can check if the helper is null or not (for isObserved) 
> and check if the nullity changed during addListener/removeListener 
> calls to make their call to "observed" or "unobserved".? No additional 
> fields are required.
>
> I've added a proof of concept here 
> (https://github.com/openjdk/jfx/pull/1004) where `ListPropertyBase` 
> was altered to use these new methods to delay its listener 
> registration and to remove its listener when no longer observed. This 
> PoC includes the tests written by Florian Kirmaier which fail on the 
> current ListProperty implementation (but pass with this version).
>
> --John
>

From mstrauss at openjdk.org  Tue Feb  7 15:12:09 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 7 Feb 2023 15:12:09 GMT
Subject: Integrated: 8290765: Remove parent disabled/treeVisible listeners
In-Reply-To: 
References: 
Message-ID: 

On Thu, 21 Jul 2022 04:43:15 GMT, Michael Strau?  wrote:

> `Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible` properties and calls its own `updateDisabled()` and `updateTreeVisible(boolean)` methods when the property values change.
> 
> These listeners are not required, since `Node` can easily call the `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, saving the memory cost of maintaining listeners and bindings.

This pull request has now been integrated.

Changeset: 44b8c620
Author:    Michael Strau? 
URL:       https://git.openjdk.org/jfx/commit/44b8c620082e26a23c48b3c0feb96c17e7aa7d5a
Stats:     79 lines in 3 files changed: 54 ins; 19 del; 6 mod

8290765: Remove parent disabled/treeVisible listeners

Reviewed-by: arapte, jhendrikx, nlisker

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

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

From lkostyra at openjdk.org  Tue Feb  7 15:54:23 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 7 Feb 2023 15:54:23 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage() [v3]
In-Reply-To: 
References: 
Message-ID: 

> Windows implementation of GlassClipboard.cpp uses IStorage interface in `PopImage()` to allocate a temporary file, which is then used to capture Image data from system clipboard and move it to JVM side. In order for temporary file to be removed automatically on `IStorage::Release()`, `StgCreateDocfile` API requires passing STGM_DELETEONRELEASE flag - otherwise the file will be left behind when IStorage is released. Contents of temporary file are immediately copied to a JNI Byte Array after acquiring them from clibpoard, so it is safe to provide this flag and remove the file after `PopImage()` is done.
> 
> Creating a unit test for this case would a bit difficult, as IStorage and its file are created with random temporary name each time, which we cannot easily access. On the other hand, just scouting the temp directory for any leftover .TMP files might prove false results, as other apps or even JFX itself might use IStorage temporary files for some other purposes than managing clipboard images. As such, because this is a simple API change, I did not make a test for this.
> 
> Tested this change on Windows 10 and it doesn't break any existing tests. Calling `Clipboard.getSystemClipboard().getImage()` with an image stored inside the system clipboard now leaves no leftover files.

Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unnecessary files from manual clipboard test
 - ClipboardExtImageTest: Use isWindows() only on startup

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/994/files
  - new: https://git.openjdk.org/jfx/pull/994/files/139b1c4c..624b76b5

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

  Stats: 53 lines in 4 files changed: 0 ins; 50 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/994.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/994/head:pull/994

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

From lkostyra at openjdk.org  Tue Feb  7 15:54:24 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 7 Feb 2023 15:54:24 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage() [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 7 Feb 2023 11:50:21 GMT, Ajit Ghaisas  wrote:

>> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - ClipboardExtImageTest: Add missing copyright notice
>>  - Add manual test to check for leftover Clipboard files
>
> tests/manual/clipboard/ClipboardExtImageTest.java line 193:
> 
>> 191:     public void start(Stage primaryStage) throws Exception {
>> 192:         try {
>> 193:             /*if (!isWindows()) {
> 
> This test can be only Windows specific.
> I would enable this check and get rid of `isWindows()` check everywhere.

Done

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

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

From angorya at openjdk.org  Tue Feb  7 16:24:34 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 16:24:34 GMT
Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text
 input controls [v2]
In-Reply-To: 
References: 
Message-ID: <2w4sh9LLuvsEgQhBbvUYIxTOAwsG0iZpAaeKL-xp2bQ=.960cab98-ce47-41f0-8a0c-3b3bb900b25c@github.com>

> **Targeting jfx20 branch**
> 
> A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877).
> 
> For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242.
> 
> The fix involves changing the code back to setting the control properties and doing so in the install() method.
> 
> Thank you Martin Fox  for noticing the issue!

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8301832: added test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1024/files
  - new: https://git.openjdk.org/jfx/pull/1024/files/e91dd945..54db56ac

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

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

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

From angorya at openjdk.org  Tue Feb  7 16:49:48 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 16:49:48 GMT
Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text
 input controls
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Feb 2023 12:11:58 GMT, Kevin Rushforth  wrote:

>> **Targeting jfx20 branch**
>> 
>> A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877).
>> 
>> For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242.
>> 
>> The fix involves changing the code back to setting the control properties and doing so in the install() method.
>> 
>> Thank you Martin Fox  for noticing the issue!
>
> This is the same category of bug fix as many accessibility fixes, in that it requires entering a special mode on your computer to test it using an existing test program like `HelloTextArea`. For this reason, I added a `noreg-hard` keyword to the JBS bug.

@kevinrushforth @aghaisas please re-review

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

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

From duke at openjdk.org  Tue Feb  7 16:57:20 2023
From: duke at openjdk.org (JoachimSchriek)
Date: Tue, 7 Feb 2023 16:57:20 GMT
Subject: RFR: 8173321: TableView: Click on right trough has no effect when
 cell height is higher than viewport height [v7]
In-Reply-To: 
References: 
 
 
Message-ID: <0AZZJgD0cuJQ6bLehddwYD6rKJBxiiLU51fEvZ1lfbM=.075eb8ac-bfe7-4ebf-897f-58eb6033d72a@github.com>

On Tue, 7 Feb 2023 12:08:19 GMT, Kevin Rushforth  wrote:

>> JoachimSchriek 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:
>> 
>>  - Merge branch 'openjdk:master' into master
>>  - Restore original VirtualFlow.java
>>  - Changes made following findings from review
>>  - Deleted trailing whitespace
>>  - Committed Test Case for [openjdk/jfx] 8173321: Click on trough has no
>>    effect when cell height > viewport (PR #985):
>>  - Replaces Tabs with Spaces
>>  - JDK-8173321: Click on trough has no effect when cell height > viewport
>>    height
>
> Can you enable GitHub actions and then do a test run (either manually or by pushing an empty commit)?

@kevinrushforth I have enabled the actions. The status of the manually started runs is "success"

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

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

From nlisker at openjdk.org  Tue Feb  7 17:01:56 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 7 Feb 2023 17:01:56 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v2]
In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
Message-ID: 

> Fixes and cleanup in the areas in the linked issue.

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

  Update modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java
  
  Co-authored-by: John Hendrikx 

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1025/files
  - new: https://git.openjdk.org/jfx/pull/1025/files/7d422a9c..d2155e51

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

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

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

From nlisker at openjdk.org  Tue Feb  7 17:12:48 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 7 Feb 2023 17:12:48 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
Message-ID: <8MNnPyh6xNm6A2l3MlGlM1DsHMkvCOCpcFCXfcJot98=.61e95675-a4ef-4d23-80d4-371ea72e3175@github.com>

> Fixes and cleanup in the areas in the linked issue.

Nir Lisker has updated the pull request incrementally with three additional commits since the last revision:

 - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
   
   Co-authored-by: John Hendrikx 
 - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
   
   Co-authored-by: John Hendrikx 
 - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
   
   Co-authored-by: John Hendrikx 

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1025/files
  - new: https://git.openjdk.org/jfx/pull/1025/files/d2155e51..fe9c9889

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

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

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

From nlisker at openjdk.org  Tue Feb  7 17:16:48 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 7 Feb 2023 17:16:48 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
Message-ID: 

On Tue, 7 Feb 2023 12:17:43 GMT, Kevin Rushforth  wrote:

>> Nir Lisker has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3277:
> 
>> 3275:         private void processDropEnd(DragEvent de) {
>> 3276:             if (source == null) {
>> 3277:                 System.out.println("Scene.DnDGesture.processDropEnd() - UNEXPECTED - source is NULL");
> 
> This reminds me... I see that this warning is printed to `System.out`. I plan to file a follow-up cleanup bug (not for `jfx20`) to fix this, here and in other places, since runtime warnings should be printed to `System.err` (or else logged using the platform logger, but that would be a larger change, so I expect we'll opt for the simple substitution).

I never understood when something should be logged vs. printed. And do we ever print to `out`?

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

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

From nlisker at openjdk.org  Tue Feb  7 17:16:52 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 7 Feb 2023 17:16:52 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
Message-ID: 

On Tue, 7 Feb 2023 12:25:14 GMT, John Hendrikx  wrote:

>> Nir Lisker has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 62:
> 
>> 60: 
>> 61: /**
>> 62:  * A special layout designed to lay out rich text.
> 
> What's "special" about it? :-)
> Suggestion:
> 
>  * A layout designed to lay out rich text.

Maybe it's special in the sense that it's specialized towards displaying text, unlike other `Pane`s that are multi-purpose for all nodes. "designed to" already points to that. Maybe "A specialized layout for rich text."?

> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 90:
> 
>> 88:  * It can be specified by the application by setting the {@code TextFlow}'s preferred
>> 89:  * width. If no wrapping is desired, the application can either set the preferred
>> 90:  * with to {@code Double.MAX_VALUE} or {@code Region.USE_COMPUTED_SIZE}.
> 
> Should these be links?  They're the first mention in this doc.

I don't think that linking to `Double.MAX_VALUE` is helpful, but maybe to `Region.USE_COMPUTED_SIZE` is.

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

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

From nlisker at openjdk.org  Tue Feb  7 17:20:15 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 7 Feb 2023 17:20:15 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
Message-ID: 

On Tue, 7 Feb 2023 13:05:21 GMT, Kevin Rushforth  wrote:

>> Nir Lisker has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>>    
>>    Co-authored-by: John Hendrikx 
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 143:
> 
>> 141:  * application may set them to other values as needed:
>> 142:  * 

>> 143:  *     textflow.setMaxWidth(500);
> 
> Maybe remove the `` tag while you are at it?

All the other panes use this format, for example, https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/layout/BorderPane.html.

Maybe in a Panes doc cleanup issue. I always thought more images were needed in these to show the layouts, so I could look into that.

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

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

From kcr at openjdk.org  Tue Feb  7 17:24:44 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Feb 2023 17:24:44 GMT
Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text
 input controls [v2]
In-Reply-To: <2w4sh9LLuvsEgQhBbvUYIxTOAwsG0iZpAaeKL-xp2bQ=.960cab98-ce47-41f0-8a0c-3b3bb900b25c@github.com>
References: 
 <2w4sh9LLuvsEgQhBbvUYIxTOAwsG0iZpAaeKL-xp2bQ=.960cab98-ce47-41f0-8a0c-3b3bb900b25c@github.com>
Message-ID: <0KBbDL6QUAJwhMndzD8k6Z6Yc4RECrgqYAq3pPeKBz0=.583464c0-1e28-405a-b058-5b60caa0c5b6@github.com>

On Tue, 7 Feb 2023 16:24:34 GMT, Andy Goryachev  wrote:

>> **Targeting jfx20 branch**
>> 
>> A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877).
>> 
>> For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242.
>> 
>> The fix involves changing the code back to setting the control properties and doing so in the install() method.
>> 
>> Thank you Martin Fox  for noticing the issue!
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301832: added test

Marked as reviewed by kcr (Lead).

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

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

From angorya at openjdk.org  Tue Feb  7 19:37:59 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 19:37:59 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: <8MNnPyh6xNm6A2l3MlGlM1DsHMkvCOCpcFCXfcJot98=.61e95675-a4ef-4d23-80d4-371ea72e3175@github.com>
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 <8MNnPyh6xNm6A2l3MlGlM1DsHMkvCOCpcFCXfcJot98=.61e95675-a4ef-4d23-80d4-371ea72e3175@github.com>
Message-ID: 

On Tue, 7 Feb 2023 17:12:48 GMT, Nir Lisker  wrote:

>> Fixes and cleanup in the areas in the linked issue.
>
> Nir Lisker has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>    
>    Co-authored-by: John Hendrikx 
>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>    
>    Co-authored-by: John Hendrikx 
>  - Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java
>    
>    Co-authored-by: John Hendrikx 

modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 472:

> 470:      * @since JavaFX 8.0
> 471:      */
> 472:     private ObjectProperty placeholder;

could we add a blank line after this statement?

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

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

From angorya at openjdk.org  Tue Feb  7 19:38:03 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 19:38:03 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
Message-ID: 

On Tue, 7 Feb 2023 17:14:27 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3277:
>> 
>>> 3275:         private void processDropEnd(DragEvent de) {
>>> 3276:             if (source == null) {
>>> 3277:                 System.out.println("Scene.DnDGesture.processDropEnd() - UNEXPECTED - source is NULL");
>> 
>> This reminds me... I see that this warning is printed to `System.out`. I plan to file a follow-up cleanup bug (not for `jfx20`) to fix this, here and in other places, since runtime warnings should be printed to `System.err` (or else logged using the platform logger, but that would be a larger change, so I expect we'll opt for the simple substitution).
>
> I never understood when something should be logged vs. printed. And do we ever print to `out`?

I wish we were using logging...

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

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

From angorya at openjdk.org  Tue Feb  7 19:38:06 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 19:38:06 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
Message-ID: 

On Tue, 7 Feb 2023 17:11:50 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 62:
>> 
>>> 60: 
>>> 61: /**
>>> 62:  * A special layout designed to lay out rich text.
>> 
>> What's "special" about it? :-)
>> Suggestion:
>> 
>>  * A layout designed to lay out rich text.
>
> Maybe it's special in the sense that it's specialized towards displaying text, unlike other `Pane`s that are multi-purpose for all nodes. "designed to" already points to that. Maybe "A specialized layout for rich text."?

A specialized layout... +1

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

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

From angorya at openjdk.org  Tue Feb  7 19:59:48 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 19:59:48 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Feb 2023 05:25:08 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 328:

> 326:         }
> 327: 
> 328:         double textWidth = emptyText ? 0.0 : Utils.computeTextWidth(font, cleanText, 0);

textWidth is being computed even if isIgnoreText() is true.  I wonder if we could re-structure the if-else statements below to avoid unnecessary computations?

There is another suggestion - isIgnoreText() is not a simple getter (does a bit of computation).  We probably should use a boolean early in this method to avoid calling it repeatedly.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 382:

> 380:                 labeled.getLineSpacing(), text.getBoundsType());
> 381: 
> 382:         double height;

same comment here - textHeight is computed regardless of whether its needed (isIgnoreText() == true),

and use a boolean to avoid multiple calls to isIgnoreText() in the same method.

isIgnoreGraphic, on the other hand, is very light weight, so it's up to you whether to use a local boolean variable in this and the other method or not.

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

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

From angorya at openjdk.org  Tue Feb  7 20:09:01 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Feb 2023 20:09:01 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Feb 2023 05:25:08 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 365:

> 363:         }
> 364: 
> 365:         String cleanText = getCleanText();

cleanText code block is unnecessary  when isIgnoreText() == true

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

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

From kcr at openjdk.org  Tue Feb  7 20:09:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Feb 2023 20:09:58 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
 
Message-ID: 

On Tue, 7 Feb 2023 19:31:58 GMT, Andy Goryachev  wrote:

>> I never understood when something should be logged vs. printed. And do we ever print to `out`?
>
> I wish we were using logging...

We aren't very consistent on this. Most of the places where we produce warnings, or where we provide verbose output, are done by printing. At a minimum, those should go to `System.err` rather than `System.out`. Unless there is an API whose expected result is to print something to `System.out`, a library really shouldn't print to System.out (as opposed to a test or a demo app, where it's fine). So the only places I would expect to see it in the library -- meaning source code under `modules/javafx.*/src/main/java/` -- would be in examples in javadoc comments.

We could file a second follow-up issue (RFE) to consider changing some of our print statements to use logging.

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

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

From kcr at openjdk.org  Tue Feb  7 20:10:00 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Feb 2023 20:10:00 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
 
Message-ID: 

On Tue, 7 Feb 2023 19:33:45 GMT, Andy Goryachev  wrote:

>> Maybe it's special in the sense that it's specialized towards displaying text, unlike other `Pane`s that are multi-purpose for all nodes. "designed to" already points to that. Maybe "A specialized layout for rich text."?
>
> A specialized layout... +1

+1 from me as well.

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

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

From kcr at openjdk.org  Tue Feb  7 20:10:02 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Feb 2023 20:10:02 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
Message-ID: 

On Tue, 7 Feb 2023 17:17:00 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 143:
>> 
>>> 141:  * application may set them to other values as needed:
>>> 142:  * 

>>> 143:  *     textflow.setMaxWidth(500);
>> 
>> Maybe remove the `` tag while you are at it?
>
> All the other panes use this format, for example, https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/layout/BorderPane.html.
> 
> Maybe in a Panes doc cleanup issue. I always thought more images were needed in these to show the layouts, so I could look into that.

OK, let's not change it in this PR then.

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

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

From jhendrikx at openjdk.org  Tue Feb  7 20:56:55 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 7 Feb 2023 20:56:55 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
 
 
Message-ID: 

On Tue, 7 Feb 2023 19:51:55 GMT, Kevin Rushforth  wrote:

>> I wish we were using logging...
>
> We aren't very consistent on this. Most of the places where we produce warnings, or where we provide verbose output, are done by printing. At a minimum, those should go to `System.err` rather than `System.out`. Unless there is an API whose expected result is to print something to `System.out`, a library really shouldn't print to System.out (as opposed to a test or a demo app, where it's fine). So the only places I would expect to see it in the library -- meaning source code under `modules/javafx.*/src/main/java/` -- would be in examples in javadoc comments.
> 
> We could file a second follow-up issue (RFE) to consider changing some of our print statements to use logging.

Some investigation is needed if source can ever be null in such cases.  I think some of these are to inform the programmer (not the user) something unexpected happens, in which case it should be an assert or exception.  If it then ever does happen, it should be fixed.

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

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

From jhendrikx at openjdk.org  Tue Feb  7 21:18:14 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 7 Feb 2023 21:18:14 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
 
 
 
Message-ID: 

On Tue, 7 Feb 2023 20:54:20 GMT, John Hendrikx  wrote:

>> We aren't very consistent on this. Most of the places where we produce warnings, or where we provide verbose output, are done by printing. At a minimum, those should go to `System.err` rather than `System.out`. Unless there is an API whose expected result is to print something to `System.out`, a library really shouldn't print to System.out (as opposed to a test or a demo app, where it's fine). So the only places I would expect to see it in the library -- meaning source code under `modules/javafx.*/src/main/java/` -- would be in examples in javadoc comments.
>> 
>> We could file a second follow-up issue (RFE) to consider changing some of our print statements to use logging.
>
> Some investigation is needed if source can ever be null in such cases.  I think some of these are to inform the programmer (not the user) something unexpected happens, in which case it should be an assert or exception.  If it then ever does happen, it should be fixed.

The drag/drop code is full of what looks like asserts that are just dumped to `System.err`.  It looks like left overs that helped during development of the underlying state machine, but it shouldn't get in such states normally.  When I run the tests, none of the exceptional cases or `System.err` code has any coverage which can be a sign that these cases can't be reached.

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

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

From nlisker at openjdk.org  Wed Feb  8 00:00:20 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 8 Feb 2023 00:00:20 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v4]
In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
Message-ID: 

> Fixes and cleanup in the areas in the linked issue.

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

  Update modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1025/files
  - new: https://git.openjdk.org/jfx/pull/1025/files/fe9c9889..a5632000

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

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

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

From nlisker at openjdk.org  Wed Feb  8 00:00:20 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 8 Feb 2023 00:00:20 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v4]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
 
 
 
Message-ID: 

On Tue, 7 Feb 2023 19:52:14 GMT, Kevin Rushforth  wrote:

>> A specialized layout... +1
>
> +1 from me as well.

Suggestion:

 * A specialized layout for rich text.

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

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

From nlisker at openjdk.org  Wed Feb  8 00:12:14 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 8 Feb 2023 00:12:14 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v5]
In-Reply-To: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
Message-ID: 

> Fixes and cleanup in the areas in the linked issue.

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/1025/files
  - new: https://git.openjdk.org/jfx/pull/1025/files/a5632000..328bdebc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1025&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1025&range=03-04

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1025.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1025/head:pull/1025

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

From angorya at openjdk.org  Wed Feb  8 00:16:51 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Feb 2023 00:16:51 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v5]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
Message-ID: 

On Wed, 8 Feb 2023 00:12:14 GMT, Nir Lisker  wrote:

>> Fixes and cleanup in the areas in the linked issue.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

definitely an improvement, thank you.

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

Marked as reviewed by angorya (Committer).

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

From jhendrikx at openjdk.org  Wed Feb  8 00:47:52 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 8 Feb 2023 00:47:52 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v5]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
Message-ID: 

On Wed, 8 Feb 2023 00:12:14 GMT, Nir Lisker  wrote:

>> Fixes and cleanup in the areas in the linked issue.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Marked as reviewed by jhendrikx (Committer).

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

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

From kcr at openjdk.org  Wed Feb  8 01:16:49 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Feb 2023 01:16:49 GMT
Subject: [jfx20] RFR: 8293587: Fix mistakes in FX API docs [v5]
In-Reply-To: 
References: <_5l0pUBjZ9aJ7drhBR59FLnjfgLXURynS9_lE1_qtbA=.869f2cbb-5faf-446a-9adf-69c47b63855d@github.com>
 
Message-ID: 

On Wed, 8 Feb 2023 00:12:14 GMT, Nir Lisker  wrote:

>> Fixes and cleanup in the areas in the linked issue.
>
> 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: https://git.openjdk.org/jfx/pull/1025

From aghaisas at openjdk.org  Wed Feb  8 04:42:48 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 8 Feb 2023 04:42:48 GMT
Subject: [jfx20] RFR: 8301832: InputMethodEvents are not enabled for text
 input controls [v2]
In-Reply-To: <2w4sh9LLuvsEgQhBbvUYIxTOAwsG0iZpAaeKL-xp2bQ=.960cab98-ce47-41f0-8a0c-3b3bb900b25c@github.com>
References: 
 <2w4sh9LLuvsEgQhBbvUYIxTOAwsG0iZpAaeKL-xp2bQ=.960cab98-ce47-41f0-8a0c-3b3bb900b25c@github.com>
Message-ID: 

On Tue, 7 Feb 2023 16:24:34 GMT, Andy Goryachev  wrote:

>> **Targeting jfx20 branch**
>> 
>> A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877).
>> 
>> For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242.
>> 
>> The fix involves changing the code back to setting the control properties and doing so in the install() method.
>> 
>> Thank you Martin Fox  for noticing the issue!
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301832: added test

Thanks for adding the unit test!

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

Marked as reviewed by aghaisas (Reviewer).

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

From aghaisas at openjdk.org  Wed Feb  8 05:11:52 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 8 Feb 2023 05:11:52 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage() [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Feb 2023 15:54:23 GMT, Lukasz Kostyra  wrote:

>> Windows implementation of GlassClipboard.cpp uses IStorage interface in `PopImage()` to allocate a temporary file, which is then used to capture Image data from system clipboard and move it to JVM side. In order for temporary file to be removed automatically on `IStorage::Release()`, `StgCreateDocfile` API requires passing STGM_DELETEONRELEASE flag - otherwise the file will be left behind when IStorage is released. Contents of temporary file are immediately copied to a JNI Byte Array after acquiring them from clibpoard, so it is safe to provide this flag and remove the file after `PopImage()` is done.
>> 
>> Creating a unit test for this case would a bit difficult, as IStorage and its file are created with random temporary name each time, which we cannot easily access. On the other hand, just scouting the temp directory for any leftover .TMP files might prove false results, as other apps or even JFX itself might use IStorage temporary files for some other purposes than managing clipboard images. As such, because this is a simple API change, I did not make a test for this.
>> 
>> Tested this change on Windows 10 and it doesn't break any existing tests. Calling `Clipboard.getSystemClipboard().getImage()` with an image stored inside the system clipboard now leaves no leftover files.
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unnecessary files from manual clipboard test
>  - ClipboardExtImageTest: Use isWindows() only on startup

Looks good!

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

Marked as reviewed by aghaisas (Reviewer).

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

From kpk at openjdk.org  Wed Feb  8 07:42:14 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 8 Feb 2023 07:42:14 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
Message-ID: 

> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
> 
> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
> 
> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.

Karthik P K has updated the pull request incrementally with two additional commits since the last revision:

 - Renamed system test file
 - Fixing issue in all XYCharts

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1015/files
  - new: https://git.openjdk.org/jfx/pull/1015/files/6f59b6d7..0282896e

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

  Stats: 533 lines in 7 files changed: 382 ins; 134 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1015.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1015/head:pull/1015

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

From kpk at openjdk.org  Wed Feb  8 08:31:57 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 8 Feb 2023 08:31:57 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Feb 2023 07:42:14 GMT, Karthik P K  wrote:

>> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
>> 
>> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
>> 
>> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Renamed system test file
>  - Fixing issue in all XYCharts

Fixed duplicate child added exception in all XYCharts.
In `StackedBarChart`, Y axis value was being manipulated with relative zero position. Due to this the actual Y value was getting changed and chart was getting modified as we remove and add the series back to the chart. Fixed this issue as well.

Added system test to validate the fix for all the XYCharts.

@aghaisas and @andy-goryachev-oracle please review these changes.

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

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

From lkostyra at openjdk.org  Wed Feb  8 12:12:57 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 8 Feb 2023 12:12:57 GMT
Subject: Integrated: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 12 Jan 2023 11:11:23 GMT, Lukasz Kostyra  wrote:

> Windows implementation of GlassClipboard.cpp uses IStorage interface in `PopImage()` to allocate a temporary file, which is then used to capture Image data from system clipboard and move it to JVM side. In order for temporary file to be removed automatically on `IStorage::Release()`, `StgCreateDocfile` API requires passing STGM_DELETEONRELEASE flag - otherwise the file will be left behind when IStorage is released. Contents of temporary file are immediately copied to a JNI Byte Array after acquiring them from clibpoard, so it is safe to provide this flag and remove the file after `PopImage()` is done.
> 
> Creating a unit test for this case would a bit difficult, as IStorage and its file are created with random temporary name each time, which we cannot easily access. On the other hand, just scouting the temp directory for any leftover .TMP files might prove false results, as other apps or even JFX itself might use IStorage temporary files for some other purposes than managing clipboard images. As such, because this is a simple API change, I did not make a test for this.
> 
> Tested this change on Windows 10 and it doesn't break any existing tests. Calling `Clipboard.getSystemClipboard().getImage()` with an image stored inside the system clipboard now leaves no leftover files.

This pull request has now been integrated.

Changeset: 73ed7b6a
Author:    Lukasz Kostyra 
Committer: Ajit Ghaisas 
URL:       https://git.openjdk.org/jfx/commit/73ed7b6a92bca217ad602ccb6c5de64efa30f856
Stats:     203 lines in 2 files changed: 202 ins; 0 del; 1 mod

8290092: Temporary files are kept when call Clipboard.getSystemClipboard().getImage()

Reviewed-by: aghaisas

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

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

From kpk at openjdk.org  Wed Feb  8 12:19:34 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 8 Feb 2023 12:19:34 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v5]
In-Reply-To: 
References: 
Message-ID: <6955bMGClU0vbErwZCX4vBxudvI37GkmC7EjMlEIPXg=.1cf9c304-f58d-438b-88ad-72b8ee1973ad@github.com>

> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
> 
> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
> 
> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/996/files
  - new: https://git.openjdk.org/jfx/pull/996/files/1b868a6f..ede9c535

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=03-04

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

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

From kpk at openjdk.org  Wed Feb  8 12:48:54 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 8 Feb 2023 12:48:54 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 7 Feb 2023 19:47:50 GMT, Andy Goryachev  wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 328:
> 
>> 326:         }
>> 327: 
>> 328:         double textWidth = emptyText ? 0.0 : Utils.computeTextWidth(font, cleanText, 0);
> 
> textWidth is being computed even if isIgnoreText() is true.  I wonder if we could re-structure the if-else statements below to avoid unnecessary computations?
> 
> There is another suggestion - isIgnoreText() is not a simple getter (does a bit of computation).  We probably should use a boolean early in this method to avoid calling it repeatedly.

Previously both `textWidth` and `graphicWidth` were calculated regardless of the condition. In the updated code calculation of `graphicWidth` is moved to `else` block so that one unnecessary calculation is avoided. Since `textWidth` is used in 2 more conditions in `else` block, calculated it before the start of `if` block.

Since `isIgnoreText()` does more than just checking for `ContentDisplay` value, further reordering `if-else` statements generates different result than expected.
So this further leads to question previously raised by @hjohn, if `isIgnoreText()` and `isIgnoreGraphic()` should only check for ContetDisplay type or check for conditions like null/empty graphic or text as well. If this needs to be separated, again it gives raise to more conditions in the `computePrefWidth()` method.

Added boolean in the beginning as suggested.

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

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

From kpk at openjdk.org  Wed Feb  8 12:59:01 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 8 Feb 2023 12:59:01 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 7 Feb 2023 19:57:00 GMT, Andy Goryachev  wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 382:
> 
>> 380:                 labeled.getLineSpacing(), text.getBoundsType());
>> 381: 
>> 382:         double height;
> 
> same comment here - textHeight is computed regardless of whether its needed (isIgnoreText() == true),
> 
> and use a boolean to avoid multiple calls to isIgnoreText() in the same method.
> 
> isIgnoreGraphic, on the other hand, is very light weight, so it's up to you whether to use a local boolean variable in this and the other method or not.

In the case of `computePrefHeight` as well calculation of `graphicHeight` is moved to `else` block to avoid one unnecessary calculation.
In this method, by checking for ignore text condition before checking for ignore graphic, we can move `cleanText`, `textWidth` and `textHeight` calculation to `else` block instead of only `graphicHeight`. But this again leads to unexpected result because of the checks present in `isIgnoreText()` method. Hence did not re-order `if-else` statements now.

Added boolean for both `isIgnoreGraphic` and `isIgnoreText`.

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

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

From kpk at openjdk.org  Wed Feb  8 13:09:58 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 8 Feb 2023 13:09:58 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 7 Feb 2023 20:06:27 GMT, Andy Goryachev  wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 365:
> 
>> 363:         }
>> 364: 
>> 365:         String cleanText = getCleanText();
> 
> cleanText code block is unnecessary  when isIgnoreText() == true

Since `clenText` is used in `textHeight` calculation, this cannot be avoided before the `if-else` block as `if-else` block is not re-ordered now. Please refer to the previous comment for the details on `computePrefHeight()` method.

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

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

From jbhaskar at openjdk.org  Wed Feb  8 13:56:45 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 8 Feb 2023 13:56:45 GMT
Subject: RFR: 8301712: [linux] Crash on exit from WebKit 615.1
Message-ID: 

Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

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

Commit messages:
 - [linux] Crash on exit from WebKit 615.1

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

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

From kcr at openjdk.org  Wed Feb  8 14:05:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Feb 2023 14:05:54 GMT
Subject: RFR: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Feb 2023 13:51:29 GMT, Jay Bhaskar  wrote:

> Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
> Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
> Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

Reviewers: @kevinrushforth @HimaBinduMeda

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

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

From kcr at openjdk.org  Wed Feb  8 14:09:56 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Feb 2023 14:09:56 GMT
Subject: RFR: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Feb 2023 13:51:29 GMT, Jay Bhaskar  wrote:

> Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
> Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
> Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

The fix looks good to me. I confirm that it fixes the problem. I'll do a bit more testing before I approve.

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

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

From jhendrikx at openjdk.org  Wed Feb  8 14:54:52 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 8 Feb 2023 14:54:52 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v3]
In-Reply-To: 
References: 
Message-ID: 

> This contains the following:
> - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes
>   - This fixes odd change events being produced (with incorrect oldValue)
>   - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call
> - A test for ExpressionHelper to verify the new behavior
> - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level).
> - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it

John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Add copyright header
 - Merge branch 'master' of https://git.openjdk.org/jfx into feature/delayed-nested-emission
 - Merge branch 'master' of https://git.openjdk.org/jfx into feature/delayed-nested-emission
 - Delay nested event emission

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

Changes: https://git.openjdk.org/jfx/pull/837/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=837&range=02
  Stats: 530 lines in 4 files changed: 491 ins; 12 del; 27 mod
  Patch: https://git.openjdk.org/jfx/pull/837.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/837/head:pull/837

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

From jhendrikx at openjdk.org  Wed Feb  8 14:57:25 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 8 Feb 2023 14:57:25 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v3]
In-Reply-To: 
References: 
Message-ID: 

> Packages fixed:
> - com.sun.javafx.binding
> - com.sun.javafx.collections
> - javafx.beans
> - javafx.beans.binding
> - javafx.collections
> - javafx.collections.transformation

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

  Simplify MappingChange by using Function

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/972/files
  - new: https://git.openjdk.org/jfx/pull/972/files/24278e96..106fc11b

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

  Stats: 31 lines in 3 files changed: 4 ins; 21 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/972.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/972/head:pull/972

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

From jhendrikx at openjdk.org  Wed Feb  8 15:05:46 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 8 Feb 2023 15:05:46 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v4]
In-Reply-To: 
References: 
Message-ID: 

> Packages fixed:
> - com.sun.javafx.binding
> - com.sun.javafx.collections
> - javafx.beans
> - javafx.beans.binding
> - javafx.collections
> - javafx.collections.transformation

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 seven additional commits since the last revision:

 - Merge branch 'master' of https://git.openjdk.org/jfx into feature/fix-raw-type-warnings-in-base-2
 - Undo changes in SortHelper
 - Simplify MappingChange by using Function
 - Clean up expression classes repeated null checks
 - Use instanceof with pattern matching in a few spots
 - Use static method for no-op map
 - Fix raw type warnings in base
   
   Packages fixed:
   - com.sun.javafx.binding
   - com.sun.javafx.collections
   - javafx.beans
   - javafx.beans.binding
   - javafx.collections
   - javafx.collections.transformation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/972/files
  - new: https://git.openjdk.org/jfx/pull/972/files/106fc11b..8814a990

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

  Stats: 221805 lines in 6977 files changed: 129959 ins; 45549 del; 46297 mod
  Patch: https://git.openjdk.org/jfx/pull/972.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/972/head:pull/972

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

From hmeda at openjdk.org  Wed Feb  8 15:33:56 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 8 Feb 2023 15:33:56 GMT
Subject: RFR: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Feb 2023 13:51:29 GMT, Jay Bhaskar  wrote:

> Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
> Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
> Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

Fix looks good to me. Tested on Mac and windows.No crash is observed with the fix.

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

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

From hmeda at openjdk.org  Wed Feb  8 15:37:58 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 8 Feb 2023 15:37:58 GMT
Subject: RFR: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Feb 2023 13:51:29 GMT, Jay Bhaskar  wrote:

> Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
> Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
> Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

Marked as reviewed by hmeda (Author).

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

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

From angorya at openjdk.org  Wed Feb  8 16:24:58 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Feb 2023 16:24:58 GMT
Subject: [jfx20] Integrated: 8301832: InputMethodEvents are not enabled for
 text input controls
In-Reply-To: 
References: 
Message-ID: 

On Mon, 6 Feb 2023 18:45:10 GMT, Andy Goryachev  wrote:

> **Targeting jfx20 branch**
> 
> A fix for regression introduced by [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877).
> 
> For IME to work, both `setOnInputMethodTextChanged()` and `setInputMethodRequests()` needs to be set, see Scene:2242.
> 
> The fix involves changing the code back to setting the control properties and doing so in the install() method.
> 
> Thank you Martin Fox  for noticing the issue!

This pull request has now been integrated.

Changeset: abe80587
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/abe80587a3515bbae5ba2f3d3a65cc0614e254fb
Stats:     45 lines in 2 files changed: 41 ins; 4 del; 0 mod

8301832: InputMethodEvents are not enabled for text input controls

Reviewed-by: kcr, aghaisas

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

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

From kcr at openjdk.org  Wed Feb  8 17:37:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Feb 2023 17:37:55 GMT
Subject: RFR: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Feb 2023 13:51:29 GMT, Jay Bhaskar  wrote:

> Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
> Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
> Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

Marked as reviewed by kcr (Lead).

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

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

From angorya at openjdk.org  Wed Feb  8 19:14:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Feb 2023 19:14:00 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Feb 2023 07:42:14 GMT, Karthik P K  wrote:

>> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
>> 
>> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
>> 
>> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Renamed system test file
>  - Fixing issue in all XYCharts

looks like the main issue has been fixed, tested with MonkeyTester
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java

A few minor things are noted in the comments, most important is whether it's possible to leave the Timeline running forever.

modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 72:

> 70:     // -------------- PRIVATE FIELDS ------------------------------------------
> 71: 
> 72:     /** A multiplier for teh Y values that we store for each series, it is used to animate in a new series */

while we are at it, could we fix the comment "teh" -> "the"

modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 562:

> 560:         if (timeline != null) {
> 561:             timeline.setOnFinished(null);
> 562:             timeline.stop();

two questions:

1. should the timeline object be set to null here?  the reference will get overwritten in seriesRemoved():414, there is probably no need to keep this object in memory
2. is it possible that `seriesBeingRemovedIsAdded()` will be invoked twice with a different `series` argument?  In other words, are we going to face a situation when a `timeline` from unrelated series will not get `stop`'ped?

(these question apply to other charts as well)

tests/system/src/test/java/test/javafx/scene/control/XYChartExceptionOnAddingRemovedSeriesTest.java line 94:

> 92:     @Test
> 93:     public void testLineChartExceptionOnAddingRemovedSeries() throws Throwable {
> 94:         Thread.sleep(1000); // Wait for stage to layout

I wonder if there is a better way of doing this, other than a long sleep?  Perhaps use some kind of a concurrency primitive?

tests/system/src/test/java/test/javafx/scene/control/XYChartExceptionOnAddingRemovedSeriesTest.java line 315:

> 313:             stage.show();
> 314: 
> 315:             Thread.currentThread().setUncaughtExceptionHandler((t2, e) -> {

I think it's better to set this handler in a pre-test method annotated with @Before, and clean up in @After - see, for instance, how it's done in BehaviorCleanupTest.

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

Changes requested by angorya (Committer).

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

From angorya at openjdk.org  Wed Feb  8 20:06:54 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Feb 2023 20:06:54 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v5]
In-Reply-To: <6955bMGClU0vbErwZCX4vBxudvI37GkmC7EjMlEIPXg=.1cf9c304-f58d-438b-88ad-72b8ee1973ad@github.com>
References: 
 <6955bMGClU0vbErwZCX4vBxudvI37GkmC7EjMlEIPXg=.1cf9c304-f58d-438b-88ad-72b8ee1973ad@github.com>
Message-ID: 

On Wed, 8 Feb 2023 12:19:34 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

I'd recommend to make further optimizations, see the code sample.

For your convenience, I've added a Label page to the monkey tester
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java

(sorry, it is still in a separate repository.  if you use Eclipse, just import the project into your workspace)

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

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

From angorya at openjdk.org  Wed Feb  8 20:06:57 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Feb 2023 20:06:57 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 8 Feb 2023 12:46:15 GMT, Karthik P K  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 328:
>> 
>>> 326:         }
>>> 327: 
>>> 328:         double textWidth = emptyText ? 0.0 : Utils.computeTextWidth(font, cleanText, 0);
>> 
>> textWidth is being computed even if isIgnoreText() is true.  I wonder if we could re-structure the if-else statements below to avoid unnecessary computations?
>> 
>> There is another suggestion - isIgnoreText() is not a simple getter (does a bit of computation).  We probably should use a boolean early in this method to avoid calling it repeatedly.
>
> Previously both `textWidth` and `graphicWidth` were calculated regardless of the condition. In the updated code calculation of `graphicWidth` is moved to `else` block so that one unnecessary calculation is avoided. Since `textWidth` is used in 2 more conditions in `else` block, calculated it before the start of `if` block.
> 
> Since `isIgnoreText()` does more than just checking for `ContentDisplay` value, further reordering `if-else` statements generates different result than expected.
> So this further leads to question previously raised by @hjohn, if `isIgnoreText()` and `isIgnoreGraphic()` should only check for ContetDisplay type or check for conditions like null/empty graphic or text as well. If this needs to be separated, again it gives raise to more conditions in the `computePrefWidth()` method.
> 
> Added boolean in the beginning as suggested.

no, what I meant is try to make sure that any operations with text (and some other calls) are made only when they are needed.  

For example, this code avoids calling anything to do with text and font when isIgnoreText == true.

I also noticed that there is a field called `textWidth`; to avoid confusion I renamed the local variable from textWidth to `txWidth`.


    /** {@inheritDoc} */
    @Override
    protected double computePrefWidth(double height, double topInset, double rightInset, double bottomInset,
        double leftInset) {
        // Get the preferred width of the text
        final Labeled labeled = getSkinnable();

        boolean isIgnoreText = isIgnoreText();
        double widthPadding = leftInset + rightInset;

        double txWidth;
        if (isIgnoreText) {
            txWidth = 0.0;
        } else {
            widthPadding += (leftLabelPadding() + rightLabelPadding());

            String cleanText = getCleanText();
            boolean emptyText = cleanText == null || cleanText.isEmpty();
            if (emptyText) {
                txWidth = 0.0;
            } else {
                Font font = text.getFont();
                txWidth = Utils.computeTextWidth(font, cleanText, 0);
            }
        }

        double width;
        if (isIgnoreGraphic()) {
            width = txWidth;
        } else {
            // Fix for RT-39889
            double grWidth = graphic == null ? 0.0
                : Utils.boundedSize(graphic.prefWidth(-1), graphic.minWidth(-1), graphic.maxWidth(-1));

            if (isIgnoreText) {
                width = grWidth;
            } else {
                ContentDisplay cd = labeled.getContentDisplay();
                if (cd == ContentDisplay.LEFT || cd == ContentDisplay.RIGHT) {
                    width = txWidth + labeled.getGraphicTextGap() + grWidth;
                } else {
                    width = Math.max(txWidth, grWidth);
                }
            }
        }

        return width + widthPadding;
    }


I suggest we apply a similar treatment to the second method being modified.

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 365:
>> 
>>> 363:         }
>>> 364: 
>>> 365:         String cleanText = getCleanText();
>> 
>> cleanText code block is unnecessary  when isIgnoreText() == true
>
> Since `clenText` is used in `textHeight` calculation, this cannot be avoided before the `if-else` block as `if-else` block is not re-ordered now. Please refer to the previous comment for the details on `computePrefHeight()` method.

please see my earlier code sample, it is possible.
cleanText is only needed to get the textWidth, and that is only needed when isIgnoreText == false.
Also note that `textWidth` here is a local and hides an instance field with the same name.  Rename the local?

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

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

From jbhaskar at openjdk.org  Thu Feb  9 01:10:55 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Thu, 9 Feb 2023 01:10:55 GMT
Subject: Integrated: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: <3tkHRzRIDNBrUH1iZjDqUp06NKyQX_6VAJfMtiXX5k4=.19c8b6ba-d561-4e74-b620-5de5bc742eb1@github.com>

On Wed, 8 Feb 2023 13:51:29 GMT, Jay Bhaskar  wrote:

> Issue: [linux] Crash on exit from WebKit 615.1 Crash dump observed on Window exit
> Root cause: Accessing local storage data of a thread having client data like font cache during VM shutdown
> Solution: Add a shutdown hook to ThreadTimers class, so that no timer class doesn't fire any function during the shutdown.

This pull request has now been integrated.

Changeset: 13d8df31
Author:    Jay Bhaskar 
Committer: Kevin Rushforth 
URL:       https://git.openjdk.org/jfx/commit/13d8df31e7bc4336d01ec859e127756928db30d4
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8301712: [linux] Crash on exit from WebKit 615.1

Reviewed-by: kcr, hmeda

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

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

From kpk at openjdk.org  Thu Feb  9 09:37:33 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 9 Feb 2023 09:37:33 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v3]
In-Reply-To: 
References: 
Message-ID: 

> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
> 
> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
> 
> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1015/files
  - new: https://git.openjdk.org/jfx/pull/1015/files/0282896e..d707f321

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

  Stats: 54 lines in 7 files changed: 18 ins; 34 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1015.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1015/head:pull/1015

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

From kpk at openjdk.org  Thu Feb  9 09:37:39 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 9 Feb 2023 09:37:39 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Feb 2023 17:31:08 GMT, Andy Goryachev  wrote:

>> Karthik P K has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Renamed system test file
>>  - Fixing issue in all XYCharts
>
> modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 72:
> 
>> 70:     // -------------- PRIVATE FIELDS ------------------------------------------
>> 71: 
>> 72:     /** A multiplier for teh Y values that we store for each series, it is used to animate in a new series */
> 
> while we are at it, could we fix the comment "teh" -> "the"

Fixed this typo

> tests/system/src/test/java/test/javafx/scene/control/XYChartExceptionOnAddingRemovedSeriesTest.java line 94:
> 
>> 92:     @Test
>> 93:     public void testLineChartExceptionOnAddingRemovedSeries() throws Throwable {
>> 94:         Thread.sleep(1000); // Wait for stage to layout
> 
> I wonder if there is a better way of doing this, other than a long sleep?  Perhaps use some kind of a concurrency primitive?

Updated code to wait on `startupLatch` instead of sleep.

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

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

From kpk at openjdk.org  Thu Feb  9 09:42:56 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 9 Feb 2023 09:42:56 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Feb 2023 19:07:51 GMT, Andy Goryachev  wrote:

> two questions:
> 
>     1. should the timeline object be set to null here?  the reference will get overwritten in seriesRemoved():414, there is probably no need to keep this object in memory
> 
Yes timeline can be made null here. Updated the code.

>     2. is it possible that `seriesBeingRemovedIsAdded()` will be invoked twice with a different `series` argument?  In other words, are we going to face a situation when a `timeline` from unrelated series will not get `stop`'ped?
> 
> 
> (these question apply to other charts as well)

Since `seriesBeingRemovedIsAdded()` is called from the event handler which gets invoked when the series changes and further there is a check on `setToRemove` boolean, I believe the method will not be called with different `series` and cause unwanted `series` timeline to be stopped.

> tests/system/src/test/java/test/javafx/scene/control/XYChartExceptionOnAddingRemovedSeriesTest.java line 315:
> 
>> 313:             stage.show();
>> 314: 
>> 315:             Thread.currentThread().setUncaughtExceptionHandler((t2, e) -> {
> 
> I think it's better to set this handler in a pre-test method annotated with @Before, and clean up in @After - see, for instance, how it's done in BehaviorCleanupTest.

Updated code to set the handler in function annotated with @BeforeClass and cleaned up in  @AfterClass.

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

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

From kcr at openjdk.org  Thu Feb  9 12:40:51 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Feb 2023 12:40:51 GMT
Subject: RFR: Merge jfx20
Message-ID: 

Merfe `jfx20` branch into `master`.

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

Commit messages:
 - Merge jfx20
 - 8301832: InputMethodEvents are not enabled for text input controls
 - 8301797: Pagination control has the wrong size

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx/pull/1028/files
  Stats: 70 lines in 4 files changed: 63 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1028.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1028/head:pull/1028

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

From kcr at openjdk.org  Thu Feb  9 12:56:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Feb 2023 12:56:09 GMT
Subject: RFR: Merge jfx20 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Merfe `jfx20` branch into `master`.

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 15 additional commits since the last revision:

 - Merge jfx20
 - 8290092: Temporary files are kept when call Clipboard.getSystemClipboard().getImage()
   
   Reviewed-by: aghaisas
 - 8290765: Remove parent disabled/treeVisible listeners
   
   Reviewed-by: arapte, jhendrikx, nlisker
 - 8138842: TableViewSelectionModel.selectIndices does not select index 0
   
   Reviewed-by: angorya, aghaisas
 - 8298382: JavaFX ChartArea Accessibility Reader
   
   Reviewed-by: kcr, angorya
 - Merge
 - 8251862: Wrong position of Popup windows at the intersection of 2 screens
   
   Reviewed-by: aghaisas, arapte
 - 8301604: Replace Collections.unmodifiableList with List.of
   
   Reviewed-by: nlisker
 - 8299977: Update WebKit to 615.1
   
   Co-authored-by: Jay Bhaskar 
   Reviewed-by: kcr, sykora
 - 8237505: RadioMenuItem in ToggleGroup: deselected on accelerator
   
   Reviewed-by: angorya, aghaisas
 - ... and 5 more: https://git.openjdk.org/jfx/compare/a1d82e11...b9b2ba04

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1028/files
  - new: https://git.openjdk.org/jfx/pull/1028/files/b9b2ba04..b9b2ba04

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1028.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1028/head:pull/1028

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

From kcr at openjdk.org  Thu Feb  9 12:56:12 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Feb 2023 12:56:12 GMT
Subject: Integrated: Merge jfx20
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Feb 2023 12:36:05 GMT, Kevin Rushforth  wrote:

> Merfe `jfx20` branch into `master`.

This pull request has now been integrated.

Changeset: e7d31914
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx/commit/e7d31914b3f91076df7777a2e5da02c4c71150b0
Stats:     70 lines in 4 files changed: 63 ins; 5 del; 2 mod

Merge

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

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

From kpk at openjdk.org  Thu Feb  9 13:45:00 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 9 Feb 2023 13:45:00 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v5]
In-Reply-To: 
References: 
 <6955bMGClU0vbErwZCX4vBxudvI37GkmC7EjMlEIPXg=.1cf9c304-f58d-438b-88ad-72b8ee1973ad@github.com>
 
Message-ID: <-dTLr1FDrRl8XWTGuI30BPHkC1vnaCZSm9kY-lc_8LE=.74fd36d6-d5d1-4b3d-a947-3e323826be3b@github.com>

On Wed, 8 Feb 2023 20:03:05 GMT, Andy Goryachev  wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> For your convenience, I've added a Label page to the monkey tester
> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java
> 
> (sorry, it is still in a separate repository.  if you use Eclipse, just import the project into your workspace)

@andy-goryachev-oracle thanks for the code snippet and adding the Label page to the Monkey Tester.

In case of width calculation, the optimizations done in the code snippet is better since we avoid some computation. I implemented similar logic to `computePrefHeight()` method. 
With this optimization, for a case like empty text and empty graphic, the computed value of height will be 0.
This creates issue with some of the unit tests in `LabelSkinTest` because the expectation is that `computePrefHeight()` method returns single line string height for these cases. This is observed in unit test cases where we calculate preferred height and max height (max height also calls `computePrefHeight()` method).
Behaviorally there is no difference because a different method calculates the min height which returns the minimum height of a single line for the cases where text is empty and graphic is also null. But looking at the expected behavior of `computePrefHeight()` method from unit test cases, it looks like single line string height needs to be returned from this method in which case we will not be able to use this optimized `if-else` block since we have to calculate textHeight regardless of any conditions.
So if we have to optimize the `computePrefHeight()` method, the expected behavior also changes in these conditions.

Please let me know your thoughts on this.

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

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

From kpk at openjdk.org  Thu Feb  9 14:40:15 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 9 Feb 2023 14:40:15 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v6]
In-Reply-To: 
References: 
Message-ID: 

> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
> 
> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
> 
> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.

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

  Optimizing computePrefWidth method

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/996/files
  - new: https://git.openjdk.org/jfx/pull/996/files/ede9c535..ec748e56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=04-05

  Stats: 26 lines in 1 file changed: 10 ins; 6 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/996.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/996/head:pull/996

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

From kpk at openjdk.org  Thu Feb  9 14:40:17 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 9 Feb 2023 14:40:17 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <2VGz6F8aWXxWZxTxgbEV7E5ZWTv_vlco7leRSaz3WJI=.4a8bb3ed-8d9d-4fd5-9df9-786ca57db289@github.com>

On Wed, 8 Feb 2023 19:57:46 GMT, Andy Goryachev  wrote:

>> Previously both `textWidth` and `graphicWidth` were calculated regardless of the condition. In the updated code calculation of `graphicWidth` is moved to `else` block so that one unnecessary calculation is avoided. Since `textWidth` is used in 2 more conditions in `else` block, calculated it before the start of `if` block.
>> 
>> Since `isIgnoreText()` does more than just checking for `ContentDisplay` value, further reordering `if-else` statements generates different result than expected.
>> So this further leads to question previously raised by @hjohn, if `isIgnoreText()` and `isIgnoreGraphic()` should only check for ContetDisplay type or check for conditions like null/empty graphic or text as well. If this needs to be separated, again it gives raise to more conditions in the `computePrefWidth()` method.
>> 
>> Added boolean in the beginning as suggested.
>
> no, what I meant is try to make sure that any operations with text (and some other calls) are made only when they are needed.  
> 
> For example, this code avoids calling anything to do with text and font when isIgnoreText == true.
> 
> I also noticed that there is a field called `textWidth`; to avoid confusion I renamed the local variable from textWidth to `txWidth`.
> 
> 
>     /** {@inheritDoc} */
>     @Override
>     protected double computePrefWidth(double height, double topInset, double rightInset, double bottomInset,
>         double leftInset) {
>         // Get the preferred width of the text
>         final Labeled labeled = getSkinnable();
> 
>         boolean isIgnoreText = isIgnoreText();
>         double widthPadding = leftInset + rightInset;
> 
>         double txWidth;
>         if (isIgnoreText) {
>             txWidth = 0.0;
>         } else {
>             widthPadding += (leftLabelPadding() + rightLabelPadding());
> 
>             String cleanText = getCleanText();
>             boolean emptyText = cleanText == null || cleanText.isEmpty();
>             if (emptyText) {
>                 txWidth = 0.0;
>             } else {
>                 Font font = text.getFont();
>                 txWidth = Utils.computeTextWidth(font, cleanText, 0);
>             }
>         }
> 
>         double width;
>         if (isIgnoreGraphic()) {
>             width = txWidth;
>         } else {
>             // Fix for RT-39889
>             double grWidth = graphic == null ? 0.0
>                 : Utils.boundedSize(graphic.prefWidth(-1), graphic.minWidth(-1), graphic.maxWidth(-1));
> 
>             if (isIgnoreText) {
>                 width = grWidth;
>             } else {
>                 ContentDisplay cd = labeled.getContentDisplay();
>                 if (cd == ContentDisplay.LEFT || cd == ContentDisplay.RIGHT) {
>                     width = txWidth + labeled.getGraphicTextGap() + grWidth;
>                 } else {
>                     width = Math.max(txWidth, grWidth);
>                 }
>             }
>         }
> 
>         return width + widthPadding;
>     }
> 
> 
> I suggest we apply a similar treatment to the second method being modified.

Updated `computePrefWidth()` method.
Please refer to my comment at the end regarding `computePrefHeight()` method optimization observations.

>> Since `clenText` is used in `textHeight` calculation, this cannot be avoided before the `if-else` block as `if-else` block is not re-ordered now. Please refer to the previous comment for the details on `computePrefHeight()` method.
>
> please see my earlier code sample, it is possible.
> cleanText is only needed to get the textWidth, and that is only needed when isIgnoreText == false.
> Also note that `textWidth` here is a local and hides an instance field with the same name.  Rename the local?

Changed local variable name.
Please refer to my comment at the end regarding `computePrefHeight()` method optimization.

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

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

From angorya at openjdk.org  Thu Feb  9 16:30:59 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Feb 2023 16:30:59 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Feb 2023 09:37:33 GMT, Karthik P K  wrote:

>> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
>> 
>> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
>> 
>> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

asking for one change.

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

Changes requested by angorya (Committer).

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

From angorya at openjdk.org  Thu Feb  9 16:31:04 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Feb 2023 16:31:04 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 9 Feb 2023 09:39:49 GMT, Karthik P K  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 562:
>> 
>>> 560:         if (timeline != null) {
>>> 561:             timeline.setOnFinished(null);
>>> 562:             timeline.stop();
>> 
>> two questions:
>> 
>> 1. should the timeline object be set to null here?  the reference will get overwritten in seriesRemoved():414, there is probably no need to keep this object in memory
>> 2. is it possible that `seriesBeingRemovedIsAdded()` will be invoked twice with a different `series` argument?  In other words, are we going to face a situation when a `timeline` from unrelated series will not get `stop`'ped?
>> 
>> (these question apply to other charts as well)
>
>> two questions:
>> 
>>     1. should the timeline object be set to null here?  the reference will get overwritten in seriesRemoved():414, there is probably no need to keep this object in memory
>> 
> Yes timeline can be made null here. Updated the code.
> 
>>     2. is it possible that `seriesBeingRemovedIsAdded()` will be invoked twice with a different `series` argument?  In other words, are we going to face a situation when a `timeline` from unrelated series will not get `stop`'ped?
>> 
>> 
>> (these question apply to other charts as well)
> 
> Since `seriesBeingRemovedIsAdded()` is called from the event handler which gets invoked when the series changes and further there is a check on `setToRemove` boolean, I believe the method will not be called with different `series` and cause unwanted `series` timeline to be stopped.

Thank you for clarification, @karthikpandelu

>> tests/system/src/test/java/test/javafx/scene/control/XYChartExceptionOnAddingRemovedSeriesTest.java line 315:
>> 
>>> 313:             stage.show();
>>> 314: 
>>> 315:             Thread.currentThread().setUncaughtExceptionHandler((t2, e) -> {
>> 
>> I think it's better to set this handler in a pre-test method annotated with @Before, and clean up in @After - see, for instance, how it's done in BehaviorCleanupTest.
>
> Updated code to set the handler in function annotated with @BeforeClass and cleaned up in  @AfterClass.

I am not sure setting uncaught exception handler in @BeforeClass and clearing it in @AfterClass is correct.
The junit framework may execute these tests in parallel or sequentially (I think these are actually executed sequentially), but I would not rely on the fact that the individual tests will be executed in the same thread.

So I'd suggest to move this code to @After and @Before, just like BehaviorCleanupTest and other tests.

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

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

From angorya at openjdk.org  Thu Feb  9 16:55:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Feb 2023 16:55:00 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Feb 2023 14:40:15 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimizing computePrefWidth method

looks good now, confirmed with junit and the MonkeyTester.

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

Marked as reviewed by angorya (Committer).

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

From angorya at openjdk.org  Thu Feb  9 16:55:03 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Feb 2023 16:55:03 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v2]
In-Reply-To: 
References: 
 
 
 <_pKKZHdjgIxQgH-GNcUj6kZuRwGRpZ8PNmH2TBr3org=.6d0eca9f-8331-4b60-aa6e-bdd4a74b0643@github.com>
 
 
Message-ID: 

On Mon, 6 Feb 2023 14:23:38 GMT, Karthik P K  wrote:

>> Both `computePrefHeight()` and `computePrefWidth` can be restructured to avoid unnecessary computation (especially since these are very popular objects).
>> 
>> My point is that, for example, textWidth on line 375 (used to compute textHeight:375) is not used if isIgnoreText() == true.  
>> 
>> Similarly, graphicHeight:380 is not used if isIgnoreGraphic() == true, line 386.
>> 
>> Same optimization can be applied to computePrefWidth():315
>> 
>> Just a suggestion, really.
>
> Understood.
> I have optimized the code. Please take a look.
> Did following optimizations in the code:
> 
> - Optimized `if else` conditions by moving the `graphicHeight` and `graphicWidth` value calculation inside the else statement in `computePrefHeight` and `computePrefWidth` methods respectively.
> - Removed unused `graphic` variable.
> - In `computePrefHeight` method, since a `if` condition was already present which was same as the one used for `padding` calculation, moved `padding` calculation code to the same location.
> - In `computePrefWidth` method, replaced multiple return statements with single statement for better readability and did minor optimizations.

looks good, thank you.

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

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

From kcr at openjdk.org  Fri Feb 10 00:02:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Feb 2023 00:02:58 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v46]
In-Reply-To: 
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 
Message-ID: 

On Mon, 23 Jan 2023 03:51:33 GMT, Thiago Milczarek Sayao  wrote:

>> This cleans size and positioning code, reducing special cases, code complexity and size.
>> 
>> Changes:
>> 
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
>> - window geometry, min/max size are centralized in `update_window_constraints`;
>> - Frame extents (the window decoration size used for "total window size"):
>>     - frame extents are received in `process_property_notify`;
>>     - removed quirks in java code;
>>     - When received, call `set_bounds` again to adjust the size (to account decorations later received);
>> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it.
>> - `ensure_window_size` was a quirk - removed;
>> - `requested_bounds` removed - not used anymore;
>> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`;
>> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point)
>> - `restack` split in `to_front()` and `to_back()` to conform to managed code;
>> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`;
>> - Note:  `geometry_get_*` and `geometry_set_*` moved location but unchanged.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Fix JDK-8089923
>  - Fix JDK-8089923
>  - Fix JDK-8089923
>  - Fix deiconify regression

I did some more testing with the latest version, which includes the debug print statements. It runs fine on Ubuntu 16.04 with the just the minor previously reported failures.

On Ubuntu 20.04 I still see the race condition where most of the time the content is offset and the black band appears right below the window decoration. I managed to try it on a physical machine and get the same result, so it isn't due to running in VirtualBox. Here is the debug output:


$ java DragFailure2
set gravity: 0.500000, 0.333333
set_bounds -> x = 745, y = 231, w = 500, h = 300, cw = -1, ch = -1
notify window size -> w = 500, h = 300
notify view size -> cw = 500, ch = 300
set_bounds -> x = -1, y = -1, w = 500, h = 300, cw = 500, ch = 263
notify window size -> w = 500, h = 300
notify view size -> cw = 500, ch = 263
notify window size -> w = 500, h = 300
notify view size -> cw = 500, ch = 263


Clicking anywhere causes it to refresh.

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

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

From angorya at openjdk.org  Fri Feb 10 00:18:43 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Feb 2023 00:18:43 GMT
Subject: RFR: 8299986: Wrong sublist used in ListChangeListener
Message-ID: 

The obvious coding error has been corrected in two places.

No unit tests have been added because
a) the issue did not result in any apparent behavioral changes as it only affects  what is effectively cleanup
b) I found no easy way to construct a unit test without getting deep into implementation code

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

Commit messages:
 - 8299986: Wrong sublist used in ListChangeListener

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

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

From kpk at openjdk.org  Fri Feb 10 05:11:53 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 05:11:53 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v6]
In-Reply-To: 
References: 
 
Message-ID: <-CbytXii1T0QZp2WKWjGeUzC_DhF4_F_vnXGUU9AIrs=.5f7f4412-1cad-4c04-b425-5577ce799db3@github.com>

On Thu, 9 Feb 2023 14:40:15 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimizing computePrefWidth method

Thanks Andy.
@aghaisas and @hjohn, since there has been code changes after your approval, looks like the PR is not getting added with ready label.
Could you please review and approve the changes.

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

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

From kpk at openjdk.org  Fri Feb 10 05:28:07 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 05:28:07 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v4]
In-Reply-To: 
References: 
Message-ID: 

> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
> 
> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
> 
> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1015/files
  - new: https://git.openjdk.org/jfx/pull/1015/files/d707f321..146bef2a

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

  Stats: 14 lines in 1 file changed: 11 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1015.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1015/head:pull/1015

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

From kpk at openjdk.org  Fri Feb 10 05:28:09 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 05:28:09 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 9 Feb 2023 16:27:46 GMT, Andy Goryachev  wrote:

>> Updated code to set the handler in function annotated with @BeforeClass and cleaned up in  @AfterClass.
>
> I am not sure setting uncaught exception handler in @BeforeClass and clearing it in @AfterClass is correct.
> The junit framework may execute these tests in parallel or sequentially (I think these are actually executed sequentially), but I would not rely on the fact that the individual tests will be executed in the same thread.
> 
> So I'd suggest to move this code to @After and @Before, just like BehaviorCleanupTest and other tests.

Moved the code to @Before and @After. Please check

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

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

From kpk at openjdk.org  Fri Feb 10 05:39:33 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 05:39:33 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v4]
In-Reply-To: 
References: 
Message-ID: 

> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
> 
> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
> 
> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.

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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into textfield_issue_fix
 - Update comments
 - Fix textfield right and center alignment issues
 - Fix for TextField right alignement issue

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/980/files
  - new: https://git.openjdk.org/jfx/pull/980/files/8c1cd0c2..622cac30

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

  Stats: 204507 lines in 6889 files changed: 121197 ins; 43586 del; 39724 mod
  Patch: https://git.openjdk.org/jfx/pull/980.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/980/head:pull/980

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

From jhendrikx at openjdk.org  Fri Feb 10 08:36:57 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Feb 2023 08:36:57 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Feb 2023 14:40:15 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimizing computePrefWidth method

Marked as reviewed by jhendrikx (Committer).

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

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

From aghaisas at openjdk.org  Fri Feb 10 10:00:06 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 10 Feb 2023 10:00:06 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Feb 2023 14:40:15 GMT, Karthik P K  wrote:

>> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
>> 
>> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
>> 
>> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimizing computePrefWidth method

Looks good!

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

Marked as reviewed by aghaisas (Reviewer).

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

From jhendrikx at openjdk.org  Fri Feb 10 10:55:52 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Feb 2023 10:55:52 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 Dec 2022 10:33:15 GMT, Ajit Ghaisas  wrote:

> The proposed fix fixes the reported issue.
> 
> **Regarding the question of changing current behavior of RIGHT alignment of the TextField:** If the string is larger than the TextField width -
> 
> * LEFT align should result in - Start of the text visible and end of the text hidden.
> * RIGHT align should result in - End of the text visible at the right edge of the TextField and start of the text hidden.
> 
> Right now, only the LEFT align behaves correctly. RIGHT align behaves correctly only if the string is smaller than the TextField width. The moment string length is larger than TextField width, it starts behaving opposite (start of the text visible and end of the text hidden.) I don't know whether there is some rationale for this implementation or it is a bug which went unnoticed till now.

I'm not entirely convinced this is a bug -- it seems quite intentionally built this way.  

A reason why you may want to show the left hand side of the text if it doesn't fit is that the exact length of text and the exact size of a (resizable) UI is hard to predict before hand.  When presented with a new control where the text doesn't fit, it may make more sense and be more natural to show the user the start of the text.

We may want to check how other UI toolkits are handling these cases.

In any case, this current fix has a problem where the cursor can get lost (field is not scrolled to show it), while the current implementation has no such issues.

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

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

From kpk at openjdk.org  Fri Feb 10 11:00:03 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 11:00:03 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <9VBpxSSToB43gPuIKHU76i2cnn4YAAdg0TQrIJPQ7a4=.9a583adc-f07b-49f2-aec1-a160b47439de@github.com>

On Fri, 10 Feb 2023 09:57:21 GMT, Ajit Ghaisas  wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimizing computePrefWidth method
>
> Looks good!

@aghaisas please sponsor this PR.

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

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

From jhendrikx at openjdk.org  Fri Feb 10 11:02:07 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Feb 2023 11:02:07 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Feb 2023 05:39:33 GMT, Karthik P K  wrote:

>> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
>> 
>> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
>> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
>> 
>> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into textfield_issue_fix
>  - Update comments
>  - Fix textfield right and center alignment issues
>  - Fix for TextField right alignement issue

Before fix:
![image](https://user-images.githubusercontent.com/995917/218075416-86beba82-ad09-4c06-ae4b-97352666e353.png)
After fix:
![image](https://user-images.githubusercontent.com/995917/218075565-f4e70353-eeef-4168-872f-00726596423e.png)
I don't think I really like how the too long texts are represented initially in the second screenshot.

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

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

From kpk at openjdk.org  Fri Feb 10 11:17:59 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 11:17:59 GMT
Subject: Integrated: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Jan 2023 10:46:12 GMT, Karthik P K  wrote:

> Ignore text condition was not considered in `computePrefHeight` method while calculating the Label height.
> 
> Added `isIgnoreText` condition in `computePrefHeight` method while calculating Label height.
> 
> Tests are present for all the ContentDisplay types. Modified tests which were failing because of the new height value getting calculated.

This pull request has now been integrated.

Changeset: d3654e3a
Author:    Karthik P K 
Committer: Ajit Ghaisas 
URL:       https://git.openjdk.org/jfx/commit/d3654e3aff06a70246ba969698ae2a04d92972c0
Stats:     84 lines in 2 files changed: 27 ins; 24 del; 33 mod

8230833: LabeledSkinBase computes wrong height with ContentDisplay.GRAPHIC_ONLY

Reviewed-by: aghaisas, jhendrikx, angorya

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

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

From pedro.duquevieira at gmail.com  Fri Feb 10 13:29:24 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Fri, 10 Feb 2023 13:29:24 +0000
Subject: Alt key sticks even after app loses focus (JDK-8090647)
Message-ID: 

Hi,

I'm developing an application for a customer and it seems like we've been
hit by: JDK-8090647  (?)

Steps:

1 - press alt + tab to switch to another app
2 - press alt + tab again to switch to javafx app again
3 - type a key with an associated "mnemonic action" in the javafx app (no
alt key being pressed)

4 - "mnemonic action" gets triggered even though it shouldn't

So the problem is that the alt seems to "stick" after the javafx app loses
and regains focus (through alt + tab) .


I've tested this under Windows 10 and Windows 11.

This is problematic to us since our users often use the keyboard to
interact with our app and the previous version of our app (built in a
different language than Java) didn't have this problem.

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

From kpk at openjdk.org  Fri Feb 10 13:51:59 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Feb 2023 13:51:59 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Feb 2023 05:39:33 GMT, Karthik P K  wrote:

>> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
>> 
>> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
>> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
>> 
>> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into textfield_issue_fix
>  - Update comments
>  - Fix textfield right and center alignment issues
>  - Fix for TextField right alignement issue

I checked with HTML textfield and swing JTextField. In both the cases, the text gets aligned to the left (beginning of the text is shown) regardless of alignment type when text length is more than text field length.
In html textfield, even prompt text has same behavior but in JavaFX prompt text gets aligned to the center (center of the text is displayed) or right (beginning of the text is hidden) as specified even when the prompt text length is more than textfield length.

The case where prompt text length is more than text field length might not be frequent but I think we should have same behavior for both. So I think we should fix either the behavior of the text or the  prompt text so that both are consistent.

I went ahead with the option of fixing the behavior of text because aligning the text according to the set value regardless of the text length looked like predictable behavior.
Let me know your thoughts on this.

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

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

From angorya at openjdk.org  Fri Feb 10 16:02:02 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Feb 2023 16:02:02 GMT
Subject: RFR: 8088998: XYChart: duplicate child added exception when remove
 & add a series in several charts [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Feb 2023 05:28:07 GMT, Karthik P K  wrote:

>> While checking for duplicate series addition to the line chart, `setToRemove` value was not considered before throwing exception. Hence code to handling the case of adding the removed series was never run.
>> 
>> Added condition to check `setToRemove` boolean value before throwing exception. Made changes to call `setChart` method after calling `seriesBeingRemovedIsAdded`. Otherwise chart will not be drawn for the series, only points will be plotted.
>> 
>> This issue is reproducible only when animation is enabled because timeline will be still running when removed series is added back to the same chart. Since timeline does not run in unit tests, added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

looks good, thank you.

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

Marked as reviewed by angorya (Committer).

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

From angorya at openjdk.org  Fri Feb 10 16:51:57 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Feb 2023 16:51:57 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Feb 2023 05:39:33 GMT, Karthik P K  wrote:

>> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
>> 
>> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
>> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
>> 
>> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into textfield_issue_fix
>  - Update comments
>  - Fix textfield right and center alignment issues
>  - Fix for TextField right alignement issue

I think the behavior with the fix is correct - it should follow the alignment setting.

@hjohn is right on one account - scroll to cursor is not working right.  to reproduce
- set the alignment to either *_RIGHT or *_CENTER
- set a long text string (longer than can fit the control)
- click on the visible area and repeatedly move cursor left beyond the left edge.
Expected:
-- the view should scroll horizontally to bring the caret back into the view
Observed with the fix:
-- it doesn't

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

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

From jhendrikx at openjdk.org  Fri Feb 10 18:59:52 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Feb 2023 18:59:52 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 10 Feb 2023 13:49:43 GMT, Karthik P K  wrote:

> I checked with HTML textfield and swing JTextField. In both the cases, the text gets aligned to the left (beginning of the text is shown) regardless of alignment type when text length is more than text field length. In html textfield, even prompt text has same behavior but in JavaFX prompt text gets aligned to the center (center of the text is displayed) or right (beginning of the text is hidden) as specified even when the prompt text length is more than textfield length.

Thanks for checking this, so it's possible the behavior was modelled after this common behavior of other toolkits (or just good sense in general).

> The case where prompt text length is more than text field length might not be frequent but I think we should have same behavior for both. So I think we should fix either the behavior of the text or the prompt text so that both are consistent.

Yes, agreed on that.  I would personally lean towards fixing the prompt text then, but before we keep going back and forth it might be good to see what @kevinrushforth and others think of this.

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

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

From john.hendrikx at gmail.com  Fri Feb 10 19:27:11 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 10 Feb 2023 20:27:11 +0100
Subject: Alt key sticks even after app loses focus (JDK-8090647)
In-Reply-To: 
References: 
Message-ID: 

The behavior on Windows is all over the place for different 
applications.? I tested a few I've got running:

Notepad, Notepad++, Eclipse:

- Alt-down: Shows mnemonics on menu bar
- Alt-up: Highlights file menu on alt release
- Alt-tab: Shows mnemonics but doesn't highlight menu when it loses 
focus; when returning, mnemonics still highlighted, but doesn't act on 
them as menu not selected

-> Looks buggy

Thunderbird / Opera / Firefox:

- Alt-down: nothing
- Alt-up: shows menu bar (it is hidden normally)
- Alt-tab: works as expected, no highlighting

-> Looks well behaved

Explorer / Excel / Wordpad:

- Alt-down: nothing
- Alt-up: shows mnemonics
- Alt-tab: works as expected, no highlighting

-> Looks well behaved

Visual Studio Code:

- Alt-down: Shows mnemonics on menu bar
- Alt-up: Highlights file menu on alt release
- Alt-tab: Shows mnemonics, but hides them once it loses focus; on 
return doesn't show mnemonics

-> Looks well behaved

Chrome / IntelliJ:

-> Looks well behaved, doesn't react to alt presses in any way

None of the applications tested reacted on a mnemonic key after 
regaining focus however, even though they may have them still 
highlighted (which I think is a bug).

In my opinion, the behavior of notepad/notepad++/eclipse is incorrect 
(they need to hide the mnemonics on focus lost, like Visual Studio Code 
does, but they don't).

There seems to be two correct ways of handling mnemonics in applications 
that use them, either:

a) shows mnemonics immediately on alt-down, but hide them on focus lost 
(if the alt-down becomes an alt-tab, or probably any other alt combination)

b) only show mnemonics on a naked alt-up

Ticket JDK-8090647 mentions a spec that has been updated, but I can't 
find it.? It also mentions that the behavior for JavaFX should be what I 
described in a), so I think this is a bug that can simply be fixed.

--John

On 10/02/2023 14:29, Pedro Duque Vieira wrote:
> Hi,
>
> I'm developing an application for a customer and it seems like we've 
> been hit by: JDK-8090647 ?(?)
>
> Steps:
>
> 1 - press alt + tab to switch to another app
> 2 - press alt + tab again to switch to javafx app again
> 3 - type a key with an associated "mnemonic action" in the javafx app 
> (no alt key being pressed)
>
> 4 - "mnemonic action" gets triggered even though it shouldn't
>
> So the problem is that the alt seems to "stick" after the javafx app 
> loses and regains focus (through alt + tab) .
>
>
> I've tested this under Windows 10 and Windows 11.
>
> This is problematic to us since our users often use the keyboard to 
> interact with our app and the previous version of our app (built in a 
> different language than Java) didn't have?this problem.
>
> --
>
> Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Fri Feb 10 22:38:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Feb 2023 22:38:33 GMT
Subject: RFR: 8299986: Wrong sublist used in ListChangeListener
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Feb 2023 23:53:00 GMT, Andy Goryachev  wrote:

> The obvious coding error has been corrected in two places.
> 
> No unit tests have been added because
> a) the issue did not result in any apparent behavioral changes as it only affects  what is effectively cleanup
> b) I found no easy way to construct a unit test without getting deep into implementation code

Seems worth fixing such an obvious typo.

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

Marked as reviewed by kcr (Lead).

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

From angorya at openjdk.org  Fri Feb 10 22:45:35 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Feb 2023 22:45:35 GMT
Subject: Integrated: 8299986: Wrong sublist used in ListChangeListener
In-Reply-To: 
References: 
Message-ID: <6BmjhBbZ9CqRh0Tp9YYP6WF7Y0TT3gXktvd2a_8NOWs=.0369e918-93ed-4541-94e0-f2b73d2e3377@github.com>

On Thu, 9 Feb 2023 23:53:00 GMT, Andy Goryachev  wrote:

> The obvious coding error has been corrected in two places.
> 
> No unit tests have been added because
> a) the issue did not result in any apparent behavioral changes as it only affects  what is effectively cleanup
> b) I found no easy way to construct a unit test without getting deep into implementation code

This pull request has now been integrated.

Changeset: 55eb83da
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/55eb83daa2ab97dcd8b112d2d4208c0a628cbc38
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8299986: Wrong sublist used in ListChangeListener

Reviewed-by: kcr

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

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

From michaelstrau2 at gmail.com  Sat Feb 11 05:31:09 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 11 Feb 2023 06:31:09 +0100
Subject: Feedback requested for infrastructure for properties that wish to
 delay registering listeners
In-Reply-To: 
References: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com>
 
 
 
Message-ID: 

I think that we are conflating two distinct questions in this discussion:

1. The first question is whether a listener that is registered on an
ObservableValue should prevent the ObservableValue from being eligible
for garbage collection.

2. The second question is whether the object contained in an
ObservableValue should hold a strong reference back to the
ObservableValue.

I'm only addressing the second question here. ObservableValue is a
property system: it allows developers to declare named values (much
like fields, but in addition to fields, it also allows observers to
see when the value was changed). It seems obvious to me that, while a
field refers to its value, the value of a field should not magically
refer back to the field itself (or its declaring object). Unless, of
course, the back-reference is manually added by the developer.
Similarly, the value of an ObservableValue should not magically refer
back to the ObservableValue; it is a one-way dependency by default.

This one-way dependency makes a lot of sense: it binds the lifetime of
the contained value to the lifetime of the property wrapper. The
inverse makes no sense: why should the lifetime of the property
wrapper be bound to the lifetime of its value? Plain fields don't work
like this, neither do Beans, C#'s language properties, WPF's
DependencyProperty, or any other property system that I've come
across.

And that's how most implementations in JavaFX work. Consider
ObjectProperty: the contained value will not refer to ObjectProperty,
regardless of whether listeners are registered on ObjectProperty.

But ListProperty is an anomaly: it adds a ListChangeListener to its
contained list, which causes the contained list to magically refer
back to ListProperty without the intervention of the developer. This
violates the expectation that there's a one-way dependency between an
ObservableValue and its contained value.

The anomaly is caused by the decision to have ListProperty also
implement ObservableList: this makes it looks like ListProperty (this
is our ObservableValue) is actually the same thing as its contained
value (the ObservableList). But it's not, from the perspective of
ObservableValue these are two very distinct things. One is the
wrapper, the other is the contained value.

Purely as an implementation detail, ListProperty needs the internal
ListChangeListener to replay the changes of its contained list, in
order to perfectly masquerade as its contained list. But
implementation details shouldn't change the semantics of the
fundamental API, and this is why the internal dependency between
ListProperty and its contained list needs to be broken by a weak
reference.

Note that I'm not talking about listener semantics at all. This is
just about the semantics that govern the relationship between an
ObservableValue and its contained value. Florian's PR is a targeted
fix for this very specific bug, and I remain convinced that this is a
bug.

Furthermore, fixing this bug has no bearing on whether and how we
address question 1, which you are passionate about. Leaving the
current behavior as-is does not bring us closer to having "sticky
listeners". It seems to me that much of what you've written is an
endorsement for sticky listeners, but does not address the very narrow
problem of the PR in question.


>> But the test shouldn't ever fail, because the ObservableList that is
>> wrapped by ListProperty should never keep a strong reference to the
>> ListProperty, even if the ListProperty is itself observed.
> Why should it work that way?  The alternative is that my listener is
> discarded without my knowledge.

You didn't add a listener to the contained list; you added a listener
to the property wrapper. This listener is not discarded.
It may seem like it was, but that's only because ListProperty fooled
us into thinking it was the same thing as its contained list.

From kcr at openjdk.org  Sat Feb 11 14:17:04 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:17:04 GMT
Subject: [jfx11u] RFR: 8295755: Update SQLite to 3.39.4
Message-ID: 

Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8295755: Update SQLite to 3.39.4

Changes: https://git.openjdk.org/jfx11u/pull/130/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295755
  Stats: 11694 lines in 4 files changed: 5822 ins; 1215 del; 4657 mod
  Patch: https://git.openjdk.org/jfx11u/pull/130.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/130/head:pull/130

PR: https://git.openjdk.org/jfx11u/pull/130

From kcr at openjdk.org  Sat Feb 11 14:18:07 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:18:07 GMT
Subject: [jfx11u] RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
Message-ID: 

Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON

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

PR: https://git.openjdk.org/jfx11u/pull/129

From kcr at openjdk.org  Sat Feb 11 14:18:20 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:18:20 GMT
Subject: [jfx11u] RFR: 8298167: Opacity in WebView not working anymore
Message-ID: 

Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8298167: Opacity in WebView not working anymore

Changes: https://git.openjdk.org/jfx11u/pull/131/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298167
  Stats: 76 lines in 3 files changed: 72 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx11u/pull/131.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/131/head:pull/131

PR: https://git.openjdk.org/jfx11u/pull/131

From kcr at openjdk.org  Sat Feb 11 14:19:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:19:14 GMT
Subject: [jfx11u] RFR: 8301712: [linux] Crash on exit from WebKit 615.1
Message-ID: 

Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8301712: [linux] Crash on exit from WebKit 615.1

Changes: https://git.openjdk.org/jfx11u/pull/133/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301712
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx11u/pull/133.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/133/head:pull/133

PR: https://git.openjdk.org/jfx11u/pull/133

From kcr at openjdk.org  Sat Feb 11 14:32:21 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:32:21 GMT
Subject: [jfx11u] RFR: 8299977: Update WebKit to 615.1
Message-ID: 

Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8299977: Update WebKit to 615.1

Changes: https://git.openjdk.org/jfx11u/pull/132/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299977
  Stats: 197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod
  Patch: https://git.openjdk.org/jfx11u/pull/132.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/132/head:pull/132

PR: https://git.openjdk.org/jfx11u/pull/132

From kcr at openjdk.org  Sat Feb 11 14:38:40 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:38:40 GMT
Subject: [jfx11u] RFR: 8299977: Update WebKit to 615.1
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:11:24 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

As often happens with a very large patch like this one, Skara has not marked it clean even though it is. Here is the diff of the two patches:


$ diff 301bbd6409d463c4f789e2b3dcb6b2ea200d7373.patch 65c73e5ab15ef095a09b95b5a012fbe3636a1cfd.patch
1c1
< commit 301bbd6409d463c4f789e2b3dcb6b2ea200d7373
---
> commit 65c73e5ab15ef095a09b95b5a012fbe3636a1cfd
167546c167546
< index 23efcd5441..17752cafb9 100644
---
> index acd7c980f3..4d716d6ca7 100644
342135c342135
< index afbd76f473..d6559d19c1 100644
---
> index 4ad0097a28..1802773ccd 100644
342176c342176
< @@ -649,10 +649,10 @@ void GraphicsContextJava::strokeRect(const FloatRect& rect, float lineWidth)
---
> @@ -645,10 +645,10 @@ void GraphicsContextJava::strokeRect(const FloatRect& rect, float lineWidth)
342190c342190
< @@ -742,10 +742,10 @@ void GraphicsContextJava::strokePath(const Path& path)
---
> @@ -738,10 +738,10 @@ void GraphicsContextJava::strokePath(const Path& path)
342204c342204
< @@ -869,26 +869,26 @@ void GraphicsContextJava::fillPath(const Path& path)
---
> @@ -865,26 +865,26 @@ void GraphicsContextJava::fillPath(const Path& path)
342240c342240
< @@ -993,37 +993,37 @@ AffineTransform GraphicsContextJava::getCTM(IncludeDeviceScale) const
---
> @@ -989,37 +989,37 @@ AffineTransform GraphicsContextJava::getCTM(IncludeDeviceScale) const
342292c342292
< @@ -1036,6 +1036,8 @@ void GraphicsContextJava::fillRoundedRectImpl(const FloatRoundedRect& rect, cons
---
> @@ -1032,6 +1032,8 @@ void GraphicsContextJava::fillRoundedRectImpl(const FloatRoundedRect& rect, cons
342302c342302
< index a27102d804..6ce99ab62f 100644
---
> index 526ee45a1f..209790bcae 100644
447690c447690
< index 10832859f7..4dc5171f39 100644
---
> index 5cea56639d..d0a174e233 100644


There are no differences in the two patches, either in the diffs themselves or in the surrounding context. The line numbers are different because the mainline patch was done on top of the fix for [JDK-8298167](https://bugs.openjdk.org/browse/JDK-8298167), which added (unconflicting) code to `GraphicsContextJava.cpp`, whereas the backport patch was not. This isn't what is causing Skara to fail to mark this as clean, though. Rather the failure of Skara to mark this as clean is another instance of [SKARA-1332](https://bugs.openjdk.org/browse/SKARA-1332). I am manually marking it clean.

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

PR: https://git.openjdk.org/jfx11u/pull/132

From kcr at openjdk.org  Sat Feb 11 14:41:34 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:41:34 GMT
Subject: [jfx11u] RFR: 8299977: Update WebKit to 615.1
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:11:24 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

It turns out I just wasn't patient enough and didn't refresh the PR before posting my comment. Skara marked it clean after all. :)

So you can ignore my previous comment (although it was a good double-check that the patch was in fact clean).

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

PR: https://git.openjdk.org/jfx11u/pull/132

From kcr at openjdk.org  Sat Feb 11 14:48:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:48:35 GMT
Subject: [jfx11u] Integrated: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: 
References: 
Message-ID: <14Bmcbi4_GSC1DLfP4lYgf2oFkod_ciFZPzAc85epSI=.50bded39-af3b-4b91-ac5f-60ee2353eb5d@github.com>

On Sat, 11 Feb 2023 14:10:59 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: ac4756c6
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx11u/commit/ac4756c6b2365688d6340ff0efb379dd247b7e2b
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON

Backport-of: 28f8fa9c20363ced9a94787ecfd45735b3e6b82e

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

PR: https://git.openjdk.org/jfx11u/pull/129

From kcr at openjdk.org  Sat Feb 11 14:49:15 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:49:15 GMT
Subject: [jfx17u] RFR: 8298167: Opacity in WebView not working anymore
Message-ID: <4c4kMyXHLnuNuUMHFIxxvZn7t9ErJH9bahTQOiYDpfI=.7c86444b-8dce-40f8-92cf-e87bcf460985@github.com>

Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8298167: Opacity in WebView not working anymore

Changes: https://git.openjdk.org/jfx17u/pull/111/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=111&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298167
  Stats: 76 lines in 3 files changed: 72 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx17u/pull/111.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/111/head:pull/111

PR: https://git.openjdk.org/jfx17u/pull/111

From kcr at openjdk.org  Sat Feb 11 14:49:24 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:49:24 GMT
Subject: [jfx17u] RFR: 8295755: Update SQLite to 3.39.4
Message-ID: <1i4M8vnaX7Eeg785Ksq4YyhURdfmZcKq_cyu6XzmIas=.f16d91d1-ac21-482c-affe-53ebeee8bb3d@github.com>

Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8295755: Update SQLite to 3.39.4

Changes: https://git.openjdk.org/jfx17u/pull/110/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295755
  Stats: 11694 lines in 4 files changed: 5822 ins; 1215 del; 4657 mod
  Patch: https://git.openjdk.org/jfx17u/pull/110.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/110/head:pull/110

PR: https://git.openjdk.org/jfx17u/pull/110

From kcr at openjdk.org  Sat Feb 11 14:49:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:49:35 GMT
Subject: [jfx11u] Integrated: 8295755: Update SQLite to 3.39.4
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:11:05 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: 903bef50
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx11u/commit/903bef506d34ab14774e79fcc6e10ed8e0944f5d
Stats:     11694 lines in 4 files changed: 5822 ins; 1215 del; 4657 mod

8295755: Update SQLite to 3.39.4

Backport-of: 9f6ec88b222461da9486911ecefb68a936e5fc77

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

PR: https://git.openjdk.org/jfx11u/pull/130

From kcr at openjdk.org  Sat Feb 11 14:51:12 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:51:12 GMT
Subject: [jfx17u] RFR: 8301712: [linux] Crash on exit from WebKit 615.1
Message-ID: 

Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8301712: [linux] Crash on exit from WebKit 615.1

Changes: https://git.openjdk.org/jfx17u/pull/113/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301712
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx17u/pull/113.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/113/head:pull/113

PR: https://git.openjdk.org/jfx17u/pull/113

From kcr at openjdk.org  Sat Feb 11 14:51:36 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:51:36 GMT
Subject: [jfx11u] Integrated: 8298167: Opacity in WebView not working anymore
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:11:14 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: fc8904a3
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx11u/commit/fc8904a32e99b8182714f5a806be53f6dc124859
Stats:     76 lines in 3 files changed: 72 ins; 0 del; 4 mod

8298167: Opacity in WebView not working anymore

Backport-of: 8136b11fdc75aba64d8b77cf286097db3e12d6c9

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

PR: https://git.openjdk.org/jfx11u/pull/131

From kcr at openjdk.org  Sat Feb 11 14:58:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 14:58:38 GMT
Subject: [jfx11u] Integrated: 8299977: Update WebKit to 615.1
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:11:24 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: b0eed55c
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx11u/commit/b0eed55ce5b08967fa280d6b2416ad5f267586cb
Stats:     197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod

8299977: Update WebKit to 615.1

Backport-of: 301bbd6409d463c4f789e2b3dcb6b2ea200d7373

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

PR: https://git.openjdk.org/jfx11u/pull/132

From kcr at openjdk.org  Sat Feb 11 15:00:39 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 15:00:39 GMT
Subject: [jfx11u] Integrated: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:11:31 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 4 other WebKit fixes in the `test-kcr-11.0.19` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: a7a610e2
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx11u/commit/a7a610e2f090e2683bb2d1ea2588830326ead79c
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8301712: [linux] Crash on exit from WebKit 615.1

Backport-of: 13d8df31e7bc4336d01ec859e127756928db30d4

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

PR: https://git.openjdk.org/jfx11u/pull/133

From kcr at openjdk.org  Sat Feb 11 15:01:36 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 15:01:36 GMT
Subject: [jfx17u] Integrated: 8295755: Update SQLite to 3.39.4
In-Reply-To: <1i4M8vnaX7Eeg785Ksq4YyhURdfmZcKq_cyu6XzmIas=.f16d91d1-ac21-482c-affe-53ebeee8bb3d@github.com>
References: <1i4M8vnaX7Eeg785Ksq4YyhURdfmZcKq_cyu6XzmIas=.f16d91d1-ac21-482c-affe-53ebeee8bb3d@github.com>
Message-ID: 

On Sat, 11 Feb 2023 14:42:41 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: 822dfe3b
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx17u/commit/822dfe3b3444886a3d6e359b4d8effa2372b7a2a
Stats:     11694 lines in 4 files changed: 5822 ins; 1215 del; 4657 mod

8295755: Update SQLite to 3.39.4

Backport-of: 9f6ec88b222461da9486911ecefb68a936e5fc77

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

PR: https://git.openjdk.org/jfx17u/pull/110

From kcr at openjdk.org  Sat Feb 11 15:03:01 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 15:03:01 GMT
Subject: [jfx17u] RFR: 8299977: Update WebKit to 615.1
Message-ID: 

Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

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

Commit messages:
 - 8299977: Update WebKit to 615.1

Changes: https://git.openjdk.org/jfx17u/pull/112/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299977
  Stats: 197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod
  Patch: https://git.openjdk.org/jfx17u/pull/112.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/112/head:pull/112

PR: https://git.openjdk.org/jfx17u/pull/112

From kcr at openjdk.org  Sat Feb 11 15:03:36 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 15:03:36 GMT
Subject: [jfx17u] Integrated: 8298167: Opacity in WebView not working anymore
In-Reply-To: <4c4kMyXHLnuNuUMHFIxxvZn7t9ErJH9bahTQOiYDpfI=.7c86444b-8dce-40f8-92cf-e87bcf460985@github.com>
References: <4c4kMyXHLnuNuUMHFIxxvZn7t9ErJH9bahTQOiYDpfI=.7c86444b-8dce-40f8-92cf-e87bcf460985@github.com>
Message-ID: 

On Sat, 11 Feb 2023 14:42:57 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: e0b7eda1
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx17u/commit/e0b7eda1f26f0394b9ab64e6815a57e0be969db8
Stats:     76 lines in 3 files changed: 72 ins; 0 del; 4 mod

8298167: Opacity in WebView not working anymore

Backport-of: 8136b11fdc75aba64d8b77cf286097db3e12d6c9

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

PR: https://git.openjdk.org/jfx17u/pull/111

From kcr at openjdk.org  Sat Feb 11 15:05:41 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 15:05:41 GMT
Subject: [jfx17u] Integrated: 8299977: Update WebKit to 615.1
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:43:08 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: b30861fd
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx17u/commit/b30861fddbc2398fb5071c4ddf174e1dc0e87754
Stats:     197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod

8299977: Update WebKit to 615.1

Backport-of: 301bbd6409d463c4f789e2b3dcb6b2ea200d7373

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

PR: https://git.openjdk.org/jfx17u/pull/112

From kcr at openjdk.org  Sat Feb 11 15:10:37 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Feb 2023 15:10:37 GMT
Subject: [jfx17u] Integrated: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: 
References: 
Message-ID: 

On Sat, 11 Feb 2023 14:43:18 GMT, Kevin Rushforth  wrote:

> Clean backport. Tested in connection with 3 other WebKit fixes in the `test-kcr-17.0.7` branch, including a successful CI build. I also verfied that the native WebKit code is identical to mainline jfx after applying all patches (excluding a couple of copyright years).

This pull request has now been integrated.

Changeset: c05063c4
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx17u/commit/c05063c4a4bc3823e4fa1b3400f44ed1a88af06a
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8301712: [linux] Crash on exit from WebKit 615.1

Backport-of: 13d8df31e7bc4336d01ec859e127756928db30d4

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

PR: https://git.openjdk.org/jfx17u/pull/113

From john.hendrikx at gmail.com  Sat Feb 11 20:06:00 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 11 Feb 2023 21:06:00 +0100
Subject: Feedback requested for infrastructure for properties that wish to
 delay registering listeners
In-Reply-To: 
References: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com>
 
 
 
 
Message-ID: <9748c2e8-dfc0-55c5-6607-f8138c6dd90e@gmail.com>


On 11/02/2023 06:31, Michael Strau? wrote:
> I think that we are conflating two distinct questions in this discussion:
>
> 1. The first question is whether a listener that is registered on an
> ObservableValue should prevent the ObservableValue from being eligible
> for garbage collection.

This should never be the case, unless the listener does this by 
accident. The ObservableValue and listener can both be GC'd if the 
ObservableValue isn't referenced any more. Without a reference to the 
ObservableValue, you can't change it any more, and thus can't trigger 
the listener anymore.? At that point, there's no need to keep either around.

I've always advocated the opposite: the ObservableValue should prevent 
its listeners from being eligible for GC.? Yet, in JavaFX, with weak 
listeners, this can easily happen (even though the "stub" is still 
there).? This is what leads to hard to reproduce behavior as it relies 
on an unpredictable external event: garbage collection.

All I'm trying to do is to provide more tools to do timely removal of 
listeners and make it about as easy to do as weak listeners, but without 
the unpredictable behavior.? It is just jarring to see even more weak 
listeners being introduced considering all the downsides of this approach.

> 2. The second question is whether the object contained in an
> ObservableValue should hold a strong reference back to the
> ObservableValue.
>
> I'm only addressing the second question here. ObservableValue is a
> property system: it allows developers to declare named values (much
> like fields, but in addition to fields, it also allows observers to
> see when the value was changed). It seems obvious to me that, while a
> field refers to its value, the value of a field should not magically
> refer back to the field itself (or its declaring object). Unless, of
> course, the back-reference is manually added by the developer.
> Similarly, the value of an ObservableValue should not magically refer
> back to the ObservableValue; it is a one-way dependency by default.
>
> This one-way dependency makes a lot of sense: it binds the lifetime of
> the contained value to the lifetime of the property wrapper. The
> inverse makes no sense: why should the lifetime of the property
> wrapper be bound to the lifetime of its value? Plain fields don't work
> like this, neither do Beans, C#'s language properties, WPF's
> DependencyProperty, or any other property system that I've come
> across.
>
> And that's how most implementations in JavaFX work. Consider
> ObjectProperty: the contained value will not refer to ObjectProperty,
> regardless of whether listeners are registered on ObjectProperty.

I don't think I ever said the value should refer back to its property, 
so I think we're on the same frequency here.

However, if you are wrapping observable into observable you are actually 
doing what bindings are doing, as you can see these as wrappers as well. 
Handling the relationship between bindings with weak listeners is what 
results in the unpredictable semantics.

The dual nature of ListProperty is what is the root cause of the 
problems.? It is basically an ObjectProperty that 
implements ObservableList itself and offers some convenience that could 
have been provided differently; but it doesn't act like an 
ObservableList like ObservableArrayList would, and it doesn't act like 
an ObservableValue like ObjectProperty would.

In a fluent binding chain like flatMap().map().orElse(), each part of 
the chain strongly refers to its source (ie. "orElse" refers to "map" as 
its source). When the chain is observed itself, then the opposite is 
also true ("map" refers to "orElse" as "orElse" is a party interested in 
"map"s invalidations/changes).

Replace "orElse" with "ListProperty" and "map" with "ObservableList" and 
it's incredibly similar.

> But ListProperty is an anomaly: it adds a ListChangeListener to its
> contained list, which causes the contained list to magically refer
> back to ListProperty without the intervention of the developer. This
> violates the expectation that there's a one-way dependency between an
> ObservableValue and its contained value.

It's not a normal value though, it's also an Observable, and with any 
binding, there are references back and forth.

In what situation would this be a problem though, assuming the 
ListProperty itself is actively in use? Remember that I'm proposing this 
strong reference from ObservableList to ListProperty is only present 
when the ListProperty itself is being observed.

> The anomaly is caused by the decision to have ListProperty also
> implement ObservableList: this makes it looks like ListProperty (this
> is our ObservableValue) is actually the same thing as its contained
> value (the ObservableList). But it's not, from the perspective of
> ObservableValue these are two very distinct things. One is the
> wrapper, the other is the contained value.
>
> Purely as an implementation detail, ListProperty needs the internal
> ListChangeListener to replay the changes of its contained list, in
> order to perfectly masquerade as its contained list. But
> implementation details shouldn't change the semantics of the
> fundamental API, and this is why the internal dependency between
> ListProperty and its contained list needs to be broken by a weak
> reference.
>
> Note that I'm not talking about listener semantics at all. This is
> just about the semantics that govern the relationship between an
> ObservableValue and its contained value. Florian's PR is a targeted
> fix for this very specific bug, and I remain convinced that this is a
> bug.
>
> Furthermore, fixing this bug has no bearing on whether and how we
> address question 1, which you are passionate about. Leaving the
> current behavior as-is does not bring us closer to having "sticky
> listeners". It seems to me that much of what you've written is an
> endorsement for sticky listeners, but does not address the very narrow
> problem of the PR in question.

The decision to have ListProperty implement both ObservableList and 
ObservableValue is indeed as you say an "anomaly".? These two interfaces 
can't be implemented correctly in a single class and I think this is 
where the problems originate -- it can only perfectly mimick one of 
these.? They both implement Observable for example, which specifies 
methods for invalidation listeners.? For ObservableValue this would need 
to trigger when its value (a reference to the list as returned by 
`getValue`) is invalidated, while for ObservableList it would trigger 
when any mutation occurs.

On top of that, the ObservableValue part doesn't behave like any other 
ObservableValue. Calling `get` gets you the ObservableList, but adding a 
ChangeListener triggers many times with nonsense old and new values when 
modifying the underlying list (ie. something like: "old value = [A], 
current value = [A]" when adding "A" to an empty list).

I understand the desire to have something better than 
"ObjectProperty>" and so "ListProperty" was born. 
But you can also just use the ObservableList directly (without wrapper); 
this is 99% effective already, with only a few downsides:

1) I can't bind to empty/size
2) I can't replace the entire list efficiently (requires clear/addAll)
3) There is no change listener (only list change listener)

1) can easily be fixed by just having a convenient way to construct 
these bindings as all that is needed is to add an invalidation listener 
to the observable list, and a computeValue that calls `size` or 
`empty`.? These can probably just be default methods in `ObservableList`.

2) could probably be done with a default method (but I haven't really 
looked much into it).? By default it can do a clear/addAll, allowing 
smarter more efficient implementations to override this. These 
implementations never implement `ObservableValue` -- it's already 
observable, and just as distinct as a boolean or double; there is no 
need to wrap it again.

3) there are already list change listeners; change listeners offer 
nothing over these or invalidation listeners, unless they could 
correctly return the original list as old value; as it is, they're worse 
than useless; not having them is actually better than having broken 
ones, less confusing too.

>
>>> But the test shouldn't ever fail, because the ObservableList that is
>>> wrapped by ListProperty should never keep a strong reference to the
>>> ListProperty, even if the ListProperty is itself observed.
>> Why should it work that way?  The alternative is that my listener is
>> discarded without my knowledge.
> You didn't add a listener to the contained list; you added a listener
> to the property wrapper. This listener is not discarded.
> It may seem like it was, but that's only because ListProperty fooled
> us into thinking it was the same thing as its contained list.

I added it to an ObservableList, an interface with a contract, which may 
or may not be a ListProperty; this contract is what ListProperty claims 
to implement.

If I have two ObservableList's, A and B, that I received from somewhere, 
the interface documentation tells me what to expect. For some reason 
though, if I add an invalidation listener to A it keeps working, but if 
I add it to B, it breaks after a GC.

A is an ObservableArrayList

B is a ListProperty

An interface is supposed to be solid contract that you can rely upon.? 
ListProperty acts like they're just guidelines and does its own thing 
whenever the gap between ObservableList and ObservableValue is too hard 
to reconcile easily.

--John


From bourges.laurent at gmail.com  Sun Feb 12 09:21:07 2023
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sun, 12 Feb 2023 10:21:07 +0100
Subject: Enhance javafx Canvas API
In-Reply-To: 
References: 
Message-ID: 

Hi,

For jfree.FXGraphics2D, I implemented the proposed approach in the new
GCHandler:
https://github.com/jfree/fxgraphics2d/blob/1994b9cb3a9bff93bf95100d398756d7f9f626c2/src/main/java/org/jfree/fx/GCStateHandler.java

It boosts fxG2D performance & correctness.

Ideally, such methods getSavePoint(), restoreToCount() should be added to
GraphicsContext API...

Cheers,
Laurent

Le ven. 3 f?vr. 2023, 23:31, Laurent Bourg?s  a
?crit :

> Hi,
>
> While working with skia & jfree's skijaGraphics2D wrapper, I observed skia
> offers nice methods in SkCanvas missing in javafx Canvas/GraphicsContext to
> deal with save/restore state:
>
> - int getSaveCount ()
>   Returns the number of saved states, each containing: SkMatrix and clip.
>
> - void restoreToCount (int saveCount)
>   Restores state to SkMatrix and clip values when save(), returned
> saveCount.
>
> As javafx canvas also maintains s stack of saved states, such methods are
> trivial to implement to allow resetting completely the canvas state by
> restoreToCount(0).
>
> Moreover, clip(shape) + save/restore are really tricky to allows ensure
> clip is reset to previous state ...
>
> Would you agree to add such methods to have more predictive behaviour than
> counting all save() calls to ensure to call restore() the same number of
> times to reset the canvas to its initial state ?
>
> See SkijaGraphics2d implementation that saves / restore skCanvas clip
> using such index property:
>
> https://github.com/jfree/skijagraphics2d/blob/main/src/main/java/org/jfree/skija/SkijaGraphics2D.java
>
> Cheers,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pedro.duquevieira at gmail.com  Sun Feb 12 14:52:52 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sun, 12 Feb 2023 14:52:52 +0000
Subject: Alt key sticks even after app loses focus (JDK-8090647)
Message-ID: 

>
> The behavior on Windows is all over the place for different
> applications.? I tested a few I've got running:


Notepad, Notepad++, Eclipse:


- Alt-down: Shows mnemonics on menu bar
> - Alt-up: Highlights file menu on alt release
> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
> focus; when returning, mnemonics still highlighted, but doesn't act on
> them as menu not selected


-> Looks buggy


Thunderbird / Opera / Firefox:


- Alt-down: nothing
> - Alt-up: shows menu bar (it is hidden normally)
> - Alt-tab: works as expected, no highlighting


-> Looks well behaved


Explorer / Excel / Wordpad:


- Alt-down: nothing
> - Alt-up: shows mnemonics
> - Alt-tab: works as expected, no highlighting


-> Looks well behaved


Visual Studio Code:


- Alt-down: Shows mnemonics on menu bar
> - Alt-up: Highlights file menu on alt release
> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
> return doesn't show mnemonics


-> Looks well behaved


Chrome / IntelliJ:


-> Looks well behaved, doesn't react to alt presses in any way


None of the applications tested reacted on a mnemonic key after
> regaining focus however, even though they may have them still
> highlighted (which I think is a bug).


In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
> (they need to hide the mnemonics on focus lost, like Visual Studio Code
> does, but they don't).


There seems to be two correct ways of handling mnemonics in applications
> that use them, either:


a) shows mnemonics immediately on alt-down, but hide them on focus lost
> (if the alt-down becomes an alt-tab, or probably any other alt combination)


b) only show mnemonics on a naked alt-up


Ticket JDK-8090647 mentions a spec that has been updated, but I can't
> find it.? It also mentions that the behavior for JavaFX should be what I
> described in a), so I think this is a bug that can simply be fixed.


--John



Yap, there's quite different behaviors across apps. If you test on windows
11 you'll get yet another set of different behaviors.

But all in all, if you: alt+tab (without release) and alt+tab again so your
app regains focus, you'll have the mnemonic still activated, which, as you
say, sounds like a bug no matter the difference in behaviors across apps.

I agree with your suggestion: "a".

My client was quite disappointed and started to rant about javafx. It
didn't help that we were hit by a couple other bugs (perhaps bad
luck).  The fact that the bug was filed on 2013 (10 years later) and is
still happening can be quite problematic.
Perhaps it would make sense to review all bugs filed, giving highest
priority to the bugs that were submitted longer ago?

Thanks!

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

From nlisker at openjdk.org  Sun Feb 12 18:38:41 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 12 Feb 2023 18:38:41 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Feb 2023 15:05:46 GMT, John Hendrikx  wrote:

>> Packages fixed:
>> - com.sun.javafx.binding
>> - com.sun.javafx.collections
>> - javafx.beans
>> - javafx.beans.binding
>> - javafx.collections
>> - javafx.collections.transformation
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jfx into feature/fix-raw-type-warnings-in-base-2
>  - Undo changes in SortHelper
>  - Simplify MappingChange by using Function
>  - Clean up expression classes repeated null checks
>  - Use instanceof with pattern matching in a few spots
>  - Use static method for no-op map
>  - Fix raw type warnings in base
>    
>    Packages fixed:
>    - com.sun.javafx.binding
>    - com.sun.javafx.collections
>    - javafx.beans
>    - javafx.beans.binding
>    - javafx.collections
>    - javafx.collections.transformation

modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 235:

> 233:     }
> 234: 
> 235:     private static ObservableMap EMPTY_OBSERVABLE_MAP = new EmptyObservableMap<>();

This can be a `final` field. Same for the list and set ones. Not sure why it wasn't declared as such from the start.

modules/javafx.base/src/main/java/javafx/collections/transformation/FilteredList.java line 133:

> 131:             return getPredicate();
> 132:         }
> 133:         return (Predicate) ALWAYS_TRUE;

Do we actually need the constant `ALWAYS_TRUE`? I think that just inlining `return e -> true;` is fine and we can remove the field, the cast, and the warning suppression. What do you think?

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

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

From nlisker at openjdk.org  Sun Feb 12 18:38:43 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 12 Feb 2023 18:38:43 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v4]
In-Reply-To: <0DhuNOsx_cabpcZWUzV63eEbslwTe0CKPIW-_BLDlqc=.63adb851-7fb5-4f04-9dcc-4084cf9a3c19@github.com>
References: 
 
 <0DhuNOsx_cabpcZWUzV63eEbslwTe0CKPIW-_BLDlqc=.63adb851-7fb5-4f04-9dcc-4084cf9a3c19@github.com>
Message-ID: 

On Sun, 1 Jan 2023 15:25:01 GMT, John Hendrikx  wrote:

>> modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 1640:
>> 
>>> 1638:         @Override
>>> 1639:         public Iterator iterator() {
>>> 1640:             return new Iterator<>() {
>> 
>> Here the empty `Set` creates a listener on invocation, unlike in the list case. Might want to keep a single pattern. I prefer the one with a singleton iterator because the empty set itself is a singleton. Same comment about considering "inlining" it.
>
> Can make these consistent if the approach is agreed upon.

So let's make the list and the set use an instance singleton pattern, like the empty list does.

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

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

From jhendrikx at openjdk.org  Sun Feb 12 21:29:42 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 12 Feb 2023 21:29:42 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 12 Feb 2023 16:31:35 GMT, Nir Lisker  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 seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://git.openjdk.org/jfx into feature/fix-raw-type-warnings-in-base-2
>>  - Undo changes in SortHelper
>>  - Simplify MappingChange by using Function
>>  - Clean up expression classes repeated null checks
>>  - Use instanceof with pattern matching in a few spots
>>  - Use static method for no-op map
>>  - Fix raw type warnings in base
>>    
>>    Packages fixed:
>>    - com.sun.javafx.binding
>>    - com.sun.javafx.collections
>>    - javafx.beans
>>    - javafx.beans.binding
>>    - javafx.collections
>>    - javafx.collections.transformation
>
> modules/javafx.base/src/main/java/javafx/collections/transformation/FilteredList.java line 133:
> 
>> 131:             return getPredicate();
>> 132:         }
>> 133:         return (Predicate) ALWAYS_TRUE;
> 
> Do we actually need the constant `ALWAYS_TRUE`? I think that just inlining `return e -> true;` is fine and we can remove the field, the cast, and the warning suppression. What do you think?

I guess this is fine, as for example `Function#identity()` also just returns `t -> t` instead of using a static final.

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

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

From jhendrikx at openjdk.org  Sun Feb 12 21:49:11 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 12 Feb 2023 21:49:11 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v5]
In-Reply-To: 
References: 
Message-ID: 

> Packages fixed:
> - com.sun.javafx.binding
> - com.sun.javafx.collections
> - javafx.beans
> - javafx.beans.binding
> - javafx.collections
> - javafx.collections.transformation

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

  Fix review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/972/files
  - new: https://git.openjdk.org/jfx/pull/972/files/8814a990..40abc6e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=972&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=972&range=03-04

  Stats: 52 lines in 2 files changed: 17 ins; 24 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/972.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/972/head:pull/972

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

From jhendrikx at openjdk.org  Sun Feb 12 21:49:12 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 12 Feb 2023 21:49:12 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v5]
In-Reply-To: 
References: 
 
 <0DhuNOsx_cabpcZWUzV63eEbslwTe0CKPIW-_BLDlqc=.63adb851-7fb5-4f04-9dcc-4084cf9a3c19@github.com>
 
Message-ID: <8r9GQRJC1nu52aqMp61sEiVsiF2E91-yYwMG5F01o0o=.f753f88c-7c32-4e3b-8bb3-9f8d91494009@github.com>

On Sun, 12 Feb 2023 18:35:40 GMT, Nir Lisker  wrote:

>> Can make these consistent if the approach is agreed upon.
>
> So let's make the list and the set use an instance singleton pattern, like the empty list does.

Fixed

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

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

From nlisker at openjdk.org  Sun Feb 12 21:54:40 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 12 Feb 2023 21:54:40 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 12 Feb 2023 21:49:11 GMT, John Hendrikx  wrote:

>> Packages fixed:
>> - com.sun.javafx.binding
>> - com.sun.javafx.collections
>> - javafx.beans
>> - javafx.beans.binding
>> - javafx.collections
>> - javafx.collections.transformation
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

Marked as reviewed by nlisker (Reviewer).

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

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

From john.hendrikx at gmail.com  Sun Feb 12 22:06:24 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 12 Feb 2023 23:06:24 +0100
Subject: Alt key sticks even after app loses focus (JDK-8090647)
In-Reply-To: 
References: 
Message-ID: <49e4e4a4-1e14-6e78-9994-90949e83c1f4@gmail.com>

I'm not sure if you are able to test this yourself, but I made a fix for 
this problem.

You could potentially test it by copying the class `javafx.scene.Scene` 
in your project (without changing the package -- and if modules will 
allow it, I don't use them personally) and then using this piece of code:

 ??? private void setWindowFocused(boolean value) {
 ??????? windowFocused = value;

 ??????? Node node = getFocusOwner();
 ??????? if (node != null) {
 ??????????? node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
 ??????????? node.notifyFocusListeners();
 ??????? }

 ??????? if (windowFocused && accessible != null) {
accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
 ??????? }

 ??????? if (!windowFocused) {
getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
 ??????? }
 ??? }

The last three lines are what I added. A quick test on Windows here 
shows that the mnemonics get disabled as soon as the window loses focus, 
and when returning, they're not responding as you'd expect.

I'll submit a PR as well.

--John

On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>
>     The behavior on Windows is all over the place for different
>     applications.? I tested a few I've got running:
>
>
>     Notepad, Notepad++, Eclipse:
>
>
>     - Alt-down: Shows mnemonics on menu bar
>     - Alt-up: Highlights file menu on alt release
>     - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>     focus; when returning, mnemonics still highlighted, but doesn't act on
>     them as menu not selected
>
>
>     -> Looks buggy
>
>
>     Thunderbird / Opera / Firefox:
>
>
>     - Alt-down: nothing
>     - Alt-up: shows menu bar (it is hidden normally)
>     - Alt-tab: works as expected, no highlighting
>
>
>     -> Looks well behaved
>
>
>     Explorer / Excel / Wordpad:
>
>
>     - Alt-down: nothing
>     - Alt-up: shows mnemonics
>     - Alt-tab: works as expected, no highlighting
>
>
>     -> Looks well behaved
>
>
>     Visual Studio Code:
>
>
>     - Alt-down: Shows mnemonics on menu bar
>     - Alt-up: Highlights file menu on alt release
>     - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>     return doesn't show mnemonics
>
>
>     -> Looks well behaved
>
>
>     Chrome / IntelliJ:
>
>
>     -> Looks well behaved, doesn't react to alt presses in any way
>
>
>     None of the applications tested reacted on a mnemonic key after
>     regaining focus however, even though they may have them still
>     highlighted (which I think is a bug).
>
>
>     In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
>     (they need to hide the mnemonics on focus lost, like Visual Studio
>     Code
>     does, but they don't).
>
>
>     There seems to be two correct ways of handling mnemonics in
>     applications
>     that use them, either:
>
>
>     a) shows mnemonics immediately on alt-down, but hide them on focus
>     lost
>     (if the alt-down becomes an alt-tab, or probably any other alt
>     combination)
>
>
>     b) only show mnemonics on a naked alt-up
>
>
>     Ticket JDK-8090647 mentions a spec that has been updated, but I can't
>     find it.? It also mentions that the behavior for JavaFX should be
>     what I
>     described in a), so I think this is a bug that can simply be fixed.
>
>
>     --John
>
>
>
> Yap, there's quite different behaviors across apps. If you test on 
> windows 11 you'll get yet another set of different behaviors.
>
> But all in all, if you: alt+tab (without release) and alt+tab again so 
> your app regains focus, you'll have the mnemonic still activated, 
> which, as you say, sounds like a bug no matter the difference in 
> behaviors across apps.
>
> I agree with your suggestion: "a".
>
> My client was quite disappointed and started to rant about javafx. It 
> didn't help that we were hit by a couple other bugs (perhaps bad 
> luck).??The fact that the bug was filed on 2013 (10 years later) and 
> is still happening can be quite problematic.
> Perhaps it would make sense to review all bugs filed, giving highest 
> priority to the bugs that were submitted longer ago?
>
> Thanks!
>
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pedro.duquevieira at gmail.com  Sun Feb 12 22:15:43 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sun, 12 Feb 2023 22:15:43 +0000
Subject: Alt key sticks even after app loses focus (JDK-8090647)
In-Reply-To: <49e4e4a4-1e14-6e78-9994-90949e83c1f4@gmail.com>
References: 
 <49e4e4a4-1e14-6e78-9994-90949e83c1f4@gmail.com>
Message-ID: 

John,

Thank you very much for submitting a work around. Unfortunately, since
there were other higher priority bugs and features and we're very close to
a release, I wasn't allocated time to work on this much more than sending a
message to this mailing list to warn of the existence of this bug.
Not sure when I can get back to this. I'll submit your suggestion to the
dev team and if someone is allocated time to do it, I'll get back here and
let you know if it works.

There's also this suggestion that I forgot to mention (I haven't been able
to test it though):
https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus

Thanks again, kind regards,


On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx 
wrote:

> I'm not sure if you are able to test this yourself, but I made a fix for
> this problem.
>
> You could potentially test it by copying the class `javafx.scene.Scene` in
> your project (without changing the package -- and if modules will allow it,
> I don't use them personally) and then using this piece of code:
>
>     private void setWindowFocused(boolean value) {
>         windowFocused = value;
>
>         Node node = getFocusOwner();
>         if (node != null) {
>             node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
>             node.notifyFocusListeners();
>         }
>
>         if (windowFocused && accessible != null) {
>             accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
>         }
>
>         if (!windowFocused) {
>
> getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
>         }
>     }
>
> The last three lines are what I added. A quick test on Windows here shows
> that the mnemonics get disabled as soon as the window loses focus, and when
> returning, they're not responding as you'd expect.
>
> I'll submit a PR as well.
>
> --John
> On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>
> The behavior on Windows is all over the place for different
>> applications.? I tested a few I've got running:
>
>
> Notepad, Notepad++, Eclipse:
>
>
> - Alt-down: Shows mnemonics on menu bar
>> - Alt-up: Highlights file menu on alt release
>> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>> focus; when returning, mnemonics still highlighted, but doesn't act on
>> them as menu not selected
>
>
> -> Looks buggy
>
>
> Thunderbird / Opera / Firefox:
>
>
> - Alt-down: nothing
>> - Alt-up: shows menu bar (it is hidden normally)
>> - Alt-tab: works as expected, no highlighting
>
>
> -> Looks well behaved
>
>
> Explorer / Excel / Wordpad:
>
>
> - Alt-down: nothing
>> - Alt-up: shows mnemonics
>> - Alt-tab: works as expected, no highlighting
>
>
> -> Looks well behaved
>
>
> Visual Studio Code:
>
>
> - Alt-down: Shows mnemonics on menu bar
>> - Alt-up: Highlights file menu on alt release
>> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>> return doesn't show mnemonics
>
>
> -> Looks well behaved
>
>
> Chrome / IntelliJ:
>
>
> -> Looks well behaved, doesn't react to alt presses in any way
>
>
> None of the applications tested reacted on a mnemonic key after
>> regaining focus however, even though they may have them still
>> highlighted (which I think is a bug).
>
>
> In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
>> (they need to hide the mnemonics on focus lost, like Visual Studio Code
>> does, but they don't).
>
>
> There seems to be two correct ways of handling mnemonics in applications
>> that use them, either:
>
>
> a) shows mnemonics immediately on alt-down, but hide them on focus lost
>> (if the alt-down becomes an alt-tab, or probably any other alt
>> combination)
>
>
> b) only show mnemonics on a naked alt-up
>
>
> Ticket JDK-8090647 mentions a spec that has been updated, but I can't
>> find it.? It also mentions that the behavior for JavaFX should be what I
>> described in a), so I think this is a bug that can simply be fixed.
>
>
> --John
>
>
>
> Yap, there's quite different behaviors across apps. If you test on windows
> 11 you'll get yet another set of different behaviors.
>
> But all in all, if you: alt+tab (without release) and alt+tab again so
> your app regains focus, you'll have the mnemonic still activated, which, as
> you say, sounds like a bug no matter the difference in behaviors across
> apps.
>
> I agree with your suggestion: "a".
>
> My client was quite disappointed and started to rant about javafx. It
> didn't help that we were hit by a couple other bugs (perhaps bad
> luck).  The fact that the bug was filed on 2013 (10 years later) and is
> still happening can be quite problematic.
> Perhaps it would make sense to review all bugs filed, giving highest
> priority to the bugs that were submitted longer ago?
>
> Thanks!
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
>

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

From jhendrikx at openjdk.org  Sun Feb 12 22:20:24 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 12 Feb 2023 22:20:24 GMT
Subject: RFR: JDK-8090647: Mnemonics : on windows we should cancel the
 underscore latch when an app loses focus.
Message-ID: 

This fix hides mnemonics when the Scene's Window loses focus.

Before integration, we need to make sure this is correct behavior for Mac and Linux as well. It is correct for Windows.

How to test:

- Create a control with a mnemonic
- Alt-tab to another window (mnemonics appear when alt is pressed)

Before:
- Window shows visible mnemonic still and reacts on them when returning

After:
- Window hides mnemonics when focus is lost and doesn't react on them when returning

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

Commit messages:
 - Mnemonics should be hidden when Scene's window loses focus

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

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

From pedro.duquevieira at gmail.com  Sun Feb 12 22:23:24 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sun, 12 Feb 2023 22:23:24 +0000
Subject: Alt key sticks even after app loses focus (JDK-8090647)
In-Reply-To: 
References: 
 <49e4e4a4-1e14-6e78-9994-90949e83c1f4@gmail.com>
 
Message-ID: 

.. all in all of course, I'd prefer a solution that properly fixes this bug
and not have to rely on hacks that are prone to break in the future or code
that needs to circumvent encapsulation or the module system. So either one
is unlikely to be a fix I'm happy with.

Thanks for considering submitting a PR to properly fix this issue!

Kind regards,



On Sun, Feb 12, 2023 at 10:15 PM Pedro Duque Vieira <
pedro.duquevieira at gmail.com> wrote:

> John,
>
> Thank you very much for submitting a work around. Unfortunately, since
> there were other higher priority bugs and features and we're very close to
> a release, I wasn't allocated time to work on this much more than sending a
> message to this mailing list to warn of the existence of this bug.
> Not sure when I can get back to this. I'll submit your suggestion to the
> dev team and if someone is allocated time to do it, I'll get back here and
> let you know if it works.
>
> There's also this suggestion that I forgot to mention (I haven't been able
> to test it though):
> https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus
>
> Thanks again, kind regards,
>
>
> On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx 
> wrote:
>
>> I'm not sure if you are able to test this yourself, but I made a fix for
>> this problem.
>>
>> You could potentially test it by copying the class `javafx.scene.Scene`
>> in your project (without changing the package -- and if modules will allow
>> it, I don't use them personally) and then using this piece of code:
>>
>>     private void setWindowFocused(boolean value) {
>>         windowFocused = value;
>>
>>         Node node = getFocusOwner();
>>         if (node != null) {
>>             node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
>>             node.notifyFocusListeners();
>>         }
>>
>>         if (windowFocused && accessible != null) {
>>             accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
>>         }
>>
>>         if (!windowFocused) {
>>
>> getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
>>         }
>>     }
>>
>> The last three lines are what I added. A quick test on Windows here shows
>> that the mnemonics get disabled as soon as the window loses focus, and when
>> returning, they're not responding as you'd expect.
>>
>> I'll submit a PR as well.
>>
>> --John
>> On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>>
>> The behavior on Windows is all over the place for different
>>> applications.? I tested a few I've got running:
>>
>>
>> Notepad, Notepad++, Eclipse:
>>
>>
>> - Alt-down: Shows mnemonics on menu bar
>>> - Alt-up: Highlights file menu on alt release
>>> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>>> focus; when returning, mnemonics still highlighted, but doesn't act on
>>> them as menu not selected
>>
>>
>> -> Looks buggy
>>
>>
>> Thunderbird / Opera / Firefox:
>>
>>
>> - Alt-down: nothing
>>> - Alt-up: shows menu bar (it is hidden normally)
>>> - Alt-tab: works as expected, no highlighting
>>
>>
>> -> Looks well behaved
>>
>>
>> Explorer / Excel / Wordpad:
>>
>>
>> - Alt-down: nothing
>>> - Alt-up: shows mnemonics
>>> - Alt-tab: works as expected, no highlighting
>>
>>
>> -> Looks well behaved
>>
>>
>> Visual Studio Code:
>>
>>
>> - Alt-down: Shows mnemonics on menu bar
>>> - Alt-up: Highlights file menu on alt release
>>> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>>> return doesn't show mnemonics
>>
>>
>> -> Looks well behaved
>>
>>
>> Chrome / IntelliJ:
>>
>>
>> -> Looks well behaved, doesn't react to alt presses in any way
>>
>>
>> None of the applications tested reacted on a mnemonic key after
>>> regaining focus however, even though they may have them still
>>> highlighted (which I think is a bug).
>>
>>
>> In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
>>> (they need to hide the mnemonics on focus lost, like Visual Studio Code
>>> does, but they don't).
>>
>>
>> There seems to be two correct ways of handling mnemonics in applications
>>> that use them, either:
>>
>>
>> a) shows mnemonics immediately on alt-down, but hide them on focus lost
>>> (if the alt-down becomes an alt-tab, or probably any other alt
>>> combination)
>>
>>
>> b) only show mnemonics on a naked alt-up
>>
>>
>> Ticket JDK-8090647 mentions a spec that has been updated, but I can't
>>> find it.? It also mentions that the behavior for JavaFX should be what I
>>> described in a), so I think this is a bug that can simply be fixed.
>>
>>
>> --John
>>
>>
>>
>> Yap, there's quite different behaviors across apps. If you test on
>> windows 11 you'll get yet another set of different behaviors.
>>
>> But all in all, if you: alt+tab (without release) and alt+tab again so
>> your app regains focus, you'll have the mnemonic still activated, which, as
>> you say, sounds like a bug no matter the difference in behaviors across
>> apps.
>>
>> I agree with your suggestion: "a".
>>
>> My client was quite disappointed and started to rant about javafx. It
>> didn't help that we were hit by a couple other bugs (perhaps bad
>> luck).  The fact that the bug was filed on 2013 (10 years later) and is
>> still happening can be quite problematic.
>> Perhaps it would make sense to review all bugs filed, giving highest
>> priority to the bugs that were submitted longer ago?
>>
>> Thanks!
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
>>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>


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

From john.hendrikx at gmail.com  Sun Feb 12 22:28:09 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 12 Feb 2023 23:28:09 +0100
Subject: Alt key sticks even after app loses focus (JDK-8090647)
In-Reply-To: 
References: 
 <49e4e4a4-1e14-6e78-9994-90949e83c1f4@gmail.com>
 
 
Message-ID: <2d5211e7-8004-2e4a-3277-f26215f3c9cf@gmail.com>

Well, it is not a permanent solution, just a way to test to see if it 
actually solves your problem.

--John

On 12/02/2023 23:23, Pedro Duque Vieira wrote:
> .. all in all of course, I'd prefer a solution that properly fixes 
> this bug and not have to rely on hacks that are prone to break in the 
> future or code that needs to circumvent encapsulation or the module 
> system. So either one is unlikely to be a fix I'm happy with.
>
> Thanks for considering?submitting a PR to properly fix this issue!
>
> Kind regards,
>
>
>
> On Sun, Feb 12, 2023 at 10:15 PM Pedro Duque Vieira 
>  wrote:
>
>     John,
>
>     Thank you very much for submitting a work around. Unfortunately,
>     since there were other higher priority bugs and features and?we're
>     very close to a release, I wasn't allocated time to work on this
>     much more than sending a message?to this mailing list to warn
>     of?the existence of this bug.
>     Not sure when I can get back to this. I'll submit your suggestion
>     to the dev team and if someone is allocated time to do it, I'll
>     get back here and let you know if it works.
>
>     There's also this suggestion that I forgot to mention (I haven't
>     been able to test it though):
>     https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus
>
>     Thanks again, kind regards,
>
>
>     On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx
>      wrote:
>
>         I'm not sure if you are able to test this yourself, but I made
>         a fix for this problem.
>
>         You could potentially test it by copying the class
>         `javafx.scene.Scene` in your project (without changing the
>         package -- and if modules will allow it, I don't use them
>         personally) and then using this piece of code:
>
>         ??? private void setWindowFocused(boolean value) {
>         ??????? windowFocused = value;
>
>         ??????? Node node = getFocusOwner();
>         ??????? if (node != null) {
>         ??????????? node.setFocusQuietly(windowFocused,
>         focusOwner.focusVisible);
>         ??????????? node.notifyFocusListeners();
>         ??????? }
>
>         ??????? if (windowFocused && accessible != null) {
>         accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
>         ??????? }
>
>         ??????? if (!windowFocused) {
>         getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
>         ??????? }
>         ??? }
>
>         The last three lines are what I added. A quick test on Windows
>         here shows that the mnemonics get disabled as soon as the
>         window loses focus, and when returning, they're not responding
>         as you'd expect.
>
>         I'll submit a PR as well.
>
>         --John
>
>         On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>>
>>             The behavior on Windows is all over the place for different
>>             applications.? I tested a few I've got running:
>>
>>
>>             Notepad, Notepad++, Eclipse:
>>
>>
>>             - Alt-down: Shows mnemonics on menu bar
>>             - Alt-up: Highlights file menu on alt release
>>             - Alt-tab: Shows mnemonics but doesn't highlight menu
>>             when it loses
>>             focus; when returning, mnemonics still highlighted, but
>>             doesn't act on
>>             them as menu not selected
>>
>>
>>             -> Looks buggy
>>
>>
>>             Thunderbird / Opera / Firefox:
>>
>>
>>             - Alt-down: nothing
>>             - Alt-up: shows menu bar (it is hidden normally)
>>             - Alt-tab: works as expected, no highlighting
>>
>>
>>             -> Looks well behaved
>>
>>
>>             Explorer / Excel / Wordpad:
>>
>>
>>             - Alt-down: nothing
>>             - Alt-up: shows mnemonics
>>             - Alt-tab: works as expected, no highlighting
>>
>>
>>             -> Looks well behaved
>>
>>
>>             Visual Studio Code:
>>
>>
>>             - Alt-down: Shows mnemonics on menu bar
>>             - Alt-up: Highlights file menu on alt release
>>             - Alt-tab: Shows mnemonics, but hides them once it loses
>>             focus; on
>>             return doesn't show mnemonics
>>
>>
>>             -> Looks well behaved
>>
>>
>>             Chrome / IntelliJ:
>>
>>
>>             -> Looks well behaved, doesn't react to alt presses in
>>             any way
>>
>>
>>             None of the applications tested reacted on a mnemonic key
>>             after
>>             regaining focus however, even though they may have them still
>>             highlighted (which I think is a bug).
>>
>>
>>             In my opinion, the behavior of notepad/notepad++/eclipse
>>             is incorrect
>>             (they need to hide the mnemonics on focus lost, like
>>             Visual Studio Code
>>             does, but they don't).
>>
>>
>>             There seems to be two correct ways of handling mnemonics
>>             in applications
>>             that use them, either:
>>
>>
>>             a) shows mnemonics immediately on alt-down, but hide them
>>             on focus lost
>>             (if the alt-down becomes an alt-tab, or probably any
>>             other alt combination)
>>
>>
>>             b) only show mnemonics on a naked alt-up
>>
>>
>>             Ticket JDK-8090647 mentions a spec that has been updated,
>>             but I can't
>>             find it.? It also mentions that the behavior for JavaFX
>>             should be what I
>>             described in a), so I think this is a bug that can simply
>>             be fixed.
>>
>>
>>             --John
>>
>>
>>
>>         Yap, there's quite different behaviors across apps. If you
>>         test on windows 11 you'll get yet another set of different
>>         behaviors.
>>
>>         But all in all, if you: alt+tab (without release) and alt+tab
>>         again so your app regains focus, you'll have the mnemonic
>>         still activated, which, as you say, sounds like a bug no
>>         matter the difference in behaviors across apps.
>>
>>         I agree with your suggestion: "a".
>>
>>         My client was quite disappointed and started to rant about
>>         javafx. It didn't help that we were hit by a couple other
>>         bugs (perhaps bad luck).??The fact that the bug was filed on
>>         2013 (10 years later) and is still happening can be quite
>>         problematic.
>>         Perhaps it would make sense to review all bugs filed, giving
>>         highest priority to the bugs that were submitted longer ago?
>>
>>         Thanks!
>>
>>         -- 
>>         Pedro Duque Vieira - https://www.pixelduke.com
>
>
>
>     -- 
>     Pedro Duque Vieira - https://www.pixelduke.com
>
>
>
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jhendrikx at openjdk.org  Sun Feb 12 22:36:40 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 12 Feb 2023 22:36:40 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 12 Feb 2023 21:49:11 GMT, John Hendrikx  wrote:

>> Packages fixed:
>> - com.sun.javafx.binding
>> - com.sun.javafx.collections
>> - javafx.beans
>> - javafx.beans.binding
>> - javafx.collections
>> - javafx.collections.transformation
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

@arapte do you want to take a look still?

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

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

From swpalmer at gmail.com  Sun Feb 12 23:49:57 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Sun, 12 Feb 2023 18:49:57 -0500
Subject: WebKit Crashes JVM when removing nodes from DOM on wrong thread.
Message-ID: 

I'm seeing a hard crash in native code that brings down the JVM when I
accidentally called removeChild on an element from a WebView Document while
not on the Platform thread.  While I know it's my error, bringing down the
JVM instead of throwing an exception seems wrong.

Should this be considered a bug or not?

Scott

With JavaFX 17:
Thread 50 Crashed:: Java: ForkJoinPool-1-worker-5
0   libjfxwebkit.dylib                   0x14fa2ac33 WTFCrashWithInfo(int,
char const*, char const*, int) + 19
1   libjfxwebkit.dylib                   0x14ea5b60d
WebCore::TimerBase::setNextFireTime(WTF::MonotonicTime) + 541
2   libjfxwebkit.dylib                   0x14ee0a513
WebCore::RenderTreeBuilder::detachFromRenderElement(WebCore::RenderElement&,
WebCore::RenderObject&, WebCore::RenderTreeBuilder::WillBeDestroyed) + 179
3   libjfxwebkit.dylib                   0x14ee09fa2
WebCore::RenderTreeBuilder::Block::detach(WebCore::RenderBlock&,
WebCore::RenderObject&,
WebCore::RenderTreeBuilder::CanCollapseAnonymousBlock) + 562
4   libjfxwebkit.dylib                   0x14ee085ef
WebCore::RenderTreeBuilder::detach(WebCore::RenderElement&,
WebCore::RenderObject&,
WebCore::RenderTreeBuilder::CanCollapseAnonymousBlock) + 543
5   libjfxwebkit.dylib                   0x14ee082ba
WebCore::RenderTreeBuilder::destroy(WebCore::RenderObject&) + 58
6   libjfxwebkit.dylib                   0x14ee0bd57
WebCore::RenderTreeBuilder::destroyAndCleanUpAnonymousWrappers(WebCore::RenderObject&)
+ 263
7   libjfxwebkit.dylib                   0x14ee19aae
WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&,
WebCore::RenderTreeUpdater::TeardownType,
WebCore::RenderTreeBuilder&)::$_7::operator()(unsigned int) const + 734
8   libjfxwebkit.dylib                   0x14ee18c13
WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&,
WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&) +
1171
9   libjfxwebkit.dylib                   0x14ee196d1
WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&) + 65
10  libjfxwebkit.dylib                   0x14e46db9c
WebCore::ContainerNode::removeBetween(WebCore::Node*, WebCore::Node*,
WebCore::Node&) + 108
11  libjfxwebkit.dylib                   0x14e46ad44
WebCore::ContainerNode::removeChild(WebCore::Node&) + 324
12  libjfxwebkit.dylib                   0x14e50e24b
WebCore::Node::removeChild(WebCore::Node&) + 43
13  libjfxwebkit.dylib                   0x14d98deeb
Java_com_sun_webkit_dom_NodeImpl_removeChildImpl + 107
14  ???                                 0x1203e753a ???
15  ???                                 0x1203e335c ???
16  ???                                 0x1203e36a2 ???
17  ???                                 0x1203e342b ???
18  ???                                 0x1203e342b ???
19  ???                                 0x1203e388f ???
20  ???                                 0x1203e342b ???
21  ???                                 0x1203e3317 ???
22  ???                                 0x1203e3317 ???
23  ???                                 0x1203e342b ???
24  ???                                 0x1203e3317 ???
25  ???                                 0x1203e342b ???
26  ???                                 0x1203dacc9 ???
27  libjvm.dylib                         0x110790af6
JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*,
JavaThread*) + 710
28  libjvm.dylib                         0x11078fb47
JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*,
JavaCallArguments*, JavaThread*) + 327
29  libjvm.dylib                         0x11078fc13
JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*,
JavaThread*) + 99
30  libjvm.dylib                         0x11083ab94
thread_entry(JavaThread*, JavaThread*) + 180
31  libjvm.dylib                         0x110d164af
JavaThread::thread_main_inner() + 335
32  libjvm.dylib                         0x110d1481f Thread::call_run() +
207
33  libjvm.dylib                         0x110b1f898
thread_native_entry(Thread*) + 328
34  libsystem_pthread.dylib          0x7ff8062b4259 _pthread_start + 125
35  libsystem_pthread.dylib          0x7ff8062afc7b thread_start + 15


With JavaFX 19.0.2.1
Thread 48 Crashed:: Java: ForkJoinPool-1-worker-2
0   libjfxwebkit.dylib                   0x14f2eb9f3 0x14d0d8000 + 35731955
1   libjfxwebkit.dylib                   0x14e3744a6 0x14d0d8000 + 19514534
2   libjfxwebkit.dylib                   0x14e747d49 0x14d0d8000 + 23526729
3   libjfxwebkit.dylib                   0x14e747798 0x14d0d8000 + 23525272
4   libjfxwebkit.dylib                   0x14e745b7f 0x14d0d8000 + 23518079
5   libjfxwebkit.dylib                   0x14e745837 0x14d0d8000 + 23517239
6   libjfxwebkit.dylib                   0x14e749766 0x14d0d8000 + 23533414
7   libjfxwebkit.dylib                   0x14e757dc1 0x14d0d8000 + 23592385
8   libjfxwebkit.dylib                   0x14e757033 0x14d0d8000 + 23588915
9   libjfxwebkit.dylib                   0x14e757aa1 0x14d0d8000 + 23591585
10  libjfxwebkit.dylib                   0x14dd3a2ec 0x14d0d8000 + 12985068
11  libjfxwebkit.dylib                   0x14dd37344 0x14d0d8000 + 12972868
12  libjfxwebkit.dylib                   0x14dddd01b 0x14d0d8000 + 13651995
13  libjfxwebkit.dylib                   0x14d18841b
Java_com_sun_webkit_dom_NodeImpl_removeChildImpl + 107
14  ???                                 0x120a6453a ???
15  ???                                 0x120a6035c ???
16  ???                                 0x120a606a2 ???
17  ???                                 0x120a6042b ???
18  ???                                 0x120a6042b ???
19  ???                                 0x120a6088f ???
20  ???                                 0x120a6042b ???
21  ???                                 0x120a60317 ???
22  ???                                 0x120a60317 ???
23  ???                                 0x120a6042b ???
24  ???                                 0x120a60317 ???
25  ???                                 0x120a6042b ???
26  ???                                 0x120a57cc9 ???
27  libjvm.dylib                         0x110e0daf6
JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*,
JavaThread*) + 710
28  libjvm.dylib                         0x110e0cb47
JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*,
JavaCallArguments*, JavaThread*) + 327
29  libjvm.dylib                         0x110e0cc13
JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*,
JavaThread*) + 99
30  libjvm.dylib                         0x110eb7b94
thread_entry(JavaThread*, JavaThread*) + 180
31  libjvm.dylib                         0x1113934af
JavaThread::thread_main_inner() + 335
32  libjvm.dylib                         0x11139181f Thread::call_run() +
207
33  libjvm.dylib                         0x11119c898
thread_native_entry(Thread*) + 328
34  libsystem_pthread.dylib          0x7ff8062b4259 _pthread_start + 125
35  libsystem_pthread.dylib          0x7ff8062afc7b thread_start + 15
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tsayao at openjdk.org  Sun Feb 12 23:54:38 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 12 Feb 2023 23:54:38 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v46]
In-Reply-To: 
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 
Message-ID: 

On Mon, 23 Jan 2023 03:51:33 GMT, Thiago Milczarek Sayao  wrote:

>> This cleans size and positioning code, reducing special cases, code complexity and size.
>> 
>> Changes:
>> 
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
>> - window geometry, min/max size are centralized in `update_window_constraints`;
>> - Frame extents (the window decoration size used for "total window size"):
>>     - frame extents are received in `process_property_notify`;
>>     - removed quirks in java code;
>>     - When received, call `set_bounds` again to adjust the size (to account decorations later received);
>> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it.
>> - `ensure_window_size` was a quirk - removed;
>> - `requested_bounds` removed - not used anymore;
>> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`;
>> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point)
>> - `restack` split in `to_front()` and `to_back()` to conform to managed code;
>> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`;
>> - Note:  `geometry_get_*` and `geometry_set_*` moved location but unchanged.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Fix JDK-8089923
>  - Fix JDK-8089923
>  - Fix JDK-8089923
>  - Fix deiconify regression

Working on it - I think it's possible to fix the DeIconify bug too.

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

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

From tsayao at openjdk.org  Mon Feb 13 00:15:04 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 13 Feb 2023 00:15:04 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v47]
In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
Message-ID: 

> This cleans size and positioning code, reducing special cases, code complexity and size.
> 
> Changes:
> 
> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
> - window geometry, min/max size are centralized in `update_window_constraints`;
> - Frame extents (the window decoration size used for "total window size"):
>     - frame extents are received in `process_property_notify`;
>     - removed quirks in java code;
>     - When received, call `set_bounds` again to adjust the size (to account decorations later received);
> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it.
> - `ensure_window_size` was a quirk - removed;
> - `requested_bounds` removed - not used anymore;
> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`;
> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point)
> - `restack` split in `to_front()` and `to_back()` to conform to managed code;
> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`;
> - Note:  `geometry_get_*` and `geometry_set_*` moved location but unchanged.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix deiconify bug

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/915/files
  - new: https://git.openjdk.org/jfx/pull/915/files/ccd84d72..4360d952

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=46
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=45-46

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

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

From kevin.rushforth at oracle.com  Mon Feb 13 13:41:47 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 13 Feb 2023 05:41:47 -0800
Subject: WebKit Crashes JVM when removing nodes from DOM on wrong thread.
In-Reply-To: 
References: 
Message-ID: <100893c2-fd14-e0fe-2e62-a96b97748742@oracle.com>

Yes, please file a bug. An intermittent exception would be one thing, 
but it shouldn't actually crash when doing that.

-- Kevin


On 2/12/2023 3:49 PM, Scott Palmer wrote:
> I'm seeing a hard crash in native code that brings down the JVM when I 
> accidentally called removeChild on an element from a WebView Document 
> while not on the Platform thread.? While I know it's my error, 
> bringing down the JVM instead of throwing an exception seems wrong.
>
> Should this be considered a bug or not?
>
> Scott
>
> With JavaFX 17:
> Thread 50 Crashed:: Java: ForkJoinPool-1-worker-5
> 0 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14fa2ac33 
> WTFCrashWithInfo(int, char const*, char const*, int) + 19
> 1 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ea5b60d 
> WebCore::TimerBase::setNextFireTime(WTF::MonotonicTime) + 541
> 2 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee0a513 
> WebCore::RenderTreeBuilder::detachFromRenderElement(WebCore::RenderElement&, 
> WebCore::RenderObject&, WebCore::RenderTreeBuilder::WillBeDestroyed) + 179
> 3 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee09fa2 
> WebCore::RenderTreeBuilder::Block::detach(WebCore::RenderBlock&, 
> WebCore::RenderObject&, 
> WebCore::RenderTreeBuilder::CanCollapseAnonymousBlock) + 562
> 4 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee085ef 
> WebCore::RenderTreeBuilder::detach(WebCore::RenderElement&, 
> WebCore::RenderObject&, 
> WebCore::RenderTreeBuilder::CanCollapseAnonymousBlock) + 543
> 5 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee082ba 
> WebCore::RenderTreeBuilder::destroy(WebCore::RenderObject&) + 58
> 6 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee0bd57 
> WebCore::RenderTreeBuilder::destroyAndCleanUpAnonymousWrappers(WebCore::RenderObject&) 
> + 263
> 7 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee19aae 
> WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&, 
> WebCore::RenderTreeUpdater::TeardownType, 
> WebCore::RenderTreeBuilder&)::$_7::operator()(unsigned int) const + 734
> 8 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee18c13 
> WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&, 
> WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&) 
> + 1171
> 9 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14ee196d1 
> WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&) + 65
> 10 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e46db9c 
> WebCore::ContainerNode::removeBetween(WebCore::Node*, WebCore::Node*, 
> WebCore::Node&) + 108
> 11 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e46ad44 
> WebCore::ContainerNode::removeChild(WebCore::Node&) + 324
> 12 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e50e24b 
> WebCore::Node::removeChild(WebCore::Node&) + 43
> 13 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14d98deeb 
> Java_com_sun_webkit_dom_NodeImpl_removeChildImpl + 107
> 14 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e753a ???
> 15 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e335c ???
> 16 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e36a2 ???
> 17 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e342b ???
> 18 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e342b ???
> 19 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e388f ???
> 20 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e342b ???
> 21 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e3317 ???
> 22 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e3317 ???
> 23 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e342b ???
> 24 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e3317 ???
> 25 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203e342b ???
> 26 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x1203dacc9 ???
> 27 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110790af6 
> JavaCalls::call_helper(JavaValue*, methodHandle const&, 
> JavaCallArguments*, JavaThread*) + 710
> 28 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x11078fb47 
> JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, 
> JavaCallArguments*, JavaThread*) + 327
> 29 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x11078fc13 
> JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, 
> JavaThread*) + 99
> 30 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x11083ab94 
> thread_entry(JavaThread*, JavaThread*) + 180
> 31 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110d164af 
> JavaThread::thread_main_inner() + 335
> 32 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110d1481f 
> Thread::call_run() + 207
> 33 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110b1f898 
> thread_native_entry(Thread*) + 328
> 34 ?libsystem_pthread.dylib ? ? ? ? ?0x7ff8062b4259 _pthread_start + 125
> 35 ?libsystem_pthread.dylib ? ? ? ? ?0x7ff8062afc7b thread_start + 15
>
>
> With JavaFX 19.0.2.1
> Thread 48 Crashed:: Java: ForkJoinPool-1-worker-2
> 0 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14f2eb9f3 0x14d0d8000 + 
> 35731955
> 1 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e3744a6 0x14d0d8000 + 
> 19514534
> 2 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e747d49 0x14d0d8000 + 
> 23526729
> 3 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e747798 0x14d0d8000 + 
> 23525272
> 4 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e745b7f 0x14d0d8000 + 
> 23518079
> 5 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e745837 0x14d0d8000 + 
> 23517239
> 6 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e749766 0x14d0d8000 + 
> 23533414
> 7 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e757dc1 0x14d0d8000 + 
> 23592385
> 8 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e757033 0x14d0d8000 + 
> 23588915
> 9 ? libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14e757aa1 0x14d0d8000 + 
> 23591585
> 10 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14dd3a2ec 0x14d0d8000 + 
> 12985068
> 11 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14dd37344 0x14d0d8000 + 
> 12972868
> 12 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14dddd01b 0x14d0d8000 + 
> 13651995
> 13 ?libjfxwebkit.dylib ? ? ? ? ? ? ? ? ? 0x14d18841b 
> Java_com_sun_webkit_dom_NodeImpl_removeChildImpl + 107
> 14 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6453a ???
> 15 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6035c ???
> 16 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a606a2 ???
> 17 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6042b ???
> 18 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6042b ???
> 19 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6088f ???
> 20 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6042b ???
> 21 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a60317 ???
> 22 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a60317 ???
> 23 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6042b ???
> 24 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a60317 ???
> 25 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a6042b ???
> 26 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x120a57cc9 ???
> 27 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110e0daf6 
> JavaCalls::call_helper(JavaValue*, methodHandle const&, 
> JavaCallArguments*, JavaThread*) + 710
> 28 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110e0cb47 
> JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, 
> JavaCallArguments*, JavaThread*) + 327
> 29 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110e0cc13 
> JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, 
> JavaThread*) + 99
> 30 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x110eb7b94 
> thread_entry(JavaThread*, JavaThread*) + 180
> 31 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x1113934af 
> JavaThread::thread_main_inner() + 335
> 32 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x11139181f 
> Thread::call_run() + 207
> 33 ?libjvm.dylib ? ? ? ? ? ? ? ? ? ? ? ? 0x11119c898 
> thread_native_entry(Thread*) + 328
> 34 ?libsystem_pthread.dylib ? ? ? ? ?0x7ff8062b4259 _pthread_start + 125
> 35 ?libsystem_pthread.dylib ? ? ? ? ?0x7ff8062afc7b thread_start + 15


From pedro.duquevieira at gmail.com  Mon Feb 13 14:07:12 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 13 Feb 2023 14:07:12 +0000
Subject: Alt key sticks even after app loses focus (JDK-8090647)
In-Reply-To: <2d5211e7-8004-2e4a-3277-f26215f3c9cf@gmail.com>
References: 
 <49e4e4a4-1e14-6e78-9994-90949e83c1f4@gmail.com>
 
 
 <2d5211e7-8004-2e4a-3277-f26215f3c9cf@gmail.com>
Message-ID: 

I'll try to convince them to allocate time to test this, otherwise I'll try
to see if I can test it in my free spare time.

Thanks,

On Sun, Feb 12, 2023 at 10:28 PM John Hendrikx 
wrote:

> Well, it is not a permanent solution, just a way to test to see if it
> actually solves your problem.
>
> --John
> On 12/02/2023 23:23, Pedro Duque Vieira wrote:
>
> .. all in all of course, I'd prefer a solution that properly fixes this
> bug and not have to rely on hacks that are prone to break in the future or
> code that needs to circumvent encapsulation or the module system. So either
> one is unlikely to be a fix I'm happy with.
>
> Thanks for considering submitting a PR to properly fix this issue!
>
> Kind regards,
>
>
>
> On Sun, Feb 12, 2023 at 10:15 PM Pedro Duque Vieira <
> pedro.duquevieira at gmail.com> wrote:
>
>> John,
>>
>> Thank you very much for submitting a work around. Unfortunately, since
>> there were other higher priority bugs and features and we're very close to
>> a release, I wasn't allocated time to work on this much more than sending a
>> message to this mailing list to warn of the existence of this bug.
>> Not sure when I can get back to this. I'll submit your suggestion to the
>> dev team and if someone is allocated time to do it, I'll get back here and
>> let you know if it works.
>>
>> There's also this suggestion that I forgot to mention (I haven't been
>> able to test it though):
>> https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus
>>
>> Thanks again, kind regards,
>>
>>
>> On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx 
>> wrote:
>>
>>> I'm not sure if you are able to test this yourself, but I made a fix for
>>> this problem.
>>>
>>> You could potentially test it by copying the class `javafx.scene.Scene`
>>> in your project (without changing the package -- and if modules will allow
>>> it, I don't use them personally) and then using this piece of code:
>>>
>>>     private void setWindowFocused(boolean value) {
>>>         windowFocused = value;
>>>
>>>         Node node = getFocusOwner();
>>>         if (node != null) {
>>>             node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
>>>             node.notifyFocusListeners();
>>>         }
>>>
>>>         if (windowFocused && accessible != null) {
>>>             accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
>>>         }
>>>
>>>         if (!windowFocused) {
>>>
>>> getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
>>>         }
>>>     }
>>>
>>> The last three lines are what I added. A quick test on Windows here
>>> shows that the mnemonics get disabled as soon as the window loses focus,
>>> and when returning, they're not responding as you'd expect.
>>>
>>> I'll submit a PR as well.
>>>
>>> --John
>>> On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>>>
>>> The behavior on Windows is all over the place for different
>>>> applications.? I tested a few I've got running:
>>>
>>>
>>> Notepad, Notepad++, Eclipse:
>>>
>>>
>>> - Alt-down: Shows mnemonics on menu bar
>>>> - Alt-up: Highlights file menu on alt release
>>>> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>>>> focus; when returning, mnemonics still highlighted, but doesn't act on
>>>> them as menu not selected
>>>
>>>
>>> -> Looks buggy
>>>
>>>
>>> Thunderbird / Opera / Firefox:
>>>
>>>
>>> - Alt-down: nothing
>>>> - Alt-up: shows menu bar (it is hidden normally)
>>>> - Alt-tab: works as expected, no highlighting
>>>
>>>
>>> -> Looks well behaved
>>>
>>>
>>> Explorer / Excel / Wordpad:
>>>
>>>
>>> - Alt-down: nothing
>>>> - Alt-up: shows mnemonics
>>>> - Alt-tab: works as expected, no highlighting
>>>
>>>
>>> -> Looks well behaved
>>>
>>>
>>> Visual Studio Code:
>>>
>>>
>>> - Alt-down: Shows mnemonics on menu bar
>>>> - Alt-up: Highlights file menu on alt release
>>>> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>>>> return doesn't show mnemonics
>>>
>>>
>>> -> Looks well behaved
>>>
>>>
>>> Chrome / IntelliJ:
>>>
>>>
>>> -> Looks well behaved, doesn't react to alt presses in any way
>>>
>>>
>>> None of the applications tested reacted on a mnemonic key after
>>>> regaining focus however, even though they may have them still
>>>> highlighted (which I think is a bug).
>>>
>>>
>>> In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
>>>> (they need to hide the mnemonics on focus lost, like Visual Studio Code
>>>> does, but they don't).
>>>
>>>
>>> There seems to be two correct ways of handling mnemonics in applications
>>>> that use them, either:
>>>
>>>
>>> a) shows mnemonics immediately on alt-down, but hide them on focus lost
>>>> (if the alt-down becomes an alt-tab, or probably any other alt
>>>> combination)
>>>
>>>
>>> b) only show mnemonics on a naked alt-up
>>>
>>>
>>> Ticket JDK-8090647 mentions a spec that has been updated, but I can't
>>>> find it.? It also mentions that the behavior for JavaFX should be what I
>>>> described in a), so I think this is a bug that can simply be fixed.
>>>
>>>
>>> --John
>>>
>>>
>>>
>>> Yap, there's quite different behaviors across apps. If you test on
>>> windows 11 you'll get yet another set of different behaviors.
>>>
>>> But all in all, if you: alt+tab (without release) and alt+tab again so
>>> your app regains focus, you'll have the mnemonic still activated, which, as
>>> you say, sounds like a bug no matter the difference in behaviors across
>>> apps.
>>>
>>> I agree with your suggestion: "a".
>>>
>>> My client was quite disappointed and started to rant about javafx. It
>>> didn't help that we were hit by a couple other bugs (perhaps bad
>>> luck).  The fact that the bug was filed on 2013 (10 years later) and is
>>> still happening can be quite problematic.
>>> Perhaps it would make sense to review all bugs filed, giving highest
>>> priority to the bugs that were submitted longer ago?
>>>
>>> Thanks!
>>>
>>> --
>>> Pedro Duque Vieira - https://www.pixelduke.com
>>>
>>>
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
>

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

From swpalmer at gmail.com  Mon Feb 13 15:36:26 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Mon, 13 Feb 2023 10:36:26 -0500
Subject: WebKit Crashes JVM when removing nodes from DOM on wrong thread.
In-Reply-To: <100893c2-fd14-e0fe-2e62-a96b97748742@oracle.com>
References: 
 <100893c2-fd14-e0fe-2e62-a96b97748742@oracle.com>
Message-ID: 

Created JDK-8302336 

On Mon, Feb 13, 2023 at 8:42 AM Kevin Rushforth 
wrote:

> Yes, please file a bug. An intermittent exception would be one thing,
> but it shouldn't actually crash when doing that.
>
> -- Kevin
>
>
> On 2/12/2023 3:49 PM, Scott Palmer wrote:
> > I'm seeing a hard crash in native code that brings down the JVM when I
> > accidentally called removeChild on an element from a WebView Document
> > while not on the Platform thread.  While I know it's my error,
> > bringing down the JVM instead of throwing an exception seems wrong.
> >
> > Should this be considered a bug or not?
> >
> > Scott
> >
> > With JavaFX 17:
> > Thread 50 Crashed:: Java: ForkJoinPool-1-worker-5
> > 0   libjfxwebkit.dylib                   0x14fa2ac33
> > WTFCrashWithInfo(int, char const*, char const*, int) + 19
> > 1   libjfxwebkit.dylib                   0x14ea5b60d
> > WebCore::TimerBase::setNextFireTime(WTF::MonotonicTime) + 541
> > 2   libjfxwebkit.dylib                   0x14ee0a513
> >
> WebCore::RenderTreeBuilder::detachFromRenderElement(WebCore::RenderElement&,
>
> > WebCore::RenderObject&, WebCore::RenderTreeBuilder::WillBeDestroyed) +
> 179
> > 3   libjfxwebkit.dylib                   0x14ee09fa2
> > WebCore::RenderTreeBuilder::Block::detach(WebCore::RenderBlock&,
> > WebCore::RenderObject&,
> > WebCore::RenderTreeBuilder::CanCollapseAnonymousBlock) + 562
> > 4   libjfxwebkit.dylib                   0x14ee085ef
> > WebCore::RenderTreeBuilder::detach(WebCore::RenderElement&,
> > WebCore::RenderObject&,
> > WebCore::RenderTreeBuilder::CanCollapseAnonymousBlock) + 543
> > 5   libjfxwebkit.dylib                   0x14ee082ba
> > WebCore::RenderTreeBuilder::destroy(WebCore::RenderObject&) + 58
> > 6   libjfxwebkit.dylib                   0x14ee0bd57
> >
> WebCore::RenderTreeBuilder::destroyAndCleanUpAnonymousWrappers(WebCore::RenderObject&)
>
> > + 263
> > 7   libjfxwebkit.dylib                   0x14ee19aae
> > WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&,
> > WebCore::RenderTreeUpdater::TeardownType,
> > WebCore::RenderTreeBuilder&)::$_7::operator()(unsigned int) const + 734
> > 8   libjfxwebkit.dylib                   0x14ee18c13
> > WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&,
> > WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&)
> > + 1171
> > 9   libjfxwebkit.dylib                   0x14ee196d1
> > WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&) + 65
> > 10  libjfxwebkit.dylib                   0x14e46db9c
> > WebCore::ContainerNode::removeBetween(WebCore::Node*, WebCore::Node*,
> > WebCore::Node&) + 108
> > 11  libjfxwebkit.dylib                   0x14e46ad44
> > WebCore::ContainerNode::removeChild(WebCore::Node&) + 324
> > 12  libjfxwebkit.dylib                   0x14e50e24b
> > WebCore::Node::removeChild(WebCore::Node&) + 43
> > 13  libjfxwebkit.dylib                   0x14d98deeb
> > Java_com_sun_webkit_dom_NodeImpl_removeChildImpl + 107
> > 14  ???                                 0x1203e753a ???
> > 15  ???                                 0x1203e335c ???
> > 16  ???                                 0x1203e36a2 ???
> > 17  ???                                 0x1203e342b ???
> > 18  ???                                 0x1203e342b ???
> > 19  ???                                 0x1203e388f ???
> > 20  ???                                 0x1203e342b ???
> > 21  ???                                 0x1203e3317 ???
> > 22  ???                                 0x1203e3317 ???
> > 23  ???                                 0x1203e342b ???
> > 24  ???                                 0x1203e3317 ???
> > 25  ???                                 0x1203e342b ???
> > 26  ???                                 0x1203dacc9 ???
> > 27  libjvm.dylib                         0x110790af6
> > JavaCalls::call_helper(JavaValue*, methodHandle const&,
> > JavaCallArguments*, JavaThread*) + 710
> > 28  libjvm.dylib                         0x11078fb47
> > JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*,
> > JavaCallArguments*, JavaThread*) + 327
> > 29  libjvm.dylib                         0x11078fc13
> > JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*,
> > JavaThread*) + 99
> > 30  libjvm.dylib                         0x11083ab94
> > thread_entry(JavaThread*, JavaThread*) + 180
> > 31  libjvm.dylib                         0x110d164af
> > JavaThread::thread_main_inner() + 335
> > 32  libjvm.dylib                         0x110d1481f
> > Thread::call_run() + 207
> > 33  libjvm.dylib                         0x110b1f898
> > thread_native_entry(Thread*) + 328
> > 34  libsystem_pthread.dylib          0x7ff8062b4259 _pthread_start + 125
> > 35  libsystem_pthread.dylib          0x7ff8062afc7b thread_start + 15
> >
> >
> > With JavaFX 19.0.2.1
> > Thread 48 Crashed:: Java: ForkJoinPool-1-worker-2
> > 0   libjfxwebkit.dylib                   0x14f2eb9f3 0x14d0d8000 +
> > 35731955
> > 1   libjfxwebkit.dylib                   0x14e3744a6 0x14d0d8000 +
> > 19514534
> > 2   libjfxwebkit.dylib                   0x14e747d49 0x14d0d8000 +
> > 23526729
> > 3   libjfxwebkit.dylib                   0x14e747798 0x14d0d8000 +
> > 23525272
> > 4   libjfxwebkit.dylib                   0x14e745b7f 0x14d0d8000 +
> > 23518079
> > 5   libjfxwebkit.dylib                   0x14e745837 0x14d0d8000 +
> > 23517239
> > 6   libjfxwebkit.dylib                   0x14e749766 0x14d0d8000 +
> > 23533414
> > 7   libjfxwebkit.dylib                   0x14e757dc1 0x14d0d8000 +
> > 23592385
> > 8   libjfxwebkit.dylib                   0x14e757033 0x14d0d8000 +
> > 23588915
> > 9   libjfxwebkit.dylib                   0x14e757aa1 0x14d0d8000 +
> > 23591585
> > 10  libjfxwebkit.dylib                   0x14dd3a2ec 0x14d0d8000 +
> > 12985068
> > 11  libjfxwebkit.dylib                   0x14dd37344 0x14d0d8000 +
> > 12972868
> > 12  libjfxwebkit.dylib                   0x14dddd01b 0x14d0d8000 +
> > 13651995
> > 13  libjfxwebkit.dylib                   0x14d18841b
> > Java_com_sun_webkit_dom_NodeImpl_removeChildImpl + 107
> > 14  ???                                 0x120a6453a ???
> > 15  ???                                 0x120a6035c ???
> > 16  ???                                 0x120a606a2 ???
> > 17  ???                                 0x120a6042b ???
> > 18  ???                                 0x120a6042b ???
> > 19  ???                                 0x120a6088f ???
> > 20  ???                                 0x120a6042b ???
> > 21  ???                                 0x120a60317 ???
> > 22  ???                                 0x120a60317 ???
> > 23  ???                                 0x120a6042b ???
> > 24  ???                                 0x120a60317 ???
> > 25  ???                                 0x120a6042b ???
> > 26  ???                                 0x120a57cc9 ???
> > 27  libjvm.dylib                         0x110e0daf6
> > JavaCalls::call_helper(JavaValue*, methodHandle const&,
> > JavaCallArguments*, JavaThread*) + 710
> > 28  libjvm.dylib                         0x110e0cb47
> > JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*,
> > JavaCallArguments*, JavaThread*) + 327
> > 29  libjvm.dylib                         0x110e0cc13
> > JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*,
> > JavaThread*) + 99
> > 30  libjvm.dylib                         0x110eb7b94
> > thread_entry(JavaThread*, JavaThread*) + 180
> > 31  libjvm.dylib                         0x1113934af
> > JavaThread::thread_main_inner() + 335
> > 32  libjvm.dylib                         0x11139181f
> > Thread::call_run() + 207
> > 33  libjvm.dylib                         0x11119c898
> > thread_native_entry(Thread*) + 328
> > 34  libsystem_pthread.dylib          0x7ff8062b4259 _pthread_start + 125
> > 35  libsystem_pthread.dylib          0x7ff8062afc7b thread_start + 15
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mhanl at openjdk.org  Mon Feb 13 17:53:41 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 13 Feb 2023 17:53:41 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Jan 2023 23:55:51 GMT, Thiago Milczarek Sayao  wrote:

> This PR does:
> 
> - Remove specific Idea files and let it be imported from gradle;
> - Adds checkstyle (to use with checkstyle plugin - it will let you know style mistakes);
> - Configures auto-format to sun style (with the changes mentioned in [Code Style Rules](https://wiki.openjdk.org/display/OpenJFX/Code+Style+Rules));
> - Automatically sets Copyright notice (updates year too);
> - Run configurations for samples/toys and builds.

Looks good to me. I just tested it with the newest `IntelliJ` version (2022.3.2) and it works fine.
It also follows what IntelliJ is suggesting. 
Also the gradle changes looks fine to me, although not sure how I can start the manual tests.
I left some comments.

.idea/codeStyles/Project.xml line 2:

> 1: 
> 2:   

We should consider adding `