From mstrauss at openjdk.org  Sun Jan  1 04:43:08 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 1 Jan 2023 04:43:08 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v15]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <sEdoXU-ybeLZxteXKo07ppmQDSl8U2EMOjiPZKTLUW4=.d2ade660-9ff1-477c-b8b9-be9dfb8dabd3@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the user-agent stylesheet of the application.
>      * <p>
>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>      * It can be used to provide default styling for UI controls and other nodes.
>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>      * <p>
>      * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>      * scene graph.
>      * <p>
>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. PlatformPreferences
> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface PlatformPreferences extends Map<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> 
>     void addListener(PlatformPreferencesListener listener);
>     void removeListener(PlatformPreferencesListener listener);
> }
> 
> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  Added manual StyleTheme test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/444d4c0d..84598dc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=13-14

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

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

From jhendrikx at openjdk.org  Sun Jan  1 15:06:55 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 1 Jan 2023 15:06:55 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages
In-Reply-To: <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
Message-ID: <5x95Njeallu0gXGrN-RRd1zV8ki0TKfjk766akNVjAw=.3e7fd836-1897-4a12-8f0a-22af9c6d273d@github.com>

On Wed, 28 Dec 2022 18:57:23 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 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/com/sun/javafx/binding/BidirectionalContentBinding.java line 81:
> 
>> 79:         if ((obj1 instanceof ObservableList<?> list1) && (obj2 instanceof ObservableList<?> list2)) {
>> 80:             @SuppressWarnings("unchecked")
>> 81:             final ListContentBinding<Object> binding = new ListContentBinding<>((ObservableList<Object>) list1, (ObservableList<Object>) list2);
> 
> Although the previous code has the same problem, this is sketchy. The two lists can be of different types while `ListContentBinding` requires the same type. This is a result of the `Bindings` public API that takes two `Objects`, so all type information is lost. Is it worth adding a comment about this since suppressing the warning can be understood as "trust me, this is fine".

What would go wrong if they're not the same type?  `ListContentBinding` doesn't (and can't) enforce it and doesn't care either way.  The whole function fails silently if types don't match.  Also `ListContentBinding` is a private class and so I'd expect this code to be aware of how it works and what is/isn't safe to do. 

I personally think this entire class is unfinished.  It fails miserably in edge cases without so much as a warning to the user. Take this for example:

    public static void main(String[] args) {
        ObservableList<String> a = FXCollections.observableArrayList();
        ObservableList<String> b = FXCollections.observableArrayList();
        Bindings.bindContentBidirectional(a, b);
        Bindings.bindContentBidirectional(a, b);
        a.add("A");
        System.out.println(a + " : " + b);
    }

Prints:

    [A, A, A, A] : [A, A, A]

No mention about this in the API docs at all.  It breaks even worse when you make circular bindings `[a,b], [b,c], [c,a]` (stack traces get logged to the console complaining about `IndexOutOfBoundsException`).

I've created a solution that rejects double bindings and circular bindings, but it's a bit out of scope for this.  I think however that it is worth adding, and considering that the current behavior is broken when doing any of such things, not a big API break if instead we throw an exception.

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

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

From jhendrikx at openjdk.org  Sun Jan  1 15:14:57 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 1 Jan 2023 15:14:57 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages
In-Reply-To: <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
Message-ID: <xWkTrgMgC9ZHGxbETlcobE4oObhIhHoRr_bX8RwU9QE=.4e4fd601-9a75-4555-8224-296e09f8f75e@github.com>

On Wed, 28 Dec 2022 19:11:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 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/com/sun/javafx/binding/ContentBinding.java line 89:
> 
>> 87:             ListContentBinding<Object> binding = new ListContentBinding<>((List<Object>) list1);
>> 88: 
>> 89:             list2.removeListener(binding);
> 
> Another problem inherited from the existing code. What if the `obj2` is a `List` and `obj1` is an `ObservableList`? The docs don't say anything about the order.
> 
> Same question as before about adding a comment addressing the case that the two lists are not of the same type.

Yes, looks like this is quite broken. This wouldn't have gone unnoticed so long if unbind would just throw an exception when nothing could be unbound; silently failing is never a good idea.

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

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

From jhendrikx at openjdk.org  Sun Jan  1 15:27:53 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 1 Jan 2023 15:27:53 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages
In-Reply-To: <husAbvarXaJJ4M1ElTLF4EIf6snwJd2iFNLnhV0zvOM=.dfc7fb7c-3253-4fd5-8640-c199743af120@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <husAbvarXaJJ4M1ElTLF4EIf6snwJd2iFNLnhV0zvOM=.dfc7fb7c-3253-4fd5-8640-c199743af120@github.com>
Message-ID: <0DhuNOsx_cabpcZWUzV63eEbslwTe0CKPIW-_BLDlqc=.63adb851-7fb5-4f04-9dcc-4084cf9a3c19@github.com>

On Fri, 30 Dec 2022 20:53:01 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 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 709:
> 
>> 707:     private static class EmptyObservableList<E> extends AbstractList<E> implements ObservableList<E> {
>> 708: 
>> 709:         private static final ListIterator<Object> iterator = new ListIterator<>() {
> 
> Isn't a better fix is to not make this class static and use `<E>`? Other lists create a new iterator on each invocation, but this is effectively a singleton.
> In fact, `EmptyObservableList` doesn't need to be declared because it's called only in one place, so it can be "inlined" when declaring the `EMPTY_LIST` field. Maybe this is out of scope.

I considered all that, and don't mind changing it if we're in agreement.

The reason I didn't is that it would subtly change the iterator (it would have an unnecessary reference to its containing class).

> modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 1640:
> 
>> 1638:         @Override
>> 1639:         public Iterator<E> 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.

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

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

From jhendrikx at openjdk.org  Sun Jan  1 16:08:15 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 1 Jan 2023 16:08:15 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
Message-ID: <fwBTsRBUBl5t-ZLRiy-iMNV6zMNlJSezF-XZgXglEv0=.2637c745-51fa-4b09-9d06-159b8c96ccb6@github.com>

> 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

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

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

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

  Stats: 243 lines in 5 files changed: 3 ins; 172 del; 68 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 Jan  1 16:08:15 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 1 Jan 2023 16:08:15 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <-m4AJZ-2Uw6vNMNV9AwQTMCxamAom5Qklvr5zERmboo=.d87bffe9-e604-4896-82b1-a1edeec75ab2@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <3yOrL-J_4PW5tct6J1qHpkW7ltB4Pd02L5KwjveWd1o=.d0b9e47d-5d46-437e-8963-d4a1d965e297@github.com>
 <jlygcvX6EaumtGwyS4_FbWcnrdmdp6idrE0tYhDqDw8=.c832640f-144f-4f17-b2b7-107b6b60b1aa@github.com>
 <-m4AJZ-2Uw6vNMNV9AwQTMCxamAom5Qklvr5zERmboo=.d87bffe9-e604-4896-82b1-a1edeec75ab2@github.com>
Message-ID: <SSlaZI4nNbBnwuRjnpBBGBh6XCvoCmNhvTrHJ4LVd1M=.a9769837-2884-41ed-ad63-baa385a3ac06@github.com>

On Fri, 30 Dec 2022 16:21:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> I'm fine with that; the first two are equivalent, but in some cases I need to add the type witness to avoid a warning and you can only do that by adding the class name as well (ie. `<E>emptyList()` is not allowed, but `ListExpression.<E>emptyList()` is.
>
> Why not use `FXCollections.<E>emptyObservableList()` directly? If it's too long, a convenvenience method can be used:
> 
>     private static <E> ObservableList<E> emptyList() {
>         return FXCollections.<E>emptyObservableList();
>     }
> 
> No need to hold the instance here again in a way that makes it lose its type and do the same cast (and supress the warning) that `FXCollections` already does.
> 
> Same with the other collections.

I've removed the repeated checks from these classes.

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

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

From john at status6.com  Sun Jan  1 18:40:42 2023
From: john at status6.com (John Neffenger)
Date: Sun, 1 Jan 2023 10:40:42 -0800
Subject: libav.org is not resolving
Message-ID: <28314e5b-688a-31d9-afbd-351514339f99@status6.com>

The domain 'libav.org' is not resolving for at least a week now, causing 
the build to fail when '-PBUILD_LIBAV_STUBS=true' (see below). The 
domain itself is good until 2024:

   Creation Date: 2011-01-19T23:35:14Z
   Registry Expiry Date: 2024-01-19T23:35:14Z

If the problem persists, we could use GitHub as an alternative (assuming 
those are source archives):

https://github.com/libav/libav/archive/v9.14.tar.gz
==> content-disposition: attachment; filename=libav-9.14.tar.gz

https://github.com/libav/libav/archive/v11.4.tar.gz
==> content-disposition: attachment; filename=libav-11.4.tar.gz

https://github.com/libav/libav/archive/v12.1.tar.gz
==> content-disposition: attachment; filename=libav-12.1.tar.gz

I'll keep trying, and I'll test whether the GitHub alternative works.

John

=====================================
 > Task :media:buildFFmpegStubs FAILED

FAILURE: Build failed with an exception.

* Where:
Build file '/home/ubuntu/src/jfx/build.gradle' line: 3264

* What went wrong:
Execution failed for task ':media:buildFFmpegStubs'.
 > Could not resolve all files for configuration ':media:media'.

 > Could not resolve :libav-9.14.
Required by:
project :media
 > Could not resolve :libav-9.14.
 > Could not get resource 'https://libav.org/releases/libav-9.14.tar.gz'.
 > Could not HEAD 'https://libav.org/releases/libav-9.14.tar.gz'.
 > libav.org

 > Could not resolve :libav-11.4.
Required by:
project :media
 > Could not resolve :libav-11.4.
 > Could not get resource 'https://libav.org/releases/libav-11.4.tar.gz'.
 > Could not HEAD 'https://libav.org/releases/libav-11.4.tar.gz'.
 > libav.org

 > Could not resolve :libav-12.1.
Required by:
project :media
 > Could not resolve :libav-12.1.
 > Could not get resource 'https://libav.org/releases/libav-12.1.tar.gz'.
 > Could not HEAD 'https://libav.org/releases/libav-12.1.tar.gz'.
 > libav.org

...

BUILD FAILED in 1m 15s
43 actionable tasks: 43 executed

From swpalmer at gmail.com  Sun Jan  1 19:02:12 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Sun, 1 Jan 2023 14:02:12 -0500
Subject: JavaFX Font support for Emojis
Message-ID: <61387EA4-0690-419B-AA7D-54DD4858A327@gmail.com>

I?ve been experimenting, trying to figure out a cross-platform way of displaying emojis in a JavaFX application.  It has been interesting.

I tested on macOS and Windows 11. On macOS I explicitly set the font to ?Apple Color Emoji?, on Windows 11, I used ?Segoe UI Emoji?.  Those appear to be the standard fonts for emojis on the respective platforms.
 
On macOS with JavaFX, emojis render in monochrome with shades of grey, smaller than they should be and shifted down slightly, sometimes cropping off the bottom pixels.  With Swing (via SwingPane) they render in full colour the same as native applications.

On Windows with JavaFX the emoji is rendered in black and white (no shading) for both JavaFX and Swing.  This is the same as how WordPad renders them, but different than Microsoft Word, which will show the emojis in full colour. The emojis are the right size and not vertically shift as they are on macOS.

If I set the font to something else, I used ?Fira Code? that I downloaded so it should be the exact same on both platforms, I get different behaviour.  
On Windows 11 with JavaFX the \uFE0F combining character that indicates the previous character should be rendered as an emoji causes a blocked ? to print after a non-emoji heart character. (To get a ?Red Heart? emoji I am using the standard Unicode heart ?\u2764? followed by "\uFE0F?.)
Swing on macOS still renders full colour emojis, but on Windows 11 it claims it can?t render the emoji characters at all - sure enough java.awt.Font.canDisplay(codePoint) returns true on macOS and false on Windows 11, even though the font is the same.  

If I use a logical font, e.g. ?Monospaced?, Swing renders the emojis the same as when using the explicit emoji font on both platforms, as does JavaFX on macOS. However, JavaFX on Windows 11 still prints the blocked ? for \uFE0F.

So a few questions:

Can JavaFX render full colour emojis? Is the greyscale rendering on macOS intentional?
Presumably the smaller scale and vertical shift on macOS are bugs?
Can Swing on Windows render emojis in colour like it does on macOS?
(Btw, SwingPane on Windows 11 doesn?t paint at all until it is ?provoked? with some sort of event, like dragging the window so it is partially obscured.)

And finally, is there any hope to get cross-platform support for full colour emojis in a JavaFX application via Text nodes, or would it be best to abandon the idea altogether and use Image nodes for them instead?

Regards,

Scott

From tsayao at openjdk.org  Mon Jan  2 02:25:17 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 2 Jan 2023 02:25:17 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v4]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <nzC8KiBrD1YK5Or70U3OHIv4bLcVe6F7e8n_rkhrenE=.19fdd07a-c2b7-4172-8d1a-0c1c7450de84@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix DragView

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/6c2d5139..eea3f47d

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

  Stats: 149 lines in 2 files changed: 45 ins; 62 del; 42 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From nlisker at openjdk.org  Mon Jan  2 02:52:43 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 2 Jan 2023 02:52:43 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always showing
Message-ID: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>

A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.

Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

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

Commit messages:
 - Removed whitespaces
 - Name and whitespace fixes to the test app
 - Manual test utility
 - Fix

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

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

From nlisker at openjdk.org  Mon Jan  2 02:52:44 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 2 Jan 2023 02:52:44 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <GOfjQ0KPFd4P3XJIMAkciJS5EBkPcf-UXTn3wOmVkB4=.082e123f-5a4b-4f6d-abc6-19541be4a267@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

@aghaisas @kleopatra Since you are the assignee and reported of the original issue, can you have a look?

I also need advice for how to write a test for it as I'm not too familiar with virtual flow.

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

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

From tsayao at openjdk.org  Mon Jan  2 02:54:04 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 2 Jan 2023 02:54:04 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v5]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <wJx3PZHJ35qFwpjK-tcWqiOFJxE-kqA4_x5rbMk0qao=.c0edefcd-c19b-4e0a-a584-c83c5a374031@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix DragView 2/2

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/eea3f47d..7329349f

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

  Stats: 17 lines in 2 files changed: 5 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From tsayao at openjdk.org  Mon Jan  2 03:00:08 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 2 Jan 2023 03:00:08 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v6]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <NiAB8Gc6UxjB4nf7IrUfON0_UIUNWNEvGNbJCFlZZmU=.b2bc6921-810c-4843-a1d1-7498fe0be9f4@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix DragView 3/3

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/7329349f..047c7e03

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

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

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

From fkirmaier at openjdk.org  Mon Jan  2 09:26:14 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Mon, 2 Jan 2023 09:26:14 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v2]
In-Reply-To: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
Message-ID: <TrrJ2Y0WX9cWUCRECjgh4FVMNsYoM3b3RgpW49vs3og=.0edf5f0f-fe7c-4c5f-a599-5a36dea73dee@github.com>

> This PR fixes the leak in the mac system menu bar.
> 
> Inside the native code, NewGlobalRef is called for the callable.
> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
> 
> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
> 
> The unit test verifies, that this bug happened without this change, but no longer happens with this change.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8299423
  Simplified the fix for the mac-menu-bar based on code review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/987/files
  - new: https://git.openjdk.org/jfx/pull/987/files/661ed5e4..02d37146

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

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

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

From kpk at openjdk.org  Mon Jan  2 11:39:19 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 2 Jan 2023 11:39:19 GMT
Subject: RFR: 8216507: StyleablePropertyFactory: example in class javadoc
 does not compile [v3]
In-Reply-To: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
References: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
Message-ID: <n_moELMjienZItb4eDROuJg-oVR1Gs3u60wlUVfwCkE=.11bb4647-3212-4797-a30f-bb11a95c6d27@github.com>

> In the javadoc example of `StyleablePropertyFactory` class, wrong parameter was used while initializing `StyleableProperty`. 
> 
> Assigned the `CssMetadData` object to `SELECTED` variable returned by `createBooleanCssMetaData` method called in anonymous inner-class class, which is then used while initializing `StyleableProperty`.
> 
> Added missing semicolon in the same example.

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

  Add unit test for javadoc example of StyleablePropertyFactory

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/983/files
  - new: https://git.openjdk.org/jfx/pull/983/files/cf0b0ee1..8e1bbb4b

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

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

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

From kpk at openjdk.org  Mon Jan  2 11:42:55 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 2 Jan 2023 11:42:55 GMT
Subject: RFR: 8216507: StyleablePropertyFactory: example in class javadoc
 does not compile [v3]
In-Reply-To: <OnPXYDhfM2qSAQ8JekC4HIX3qrwf2l5SoChxBl9DdVA=.ae2b499c-f764-4ab5-81fe-e92341cb2c42@github.com>
References: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
 <0X0ZIPQz5DDHXmKkAyAztHBJ0kGmmXTWueYPYkb94L4=.ee5ed533-f03e-4e21-8f37-26a0d6ccbc9b@github.com>
 <e3dXxqMy2uddeTOHejq2BjtnsRb0E2FWchb8X5Z97Sw=.6c5d13bb-7e23-451a-a22b-33cbeb37f248@github.com>
 <bD5DW9sDrSYnsE1dDgpeKZUNHOuDhi_99Oi85T1npRw=.3fcdcfb9-a65a-4fd0-a4a9-541df3f4a0f1@github.com>
 <cE7rxHFUvM1pML-RVy-uAzrWHwtYUQ8Pm2IQkwfb8mk=.3e109e0e-4e43-45f8-bdde-32a80480e89e@github.com>
 <6QyvBcLloOQJ2j1F9WTN95uL4VlQKn1SL2Od7TAEAIw=.a216b11d-a78b-4097-82d1-d2bfd70bbcb4@github.com>
 <OnPXYDhfM2qSAQ8JekC4HIX3qrwf2l5SoChxBl9DdVA=.ae2b499c-f764-4ab5-81fe-e92341cb2c42@github.com>
Message-ID: <6WMngIYo8R-jmAijgD5pkyfYIME1BVSshlu7W0Haa-k=.c919e4f0-048b-4ea3-9658-ae8dea5df547@github.com>

On Fri, 23 Dec 2022 17:30:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I think it is good to add unit test to test the example code. Only thing I'm looking at is that if the example changes in future, we need to make sure that corresponding `MyButton` class is updated in unit test. 
>> Since the example code might not change frequently, we can add unit test.
>
> I agree, let's add a unit test, unless  `StyleablePropertyFactoryTest` covers the same scenario.

Added unit test for the 3rd example in `StyleablePropertyFactoryTest`.
Unit test for 1st example is already covered as part of `myBoolean` property.
Since example 2 and 3 are similar except for the place where `createBooleanCssMetaData` method is called, added single test for this.
Please review the newly added unit test

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

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

From arapte at openjdk.org  Mon Jan  2 11:46:00 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 2 Jan 2023 11:46:00 GMT
Subject: RFR: 8296413: Tree/TableView with null focus model throws NPE in
 queryAccessibleAttribute()
In-Reply-To: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
References: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
Message-ID: <DVE26FN-rVaQDligouJAILEhhzKyRAZlb1JLofHSqwo=.eb5769ec-6743-416b-935e-39a346b2d8b8@github.com>

On Fri, 4 Nov 2022 22:58:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> - added test to ensure no exception is thrown from Control.queryAccessibleAttribute() for all accessible attributes values
> - fixed null focus model case in Tree/TableView

Looks good to me, one minor change needed in new file to change copyright year to 2023

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/QueryAccessibleAttributeTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

Please change year to 2023

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

Changes requested by arapte (Reviewer).

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

From lkostyra at openjdk.org  Mon Jan  2 14:10:20 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 2 Jan 2023 14:10:20 GMT
Subject: RFR: 8231864: JavaFX Labels in Tab's VBox is not displayed until
 it is clicked [v2]
In-Reply-To: <w6sJUfz8XPa0ZyZ6zyPMb3lJ3hMBpyPLCwcTA0v4704=.5532aced-2817-4c1d-be8f-99effc0a2026@github.com>
References: <w6sJUfz8XPa0ZyZ6zyPMb3lJ3hMBpyPLCwcTA0v4704=.5532aced-2817-4c1d-be8f-99effc0a2026@github.com>
Message-ID: <kobZY2OAi18ltu9rbscuURg5zmYGPflHs1kNCHbUCh4=.e52a93c3-5a38-4749-8b55-f90d182cb312@github.com>

> Creating a not-displayed node and then modifying its contents caused JFX to not consume its old dirty region and thus not update it. When such node was displayed, its old dirty region was used for drawing, which in some cases (ex. new content taking more space - a Label having more text as in bug request) caused it to clip.
> 
> Resolved by always unionizing dirty regions with new bounds when calculating Node's transformed bounds.
> 
> Change was tested on macOS and Windows 10 and does not affect any tests.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  NGNode: Change comment at dirty bounds update for clarification

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/978/files
  - new: https://git.openjdk.org/jfx/pull/978/files/1fa43f3b..f5348154

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

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

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

From lkostyra at openjdk.org  Mon Jan  2 14:10:20 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 2 Jan 2023 14:10:20 GMT
Subject: RFR: 8231864: JavaFX Labels in Tab's VBox is not displayed until
 it is clicked [v2]
In-Reply-To: <zHMu6iXN4fOpdZj8Dd05OWGVcPfWdWAI3QB03crux4A=.825833c9-0edb-4159-8b6d-fbe16971f7a7@github.com>
References: <w6sJUfz8XPa0ZyZ6zyPMb3lJ3hMBpyPLCwcTA0v4704=.5532aced-2817-4c1d-be8f-99effc0a2026@github.com>
 <zHMu6iXN4fOpdZj8Dd05OWGVcPfWdWAI3QB03crux4A=.825833c9-0edb-4159-8b6d-fbe16971f7a7@github.com>
Message-ID: <Gj3TEmHsR7gyi39-Tt7jJnaYcMMAHxSAXrEJZFLThpE=.0daada5f-a3ec-48e1-a9b9-2e8d2bd7da09@github.com>

On Wed, 21 Dec 2022 13:38:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NGNode: Change comment at dirty bounds update for clarification
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java line 335:
> 
>> 333:         } else {
>> 334:             // TODO I think this is vestigial from Scenario and will never
>> 335:             // actually occur in real life... (RT-23956)
> 
> The comments should be removed and updated to explain the scenario when flow enters the else block and I think RT-23956 can be closed with this fix.

I updated the comment. I agree, RT-23956 can now be closed.

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

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

From mstrauss at openjdk.org  Mon Jan  2 17:06:57 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 2 Jan 2023 17:06:57 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs
In-Reply-To: <xwo8k1JzKrv0twUDEX8KubKH3h9d9NUsm5N9-eMgSzY=.0ef1bf6b-c63b-4717-861e-dc5ba58ee7dd@github.com>
References: <xwo8k1JzKrv0twUDEX8KubKH3h9d9NUsm5N9-eMgSzY=.0ef1bf6b-c63b-4717-861e-dc5ba58ee7dd@github.com>
Message-ID: <MmGxd0J8FKLdVqe9wygg493aGfPBo0mjGQovScZ5fxY=.ed46e407-66f8-42c1-b916-ab1e6ffa046a@github.com>

On Sun, 17 Jul 2022 20:59:46 GMT, John Hendrikx <jhendrikx at openjdk.org> 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

I've re-read the discussion on the [mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034705.html). The approach as implemented in this PR is a good solution, as it has a very low implementation and runtime overhead, and gets us to having consistent histories for change listeners.

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

Marked as reviewed by mstrauss (Committer).

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

From john at status6.com  Mon Jan  2 18:29:45 2023
From: john at status6.com (John Neffenger)
Date: Mon, 2 Jan 2023 10:29:45 -0800
Subject: Cygwin Python 3.9 breaks Windows WebKit build
Message-ID: <52f72b83-3251-60f2-d0d2-cd745f371c02@status6.com>

The latest Python version 3.9 available on Cygwin breaks the WebKit 
build on Windows. The previous version, Python 3.8, works fine.

The bug is reported to Python in the GitHub issue below, but the Python 
developers expect any fix to come from the Cygwin Python maintainers:

   Windows-style path is not recognized under cygwin
   https://github.com/python/cpython/issues/90907

I'm building with:

bash gradlew --no-daemon \
   -PCONF=Release -PPROMOTED_BUILD_NUMBER=7 \
   -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx \
   -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true \
   sdk jmods javadoc

The build fails with the following messages:

----------------------------
 > Task :web:compileNativeWin

...

[424/5282] Generating
     ../../JavaScriptCore/DerivedSources/CombinedDomains.json
FAILED: JavaScriptCore/DerivedSources/CombinedDomains.json
C:/cygwin64/home/john/src/jfx/modules/javafx.web/build/win/Release/
     JavaScriptCore/DerivedSources/CombinedDomains.json
cmd.exe /C "cd /D
     C:\cygwin64\home\john\src\jfx\modules\javafx.web\build\win\Release\
         Source\JavaScriptCore
         && C:\cygwin64\bin\python3.9.exe
     C:/cygwin64/home/john/src/jfx/modules/javafx.web/build/win/Release/
         JavaScriptCore/Scripts/generate-combined-inspector-json.py ...

...

/usr/bin/python3.9: can't open file
'/home/john/src/jfx/modules/javafx.web/build/win/Release/Source/
     JavaScriptCore/C:/cygwin64/home/john/src/jfx/modules/javafx.web/
     build/win/Release/JavaScriptCore/Scripts/
     generate-combined-inspector-json.py':
[Errno 2] No such file or directory
----------------------------

An up-to-date installation of Cygwin has the following Python versions 
available:

----------------------------
$ /usr/sbin/update-alternatives --display python
python - status is auto.
  link currently points to /usr/bin/python3.9
/usr/bin/python2.7 - priority 27
/usr/bin/python3.8 - priority 38
/usr/bin/python3.9 - priority 39
Current `best' version is /usr/bin/python3.9.

$ python --version
Python 3.9.10
----------------------------

To run the build, I had to remove the Python 3.9 packages entirely so 
that only the following two alternatives remain:

----------------------------
$ /usr/sbin/update-alternatives --display python
python - status is auto.
  link currently points to /usr/bin/python3.8
/usr/bin/python2.7 - priority 27
/usr/bin/python3.8 - priority 38
Current `best' version is /usr/bin/python3.8.

$ python --version
Python 3.8.12
----------------------------

John

From john at status6.com  Mon Jan  2 21:04:19 2023
From: john at status6.com (John Neffenger)
Date: Mon, 2 Jan 2023 13:04:19 -0800
Subject: Windows build fails at MediaCapabilities.cpp(323): error C2327
Message-ID: <c5073481-9483-5320-d056-a68854f6d65f@status6.com>

After fixing the error with Cygwin Python 3.9 (see previous message), 
I'm now getting the compiler error shown below. I haven't seen this before.

==================================================
FAILED: Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/
   DerivedSources/unified-sources/UnifiedSource-4babe430-14.cpp.obj

...

C:\cygwin64\home\john\src\jfx\modules\javafx.web\src\main\native\
   Source\WebCore\Modules/mediacapabilities/MediaCapabilities.cpp(323):
   error C2327: 'WebCore::MediaCapabilities::m_encodingTasks':
   is not a type name, static, or enumerator
==================================================

I'm building with the latest Visual Studio 2022 version 17.4.3 
(Community Edition). My environment script defines:

==================================================
# Visual Studio Community 2022
export VS150COMNTOOLS="C:\\Program Files\\Microsoft Visual 
Studio\\2022\\Community\\VC\\Auxiliary\\Build"

cmake=$HOME/opt/cmake-3.25.1-windows-x86_64
jdk=$HOME/opt/jdk-19.0.1
ant=$HOME/opt/apache-ant-1.10.12
==================================================

while the versions in the JavaFX 'build.properties' file are:

==================================================
# JDK
jfx.build.jdk.version=19.0.1

# Toolchains
jfx.build.windows.msvc.version=VS2022-17.1.0+1.0

# Build tools
jfx.build.cmake.version=3.22.3
jfx.build.ant.version=1.10.5
==================================================

I'm slightly ahead in my versions of Microsoft Visual Studio, CMake, and 
Apache Ant, but I've always used the latest releases just to pick up any 
recent fixes for reproducible builds.

The error appears to be coming from the compiler, whose version is shown 
below:

==================================================
$ /cygdrive/c/Program\ Files/Microsoft\ Visual\ 
Studio/2022/Community/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.34.31937 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]
==================================================

John


From nlisker at openjdk.org  Tue Jan  3 00:03:55 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 00:03:55 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <0DhuNOsx_cabpcZWUzV63eEbslwTe0CKPIW-_BLDlqc=.63adb851-7fb5-4f04-9dcc-4084cf9a3c19@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <husAbvarXaJJ4M1ElTLF4EIf6snwJd2iFNLnhV0zvOM=.dfc7fb7c-3253-4fd5-8640-c199743af120@github.com>
 <0DhuNOsx_cabpcZWUzV63eEbslwTe0CKPIW-_BLDlqc=.63adb851-7fb5-4f04-9dcc-4084cf9a3c19@github.com>
Message-ID: <cf5R0-4121FYyuq7DpFJZsiUyfJKf-b9TMAiBZQRc-A=.ba29406f-faeb-4e8e-a015-64a96fea6c8c@github.com>

On Sun, 1 Jan 2023 15:23:16 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 709:
>> 
>>> 707:     private static class EmptyObservableList<E> extends AbstractList<E> implements ObservableList<E> {
>>> 708: 
>>> 709:         private static final ListIterator<Object> iterator = new ListIterator<>() {
>> 
>> Isn't a better fix is to not make this class static and use `<E>`? Other lists create a new iterator on each invocation, but this is effectively a singleton.
>> In fact, `EmptyObservableList` doesn't need to be declared because it's called only in one place, so it can be "inlined" when declaring the `EMPTY_LIST` field. Maybe this is out of scope.
>
> I considered all that, and don't mind changing it if we're in agreement.
> 
> The reason I didn't is that it would subtly change the iterator (it would have an unnecessary reference to its containing class).

In my opinion that's fine. The iterator might not use its reference to the list, but it's using its type information.

As for creating a new iterator on every invocation (like empty set does) or returning the same instance (like empty list does), I don't mind that much and I can't imagine it mattering in terms of performance.

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

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

From tsayao at openjdk.org  Tue Jan  3 00:20:15 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 3 Jan 2023 00:20:15 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v7]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <ON95iReAMM28z5pP8wVjCjkGjG5g3VvacIaxMbN1nD0=.7d6b1669-eeb4-4060-ab6a-cbf8625bd719@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Cursors

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/047c7e03..6c62ba28

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

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

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

From jgneff at openjdk.org  Tue Jan  3 00:21:53 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 3 Jan 2023 00:21:53 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
Message-ID: <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>

> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
> 
> 
> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
> $ bash gradlew sdk jmods javadoc
> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
> 
> 
> The three commands:
> 
> 1. set the build timestamp to the date of the latest source code change,
> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
> 3. recreate the JMOD files with stable file modification times and ordering.
> 
> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
> 
> #### Fixes
> 
> There are at least four sources of non-determinism in the JavaFX builds:
> 
> 1. Build timestamp
> 
>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
> 
> 2. Modification times
> 
>     The JAR, JMOD, and ZIP archives store the modification time of each file.
> 
> 3. File ordering
> 
>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
> 
> 4. Build path
> 
>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
> 
> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
> 
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism

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

 - Add '--date' argument for deterministic JMOD files
 - Merge branch 'master' into allow-reproducible-builds
 - Merge branch 'master' into allow-reproducible-builds
 - Comment out 'jmod --date' until building on JDK 19
   
   Support for the 'jmod --date' option was added to JDK 19 starting
   with the 19+2 early-access build, and it was backported to JDK 17
   starting with release 17.0.3. It is not available in JDK 18.
 - Merge 'master' into allow-reproducible-builds
 - Make minimal changes for new '--date' option
 - Add new '--date' option to JMOD task
 - Add '--source-date' option to JMOD task
 - Get build timestamp in UTC and set ZIP timestamps
   
   Create the build timestamp as a zoned date and time in UTC instead
   of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
   last modification time of ZIP and JAR entries to the local date and
   time in UTC of the instant defined by SOURCE_DATE_EPOCH.
   
   Add a comment as a reminder to make JMOD files deterministic when
   the following enhancements are complete:
   
   * Enable deterministic file content ordering for Jar and Jmod
     https://bugs.openjdk.java.net/browse/JDK-8276764
     https://github.com/openjdk/jdk/pull/6395
   
   * Enable jar and jmod to produce deterministic timestamped content
     https://bugs.openjdk.java.net/browse/JDK-8276766
     https://github.com/openjdk/jdk/pull/6481
 - Merge branch 'master' into allow-reproducible-builds
 - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b

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

Changes: https://git.openjdk.org/jfx/pull/446/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=446&range=07
  Stats: 145 lines in 7 files changed: 115 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/446.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/446/head:pull/446

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

From nlisker at openjdk.org  Tue Jan  3 00:28:58 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 00:28:58 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <5x95Njeallu0gXGrN-RRd1zV8ki0TKfjk766akNVjAw=.3e7fd836-1897-4a12-8f0a-22af9c6d273d@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
 <5x95Njeallu0gXGrN-RRd1zV8ki0TKfjk766akNVjAw=.3e7fd836-1897-4a12-8f0a-22af9c6d273d@github.com>
Message-ID: <JD59yLTii_D36uysl98J-4DQyD82OZ4QHV8LMD2NHrE=.f79b5dc4-1c48-4251-bee2-8fce88c49857@github.com>

On Sun, 1 Jan 2023 15:04:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/BidirectionalContentBinding.java line 81:
>> 
>>> 79:         if ((obj1 instanceof ObservableList<?> list1) && (obj2 instanceof ObservableList<?> list2)) {
>>> 80:             @SuppressWarnings("unchecked")
>>> 81:             final ListContentBinding<Object> binding = new ListContentBinding<>((ObservableList<Object>) list1, (ObservableList<Object>) list2);
>> 
>> Although the previous code has the same problem, this is sketchy. The two lists can be of different types while `ListContentBinding` requires the same type. This is a result of the `Bindings` public API that takes two `Objects`, so all type information is lost. Is it worth adding a comment about this since suppressing the warning can be understood as "trust me, this is fine".
>
> What would go wrong if they're not the same type?  `ListContentBinding` doesn't (and can't) enforce it and doesn't care either way.  The whole function fails silently if types don't match.  Also `ListContentBinding` is a private class and so I'd expect this code to be aware of how it works and what is/isn't safe to do. 
> 
> I personally think this entire class is unfinished.  It fails miserably in edge cases without so much as a warning to the user. Take this for example:
> 
>     public static void main(String[] args) {
>         ObservableList<String> a = FXCollections.observableArrayList();
>         ObservableList<String> b = FXCollections.observableArrayList();
>         Bindings.bindContentBidirectional(a, b);
>         Bindings.bindContentBidirectional(a, b);
>         a.add("A");
>         System.out.println(a + " : " + b);
>     }
> 
> Prints:
> 
>     [A, A, A, A] : [A, A, A]
> 
> No mention about this in the API docs at all.  It breaks even worse when you make circular bindings `[a,b], [b,c], [c,a]` (stack traces get logged to the console complaining about `IndexOutOfBoundsException`).
> 
> I've created a solution that rejects double bindings and circular bindings, but it's a bit out of scope for this.  I think however that it is worth adding, and considering that the current behavior is broken when doing any of such things, not a big API break if instead we throw an exception.

You are right, nothing would go wrong.

I agree that the behavior is undesired and should be fixed in another issue. I was thinking of adding more specific overloads that make sense to the public API and deprecating the method that takes everything, making it throw.

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/ContentBinding.java line 89:
>> 
>>> 87:             ListContentBinding<Object> binding = new ListContentBinding<>((List<Object>) list1);
>>> 88: 
>>> 89:             list2.removeListener(binding);
>> 
>> Another problem inherited from the existing code. What if the `obj2` is a `List` and `obj1` is an `ObservableList`? The docs don't say anything about the order.
>> 
>> Same question as before about adding a comment addressing the case that the two lists are not of the same type.
>
> Yes, looks like this is quite broken. This wouldn't have gone unnoticed so long if unbind would just throw an exception when nothing could be unbound; silently failing is never a good idea.

Can you file an issue for this if it's not filed already?

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

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

From philip.race at oracle.com  Tue Jan  3 00:38:27 2023
From: philip.race at oracle.com (Philip Race)
Date: Mon, 2 Jan 2023 16:38:27 -0800
Subject: JavaFX Font support for Emojis
In-Reply-To: <61387EA4-0690-419B-AA7D-54DD4858A327@gmail.com>
References: <61387EA4-0690-419B-AA7D-54DD4858A327@gmail.com>
Message-ID: <efb33166-7730-21f2-d63a-d1e505242509@oracle.com>

>Can JavaFX render full colour emojis? Is the greyscale rendering on macOS intentional?

https://bugs.openjdk.org/browse/JDK-8290866
I was looking at this before we started our winter break, and realised it was
going to be a chunk of work.

So not intentional but anything that ever appeared to work was just serendipitous.

> Presumably the smaller scale and vertical shift on macOS are bugs?

Not noticed vertical shift but for the size problem this was already reported but not yet investigated
https://bugs.openjdk.org/browse/JDK-8291469


> Can Swing on Windows render emojis in colour like it does on macOS?

You mean Java 2D ? Swing is "FX Controls" whereas Java 2D is "FX Graphics".
What you see on Windows is because Windows Emoji fonts also contain
standard glyphs and so any font / text code that doesn't know about Emojis
uses those so gets something sensible, just not in colour.t

Apple's Emoji font just contains PNG images at several sizes .. CoreText scales
the closest image of the same size or larger to what is requested.

BTW GDI will never be updated to report Emoji glyphs, but I think Java 2D
on Windows can use freetype for that rather than more complex migration to DirectWrite.


>(Btw, SwingPane on Windows 11 doesn?t paint at all until it is ?provoked? with some sort of event,
> like dragging the window so it is partially obscured.)

I think Kevin recently discovered this and there's a bug open.

 >? And finally, is there any hope to get cross-platform support for 
full colour emojis in a JavaFX application
 > via Text nodes, or would it be best to abandon the idea altogether 
and use Image nodes for them instead?

Well, there is not going to be a cross-platform way for this to work 
internally
Some code can be cross-platform but platform-specific code is inevitable.
I mean in the FX implementation. I am not suggesting FX user apps try this

So it is probable that Emoji support will appear one platform at a time but
will always be cross-platform to user code .. it'll just be a matter of 
whether it works or not.

But the goal is (or should be) that they appear in colour in Text nodes 
and UI controls
no matter what the text rendering mode. There may be some challenges 
along the
way to this, but that is the goal.

-phil.

On 1/1/23 11:02 AM, Scott Palmer wrote:
> I?ve been experimenting, trying to figure out a cross-platform way of displaying emojis in a JavaFX application.  It has been interesting.
>
> I tested on macOS and Windows 11. On macOS I explicitly set the font to ?Apple Color Emoji?, on Windows 11, I used ?Segoe UI Emoji?.  Those appear to be the standard fonts for emojis on the respective platforms.
>   
> On macOS with JavaFX, emojis render in monochrome with shades of grey, smaller than they should be and shifted down slightly, sometimes cropping off the bottom pixels.  With Swing (via SwingPane) they render in full colour the same as native applications.
>
> On Windows with JavaFX the emoji is rendered in black and white (no shading) for both JavaFX and Swing.  This is the same as how WordPad renders them, but different than Microsoft Word, which will show the emojis in full colour. The emojis are the right size and not vertically shift as they are on macOS.
>
> If I set the font to something else, I used ?Fira Code? that I downloaded so it should be the exact same on both platforms, I get different behaviour.
> On Windows 11 with JavaFX the \uFE0F combining character that indicates the previous character should be rendered as an emoji causes a blocked ? to print after a non-emoji heart character. (To get a ?Red Heart? emoji I am using the standard Unicode heart ?\u2764? followed by "\uFE0F?.)
> Swing on macOS still renders full colour emojis, but on Windows 11 it claims it can?t render the emoji characters at all - sure enough java.awt.Font.canDisplay(codePoint) returns true on macOS and false on Windows 11, even though the font is the same.
>
> If I use a logical font, e.g. ?Monospaced?, Swing renders the emojis the same as when using the explicit emoji font on both platforms, as does JavaFX on macOS. However, JavaFX on Windows 11 still prints the blocked ? for \uFE0F.
>
> So a few questions:
>
> Can JavaFX render full colour emojis? Is the greyscale rendering on macOS intentional?
> Presumably the smaller scale and vertical shift on macOS are bugs?
> Can Swing on Windows render emojis in colour like it does on macOS?
> (Btw, SwingPane on Windows 11 doesn?t paint at all until it is ?provoked? with some sort of event, like dragging the window so it is partially obscured.)
>
> And finally, is there any hope to get cross-platform support for full colour emojis in a JavaFX application via Text nodes, or would it be best to abandon the idea altogether and use Image nodes for them instead?
>
> Regards,
>
> Scott


From jgneff at openjdk.org  Tue Jan  3 01:04:04 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 3 Jan 2023 01:04:04 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
Message-ID: <jqziqmt06Ixt8WPwDpoy9bToL_mI9BYE8jFgPSNJPhU=.441b20dd-c1fe-4a87-b0d9-4f841df75d9c@github.com>

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
>> 
>> 
>> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
>> $ bash gradlew sdk jmods javadoc
>> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
>> 
>> 
>> The three commands:
>> 
>> 1. set the build timestamp to the date of the latest source code change,
>> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
>> 3. recreate the JMOD files with stable file modification times and ordering.
>> 
>> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
>> 
>> #### Fixes
>> 
>> There are at least four sources of non-determinism in the JavaFX builds:
>> 
>> 1. Build timestamp
>> 
>>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
>> 
>> 2. Modification times
>> 
>>     The JAR, JMOD, and ZIP archives store the modification time of each file.
>> 
>> 3. File ordering
>> 
>>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
>> 
>> 4. Build path
>> 
>>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
>> 
>> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
>> 
>> [1]: https://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add '--date' argument for deterministic JMOD files
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Comment out 'jmod --date' until building on JDK 19
>    
>    Support for the 'jmod --date' option was added to JDK 19 starting
>    with the 19+2 early-access build, and it was backported to JDK 17
>    starting with release 17.0.3. It is not available in JDK 18.
>  - Merge 'master' into allow-reproducible-builds
>  - Make minimal changes for new '--date' option
>  - Add new '--date' option to JMOD task
>  - Add '--source-date' option to JMOD task
>  - Get build timestamp in UTC and set ZIP timestamps
>    
>    Create the build timestamp as a zoned date and time in UTC instead
>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>    last modification time of ZIP and JAR entries to the local date and
>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>    
>    Add a comment as a reminder to make JMOD files deterministic when
>    the following enhancements are complete:
>    
>    * Enable deterministic file content ordering for Jar and Jmod
>      https://bugs.openjdk.java.net/browse/JDK-8276764
>      https://github.com/openjdk/jdk/pull/6395
>    
>    * Enable jar and jmod to produce deterministic timestamped content
>      https://bugs.openjdk.java.net/browse/JDK-8276766
>      https://github.com/openjdk/jdk/pull/6481
>  - Merge branch 'master' into allow-reproducible-builds
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b

The results of my latest tests are shown below for each type of build:

| System  | Develop | Actions | Release | Notes                        |
|:-------:|:-------:|:-------:|:-------:| ---------------------------- |
| Linux   |    ?    |    ?    |    ?    | Release build failed         |
| macOS   |    ?    |    ?    |    ?    | Some shared libraries differ |
| Windows |    ?    |    ?    |    ?    | Release build failed         |

where:

? means that the unit tests ran successfully and that the files in the `build` directory were identical between two builds in the same project directory on the same system,

? means there were random differences in the native shared libraries between the two builds, such as `libjavafx_iio.dylib`, `libglib-lite.dylib`, and `libjfxwebkit.dylib`, and

? means the build failed due to an error unrelated to this pull request.

The build types are defined by the Shell scripts in the repository [jgneff/jfxbuild][1]. The Release build failed on Linux because [libav.org is not resolving][2]. The Release build failed on Windows due to [compiler error C2327][3].

[1]: https://github.com/jgneff/jfxbuild
[2]: https://mail.openjdk.org/pipermail/openjfx-dev/2023-January/037808.html
[3]: https://mail.openjdk.org/pipermail/openjfx-dev/2023-January/037823.html

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

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

From tsayao at openjdk.org  Tue Jan  3 01:09:08 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 3 Jan 2023 01:09:08 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v8]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <X-EhCxTLVGLcb59WHlilzwowh70JIGz5UV9bn3R49FU=.c817ca3d-ae46-4e4c-9087-f1f484d1940b@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix DragWindow 4/4

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/6c62ba28..5150b5ce

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

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

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

From arapte at openjdk.org  Tue Jan  3 05:55:58 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 3 Jan 2023 05:55:58 GMT
Subject: RFR: 8251862: Wrong position of Popup windows at the intersection
 of 2 screens [v2]
In-Reply-To: <HCQUYj1RCrVJUM6932iKXmRldCy7LX4fG9bCywibMa8=.cc1e280f-b761-4ef2-bb22-a9177d67d3e4@github.com>
References: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
 <HCQUYj1RCrVJUM6932iKXmRldCy7LX4fG9bCywibMa8=.cc1e280f-b761-4ef2-bb22-a9177d67d3e4@github.com>
Message-ID: <YAKefTEoJtZY2wugdkmDhCrGJqNVpX6bkUySGCnXxPQ=.502ae52b-f2f5-4af7-a217-3ca6972811f5@github.com>

On Fri, 23 Dec 2022 14:46:25 GMT, Kevin Rushforth <kcr at openjdk.org> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8251862-multi-screen-popup
>  - 8251862: Wrong position of Popup windows at the intersection of 2 screens

I noticed some wrong position of menu popup when tested with 2 external monitors.
I have a monitors configured in portrait mode as:
![Screenshot 2022-12-09 145806](https://user-images.githubusercontent.com/11330676/210305749-d5073945-bfaa-44cc-98eb-172f6b344e22.png)

Screenshots of some observations:
1. 
![Screenshot 2022-12-09 144504](https://user-images.githubusercontent.com/11330676/210305790-61530649-eaec-441b-8262-ebd9f7bb877c.png)
2.
![Screenshot 2022-12-09 144624](https://user-images.githubusercontent.com/11330676/210305822-6b3aa883-bb2f-496d-9a0a-6f95fcffdddb.png)
3.
![Screenshot 2022-12-09 145645](https://user-images.githubusercontent.com/11330676/210305861-5249ee28-3898-4d5b-8b52-d3e1b3389af2.png)
4.
![Screenshot 2022-12-09 144722](https://user-images.githubusercontent.com/11330676/210305838-711ddcfa-a3ee-4b35-8b02-f1a510d080f9.png)

Similar behavior can also be observed if monitors are in landscape mode:
![Screenshot 2022-12-09 150231](https://user-images.githubusercontent.com/11330676/210305945-ba171790-4767-4cd2-96c4-2f6fb57b7e50.png)

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

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

From mstrauss at openjdk.org  Tue Jan  3 06:31:37 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 3 Jan 2023 06:31:37 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
Message-ID: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>

> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
> 
> The following program shows the problem for HBox:
> 
> Region r1 = new Region();
> Region r2 = new Region();
> Region r3 = new Region();
> Region r4 = new Region();
> Region r5 = new Region();
> Region r6 = new Region();
> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
> r1.setPrefWidth(25.3);
> r2.setPrefWidth(25.3);
> r3.setPrefWidth(25.4);
> r4.setPrefWidth(25.3);
> r5.setPrefWidth(25.3);
> r6.setPrefWidth(25.4);
> r1.setMaxHeight(30);
> r2.setMaxHeight(30);
> r3.setMaxHeight(30);
> r4.setMaxHeight(30);
> r5.setMaxHeight(30);
> r6.setMaxHeight(30);
> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
> hbox1.setPrefHeight(40);
> 
> r1 = new Region();
> r2 = new Region();
> r3 = new Region();
> r4 = new Region();
> r5 = new Region();
> r6 = new Region();
> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
> r1.setPrefWidth(25.3);
> r2.setPrefWidth(25.3);
> r3.setPrefWidth(25.4);
> r4.setPrefWidth(25.3);
> r5.setPrefWidth(25.3);
> r6.setPrefWidth(25.4);
> r1.setMaxHeight(30);
> r2.setMaxHeight(30);
> r3.setMaxHeight(30);
> r4.setMaxHeight(30);
> r5.setMaxHeight(30);
> r6.setMaxHeight(30);
> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
> hbox2.setPrefHeight(40);
> hbox2.setPrefWidth(152);
> 
> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
> root.setSpacing(20);
> Scene scene = new Scene(root, 500, 250);
> 
> primaryStage.setScene(scene);
> primaryStage.show();
> 
> 
> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
> 
> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - changes per review
 - Merge branch 'master' into fixes/box-snap-to-pixel
   
   # Conflicts:
   #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
   #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
 - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
 - revert snappedSum
 - don't call snappedSum in hot loop
 - Improved code documentation
 - Merge branch 'master' into fixes/box-snap-to-pixel
 - changed some method names, make test config a local class
 - added documentation, improved method names
 - Merge branch 'master' into fixes/box-snap-to-pixel
 - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

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

Changes: https://git.openjdk.org/jfx/pull/445/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=445&range=06
  Stats: 465 lines in 5 files changed: 355 ins; 16 del; 94 mod
  Patch: https://git.openjdk.org/jfx/pull/445.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/445/head:pull/445

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

From mstrauss at openjdk.org  Tue Jan  3 06:31:41 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 3 Jan 2023 06:31:41 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v6]
In-Reply-To: <revc_ZKFAyg3JGZ0UBmHIAgiDt7GM1T5rvJlVVSmupc=.2a56fb30-3f4b-48bd-be6b-6a662f52de4e@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <Ba_WtrpY71Q7pH7T-LgfNlUO1YMK-scaJ6mawML_3GI=.ae9d1bdd-8ccd-4320-9c9d-6defcff30b3e@github.com>
 <revc_ZKFAyg3JGZ0UBmHIAgiDt7GM1T5rvJlVVSmupc=.2a56fb30-3f4b-48bd-be6b-6a662f52de4e@github.com>
Message-ID: <tQZpL_d84bY8KuNEKvTiRWkWlOvqzbOME7_6GOY4tX0=.6d1b3b67-3fd3-48c9-9c80-9979c6df5490@github.com>

On Sun, 11 Sep 2022 21:10:50 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>>  - revert snappedSum
>>  - don't call snappedSum in hot loop
>>  - Improved code documentation
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>  - changed some method names, make test config a local class
>>  - added documentation, improved method names
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>  - Fix pixel-snapping glitches in VBox/HBox
>>  - Failing test
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java line 804:
> 
>> 802:      */
>> 803:     @Test public void testPixelSnappedContentHeightIsSameAsBoxHeight() {
>> 804:         class testPixelSnapConfig {
> 
> should be `TestPixelSnapConfig`. 
> And I think for the sake of testing, this can be a standalone class or inner class as well

I've renamed the class. Since it is not reusable and only relevant within this single test, I think it's okay to leave it as a local class.

> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java line 819:
> 
>> 817:             // For these tests, VBox.prefHeight is specified, so we expect the final height to be exactly that.
>> 818:             // Child heights will be adjusted appropriately such that the sum of child widths corresponds to VBox.prefHeight.
>> 819:             new testPixelSnapConfig(76.0, 1.0, true),
> 
> I would prefer the initialization of the array before looping so the code looks more clean

Done.

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

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

From mstrauss at openjdk.org  Tue Jan  3 06:37:59 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 3 Jan 2023 06:37:59 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v5]
In-Reply-To: <XxCLgBzeZqFH-MgSwlWoTaJN4ERUaG1WtM6bMc3rg9E=.88f4b740-2bd4-4932-9f28-6ff7787737da@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <dPTHQPJefkIZDMHI38NJMtsBmF_UpsSq3TDknUIiM9g=.b5da17b0-c597-4007-a621-ef32ee50bc56@github.com>
 <XxCLgBzeZqFH-MgSwlWoTaJN4ERUaG1WtM6bMc3rg9E=.88f4b740-2bd4-4932-9f28-6ff7787737da@github.com>
Message-ID: <UZ3lSc7piSTfKNlhDEx5IgX1siJvadnNY1rZCd33pbc=.5b77925c-cb00-460b-b5b6-9c40b4283534@github.com>

On Tue, 5 Jul 2022 22:16:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert snappedSum
>>  - don't call snappedSum in hot loop
>
> I've expanded the documentation of the improved algorithm, which hopefully makes it easier to understand the changes.

> @mstr2 Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information.

Not sure what happened here. I didn't rebase or force-push.

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

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

From jgneff at openjdk.org  Tue Jan  3 06:40:04 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 3 Jan 2023 06:40:04 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
Message-ID: <OC0RJP3TmGyQNQeEknB319xpvfwxREnT6q9Y7jCEK2Y=.15c67635-06c4-4c68-9229-7d8bf711e9fa@github.com>

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
>> 
>> 
>> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
>> $ bash gradlew sdk jmods javadoc
>> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
>> 
>> 
>> The three commands:
>> 
>> 1. set the build timestamp to the date of the latest source code change,
>> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
>> 3. recreate the JMOD files with stable file modification times and ordering.
>> 
>> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
>> 
>> #### Fixes
>> 
>> There are at least four sources of non-determinism in the JavaFX builds:
>> 
>> 1. Build timestamp
>> 
>>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
>> 
>> 2. Modification times
>> 
>>     The JAR, JMOD, and ZIP archives store the modification time of each file.
>> 
>> 3. File ordering
>> 
>>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
>> 
>> 4. Build path
>> 
>>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
>> 
>> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
>> 
>> [1]: https://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add '--date' argument for deterministic JMOD files
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Comment out 'jmod --date' until building on JDK 19
>    
>    Support for the 'jmod --date' option was added to JDK 19 starting
>    with the 19+2 early-access build, and it was backported to JDK 17
>    starting with release 17.0.3. It is not available in JDK 18.
>  - Merge 'master' into allow-reproducible-builds
>  - Make minimal changes for new '--date' option
>  - Add new '--date' option to JMOD task
>  - Add '--source-date' option to JMOD task
>  - Get build timestamp in UTC and set ZIP timestamps
>    
>    Create the build timestamp as a zoned date and time in UTC instead
>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>    last modification time of ZIP and JAR entries to the local date and
>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>    
>    Add a comment as a reminder to make JMOD files deterministic when
>    the following enhancements are complete:
>    
>    * Enable deterministic file content ordering for Jar and Jmod
>      https://bugs.openjdk.java.net/browse/JDK-8276764
>      https://github.com/openjdk/jdk/pull/6395
>    
>    * Enable jar and jmod to produce deterministic timestamped content
>      https://bugs.openjdk.java.net/browse/JDK-8276766
>      https://github.com/openjdk/jdk/pull/6481
>  - Merge branch 'master' into allow-reproducible-builds
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b

I also confirmed that the builds are reproducible on all of the following Linux architectures running Ubuntu 18.04 LTS when built from the same project path:

| Architecture | Develop |
|:------------:|:-------:|
| amd64        |    ?    |
| arm64        |    ?    |
| armhf        |    ?    |
| i386         |    ?    |
| ppc64el      |    ?    |
| s390x        |    ?    |

where the Develop build script includes:


SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH
bash gradlew --no-daemon -PPROMOTED_BUILD_NUMBER=14 \
    -PRELEASE_SUFFIX="-ea" -PJDK_DOCS="$JDK_DOCS" \
    sdk jmods javadoc


I just discovered that the `--date` argument for the `jmod` tool was back-ported to JDK 17, so I didn't need to wait for JDK 19 after all! Oh well. I think this pull request is now ready for a final review. I welcome any other comments or suggestions.

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

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

From jhendrikx at openjdk.org  Tue Jan  3 09:42:05 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 09:42:05 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v2]
In-Reply-To: <xwo8k1JzKrv0twUDEX8KubKH3h9d9NUsm5N9-eMgSzY=.0ef1bf6b-c63b-4717-861e-dc5ba58ee7dd@github.com>
References: <xwo8k1JzKrv0twUDEX8KubKH3h9d9NUsm5N9-eMgSzY=.0ef1bf6b-c63b-4717-861e-dc5ba58ee7dd@github.com>
Message-ID: <y09ysfJAlFMb1e4eX_qzflZYi4RLPOYYTbouvlxBdtA=.636c4cb1-9ffd-45df-9d21-a56156152c6e@github.com>

> 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

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

Changes: https://git.openjdk.org/jfx/pull/837/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=837&range=01
  Stats: 505 lines in 4 files changed: 466 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 arapte at openjdk.org  Tue Jan  3 09:49:58 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 3 Jan 2023 09:49:58 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
Message-ID: <MoGbWwy5kz6admUJgLrNqRZUJnD2F00JL2xjlDWeZ3A=.8b3d48b9-b0e4-4ce7-b604-7a2c18f6f908@github.com>

On Mon, 27 Apr 2020 11:43:28 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
> 
> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.

Looks good to me. Tested on Windows10 and verified that not setting `observer` to `null` does not lead to any leak.
Please merge with latest master to trigger a GitHub build and test.

Under a different bug, should we implement the `dispose()` method? Track all observables in a Weak list and remove `observer` from them in `dispose()`

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

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

From jhendrikx at openjdk.org  Tue Jan  3 09:54:42 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 09:54:42 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes [v2]
In-Reply-To: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
Message-ID: <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>

> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
> 
> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.

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

 - Merge branch 'master' of https://git.openjdk.org/jfx into feature/unbind
 - 8243115: Unregister bindings when unbind called multiple times
   
   This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/198/files
  - new: https://git.openjdk.org/jfx/pull/198/files/e3095db3..011017b7

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

  Stats: 2030609 lines in 18328 files changed: 1087981 ins; 691043 del; 251585 mod
  Patch: https://git.openjdk.org/jfx/pull/198.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/198/head:pull/198

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

From jhendrikx at openjdk.org  Tue Jan  3 10:15:58 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 10:15:58 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <jCBB3wQ-xQD0WLrlPaWBMhwZCI9j9v8nKCXN7AYmfpA=.461d6d60-3957-4c64-8e50-1e6aaf333766@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <QZ0E_MGhzgEniRfDuSbWlNrE3q3tyKFs_uYEYZQD4yg=.f18a7e31-d6c7-4f49-97a9-1ce45d91d340@github.com>
 <iZ_VKNDGhAubihs6UADT1FIt2uiCtvyhMZ2CamQ9O_Q=.5cebb3e4-7f01-442d-8df5-131eda2e88ca@github.com>
 <CrlqE2AOM48IdHVVJi4YKpWjOPRDQMPwHUATqfFICOo=.77648651-e422-4c07-b2f7-967ca0175a0a@github.com>
 <enIdAX-RsWxJP9xhOs-h2po16HmEZS3v8sPVqqsy9O8=.0c7cd310-3ec9-4645-a232-5613b747f713@github.com>
 <rrFVTMzwK3LDpR9_AUiR8TUvaVBTira0f8aFayFGqTU=.af400e92-f0de-4a4b-94af-31d8594872a6@github.com>
 <KzSfiCjfavbfvs-eGcaHt6RYJnPqxAqXRHGjSb8tuVg=.d4539e42-90b7-409a-ba9c-1e0c526378ec@github.com>
 <jCBB3wQ-xQD0WLrlPaWBMhwZCI9j9v8nKCXN7AYmfpA=.461d6d60-3957-4c64-8e50-1e6aaf333766@github.com>
Message-ID: <fEC2tXP2IuUxxLJbH0CcyZ-X9-8lox7CYhbc10B8oVw=.2aec3e97-02cd-44ee-bd86-c183a45cdbc8@github.com>

On Tue, 12 May 2020 22:41:14 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > I'm fine with doing a fix, but I need to know which one. Avoiding NPE's and silently doing nothing is IMHO not very desirable as this will give the user of the API no feedback that something went wrong.
> > So I would prefer to fix this by documenting that these cases will result in a NPE.
> > The `bind` method has a similar issue -- it doesn't check its array elements for `null`, and will throw a NPE when attempting to add a listener to `null`. Again, I would just document the NPE so what is clearly a mistake doesn't go unnoticed.
> 
> I think that checking the array elements doesn't help much because by the time you can check them they will already be used, and that will throw an NPE implicitly.

(I must have missed this comment)

What I meant here was to document this behavior, not to add a null check.  So for bind:


    /**
     * Start observing the dependencies for changes. If the value of one of the
     * dependencies changes, the binding is marked as invalid.
     *
     * @param dependencies
     *            the dependencies to observe
+    * @throws NullPointerException when dependencies is null, or any of its elements was null
     */
    protected final void bind(Observable... dependencies) {
-       if ((dependencies != null) && (dependencies.length > 0)) {
+       if (dependencies.length > 0) {
            if (observer == null) {
                observer = new BindingHelperObserver(this);
            }
            for (final Observable dep : dependencies) {
                dep.addListener(observer);
            }
        }
    }


And if you want to be even more specific, we could add that when a NPE is thrown, the result is undefined (as some dependencies may have been added already).  I don't think we want to specify that case.

> `bind` is no-op for `null` or 0-length arrays, but should have probably throw an NPE on the `null` case. The 0-length check saves creating the `observer`, so I think it makes sense. `unbind` should probably only throw an NPE on `null` arrays, but that happens implicitly anyway, so maybe there is no change needed unless it's for clarity because we can add a custom error message.

I don't think we should throw a specific exception (or add a message), only documentation. IMHO, passing `null` anywhere in any form, is always incorrect and doesn't require further explanation unless explicitly allowed in the documentation.

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

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

From jhendrikx at openjdk.org  Tue Jan  3 10:36:56 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 10:36:56 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes
In-Reply-To: <MoGbWwy5kz6admUJgLrNqRZUJnD2F00JL2xjlDWeZ3A=.8b3d48b9-b0e4-4ce7-b604-7a2c18f6f908@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <MoGbWwy5kz6admUJgLrNqRZUJnD2F00JL2xjlDWeZ3A=.8b3d48b9-b0e4-4ce7-b604-7a2c18f6f908@github.com>
Message-ID: <-qwGLA1KaYzWsajDY8zt39Wq9wjAoPsrvcsjg3VfRhU=.51acdf08-c88b-499e-a56f-a278852297b5@github.com>

On Tue, 3 Jan 2023 09:46:51 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Looks good to me. Tested on Windows10 and verified that not setting `observer` to `null` does not lead to any leak. Please merge with latest master to trigger a GitHub build and test.

Thanks, I've merged in master.

> Under a different bug, should we implement the `dispose()` method? Track all observables in a Weak list and remove `observer` from them in `dispose()`

Perhaps, currently only more specific implementations (provided mainly by `Bindings`) do this. 

I think it was left up to the subclass to decide whether this would be worth it in order to keep bindings as light weight as possible. `dispose` certainly makes no promises in that regard (it basically makes no promises at all after reading the docs).

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

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

From jhendrikx at openjdk.org  Tue Jan  3 11:03:58 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 11:03:58 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
Message-ID: <6H986k3tNv1ie_yZFWoOmFOzGw-p3d-KfOkzIE059tQ=.6954a62e-ec9c-4caf-8c0c-880c30dbd350@github.com>

On Wed, 28 Dec 2022 20:16:51 GMT, Nir Lisker <nlisker at openjdk.org> 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
>
> modules/javafx.base/src/main/java/com/sun/javafx/collections/MappingChange.java line 38:
> 
>> 36:     private List<F> removed;
>> 37: 
>> 38:     private static final Map<?, ?> NOOP_MAP = new Map<>() {
> 
> I think that we can do better with a bit of refactoring. The `Map` interface here is just `java.util.Function`. We can get rid of it and use `Function` instead. The `map` method call in `getRemoved` will be replaced with `apply`. The call sites needs just a little adjustment:
> * In `TableView::TableViewArrayListSelectionModel` the `cellToIndicesMap` needs to change its type to `Function`, but it is also unused (didn't look what it was supposed to be for), so no issue there.
> * In `TableView`, the method `fireCustomSelectedCellsListChangeEvent` needs to change its 2nd argument in the `MappingChange` constructor to `Function.indentity()` or something like `f -> f`.
> * Same changes for `TreeTableView`.
> 
> I think that we can also use JavaFX's `Callback`, though I never use it if I can use `Function`.

Changed as suggested; I removed the unused fields.

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

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

From jhendrikx at openjdk.org  Tue Jan  3 11:25:57 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 11:25:57 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <JD59yLTii_D36uysl98J-4DQyD82OZ4QHV8LMD2NHrE=.f79b5dc4-1c48-4251-bee2-8fce88c49857@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
 <5x95Njeallu0gXGrN-RRd1zV8ki0TKfjk766akNVjAw=.3e7fd836-1897-4a12-8f0a-22af9c6d273d@github.com>
 <JD59yLTii_D36uysl98J-4DQyD82OZ4QHV8LMD2NHrE=.f79b5dc4-1c48-4251-bee2-8fce88c49857@github.com>
Message-ID: <0LserJM07I-oeM95h20Y6_-oB4cE15GrJKfDj3mK7yQ=.8f8ac5ce-500b-4092-98a4-59f9615b3cd2@github.com>

On Tue, 3 Jan 2023 00:26:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Yes, looks like this is quite broken. This wouldn't have gone unnoticed so long if unbind would just throw an exception when nothing could be unbound; silently failing is never a good idea.
>
> Can you file an issue for this if it's not filed already?

I've filed https://bugs.openjdk.org/browse/JDK-8299521

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

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

From aghaisas at openjdk.org  Tue Jan  3 12:05:01 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 3 Jan 2023 12:05:01 GMT
Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing [v2]
In-Reply-To: <AbaGBLHuA_YL-I8hYhdnk2qPl7iFMbiIsjzOH6BQVZM=.268d1821-47ee-4dda-a4f7-a7bc59e4d5ea@github.com>
References: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
 <AbaGBLHuA_YL-I8hYhdnk2qPl7iFMbiIsjzOH6BQVZM=.268d1821-47ee-4dda-a4f7-a7bc59e4d5ea@github.com>
Message-ID: <dqjMXkFKiQClpgCCjhIPsefMebT2JncJtIu6HqAPeI0=.b1e562c7-65af-4bf1-9ba3-00ce483912d6@github.com>

On Tue, 20 Dec 2022 17:49:13 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> When recalculating sizes, we often don't want the current index and/or offset to change.
>> 
>> Allow to fix the index/offset when doing recalculations.
>> 
>> Fix JDK-8298728
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move statements to new lines.
>   Add another failing test, and a fix: when the cell that is positioned at the "current index"
>   is resized, we also need to modify the offset (wich is calculated from the top of that cell
>   to the start of the viewport).

Overall fix looks good to me.

I have identified two very minor typos.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2329:

> 2327:             getOrCreateCellSize(index - 1);
> 2328:         }
> 2329:         if (index < getCellCount() -1) {

Minor : Need a space after `-`

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1473:

> 1471: 
> 1472: 
> 1473:         for (int i =0 ; i < heights.length; i++) {

Minor : Need a space after `=`

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

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

From jhendrikx at openjdk.org  Tue Jan  3 13:11:56 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 13:11:56 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <JD59yLTii_D36uysl98J-4DQyD82OZ4QHV8LMD2NHrE=.f79b5dc4-1c48-4251-bee2-8fce88c49857@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <zD4lJP6Xl989_71WOwCzZdZ22JM9tZKYnfl12r5io9s=.41c40bdb-3d8e-4bc2-a894-9b5deec36cde@github.com>
 <5x95Njeallu0gXGrN-RRd1zV8ki0TKfjk766akNVjAw=.3e7fd836-1897-4a12-8f0a-22af9c6d273d@github.com>
 <JD59yLTii_D36uysl98J-4DQyD82OZ4QHV8LMD2NHrE=.f79b5dc4-1c48-4251-bee2-8fce88c49857@github.com>
Message-ID: <pcbki2G1LSNTqirF7b-uBGGXcoeyQcxN3-7YuKM9OGI=.8238fede-b99b-4f6f-bbc4-216405c6f968@github.com>

On Tue, 3 Jan 2023 00:24:25 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> What would go wrong if they're not the same type?  `ListContentBinding` doesn't (and can't) enforce it and doesn't care either way.  The whole function fails silently if types don't match.  Also `ListContentBinding` is a private class and so I'd expect this code to be aware of how it works and what is/isn't safe to do. 
>> 
>> I personally think this entire class is unfinished.  It fails miserably in edge cases without so much as a warning to the user. Take this for example:
>> 
>>     public static void main(String[] args) {
>>         ObservableList<String> a = FXCollections.observableArrayList();
>>         ObservableList<String> b = FXCollections.observableArrayList();
>>         Bindings.bindContentBidirectional(a, b);
>>         Bindings.bindContentBidirectional(a, b);
>>         a.add("A");
>>         System.out.println(a + " : " + b);
>>     }
>> 
>> Prints:
>> 
>>     [A, A, A, A] : [A, A, A]
>> 
>> No mention about this in the API docs at all.  It breaks even worse when you make circular bindings `[a,b], [b,c], [c,a]` (stack traces get logged to the console complaining about `IndexOutOfBoundsException`).
>> 
>> I've created a solution that rejects double bindings and circular bindings, but it's a bit out of scope for this.  I think however that it is worth adding, and considering that the current behavior is broken when doing any of such things, not a big API break if instead we throw an exception.
>
> You are right, nothing would go wrong.
> 
> I agree that the behavior is undesired and should be fixed in another issue. I was thinking of adding more specific overloads that make sense to the public API and deprecating the method that takes everything, making it throw.

Adding more specific unbind functions may be a good idea, but I don't think we can change `unbind` to throw :)

I've added concept code here (https://github.com/openjdk/jfx/pull/988) that rejects situations that would lead to lists becoming unsynced or behave badly in other ways.

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

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

From kevin.rushforth at oracle.com  Tue Jan  3 15:17:03 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 3 Jan 2023 07:17:03 -0800
Subject: CFV: New OpenJFX Committer: John Hendrikx
Message-ID: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>

I hereby nominate John Hendrikx [1] to OpenJFX Committer.

John is an OpenJFX community member, who has contributed 16 commits [2] 
to OpenJFX.

Votes are due by January 17, 2023 at 16: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.java.net/census#jhendrikx

[2] 
https://github.com/openjdk/jfx/search?q=author-name%3A%22John+Hendrikx%22&s=author-date&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#lazy-consensus

[5] https://openjdk.java.net/projects#project-committer


From kevin.rushforth at oracle.com  Tue Jan  3 15:17:52 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 3 Jan 2023 07:17:52 -0800
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <282af96a-3ace-fe1e-d46e-9917f720608a@oracle.com>

Vote: YES

On 1/3/2023 7:17 AM, Kevin Rushforth wrote:
> I hereby nominate John Hendrikx [1] to OpenJFX Committer.


From nlisker at gmail.com  Tue Jan  3 15:21:59 2023
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 3 Jan 2023 17:21:59 +0200
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <282af96a-3ace-fe1e-d46e-9917f720608a@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
 <282af96a-3ace-fe1e-d46e-9917f720608a@oracle.com>
Message-ID: <CA+0ynh-E0+bYgssK-rW3n2q_PFzMoe1z96TvbQ-rdxXov7rhqA@mail.gmail.com>

Vote: YES

On Tue, Jan 3, 2023 at 5:18 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Vote: YES
>
> On 1/3/2023 7:17 AM, Kevin Rushforth wrote:
> > I hereby nominate John Hendrikx [1] to OpenJFX Committer.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230103/c64bd791/attachment.htm>

From john at status6.com  Tue Jan  3 16:09:06 2023
From: john at status6.com (John Neffenger)
Date: Tue, 3 Jan 2023 08:09:06 -0800
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <2c0c3483-6223-182b-65f4-08ba1c397172@status6.com>

Vote: YES

On 1/3/23 7:17 AM, Kevin Rushforth wrote:
> I hereby nominate John Hendrikx [1] to OpenJFX Committer.


From ajit.ghaisas at oracle.com  Tue Jan  3 16:14:57 2023
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Tue, 3 Jan 2023 16:14:57 +0000
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <FD8A1CF4-2552-4FAA-BDC0-02EA9EFCF52F@oracle.com>

Vote: Yes

Regards,
Ajit


> On 03-Jan-2023, at 8:47 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I hereby nominate John Hendrikx [1] to OpenJFX Committer.
> 
> John is an OpenJFX community member, who has contributed 16 commits [2] to OpenJFX.
> 
> Votes are due by January 17, 2023 at 16: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.java.net/census#jhendrikx
> 
> [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22John+Hendrikx%22&s=author-date&type=commits
> 
> [3] https://openjdk.java.net/census#openjfx
> 
> [4] https://openjdk.java.net/bylaws#lazy-consensus
> 
> [5] https://openjdk.java.net/projects#project-committer
> 


From andy.goryachev at oracle.com  Tue Jan  3 16:15:55 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 3 Jan 2023 16:15:55 +0000
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <DM5PR1001MB2172C1C8105B5BC34B036E29E5F49@DM5PR1001MB2172.namprd10.prod.outlook.com>

Vote: YES

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Tuesday, 2023/01/03 at 07:17
To: John Hendrikx <john.hendrikx at gmail.com>, openjfx-dev <openjfx-dev at openjdk.org>
Subject: CFV: New OpenJFX Committer: John Hendrikx
I hereby nominate John Hendrikx [1] to OpenJFX Committer.

John is an OpenJFX community member, who has contributed 16 commits [2]
to OpenJFX.

Votes are due by January 17, 2023 at 16: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.java.net/census#jhendrikx

[2]
https://github.com/openjdk/jfx/search?q=author-name%3A%22John+Hendrikx%22&s=author-date&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#lazy-consensus

[5] https://openjdk.java.net/projects#project-committer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230103/76439b69/attachment-0001.htm>

From michaelstrau2 at gmail.com  Tue Jan  3 16:59:50 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 3 Jan 2023 17:59:50 +0100
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <CAJEpuXQ=hrcKv0vjJKG5OfD8vp_3nYv4gWxPRYsFg_DYbnreXw@mail.gmail.com>

Vote: YES

On Tue, Jan 3, 2023 at 4:17 PM Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
>
> I hereby nominate John Hendrikx [1] to OpenJFX Committer.
>
> John is an OpenJFX community member, who has contributed 16 commits [2]
> to OpenJFX.
>
> Votes are due by January 17, 2023 at 16: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.java.net/census#jhendrikx
>
> [2]
> https://github.com/openjdk/jfx/search?q=author-name%3A%22John+Hendrikx%22&s=author-date&type=commits
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#lazy-consensus
>
> [5] https://openjdk.java.net/projects#project-committer
>

From angorya at openjdk.org  Tue Jan  3 17:49:22 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 17:49:22 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v28]
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <LV05nueEO4UHvIstkXgX43KraKdynZ--C1iRR1o9GGY=.ed51371f-65aa-45e4-b6ba-06a1a8266b9c@github.com>

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

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

  small delta

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/897/files
  - new: https://git.openjdk.org/jfx/pull/897/files/9b8fd1f0..645407ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=27
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=26-27

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

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

From thiago.sayao at gmail.com  Tue Jan  3 17:49:20 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 3 Jan 2023 14:49:20 -0300
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <CAAP_wunRx4dzcAdvUfx6csZF5F2mtF3ah7BrfTNT7EVRsNCU4A@mail.gmail.com>

Vote: YES

Em ter., 3 de jan. de 2023 ?s 12:17, Kevin Rushforth <
kevin.rushforth at oracle.com> escreveu:

> I hereby nominate John Hendrikx [1] to OpenJFX Committer.
>
> John is an OpenJFX community member, who has contributed 16 commits [2]
> to OpenJFX.
>
> Votes are due by January 17, 2023 at 16: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.java.net/census#jhendrikx
>
> [2]
>
> https://github.com/openjdk/jfx/search?q=author-name%3A%22John+Hendrikx%22&s=author-date&type=commits
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#lazy-consensus
>
> [5] https://openjdk.java.net/projects#project-committer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230103/7f1841cc/attachment.htm>

From angorya at openjdk.org  Tue Jan  3 19:02:20 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 19:02:20 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v29]
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - 2023
 - 2023

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/897/files
  - new: https://git.openjdk.org/jfx/pull/897/files/645407ef..d7741c46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=28
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=27-28

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

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

From angorya at openjdk.org  Tue Jan  3 20:18:40 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 20:18:40 GMT
Subject: RFR: 8296413: Tree/TableView with null focus model throws NPE in
 queryAccessibleAttribute() [v2]
In-Reply-To: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
References: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
Message-ID: <CR5ps8C-lSarhewI91QOBNO53cs0t_N9sFQx9f2Xv-w=.ac67a6b0-1645-4eb9-9201-61087876a61d@github.com>

> - added test to ensure no exception is thrown from Control.queryAccessibleAttribute() for all accessible attributes values
> - fixed null focus model case in Tree/TableView

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

 - 8296413: 2023
 - Merge remote-tracking branch 'origin/master' into 8296413.query.accessible
 - Merge remote-tracking branch 'origin/master' into
   8296413.query.accessible
 - Merge branch '8187145.null.selection.model' into 8296413.query.accessible
 - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
 - Merge branch '8187145.null.selection.model' into 8296413.query.accessible
 - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
 - 8296413: cleanup
 - Merge branch '8187145.null.selection.model' into 8296413.query.accessible
 - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
 - ... and 19 more: https://git.openjdk.org/jfx/compare/a35c3bf7...6111660b

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

Changes: https://git.openjdk.org/jfx/pull/938/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=938&range=01
  Stats: 235 lines in 8 files changed: 181 ins; 26 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/938.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/938/head:pull/938

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

From angorya at openjdk.org  Tue Jan  3 20:18:42 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 20:18:42 GMT
Subject: RFR: 8296413: Tree/TableView with null focus model throws NPE in
 queryAccessibleAttribute() [v2]
In-Reply-To: <DVE26FN-rVaQDligouJAILEhhzKyRAZlb1JLofHSqwo=.eb5769ec-6743-416b-935e-39a346b2d8b8@github.com>
References: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
 <DVE26FN-rVaQDligouJAILEhhzKyRAZlb1JLofHSqwo=.eb5769ec-6743-416b-935e-39a346b2d8b8@github.com>
Message-ID: <QXNEm_ry59s7OFYl-JIkYOX7YK3qicomOwza1tXb-Jw=.62a57608-3020-4c61-9f57-f9a77eb1ef55@github.com>

On Mon, 2 Jan 2023 11:42:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - 8296413: 2023
>>  - Merge remote-tracking branch 'origin/master' into 8296413.query.accessible
>>  - Merge remote-tracking branch 'origin/master' into
>>    8296413.query.accessible
>>  - Merge branch '8187145.null.selection.model' into 8296413.query.accessible
>>  - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
>>  - Merge branch '8187145.null.selection.model' into 8296413.query.accessible
>>  - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
>>  - 8296413: cleanup
>>  - Merge branch '8187145.null.selection.model' into 8296413.query.accessible
>>  - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
>>  - ... and 19 more: https://git.openjdk.org/jfx/compare/a35c3bf7...6111660b
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/QueryAccessibleAttributeTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Please change year to 2023

done

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

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

From johan at lodgon.com  Tue Jan  3 21:00:39 2023
From: johan at lodgon.com (Johan Vos)
Date: Tue, 3 Jan 2023 22:00:39 +0100
Subject: CFV: New OpenJFX Committer: John Hendrikx
In-Reply-To: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
References: <5c326e1f-4ff9-09c1-652c-9ec10184c616@oracle.com>
Message-ID: <CAK7C+XjWu73_F=RKoUOaLebRh3DCS8AS0KR=Yfnk8LTg-m9yqQ@mail.gmail.com>

Vote: YES

Op di 3 jan. 2023 om 16:17 schreef Kevin Rushforth <
kevin.rushforth at oracle.com>:

> I hereby nominate John Hendrikx [1] to OpenJFX Committer.
>
> John is an OpenJFX community member, who has contributed 16 commits [2]
> to OpenJFX.
>
> Votes are due by January 17, 2023 at 16: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.java.net/census#jhendrikx
>
> [2]
>
> https://github.com/openjdk/jfx/search?q=author-name%3A%22John+Hendrikx%22&s=author-date&type=commits
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#lazy-consensus
>
> [5] https://openjdk.java.net/projects#project-committer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230103/565a2634/attachment.htm>

From nlisker at openjdk.org  Tue Jan  3 22:54:54 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 22:54:54 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <skr_sD4OyTK1y3q8ef0zM4HSySme88km_BurIHr6juQ=.9c8055b3-fc3b-47ca-8b76-058faecfd3fb@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

@hjohn @kevinrushforth Can you review this in time for RDP1? It's a simple fix.

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

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

From kcr at openjdk.org  Tue Jan  3 22:58:56 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 3 Jan 2023 22:58:56 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v29]
In-Reply-To: <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
Message-ID: <Fl1Rm2StwHH4h2C9y0FIGmUIqH2egVBX9b2rU3YAPjg=.6f401e7d-81a4-4930-9767-e65d384c666c@github.com>

On Tue, 3 Jan 2023 19:02:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 2023
>  - 2023

The Windows HiDPI behavior (on my system with a screen scale of 1.25) is _much_ better with the latest version. With a policy of NEXT or LAST, the divider tracks the mouse cursor as I would expect. With a policy of FLEX_NEXT or FLEX_LAST, it tracks until the first (or last) column being resized hits its minimum and it switches to another column. Similarly, with a policy of SUBSEQUENT, it doesn't quite track as expected when one of the columns gets small (i.e., close to its minimum). This might just be error accumulation. It seems like a minor problem.

I am seeing a new behavior, unrelated to HiDPI, that I don't recall seeing before. The "flex" policies will start out correctly taking the extra space from the next (or last) column, then unexpectedly switch to a different column, then later switch back to the next (or last) column. As far as I can tell, it only happens when the window is resized from its initial size. The easiest way to see this is:

1. Resize the window such that the width is larger
2. Resize the FX split pane making the table wider
3. Select "Data" -> "pref only"
4. Select "Policy" -> "AUTO_RESIZE_FLEX_LAST_COLUMN"
5. Drag the divider between "C1" and "C2" to the right

It will start out taking the space needed to make C1 larger from C4 (as expected), then switch to one of C2 or C3 before C4 has resized to its minimum, then after a while, it will switch back to C4 until it has hit its minimum. 

This happens on both Mac and Windows.

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

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

From angorya at openjdk.org  Tue Jan  3 23:05:05 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 23:05:05 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v29]
In-Reply-To: <Fl1Rm2StwHH4h2C9y0FIGmUIqH2egVBX9b2rU3YAPjg=.6f401e7d-81a4-4930-9767-e65d384c666c@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
 <Fl1Rm2StwHH4h2C9y0FIGmUIqH2egVBX9b2rU3YAPjg=.6f401e7d-81a4-4930-9767-e65d384c666c@github.com>
Message-ID: <84ROu4UHOmkF2AiUIZ7kGQvVyH38NiMM8AgHEv49v_c=.14a697e5-9b7f-40b5-8ede-0749596b40c0@github.com>

On Tue, 3 Jan 2023 22:56:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I am seeing a new behavior,

could you check the latest version please?

I think the latest version works as expected, except for one scenario with fractional size, where both AUTO_RESIZE_FLEX_LAST_COLUMN and AUTO_RESIZE_FLEX_NEXT_COLUMN result in the adjustment of the columns to the left of the one being resized (data=many columns, same pref)

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

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

From angorya at openjdk.org  Tue Jan  3 23:10:03 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 23:10:03 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <FmQH-NYwE9pN0zbIcUZ8byxUwRsL-uSEnou0aNGLCe8=.d5ef612d-7df4-49c5-87b6-0ba8fdf21525@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

tests/performance/checkboxTreeView/.classpath line 1:

> 1: <?xml version="1.0" encoding="UTF-8"?>

minor: should this project be moved to manual tests hierarchy?

BTW, I am planning to create a monkey tester application which will include many tests, to simplify the testing/verification of fixes JDK-8299335
This code be added to the tester, either as a separate page, or as a data source option for one of the TreeTableView page.

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

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

From jhendrikx at openjdk.org  Tue Jan  3 23:13:53 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 23:13:53 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <hZLuqN2NubQB8GgfBNvfkdqbe73wHD8OTYo37lmOPv0=.51b8dde9-2588-42e8-bd6e-ebf5d9bc1e5c@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

Looks good to me, releasing the graphic for empty cells. I'm left wondering if it should also be releasing the bindings it makes in that case, although that's less likely to cause (visible) issues.

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

Marked as reviewed by jhendrikx (Author).

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

From nlisker at openjdk.org  Tue Jan  3 23:16:53 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 23:16:53 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <FmQH-NYwE9pN0zbIcUZ8byxUwRsL-uSEnou0aNGLCe8=.d5ef612d-7df4-49c5-87b6-0ba8fdf21525@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <FmQH-NYwE9pN0zbIcUZ8byxUwRsL-uSEnou0aNGLCe8=.d5ef612d-7df4-49c5-87b6-0ba8fdf21525@github.com>
Message-ID: <A8cowpVmowq6ybBAJa72gaOJo3HSjtmniC2tlHcvkW0=.0394cf9d-8bd9-45a5-bae6-bbb6d97fa2b7@github.com>

On Tue, 3 Jan 2023 23:07:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> tests/performance/checkboxTreeView/.classpath line 1:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
> 
> minor: should this project be moved to manual tests hierarchy?
> 
> BTW, I am planning to create a monkey tester application which will include many tests, to simplify the testing/verification of fixes JDK-8299335
> This code be added to the tester, either as a separate page, or as a data source option for one of the TreeTableView page.

I wasn't sure exactly where to put it, but it's going to be used in a fix for performance issue I found when a node has many children.

If it will fit into a grater app I don't mind.

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

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

From angorya at openjdk.org  Tue Jan  3 23:27:52 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 23:27:52 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <5DW_OOGQ9NkTbhVChvBe4WETvgOOzwnKwNokTi6UmpM=.eca059ad-7e9d-436a-9361-b1e80bdb61f0@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

Looks good.

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

Marked as reviewed by angorya (Committer).

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

From kcr at openjdk.org  Tue Jan  3 23:27:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 3 Jan 2023 23:27:54 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <f7dnbfGq40dzio84xieKvar0Z0q0Oeh1DycsKeRrzwk=.872abc55-a88d-45e6-b003-539b1f873a91@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

The fix looks correct to me. I left a couple comments on the test program.

tests/performance/checkboxTreeView/src/main/java/checkboxTreeView/CheckBoxTreeEditor.java line 1:

> 1: package checkboxTreeView;

This needs a copyright header. Also, the convention for package names is to use all lower case.

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

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

From nlisker at openjdk.org  Tue Jan  3 23:27:55 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 23:27:55 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <hZLuqN2NubQB8GgfBNvfkdqbe73wHD8OTYo37lmOPv0=.51b8dde9-2588-42e8-bd6e-ebf5d9bc1e5c@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <hZLuqN2NubQB8GgfBNvfkdqbe73wHD8OTYo37lmOPv0=.51b8dde9-2588-42e8-bd6e-ebf5d9bc1e5c@github.com>
Message-ID: <PinrRj5hj2H_A6D4cA8rHA8EKwPQzzKEFtBr3OgbwNE=.985f8d76-3819-486a-a68e-0d06fbf3eeff@github.com>

On Tue, 3 Jan 2023 23:11:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Looks good to me, releasing the graphic for empty cells. I'm left wondering if it should also be releasing the bindings it makes in that case, although that's less likely to cause (visible) issues.

I could make that change. I don't see any issues either way.

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

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

From angorya at openjdk.org  Tue Jan  3 23:27:58 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 23:27:58 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <A8cowpVmowq6ybBAJa72gaOJo3HSjtmniC2tlHcvkW0=.0394cf9d-8bd9-45a5-bae6-bbb6d97fa2b7@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <FmQH-NYwE9pN0zbIcUZ8byxUwRsL-uSEnou0aNGLCe8=.d5ef612d-7df4-49c5-87b6-0ba8fdf21525@github.com>
 <A8cowpVmowq6ybBAJa72gaOJo3HSjtmniC2tlHcvkW0=.0394cf9d-8bd9-45a5-bae6-bbb6d97fa2b7@github.com>
Message-ID: <DAGYj0hr62vdPDrsDD2WLnDPqwZJrEpWPeFv2CRILY8=.3e930437-549a-41b5-8e4c-c58f230f75aa@github.com>

On Tue, 3 Jan 2023 23:13:52 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> tests/performance/checkboxTreeView/.classpath line 1:
>> 
>>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 
>> minor: should this project be moved to manual tests hierarchy?
>> 
>> BTW, I am planning to create a monkey tester application which will include many tests, to simplify the testing/verification of fixes JDK-8299335
>> This code be added to the tester, either as a separate page, or as a data source option for one of the TreeTableView page.
>
> I wasn't sure exactly where to put it, but it's going to be used in a fix for a performance issue I found when a node has many children.
> 
> If it will fit into a larger app, I don't mind.

I'll move it there as a part of JDK-8299335

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

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

From kcr at openjdk.org  Tue Jan  3 23:27:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 3 Jan 2023 23:27:58 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <DAGYj0hr62vdPDrsDD2WLnDPqwZJrEpWPeFv2CRILY8=.3e930437-549a-41b5-8e4c-c58f230f75aa@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <FmQH-NYwE9pN0zbIcUZ8byxUwRsL-uSEnou0aNGLCe8=.d5ef612d-7df4-49c5-87b6-0ba8fdf21525@github.com>
 <A8cowpVmowq6ybBAJa72gaOJo3HSjtmniC2tlHcvkW0=.0394cf9d-8bd9-45a5-bae6-bbb6d97fa2b7@github.com>
 <DAGYj0hr62vdPDrsDD2WLnDPqwZJrEpWPeFv2CRILY8=.3e930437-549a-41b5-8e4c-c58f230f75aa@github.com>
Message-ID: <o4VxcxJGdvI0FXtAhMLqpW3VPy5h-TmuLqOo9I8cPgQ=.dd51456d-4112-472c-bb5d-f38780d14f1e@github.com>

On Tue, 3 Jan 2023 23:19:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I wasn't sure exactly where to put it, but it's going to be used in a fix for a performance issue I found when a node has many children.
>> 
>> If it will fit into a larger app, I don't mind.
>
> I'll move it there as a part of JDK-8299335

I think it's fine as a separate test program for now. Once we have a tester application, we can consider which existing tests should go there.

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

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

From tsayao at openjdk.org  Tue Jan  3 23:29:13 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 3 Jan 2023 23:29:13 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v9]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <alsegcO35d0SqfWp_VJG78e6iYiq4zXwVw0H1zYQt9o=.6dd24672-dc95-44ed-8fce-2a1e013c5f85@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Simplify DragView paint

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/5150b5ce..c827893a

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

  Stats: 33 lines in 1 file changed: 7 ins; 22 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From nlisker at openjdk.org  Tue Jan  3 23:38:10 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 23:38:10 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v2]
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

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

  Added copyright header and changed package name

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/970/files
  - new: https://git.openjdk.org/jfx/pull/970/files/b1808afe..4d89b0da

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

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

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

From jhendrikx at openjdk.org  Tue Jan  3 23:38:10 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 3 Jan 2023 23:38:10 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v2]
In-Reply-To: <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
Message-ID: <smHti8qn-EF5svS5A7tz6WEEueuvr5oez1154VCSgJM=.6db54045-f23d-4bce-a131-15a42259a614@github.com>

On Tue, 3 Jan 2023 23:34:06 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added copyright header and changed package name

Marked as reviewed by jhendrikx (Author).

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

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

From angorya at openjdk.org  Tue Jan  3 23:42:57 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 3 Jan 2023 23:42:57 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v2]
In-Reply-To: <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
Message-ID: <X973OctaW0FvxmIg17TUMEn2hXPJOAgb0JzChEQxEbQ=.b5033b91-dc72-48fa-a133-fecd0cbd66ef@github.com>

On Tue, 3 Jan 2023 23:38:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added copyright header and changed package name

lgtm

tests/performance/checkboxTreeView/src/main/java/main/CheckBoxTreeEditor.java line 26:

> 24:  */
> 25: 
> 26: package main;

I think the package name "main" is ok here, considering this code will be folded into the tester.

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

Marked as reviewed by angorya (Committer).

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

From kcr at openjdk.org  Tue Jan  3 23:50:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 3 Jan 2023 23:50:54 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v2]
In-Reply-To: <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
Message-ID: <Mj6X7YZir3gI3ehKm3SNGLJqQYbfNZ9HeLWPXABxJBE=.792e080d-e12b-4c25-8b8d-c5a81d2e9ece@github.com>

On Tue, 3 Jan 2023 23:38:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added copyright header and changed package name

I verified that the test shows the problem without the fix and it looks good with the fix.

I left one more minor comment on the test.

tests/performance/checkboxTreeView/src/main/java/main/CheckBoxTreeEditor.java line 49:

> 47: 
> 48:     @Override
> 49:     public void start(Stage stage) throws IOException {

Minor: nothing in this program can throw IOE, so this could be removed (along with the import).

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

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

From nlisker at openjdk.org  Tue Jan  3 23:50:55 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 23:50:55 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v2]
In-Reply-To: <X973OctaW0FvxmIg17TUMEn2hXPJOAgb0JzChEQxEbQ=.b5033b91-dc72-48fa-a133-fecd0cbd66ef@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <DnxCezlU9qpn9MroriJciiIQ-zPF0SQeO_eWLJmab0Y=.1576fb5b-9d39-49d6-9788-118103ed05d6@github.com>
 <X973OctaW0FvxmIg17TUMEn2hXPJOAgb0JzChEQxEbQ=.b5033b91-dc72-48fa-a133-fecd0cbd66ef@github.com>
Message-ID: <k1AaGyyprOM4zH5BFAqlkZHrU4iPWMqw3xbKwUdVTKk=.489a43e1-c027-4b5e-af3a-cd20af67936b@github.com>

On Tue, 3 Jan 2023 23:39:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added copyright header and changed package name
>
> tests/performance/checkboxTreeView/src/main/java/main/CheckBoxTreeEditor.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package main;
> 
> I think the package name "main" is ok here, considering this code will be folded into the tester.

There is only one package with 1 class. I didn't see any meaningful name for the package.

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

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

From nlisker at openjdk.org  Tue Jan  3 23:56:12 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 3 Jan 2023 23:56:12 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v3]
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

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

  Removed thrown exception

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/970/files
  - new: https://git.openjdk.org/jfx/pull/970/files/4d89b0da..abb71bd4

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

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

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

From angorya at openjdk.org  Wed Jan  4 00:03:53 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 4 Jan 2023 00:03:53 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v3]
In-Reply-To: <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
Message-ID: <EDDNYVOjCBgN_TKyHJJ_tBma2R1eoULpwg9pHDuvaFo=.733cb34a-30a2-4f50-a990-b2642c4bbd61@github.com>

On Tue, 3 Jan 2023 23:56:12 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed thrown exception

Marked as reviewed by angorya (Committer).

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

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

From jhendrikx at openjdk.org  Wed Jan  4 00:07:55 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 4 Jan 2023 00:07:55 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v3]
In-Reply-To: <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
Message-ID: <cM9KRhEeEaywOqAyOwpu6NXGQ9E_YxGBJXky6uKhVKg=.9fd13268-5691-4b85-9524-fb6f1a59fee2@github.com>

On Tue, 3 Jan 2023 23:56:12 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed thrown exception

Marked as reviewed by jhendrikx (Author).

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

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

From kcr at openjdk.org  Wed Jan  4 00:11:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jan 2023 00:11:55 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v2]
In-Reply-To: <TrrJ2Y0WX9cWUCRECjgh4FVMNsYoM3b3RgpW49vs3og=.0edf5f0f-fe7c-4c5f-a599-5a36dea73dee@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <TrrJ2Y0WX9cWUCRECjgh4FVMNsYoM3b3RgpW49vs3og=.0edf5f0f-fe7c-4c5f-a599-5a36dea73dee@github.com>
Message-ID: <nE-k1FPcK0nEhWZZ6sEgXjx_dpbhHJsaBw39M5uR-cw=.b97a8258-a2eb-4d44-90da-60cfa9fdf66a@github.com>

On Mon, 2 Jan 2023 09:26:14 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR fixes the leak in the mac system menu bar.
>> 
>> Inside the native code, NewGlobalRef is called for the callable.
>> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
>> 
>> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
>> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
>> 
>> The unit test verifies, that this bug happened without this change, but no longer happens with this change.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8299423
>   Simplified the fix for the mac-menu-bar based on code review

> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling _setCallback with the callable "null".

That would be one approach, but it's not what this PR currently does. Instead, I see that you changed the JNI code to use weak global references. Unless there is code on the Java side that holds a strong reference, using a weak reference for the callback can cause the opposite problem of premature GC, such that the callback stops working in some cases. How certain are you that this can't happen here?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacMenuDelegate.java line 66:

> 64:                                             boolean enabled, boolean checked) {
> 65:         ptr = _createMenuItem(title, (char)shortcutKey, shortcutModifiers,
> 66:                 pixels, enabled, checked, callback);

This file now has only white-space changes, which should be reverted.

tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 1:

> 1: package test.javafx.scene.control;

This file needs a copyright header.

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

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

From kcr at openjdk.org  Wed Jan  4 00:19:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jan 2023 00:19:55 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v9]
In-Reply-To: <alsegcO35d0SqfWp_VJG78e6iYiq4zXwVw0H1zYQt9o=.6dd24672-dc95-44ed-8fce-2a1e013c5f85@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
 <alsegcO35d0SqfWp_VJG78e6iYiq4zXwVw0H1zYQt9o=.6dd24672-dc95-44ed-8fce-2a1e013c5f85@github.com>
Message-ID: <1-U35U04hcUnMKUQrCS5zIdK2JzoGn_npfza-8YTV4Q=.e76b35ab-2deb-4706-b539-c2ca69e7df52@github.com>

On Tue, 3 Jan 2023 23:29:13 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
>> 
>> To do general testing:
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify DragView paint

This will need a lot of careful testing.

Can  you provide more information about why undoing the changes from [JDK-8225571](https://bugs.openjdk.org/browse/JDK-8225571) is the best approach? Also, have you tested that the various issues that were fixed by JDK-8225571 won't regress as a result?

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

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

From tsayao at openjdk.org  Wed Jan  4 00:44:10 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 4 Jan 2023 00:44:10 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v10]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <Ta27g7vo3WnNdmcJ1Ky2PXs7SbRxDFs8mGAmNMiA_CE=.957c66bb-1520-4a51-b8a0-13e7e0abc08d@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Gtk2 fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/c827893a..665656a4

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

  Stats: 26 lines in 1 file changed: 14 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From mstrauss at openjdk.org  Wed Jan  4 01:36:52 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 01:36:52 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v2]
In-Reply-To: <TrrJ2Y0WX9cWUCRECjgh4FVMNsYoM3b3RgpW49vs3og=.0edf5f0f-fe7c-4c5f-a599-5a36dea73dee@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <TrrJ2Y0WX9cWUCRECjgh4FVMNsYoM3b3RgpW49vs3og=.0edf5f0f-fe7c-4c5f-a599-5a36dea73dee@github.com>
Message-ID: <Jb-EgLDOuCUc8Tj0ChSyXPyp-_JrmAv0gcMn-15vtK0=.fe75d0b5-ac7b-4c87-b50a-4b7f4ac25648@github.com>

On Mon, 2 Jan 2023 09:26:14 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR fixes the leak in the mac system menu bar.
>> 
>> Inside the native code, NewGlobalRef is called for the callable.
>> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
>> 
>> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
>> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
>> 
>> The unit test verifies, that this bug happened without this change, but no longer happens with this change.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8299423
>   Simplified the fix for the mac-menu-bar based on code review

If you're going forward with weak global references, you need to be aware that objects only referred to by weak references can be collected at any time. In order to do anything meaningful with a weak global reference, you need to create a new local reference to it and check whether the local reference is null (and don't forget to delete the local reference after using it).

Note that a local reference is automatically created for any object passed to a JNI method, so you only need to do that manually when the callback is used in other places.

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

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

From mstrauss at openjdk.org  Wed Jan  4 02:30:09 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 02:30:09 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v16]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <8f1oKjyEntVRCQ1Fv3EAvtBEbOHTCnXrSIE2rQeIvLg=.8f4c577b-1526-4337-86a9-7c9d7007c27f@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the user-agent stylesheet of the application.
>      * <p>
>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>      * It can be used to provide default styling for UI controls and other nodes.
>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>      * <p>
>      * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>      * scene graph.
>      * <p>
>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. PlatformPreferences
> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface PlatformPreferences extends Map<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> 
>     void addListener(PlatformPreferencesListener listener);
>     void removeListener(PlatformPreferencesListener listener);
> }
> 
> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright headers

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/84598dc1..b390f46e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=14-15

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

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

From mstrauss at openjdk.org  Wed Jan  4 02:43:16 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 02:43:16 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v17]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <BopqhVYCtkBWdJ6fg1BIh82lDvWTWeXJ1BY1VSxbkJQ=.34459102-59e1-4ac9-9dc6-56b68e0ac5f4@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the user-agent stylesheet of the application.
>      * <p>
>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>      * It can be used to provide default styling for UI controls and other nodes.
>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>      * <p>
>      * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>      * scene graph.
>      * <p>
>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. PlatformPreferences
> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface PlatformPreferences extends Map<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> 
>     void addListener(PlatformPreferencesListener listener);
>     void removeListener(PlatformPreferencesListener listener);
> }
> 
> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  Added missing newline at end of file

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/b390f46e..1304d252

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=15-16

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

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

From mstrauss at openjdk.org  Wed Jan  4 03:52:39 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 03:52:39 GMT
Subject: RFR: 8268642: Improve property system to facilitate correct usage
 [v2]
In-Reply-To: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com>
References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com>
Message-ID: <xAsOohxQpINR6GnKg6pIPZoPqq5VbFnJ-Sq8dhb6SrU=.117a8b97-f44c-48a2-8ad3-6c4c2cb97c05@github.com>

> Based on previous discussions, this PR attempts to improve the JavaFX property system by enforcing correct API usage in several cases that are outlined below. It also streamlines the API by deprecating untyped APIs in favor of typed APIs that better express intent.
> 
> ### 1. Behavioral changes for regular bindings
> 
> var target = new SimpleObjectProperty(bean, "target");
> var source = new SimpleObjectProperty(bean, "source");
> target.bind(source);
> target.bindBidirectional(source);
> 
> _Before:_ `RuntimeException` --> "bean.target: A bound value cannot be set."
> _After:_ `IllegalStateException` --> "bean.target: Bidirectional binding cannot target a bound property."
> 
> 
> var target = new SimpleObjectProperty(bean, "target");
> var source = new SimpleObjectProperty(bean, "source");
> var other = new SimpleObjectProperty(bean, "other");
> source.bind(other);
> target.bindBidirectional(source);
> 
> _Before:_ no error
> _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional binding cannot target a bound property."
> 
> 
> var target = new SimpleObjectProperty(bean, "target");
> var source = new SimpleObjectProperty(bean, "source");
> target.bindBidirectional(source);
> target.bind(source);
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Cannot bind a property that is targeted by a bidirectional binding."
> 
> 
> ### 2. Behavioral changes for content bindings
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContent(source);
> target.bindContentBidirectional(source);
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Bidirectional content binding cannot target a bound collection."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> var other = new SimpleListProperty();
> source.bindContent(other);
> target.bindContentBidirectional(source);
> 
> _Before:_ no error
> _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional content binding cannot target a bound collection."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContentBidirectional(source);
> target.bindContent(source);
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Cannot bind a collection that is targeted by a bidirectional content binding."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContent(source);
> target.set(FXCollections.observableArrayList());
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Cannot set the value of a content-bound property."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContent(source);
> target.add("foo");
> 
> _Before_: no error, but binding is broken because the lists are in an inconsistent state
> _After:_ `RuntimeExeption` via `Thread.UncaughtExceptionHandler` --> "Illegal list modification: Content binding was removed because the lists are out-of-sync."
> 
> 
> ### 3. Align un-binding of unidirectional content bindings with regular unidirectional bindings
> The API of unidirectional content bindings is aligned with regular unidirectional bindings because the semantics are similar. Like `unbind()`, `unbindContent(Object)` should not need an argument because there can only be a single content binding. For this reason, `unbindContent(Object)` will be deprecated in favor of `unbindContent()`:
> 
>   void bindContent(ObservableList<E> source);
> + void unbindContent();
> + boolean isContentBound();
> 
> + @Deprecated(since = "18", forRemoval = true)
>   void unbindContent(Object object);
> 
> 
> ### 4. Replace untyped binding APIs with typed APIs
> The following untyped APIs will be marked for removal in favor of typed replacements:
> In `javafx.beans.binding.Bindings`:
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindBidirectional(Object property1, Object property2)
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindContentBidirectional(Object obj1, Object obj2)
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindContent(Object obj1, Object obj2)
> 
> 
> In `ReadOnlyListProperty`, `ReadOnlySetProperty`, `ReadOnlyMapProperty`:
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindContentBidirectional(Object object)
> 
> 
> ~~5. Support un-binding bidirectional conversion bindings with typed API
> At this moment, `StringProperty` is the only property implementation that offers bidirectional conversion bindings, where the `StringProperty` is bound to a property of another type:~~
> 
> <U> void bindBidirectional(Property<U> other, StringConverter<U> converter)
> 
> ~~The inherited `Property.unbindBidirectional(Property<String>)` API cannot be used to unbind a conversion binding, because it only accepts arguments of type `Property<String>`.
> `StringProperty` solves this issue by adding an untyped overload: `unbindBidirectional(Object)`.~~
> 
> ~~I propose to relax the definition of `Property.unbindBidirectional`:~~
> 
> - void unbindBidirectional(Property<T> other);
> + void unbindBidirectional(Property<?> other);
> 
> ~~This allows property implementations to use the same API to un-bind regular bidirectional bindings, as well as converting bidirectional bindings. The `Property` typing is retained with a minimal impact on existing code (most _usages_ of this API will continue to compile, while classes that override `unbindBidirectional` will need to be changed to match the new API).~~
> 
> ~~As a side-effect, this allows the option of easily adding conversion bindings for other property implementations as well.~~

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - use pattern variable
 - removed unused return value
 - update copyright headers
 - Merge branch 'master' into feature/property-enhancements
 - centralized Property.toString
 - test error message in content binding tests
 - fix whitespace issues
 - fix things that broke
 - Clean up content binding API
 - Rework exception messages
 - ... and 19 more: https://git.openjdk.org/jfx/compare/a35c3bf7...86280bea

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

Changes: https://git.openjdk.org/jfx/pull/590/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=590&range=01
  Stats: 4740 lines in 94 files changed: 3084 ins; 879 del; 777 mod
  Patch: https://git.openjdk.org/jfx/pull/590.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/590/head:pull/590

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

From nlisker at openjdk.org  Wed Jan  4 05:30:54 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 4 Jan 2023 05:30:54 GMT
Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings
 and collections packages [v2]
In-Reply-To: <fwBTsRBUBl5t-ZLRiy-iMNV6zMNlJSezF-XZgXglEv0=.2637c745-51fa-4b09-9d06-159b8c96ccb6@github.com>
References: <PCSbVTB3bc5UzS1VgD4xd1ggZ_3dQlyu2GZb_xDnauo=.856f921d-eb77-4a63-bbfe-a13c4daf83b9@github.com>
 <fwBTsRBUBl5t-ZLRiy-iMNV6zMNlJSezF-XZgXglEv0=.2637c745-51fa-4b09-9d06-159b8c96ccb6@github.com>
Message-ID: <-XmEj7zD3hwuL_pmYIZ91htRrzL2FRKYgrKc5hGP7N0=.09deb870-ebd1-44dd-9cb9-f2c1d922e419@github.com>

On Sun, 1 Jan 2023 16:08:15 GMT, John Hendrikx <jhendrikx at openjdk.org> 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 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 <T extends Comparable<? super T>> void sort(ObservableList<T> list) {
        sort(list, null); // or Comparator.naturalOrder() instead of null
    }

    public static <T> void sort(ObservableList<T> list, Comparator<? super T> c) {
        if (list instanceof SortableList) {
            list.sort(c);
        } else {
            List<T> 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<T> 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<E> extends List<E>, Observable {

    @Override
    default void sort(Comparator<? super E> 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.

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

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

From mstrauss at openjdk.org  Wed Jan  4 05:36:21 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 05:36:21 GMT
Subject: RFR: 8268642: Improve property system to facilitate correct usage
 [v3]
In-Reply-To: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com>
References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com>
Message-ID: <FLBS8m8LXXSueqDfp5fY1b-aL1Io4Rhx1ADwHi0HgkQ=.af8365f3-7f13-4ab4-8b8f-9827f2096a9b@github.com>

> Based on previous discussions, this PR attempts to improve the JavaFX property system by enforcing correct API usage in several cases that are outlined below. It also streamlines the API by deprecating untyped APIs in favor of typed APIs that better express intent.
> 
> ### 1. Behavioral changes for regular bindings
> 
> var target = new SimpleObjectProperty(bean, "target");
> var source = new SimpleObjectProperty(bean, "source");
> target.bind(source);
> target.bindBidirectional(source);
> 
> _Before:_ `RuntimeException` --> "bean.target: A bound value cannot be set."
> _After:_ `IllegalStateException` --> "bean.target: Bidirectional binding cannot target a bound property."
> 
> 
> var target = new SimpleObjectProperty(bean, "target");
> var source = new SimpleObjectProperty(bean, "source");
> var other = new SimpleObjectProperty(bean, "other");
> source.bind(other);
> target.bindBidirectional(source);
> 
> _Before:_ no error
> _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional binding cannot target a bound property."
> 
> 
> var target = new SimpleObjectProperty(bean, "target");
> var source = new SimpleObjectProperty(bean, "source");
> target.bindBidirectional(source);
> target.bind(source);
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Cannot bind a property that is targeted by a bidirectional binding."
> 
> 
> ### 2. Behavioral changes for content bindings
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContent(source);
> target.bindContentBidirectional(source);
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Bidirectional content binding cannot target a bound collection."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> var other = new SimpleListProperty();
> source.bindContent(other);
> target.bindContentBidirectional(source);
> 
> _Before:_ no error
> _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional content binding cannot target a bound collection."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContentBidirectional(source);
> target.bindContent(source);
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Cannot bind a collection that is targeted by a bidirectional content binding."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContent(source);
> target.set(FXCollections.observableArrayList());
> 
> _Before:_ no error
> _After:_ `IllegalStateException` --> "bean.target: Cannot set the value of a content-bound property."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContent(source);
> target.add("foo");
> 
> _Before_: no error, but binding is broken because the lists are in an inconsistent state
> _After:_ `RuntimeExeption` via `Thread.UncaughtExceptionHandler` --> "Illegal list modification: Content binding was removed because the lists are out-of-sync."
> 
> 
> var target = new SimpleListProperty(bean, "target");
> var source = new SimpleListProperty(bean, "source");
> target.bindContentBidirectional(source);
> target.bindContentBidirectional(source);
> target.add("foo");
> 
> _Before_: no error, but `target` contains `[foo, foo, foo, foo]`, while `source` contains `[foo, foo, foo]`
> _After:_ no error, both lists contain `[foo]` (the second binding replaces the first)
> 
> 
> ### 3. Align un-binding of unidirectional content bindings with regular unidirectional bindings
> The API of unidirectional content bindings is aligned with regular unidirectional bindings because the semantics are similar. Like `unbind()`, `unbindContent(Object)` should not need an argument because there can only be a single content binding. For this reason, `unbindContent(Object)` will be deprecated in favor of `unbindContent()`:
> 
>   void bindContent(ObservableList<E> source);
> + void unbindContent();
> + boolean isContentBound();
> 
> + @Deprecated(since = "18", forRemoval = true)
>   void unbindContent(Object object);
> 
> 
> ### 4. Replace untyped binding APIs with typed APIs
> The following untyped APIs will be marked for removal in favor of typed replacements:
> In `javafx.beans.binding.Bindings`:
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindBidirectional(Object property1, Object property2)
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindContentBidirectional(Object obj1, Object obj2)
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindContent(Object obj1, Object obj2)
> 
> 
> In `ReadOnlyListProperty`, `ReadOnlySetProperty`, `ReadOnlyMapProperty`:
> 
> @Deprecated(since = "18", forRemoval = true)
> void unbindContentBidirectional(Object object)
> 
> 
> ~~5. Support un-binding bidirectional conversion bindings with typed API
> At this moment, `StringProperty` is the only property implementation that offers bidirectional conversion bindings, where the `StringProperty` is bound to a property of another type:~~
> 
> <U> void bindBidirectional(Property<U> other, StringConverter<U> converter)
> 
> ~~The inherited `Property.unbindBidirectional(Property<String>)` API cannot be used to unbind a conversion binding, because it only accepts arguments of type `Property<String>`.
> `StringProperty` solves this issue by adding an untyped overload: `unbindBidirectional(Object)`.~~
> 
> ~~I propose to relax the definition of `Property.unbindBidirectional`:~~
> 
> - void unbindBidirectional(Property<T> other);
> + void unbindBidirectional(Property<?> other);
> 
> ~~This allows property implementations to use the same API to un-bind regular bidirectional bindings, as well as converting bidirectional bindings. The `Property` typing is retained with a minimal impact on existing code (most _usages_ of this API will continue to compile, while classes that override `unbindBidirectional` will need to be changed to match the new API).~~
> 
> ~~As a side-effect, this allows the option of easily adding conversion bindings for other property implementations as well.~~

Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:

 - check for null
 - javadoc changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/590/files
  - new: https://git.openjdk.org/jfx/pull/590/files/86280bea..2aa560b8

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

  Stats: 69 lines in 8 files changed: 23 ins; 1 del; 45 mod
  Patch: https://git.openjdk.org/jfx/pull/590.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/590/head:pull/590

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

From jhendrikx at openjdk.org  Wed Jan  4 10:45:57 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 4 Jan 2023 10:45:57 GMT
Subject: RFR: 8268642: Improve property system to facilitate correct usage
 [v3]
In-Reply-To: <FLBS8m8LXXSueqDfp5fY1b-aL1Io4Rhx1ADwHi0HgkQ=.af8365f3-7f13-4ab4-8b8f-9827f2096a9b@github.com>
References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com>
 <FLBS8m8LXXSueqDfp5fY1b-aL1Io4Rhx1ADwHi0HgkQ=.af8365f3-7f13-4ab4-8b8f-9827f2096a9b@github.com>
Message-ID: <lUfmLQxCrBOX5GoR5ybJL9M_ru7pNrB8FBdBMFMWdcc=.e685c850-d5c1-46a8-a431-9ce2a00990cd@github.com>

On Wed, 4 Jan 2023 05:36:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Based on previous discussions, this PR attempts to improve the JavaFX property system by enforcing correct API usage in several cases that are outlined below. It also streamlines the API by deprecating untyped APIs in favor of typed APIs that better express intent.
>> 
>> ### 1. Behavioral changes for regular bindings
>> 
>> var target = new SimpleObjectProperty(bean, "target");
>> var source = new SimpleObjectProperty(bean, "source");
>> target.bind(source);
>> target.bindBidirectional(source);
>> 
>> _Before:_ `RuntimeException` --> "bean.target: A bound value cannot be set."
>> _After:_ `IllegalStateException` --> "bean.target: Bidirectional binding cannot target a bound property."
>> 
>> 
>> var target = new SimpleObjectProperty(bean, "target");
>> var source = new SimpleObjectProperty(bean, "source");
>> var other = new SimpleObjectProperty(bean, "other");
>> source.bind(other);
>> target.bindBidirectional(source);
>> 
>> _Before:_ no error
>> _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional binding cannot target a bound property."
>> 
>> 
>> var target = new SimpleObjectProperty(bean, "target");
>> var source = new SimpleObjectProperty(bean, "source");
>> target.bindBidirectional(source);
>> target.bind(source);
>> 
>> _Before:_ no error
>> _After:_ `IllegalStateException` --> "bean.target: Cannot bind a property that is targeted by a bidirectional binding."
>> 
>> 
>> ### 2. Behavioral changes for content bindings
>> 
>> var target = new SimpleListProperty(bean, "target");
>> var source = new SimpleListProperty(bean, "source");
>> target.bindContent(source);
>> target.bindContentBidirectional(source);
>> 
>> _Before:_ no error
>> _After:_ `IllegalStateException` --> "bean.target: Bidirectional content binding cannot target a bound collection."
>> 
>> 
>> var target = new SimpleListProperty(bean, "target");
>> var source = new SimpleListProperty(bean, "source");
>> var other = new SimpleListProperty();
>> source.bindContent(other);
>> target.bindContentBidirectional(source);
>> 
>> _Before:_ no error
>> _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional content binding cannot target a bound collection."
>> 
>> 
>> var target = new SimpleListProperty(bean, "target");
>> var source = new SimpleListProperty(bean, "source");
>> target.bindContentBidirectional(source);
>> target.bindContent(source);
>> 
>> _Before:_ no error
>> _After:_ `IllegalStateException` --> "bean.target: Cannot bind a collection that is targeted by a bidirectional content binding."
>> 
>> 
>> var target = new SimpleListProperty(bean, "target");
>> var source = new SimpleListProperty(bean, "source");
>> target.bindContent(source);
>> target.set(FXCollections.observableArrayList());
>> 
>> _Before:_ no error
>> _After:_ `IllegalStateException` --> "bean.target: Cannot set the value of a content-bound property."
>> 
>> 
>> var target = new SimpleListProperty(bean, "target");
>> var source = new SimpleListProperty(bean, "source");
>> target.bindContent(source);
>> target.add("foo");
>> 
>> _Before_: no error, but binding is broken because the lists are in an inconsistent state
>> _After:_ `RuntimeExeption` via `Thread.UncaughtExceptionHandler` --> "Illegal list modification: Content binding was removed because the lists are out of sync."
>> 
>> 
>> var target = new SimpleListProperty(bean, "target");
>> var source = new SimpleListProperty(bean, "source");
>> target.bindContentBidirectional(source);
>> target.bindContentBidirectional(source);
>> target.add("foo");
>> 
>> _Before_: no error, but `target` contains `[foo, foo, foo, foo]`, while `source` contains `[foo, foo, foo]`
>> _After:_ no error, both lists contain `[foo]` (the second binding replaces the first)
>> 
>> 
>> ### 3. Align un-binding of unidirectional content bindings with regular unidirectional bindings
>> The API of unidirectional content bindings is aligned with regular unidirectional bindings because the semantics are similar. Like `unbind()`, `unbindContent(Object)` should not need an argument because there can only be a single content binding. For this reason, `unbindContent(Object)` will be deprecated in favor of `unbindContent()`:
>> 
>>   void bindContent(ObservableList<E> source);
>> + void unbindContent();
>> + boolean isContentBound();
>> 
>> + @Deprecated(since = "21")
>>   void unbindContent(Object object);
>> 
>> 
>> ### 4. Replace untyped binding APIs with typed APIs
>> The following untyped APIs will be deprecated in favor of typed replacements:
>> In `javafx.beans.binding.Bindings`:
>> 
>> @Deprecated(since = "21")
>> void unbindBidirectional(Object property1, Object property2)
>> 
>> @Deprecated(since = "21")
>> void unbindContentBidirectional(Object obj1, Object obj2)
>> 
>> @Deprecated(since = "21")
>> void unbindContent(Object obj1, Object obj2)
>> 
>> 
>> In `ReadOnlyListProperty`, `ReadOnlySetProperty`, `ReadOnlyMapProperty`:
>> 
>> @Deprecated(since = "21")
>> void unbindContentBidirectional(Object object)
>> 
>> 
>> ~~5. Support un-binding bidirectional conversion bindings with typed API
>> At this moment, `StringProperty` is the only property implementation that offers bidirectional conversion bindings, where the `StringProperty` is bound to a property of another type:~~
>> 
>> <U> void bindBidirectional(Property<U> other, StringConverter<U> converter)
>> 
>> ~~The inherited `Property.unbindBidirectional(Property<String>)` API cannot be used to unbind a conversion binding, because it only accepts arguments of type `Property<String>`.
>> `StringProperty` solves this issue by adding an untyped overload: `unbindBidirectional(Object)`.~~
>> 
>> ~~I propose to relax the definition of `Property.unbindBidirectional`:~~
>> 
>> - void unbindBidirectional(Property<T> other);
>> + void unbindBidirectional(Property<?> other);
>> 
>> ~~This allows property implementations to use the same API to un-bind regular bidirectional bindings, as well as converting bidirectional bindings. The `Property` typing is retained with a minimal impact on existing code (most _usages_ of this API will continue to compile, while classes that override `unbindBidirectional` will need to be changed to match the new API).~~
>> 
>> ~~As a side-effect, this allows the option of easily adding conversion bindings for other property implementations as well.~~
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - check for null
>  - javadoc changes

@mstr2 would this PR make it impossible to keep more than 2 properties in sync with each other? Bidirectional bindings previously allowed for this, and I can imagine some use as well when there are a few layers involved. 

I may for example be exposing a model for users to use, which I've bidirectionally bound to internal properties (a Skin might do the same).  The user of that model may then want to do their own bindings to wherever they see fit, which may involve another bidirectional binding.  If adding one would silently replace the one between the exposed model and internal properties, then things break.  I'm pretty sure this would break code I've written in the past (I tend to bidirectionally bind things in custom skins to a control, which in turn may be bound by the user to something)

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

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

From johan.vos at gluonhq.com  Wed Jan  4 11:00:50 2023
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 4 Jan 2023 12:00:50 +0100
Subject: libav.org is not resolving
In-Reply-To: <28314e5b-688a-31d9-afbd-351514339f99@status6.com>
References: <28314e5b-688a-31d9-afbd-351514339f99@status6.com>
Message-ID: <CABxFH2FfHiDOZrJd9uvye8S=NAb-Q_Y=eaOCwb8b0o7EbDNrqw@mail.gmail.com>

Hi John,

Thanks for pointing this out. Our automated builds are failing for the same
reason. It's not the first time that this dependency on the libav website
hits us, and I agree it's better indeed to depend on the github
repositories (which are also not guaranteed to be available though).

- Johan

On Sun, Jan 1, 2023 at 7:42 PM John Neffenger <john at status6.com> wrote:

> The domain 'libav.org' is not resolving for at least a week now, causing
> the build to fail when '-PBUILD_LIBAV_STUBS=true' (see below). The
> domain itself is good until 2024:
>
>    Creation Date: 2011-01-19T23:35:14Z
>    Registry Expiry Date: 2024-01-19T23:35:14Z
>
> If the problem persists, we could use GitHub as an alternative (assuming
> those are source archives):
>
> https://github.com/libav/libav/archive/v9.14.tar.gz
> ==> content-disposition: attachment; filename=libav-9.14.tar.gz
>
> https://github.com/libav/libav/archive/v11.4.tar.gz
> ==> content-disposition: attachment; filename=libav-11.4.tar.gz
>
> https://github.com/libav/libav/archive/v12.1.tar.gz
> ==> content-disposition: attachment; filename=libav-12.1.tar.gz
>
> I'll keep trying, and I'll test whether the GitHub alternative works.
>
> John
>
> =====================================
>  > Task :media:buildFFmpegStubs FAILED
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file '/home/ubuntu/src/jfx/build.gradle' line: 3264
>
> * What went wrong:
> Execution failed for task ':media:buildFFmpegStubs'.
>  > Could not resolve all files for configuration ':media:media'.
>
>  > Could not resolve :libav-9.14.
> Required by:
> project :media
>  > Could not resolve :libav-9.14.
>  > Could not get resource 'https://libav.org/releases/libav-9.14.tar.gz'.
>  > Could not HEAD 'https://libav.org/releases/libav-9.14.tar.gz'.
>  > libav.org
>
>  > Could not resolve :libav-11.4.
> Required by:
> project :media
>  > Could not resolve :libav-11.4.
>  > Could not get resource 'https://libav.org/releases/libav-11.4.tar.gz'.
>  > Could not HEAD 'https://libav.org/releases/libav-11.4.tar.gz'.
>  > libav.org
>
>  > Could not resolve :libav-12.1.
> Required by:
> project :media
>  > Could not resolve :libav-12.1.
>  > Could not get resource 'https://libav.org/releases/libav-12.1.tar.gz'.
>  > Could not HEAD 'https://libav.org/releases/libav-12.1.tar.gz'.
>  > libav.org
>
> ...
>
> BUILD FAILED in 1m 15s
> 43 actionable tasks: 43 executed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230104/c3571f3d/attachment-0001.htm>

From tsayao at openjdk.org  Wed Jan  4 11:15:55 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 4 Jan 2023 11:15:55 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v10]
In-Reply-To: <Ta27g7vo3WnNdmcJ1Ky2PXs7SbRxDFs8mGAmNMiA_CE=.957c66bb-1520-4a51-b8a0-13e7e0abc08d@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
 <Ta27g7vo3WnNdmcJ1Ky2PXs7SbRxDFs8mGAmNMiA_CE=.957c66bb-1520-4a51-b8a0-13e7e0abc08d@github.com>
Message-ID: <WFPZTOQfQpYwLKJWJmfXLN3nE3XmAU-XpiuxLp16Cfw=.790f15a8-8c21-47b0-82b3-ce65a7835fdc@github.com>

On Wed, 4 Jan 2023 00:44:10 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
>> 
>> To do general testing:
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Gtk2 fixes

> This will need a lot of careful testing.
> 
> Can you provide more information about why undoing the changes from [JDK-8225571](https://bugs.openjdk.org/browse/JDK-8225571) is the best approach? Also, have you tested that the various issues that were fixed by JDK-8225571 won't regress as a result?
> 
> /reviewers 2

It's the way I have found to work with key events to fix the bug. The first approach was to use the existing code, but I could'n make it work. I've done a fair bit of testing on Ubuntu 16.04, 22.04 ( the last with wayland and Xorg). 

This patch also introduces mouse grab break handling and interrupts the DND if it occurs. I will attach a test case for this.

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

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

From thiago.sayao at gmail.com  Wed Jan  4 11:17:48 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 4 Jan 2023 08:17:48 -0300
Subject: Removing gtk2 support
Message-ID: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>

Would a merge request to remove gtk2 support on the JavaFX 21 release be
welcome?

--Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230104/2b03df7b/attachment.htm>

From johan.vos at gluonhq.com  Wed Jan  4 12:20:02 2023
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 4 Jan 2023 13:20:02 +0100
Subject: Removing gtk2 support
In-Reply-To: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
References: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
Message-ID: <CABxFH2FyMwGMZQsEaB7s6KHrwB0jLAHxYvBB+=F9bDPpO2dzWA@mail.gmail.com>

I think it is absolutely worth considering that.
I actually thought we already had an issue for discussing this, but I seem
to be unable to do search queries on JBS atm.

I can't think about configurations that are stuck on GTK2 and that are
still relevant today, but it would be good to get input from others in case
such configurations are still in use.

- Johan

On Wed, Jan 4, 2023 at 12:30 PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

>
> Would a merge request to remove gtk2 support on the JavaFX 21 release be
> welcome?
>
> --Thiago.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230104/1a5044ce/attachment.htm>

From aghaisas at openjdk.org  Wed Jan  4 12:41:58 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 4 Jan 2023 12:41:58 GMT
Subject: RFR: 8216507: StyleablePropertyFactory: example in class javadoc
 does not compile [v3]
In-Reply-To: <n_moELMjienZItb4eDROuJg-oVR1Gs3u60wlUVfwCkE=.11bb4647-3212-4797-a30f-bb11a95c6d27@github.com>
References: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
 <n_moELMjienZItb4eDROuJg-oVR1Gs3u60wlUVfwCkE=.11bb4647-3212-4797-a30f-bb11a95c6d27@github.com>
Message-ID: <691ppDrmyTITWIG-2dkR9O4p7x4MjkpemVJIaQ6qBeA=.aa9cfa43-8342-4313-85fb-8a1791dba09e@github.com>

On Mon, 2 Jan 2023 11:39:19 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> In the javadoc example of `StyleablePropertyFactory` class, wrong parameter was used while initializing `StyleableProperty`. 
>> 
>> Assigned the `CssMetadData` object to `SELECTED` variable returned by `createBooleanCssMetaData` method called in anonymous inner-class class, which is then used while initializing `StyleableProperty`.
>> 
>> Added missing semicolon in the same example.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unit test for javadoc example of StyleablePropertyFactory

Looks good to me!

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

Marked as reviewed by aghaisas (Reviewer).

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

From kcr at openjdk.org  Wed Jan  4 12:57:57 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jan 2023 12:57:57 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v3]
In-Reply-To: <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
Message-ID: <-xJNts4-kCgb2s518psfE0ERPoRmSEPN5TJEziMTAmM=.55e674f1-6f99-4e84-b0f7-345c6a055293@github.com>

On Tue, 3 Jan 2023 23:56:12 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed thrown exception

Marked as reviewed by kcr (Lead).

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

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

From kevin.rushforth at oracle.com  Wed Jan  4 13:54:21 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 4 Jan 2023 05:54:21 -0800
Subject: Removing gtk2 support
In-Reply-To: <CABxFH2FyMwGMZQsEaB7s6KHrwB0jLAHxYvBB+=F9bDPpO2dzWA@mail.gmail.com>
References: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
 <CABxFH2FyMwGMZQsEaB7s6KHrwB0jLAHxYvBB+=F9bDPpO2dzWA@mail.gmail.com>
Message-ID: <055ba622-79b4-121f-5174-f9c1d2243cf0@oracle.com>

I was thinking the same thing yesterday, but hadn't filed the issue yet. 
I just now filed:

https://bugs.openjdk.org/browse/JDK-8299595

If you are willing to do this, it would be appreciated. You can assign 
the bug to yourself. It will need a CSR and a release note.

My recommendation is that it be done without any refactoring of the 
sources, so that it is minimally intrusive. The changes would then be 
limited to removing the build task from build.gradle, and removing GTK 2 
as an option in "launcher.c" (leaving the logic in place in case we 
later want to support gtk4 and gtk3 in the same way we support gtk3 / 
gtk2 today).

-- Kevin


On 1/4/2023 4:20 AM, Johan Vos wrote:
> I think it is absolutely worth considering that.
> I actually thought we already had an issue for discussing this, but I 
> seem to be unable to do search queries on JBS atm.
>
> I can't think about configurations that are stuck on GTK2 and that are 
> still relevant today, but it would be good to get input from others in 
> case such configurations are still in use.
>
> - Johan
>
> On Wed, Jan 4, 2023 at 12:30 PM Thiago Milczarek Say?o 
> <thiago.sayao at gmail.com> wrote:
>
>
>     Would a merge request to remove gtk2 support on the JavaFX 21
>     release be welcome?
>
>     --Thiago.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230104/38ab77c0/attachment.htm>

From nlisker at openjdk.org  Wed Jan  4 14:33:04 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 4 Jan 2023 14:33:04 GMT
Subject: RFR: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing [v3]
In-Reply-To: <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
 <GiefOSupkRfdO7nm0EsVcmdAu9m-1Ha5ePUsiHkrZLI=.8030fd83-a423-44ba-9118-4126dd088dd3@github.com>
Message-ID: <1qb2eXzAlbqXwm7sY0KifgCIDwWY_wxBCJxBiMR7B9g=.41e75980-d8aa-4104-841a-b8d0d03766fb@github.com>

On Tue, 3 Jan 2023 23:56:12 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
>> 
>> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed thrown exception

Thanks for the quick review!

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

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

From nlisker at openjdk.org  Wed Jan  4 14:33:06 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 4 Jan 2023 14:33:06 GMT
Subject: Integrated: 8209017: CheckBoxTreeCell: graphic on TreeItem not always
 showing
In-Reply-To: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
References: <MvPYq5qMV740eDc6qIqhN3Bdez39Ss7QLbJsaEqWxjg=.ac7bcbcd-8e67-46a8-a531-98e01f6747b1@github.com>
Message-ID: <1tBrbGEz1Uk2VSPfLKtbLtaELZ3TVY4ER1sLkb0kxwA=.a0ed68c7-5faf-4255-9a8e-c0b64325ee0b@github.com>

On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after expand/collapse events. The graphics node needs to be released from the previous checkbox so that it doesn't serve as the graphics of more than one checkbox at once. If it does, only one checkbox (its skin) can actually use it as a scenegraph child, and it's not always the correct one.
> 
> Added also a manual test app as I'm unsure about how to do an automatic test for this. The test app will be useful for later fixes, so I suggest adding it anyway. To test the fix, simply expand and collapse the root note repeatedly while it has a child. Before the fix the graphic will disappear after a few tries, after the fix it won't. You can test other hierarchies as well by adding children to the tree.

This pull request has now been integrated.

Changeset: 012fa16f
Author:    Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/012fa16faccaf9b6a1f56cd3b5450ab200bdec9c
Stats:     135 lines in 5 files changed: 134 ins; 0 del; 1 mod

8209017: CheckBoxTreeCell: graphic on TreeItem not always showing

Reviewed-by: jhendrikx, angorya, kcr

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

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

From mstrauss at openjdk.org  Wed Jan  4 15:02:03 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 15:02:03 GMT
Subject: RFR: 8268642: Improve property system to facilitate correct usage
 [v3]
In-Reply-To: <lUfmLQxCrBOX5GoR5ybJL9M_ru7pNrB8FBdBMFMWdcc=.e685c850-d5c1-46a8-a431-9ce2a00990cd@github.com>
References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com>
 <FLBS8m8LXXSueqDfp5fY1b-aL1Io4Rhx1ADwHi0HgkQ=.af8365f3-7f13-4ab4-8b8f-9827f2096a9b@github.com>
 <lUfmLQxCrBOX5GoR5ybJL9M_ru7pNrB8FBdBMFMWdcc=.e685c850-d5c1-46a8-a431-9ce2a00990cd@github.com>
Message-ID: <L9QVltOoO9P0FqZuJy-TG28gsXF9_0SxZ5mXfmdejps=.e3ebda6b-d50b-4d7c-8ac0-3e29c1a0c1d6@github.com>

On Wed, 4 Jan 2023 10:43:20 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> @mstr2 would this PR make it impossible to keep more than 2 properties in sync with each other? Bidirectional bindings previously allowed for this, and I can imagine some use as well when there are a few layers involved.

Sure, this PR doesn't remove any functionality that currently exists. The point of this PR is to explicitly disallow scenarios that cannot meaningfully work at all.

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

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

From gschmidj at qfs.de  Wed Jan  4 15:59:20 2023
From: gschmidj at qfs.de (Gregor Schmid)
Date: Wed, 04 Jan 2023 16:59:20 +0100
Subject: Removing gtk2 support
In-Reply-To: <CABxFH2FyMwGMZQsEaB7s6KHrwB0jLAHxYvBB+=F9bDPpO2dzWA@mail.gmail.com>
 (Johan Vos's message of "Wed, 4 Jan 2023 13:20:02 +0100")
References: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
 <CABxFH2FyMwGMZQsEaB7s6KHrwB0jLAHxYvBB+=F9bDPpO2dzWA@mail.gmail.com>
Message-ID: <4hwn6247fr.fsf@qfs.de>


>From my experience there are always people stuck on old systems with
the weirdest configurations. One wouldn't expect them to use JavaFX 21
upwards, however they often need to combine their
very-old-and-unsupported-for-years legacy stuff with some other
lets-use-the-latest-and-greatest application that their devs just came
up with.

I think the question is whether there is - or you would want to
implement - a clear policy defining the minimum requirements for
JavaFX version <x>. E.g. for Linux: Official distributions going back
<n> years from a Java/JavaFX LTS release. With that in place it is
relatively easy to answer these kinds of questions. It's also easier
for developers to anticipate what's likely to get dropped from JavaFX
and when.

That said, I think we could use such a policy ourselves... ;-)

Best regards,
    Greg

Johan Vos <johan.vos at gluonhq.com> writes:

> I think it is absolutely worth considering that.
> I actually thought we already had an issue for discussing this, but I seem
> to be unable to do search queries on JBS atm.
>
> I can't think about configurations that are stuck on GTK2 and that are
> still relevant today, but it would be good to get input from others in case
> such configurations are still in use.
>
> - Johan
>
> On Wed, Jan 4, 2023 at 12:30 PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>>
>> Would a merge request to remove gtk2 support on the JavaFX 21 release be
>> welcome?
>>
>> --Thiago.
>>
>>
>>

-- 
Gregor Schmid

E: gregor.schmid at qfs.de
T: +49 8171 38648-11
F: +49 8171 38648-16

Quality First Software GmbH | www.qfs.de
B?rgermeister-Graf-Ring 10 | 82538 Geretsried | Germany
GF Gregor Schmid, Karlheinz Kellerer
HRB M?nchen 140833

The data protection information in accordance with the EU General Data
Protection Regulation applies to authorized representatives /
authorized representatives of "legal persons" in accordance with Art.
12 ff. DS-GVO
https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf

From john at status6.com  Wed Jan  4 16:11:19 2023
From: john at status6.com (John Neffenger)
Date: Wed, 4 Jan 2023 08:11:19 -0800
Subject: libav.org is not resolving
In-Reply-To: <CABxFH2FfHiDOZrJd9uvye8S=NAb-Q_Y=eaOCwb8b0o7EbDNrqw@mail.gmail.com>
References: <28314e5b-688a-31d9-afbd-351514339f99@status6.com>
 <CABxFH2FfHiDOZrJd9uvye8S=NAb-Q_Y=eaOCwb8b0o7EbDNrqw@mail.gmail.com>
Message-ID: <0c509c1d-53e1-f0a4-2a39-4441a686af51@status6.com>

I've been unable to get the GitHub archive working as a replacement. I 
think the problem is due to the lack of the file name in the URL, which 
our Gradle build file expects:

   https://github.com/libav/libav/archive/v12.1.tar.gz
   ==> content-disposition: attachment; filename=libav-12.1.tar.gz

   <component group="" name="libav-12.1" version="">
     <artifact name="libav-12.1-.tar.gz">
       <sha256 value="f08d48bf...2a4527e1" origin="Generated by Gradle"/>
     </artifact>
   </component>

I notice we're building both Libav and FFmpeg, but I think we can drop 
Libav now. I know it's gone back and forth even in the Linux 
distributions between the original and fork, but it seems the forking 
battle is finally over. Wikipedia says:

   "As of 2022, Libav is an abandoned software project, with Libav 
developers either returning to FFmpeg, moving to other multimedia 
projects like the AV1 video codec,[17] or leaving the multimedia field 
entirely."
https://en.wikipedia.org/wiki/Libav#Fork_from_FFmpeg

Maybe that's why the domain name is no longer resolving: nobody is 
around to fix it anymore. Can we remove it from the build?

John

On 1/4/23 3:00 AM, Johan Vos wrote:
> Hi John,
> 
> Thanks for pointing this out. Our automated builds are failing for the 
> same reason. It's not the first time that this dependency on the libav 
> website hits us, and I agree it's better indeed to depend on the github 
> repositories (which are also not guaranteed to be available though).
> 
> - Johan


From angorya at openjdk.org  Wed Jan  4 16:17:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 4 Jan 2023 16:17:00 GMT
Subject: RFR: 8216507: StyleablePropertyFactory: example in class javadoc
 does not compile [v3]
In-Reply-To: <n_moELMjienZItb4eDROuJg-oVR1Gs3u60wlUVfwCkE=.11bb4647-3212-4797-a30f-bb11a95c6d27@github.com>
References: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
 <n_moELMjienZItb4eDROuJg-oVR1Gs3u60wlUVfwCkE=.11bb4647-3212-4797-a30f-bb11a95c6d27@github.com>
Message-ID: <Npok-Wi0nzUiwGeTQgavvsNc44yBuCQzhWERa7eL0Vw=.01e94523-4970-4156-9dd1-7e4cb80a3952@github.com>

On Mon, 2 Jan 2023 11:39:19 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> In the javadoc example of `StyleablePropertyFactory` class, wrong parameter was used while initializing `StyleableProperty`. 
>> 
>> Assigned the `CssMetadData` object to `SELECTED` variable returned by `createBooleanCssMetaData` method called in anonymous inner-class class, which is then used while initializing `StyleableProperty`.
>> 
>> Added missing semicolon in the same example.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unit test for javadoc example of StyleablePropertyFactory

good work!

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

Marked as reviewed by angorya (Committer).

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

From kpk at openjdk.org  Wed Jan  4 16:36:59 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 4 Jan 2023 16:36:59 GMT
Subject: Integrated: 8216507: StyleablePropertyFactory: example in class
 javadoc does not compile
In-Reply-To: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
References: <sQBwwv9QajOBADIFDzs-6DnaQuU7yuvReVxSSHTs900=.81456217-165f-48e8-b026-aee0ce738cf6@github.com>
Message-ID: <EWLn0oidsZJNapbDui8GnyqqSIfoNAbWs_tKvpqLrZE=.f4b878a6-dd77-4fe2-929f-d26c0578c8ac@github.com>

On Fri, 23 Dec 2022 13:55:30 GMT, Karthik P K <kpk at openjdk.org> wrote:

> In the javadoc example of `StyleablePropertyFactory` class, wrong parameter was used while initializing `StyleableProperty`. 
> 
> Assigned the `CssMetadData` object to `SELECTED` variable returned by `createBooleanCssMetaData` method called in anonymous inner-class class, which is then used while initializing `StyleableProperty`.
> 
> Added missing semicolon in the same example.

This pull request has now been integrated.

Changeset: 94fb7ede
Author:    Karthik P K <kpk at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/94fb7ede2dcde306a631d1feb0107c96a8221452
Stats:     19 lines in 2 files changed: 15 ins; 0 del; 4 mod

8216507: StyleablePropertyFactory: example in class javadoc does not compile

Reviewed-by: angorya, aghaisas

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

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

From zjx001202 at gmail.com  Wed Jan  4 18:26:42 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 5 Jan 2023 02:26:42 +0800
Subject: Removing gtk2 support
In-Reply-To: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
References: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
Message-ID: <CAJL5A3k3FE9uXcEoWtW_acpY9Hc14y3i-juKgdU4B2V3Q9KguA@mail.gmail.com>

Our JavaFX application has some strange problems when using GTK3,
one of the problems is that some ScrollPanes cannot scroll up with the
mouse wheel.

These problems only occur when GTK3 is used on Linux. To avoid this
problem, we have to set jdk.gtk.version to 2.

I haven't found any information about this problem. Does anyone know what
may be the cause?

On Wed, Jan 4, 2023 at 7:28 PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

>
> Would a merge request to remove gtk2 support on the JavaFX 21 release be
> welcome?
>
> --Thiago.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230105/c1d28dc5/attachment.htm>

From angorya at openjdk.org  Wed Jan  4 18:38:23 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 4 Jan 2023 18:38:23 GMT
Subject: RFR: 8296413: Tree/TableView with null focus model throws NPE in
 queryAccessibleAttribute() [v3]
In-Reply-To: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
References: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
Message-ID: <IOVs2TFI-pP9BBSIRJt5FNQR5PrMmf0CaF-I5UOZN9s=.384d2b8b-68cc-4b63-bb70-6655fb8a5ced@github.com>

> - added test to ensure no exception is thrown from Control.queryAccessibleAttribute() for all accessible attributes values
> - fixed null focus model case in Tree/TableView

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

  8296413: 2023

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/938/files
  - new: https://git.openjdk.org/jfx/pull/938/files/6111660b..f7ecf537

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

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

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

From thiago.sayao at gmail.com  Wed Jan  4 19:10:10 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 4 Jan 2023 16:10:10 -0300
Subject: Removing gtk2 support
In-Reply-To: <CAJL5A3k3FE9uXcEoWtW_acpY9Hc14y3i-juKgdU4B2V3Q9KguA@mail.gmail.com>
References: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
 <CAJL5A3k3FE9uXcEoWtW_acpY9Hc14y3i-juKgdU4B2V3Q9KguA@mail.gmail.com>
Message-ID: <CAAP_wukordwrNtZXgcuqo3wC3EAZt4sO7ofXPTS6hQBZLwy6gQ@mail.gmail.com>

Could you report a bug with a test sample? I can take a look.

-- Thiago.

Em qua., 4 de jan. de 2023 ?s 15:27, Glavo <zjx001202 at gmail.com> escreveu:

> Our JavaFX application has some strange problems when using GTK3,
> one of the problems is that some ScrollPanes cannot scroll up with the
> mouse wheel.
>
> These problems only occur when GTK3 is used on Linux. To avoid this
> problem, we have to set jdk.gtk.version to 2.
>
> I haven't found any information about this problem. Does anyone know what
> may be the cause?
>
> On Wed, Jan 4, 2023 at 7:28 PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>>
>> Would a merge request to remove gtk2 support on the JavaFX 21 release be
>> welcome?
>>
>> --Thiago.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230104/716aea6b/attachment.htm>

From kcr at openjdk.org  Wed Jan  4 21:21:03 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jan 2023 21:21:03 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v29]
In-Reply-To: <84ROu4UHOmkF2AiUIZ7kGQvVyH38NiMM8AgHEv49v_c=.14a697e5-9b7f-40b5-8ede-0749596b40c0@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
 <Fl1Rm2StwHH4h2C9y0FIGmUIqH2egVBX9b2rU3YAPjg=.6f401e7d-81a4-4930-9767-e65d384c666c@github.com>
 <84ROu4UHOmkF2AiUIZ7kGQvVyH38NiMM8AgHEv49v_c=.14a697e5-9b7f-40b5-8ede-0749596b40c0@github.com>
Message-ID: <-SYUH_CAfmzRSp-GDBhI2G05_5ZzEsFpAw7aOEKOMyM=.29c2cf22-1db4-4e4a-974d-3b3831e9936a@github.com>

On Tue, 3 Jan 2023 23:02:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > I am seeing a new behavior,
> 
> could you check the latest version please?

I just confirmed that I was testing the latest version yesterday afternoon.

> I think the latest version works as expected, except for one scenario with fractional size, where both AUTO_RESIZE_FLEX_LAST_COLUMN and AUTO_RESIZE_FLEX_NEXT_COLUMN result in the adjustment of the columns to the left of the one being resized (data=many columns, same pref)

I can reproduce the bug I reported above with flex policies using a screen scale of 1 on Mac, Windows, and Linux.

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

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

From angorya at openjdk.org  Wed Jan  4 21:33:02 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 4 Jan 2023 21:33:02 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v29]
In-Reply-To: <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
Message-ID: <eoPrEhUD6wEHxq76jBM4wRqNqrpXrOymQQmrryvymQQ=.275c07d6-e1dc-4941-a216-c17f49ab7871@github.com>

On Tue, 3 Jan 2023 19:02:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 2023
>  - 2023

Kevin, I now see what you mean (one has to resize the table almost to the full screen width, to make sure all columns are wider than their preferred widths).

It's working as expected, actually.  It first tries to use excess space (over preferred width) so it will switch from next to the following column, then, once all the columns are at their preferred widths, it starts with the column next to one being resized.

In other words, rather than squishing the next or last column to an unusable width, it first tries to use the excess space (thus the name "flex" you so aptly suggested).

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

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

From kcr at openjdk.org  Wed Jan  4 21:45:59 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jan 2023 21:45:59 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v29]
In-Reply-To: <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <4eI1xVTO95Wph-06nlK8DSB267ENQlqQocTR6l26ApQ=.6b44bcdb-9d88-44c8-8304-437e624056cf@github.com>
Message-ID: <VALH5yCdFktyEtOP21TkaEhCIYDDsRe9k_zpYleEoC8=.bfb86ff9-c0db-4f12-914c-c6742ae4cb88@github.com>

On Tue, 3 Jan 2023 19:02:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 2023
>  - 2023

OK, that makes complete sense to me, and is, I agree, a better choice.

We might consider a follow-up doc bug to clarify this, but it isn't critical.

I also don't think the remaining HiDPI issue is critical, so that also could be a follow-up. I'll continue testing it, and also review the code.

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

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

From angorya at openjdk.org  Wed Jan  4 22:24:30 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 4 Jan 2023 22:24:30 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v30]
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <_hCSl1Rky86OzxQ3tg-ljVo3oisGdwGCD50rxHgMLBE=.56a7f969-f36f-458a-859a-103e5611f3cc@github.com>

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

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

 - Merge remote-tracking branch 'origin/master' into 8293119.constrained
 - width indicator in tester
 - 2023
 - 2023
 - small delta
 - whitespace
 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8293119.constrained
 - shrink small
 - snap after resize
 - ... and 89 more: https://git.openjdk.org/jfx/compare/94fb7ede...e09246a3

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

Changes: https://git.openjdk.org/jfx/pull/897/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=29
  Stats: 2480 lines in 14 files changed: 2213 ins; 250 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/897.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897

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

From mstrauss at openjdk.org  Wed Jan  4 23:00:58 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 4 Jan 2023 23:00:58 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v9]
In-Reply-To: <uVVfcMDiKQrYnkHyXJUjEO2YiBGBElHC-no6SJ5t3o0=.779ffc3b-c8db-44d3-9d9a-63892f328335@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <Cf5-BVWRfzuKQGbGQZe6fzg10X97rP8whvNd2ykOvjU=.bf512415-3c51-4d4e-aed1-721f547cddec@github.com>
 <uVVfcMDiKQrYnkHyXJUjEO2YiBGBElHC-no6SJ5t3o0=.779ffc3b-c8db-44d3-9d9a-63892f328335@github.com>
Message-ID: <T21Hxngs_s-xCXOcQ6RJrhO3uKjLT03IMmXRFeDj0tc=.06185912-34e9-4971-a173-98524a95103b@github.com>

On Sun, 25 Dec 2022 03:28:57 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> For reasons that I don't understand, the problem was the order of the semantics declared in the `vs2ps` struct. Moving `float2 texD : texcoord0;` down fixed the issue. I played a bit with the ordering out of curiosity and got different results. I didn't see anything in the documentation that talks about the order of the interpolated variables. This fixed problem 2 for me.

I tested this behavior at commit bb9f802, and can't observe any visual difference with regards to the order of `texD` in the `PsInput` struct. Adding two points lights works fine in either case.

Are you sure that this isn't an artifact of your local build? I notice that Gradle doesn't seem to pick up changes in HLSL headers, so I have to clean the build artifacts to prevent Gradle from skipping `:graphics:generateD3DHeaders`. Maybe you changed several things, and one of the other changes happened to fix the original problem?

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

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

From nlisker at openjdk.org  Wed Jan  4 23:32:59 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 4 Jan 2023 23:32:59 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <EtO5Jo_Nx1Nu9UAk3Zx_fITKe1LgguyWvTUTd3GIvXg=.e8423055-c18e-4af7-bcc2-b95a390bfd40@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

> I tested this behavior at commit [bb9f802](https://github.com/openjdk/jfx/commit/bb9f80263d4565cad1f485a59228064ca53d2d96), and can't observe any visual difference with regards to the order of `texD` in the `PsInput` struct. Adding two points lights works fine in either case.

Can you reproduce Kevin's observation at [1f66f61](https://github.com/openjdk/jfx/pull/789/commits/1f66f613ae3ba2ffc553d29424dd5b553d85978a)? If yes, which commit fixed it for you? For me it's the one that changed the order of the fields.

> Are you sure that this isn't an artifact of your local build? I notice that Gradle doesn't seem to pick up changes in HLSL headers, so I have to clean the build artifacts to prevent Gradle from skipping `:graphics:generateD3DHeaders`. Maybe you changed several things, and one of the other changes happened to fix the original problem?

I delete the hlsl shaders every build so that they will be recreated. Still, there could be some caching involved that I couldn't spot. I changed the order of the variables in the struct back and forth and tried several orders to make sure it's not a coincidence and the results were consistant.

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

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

From kcr at openjdk.org  Wed Jan  4 23:39:59 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jan 2023 23:39:59 GMT
Subject: RFR: 8251862: Wrong position of Popup windows at the intersection
 of 2 screens [v2]
In-Reply-To: <YAKefTEoJtZY2wugdkmDhCrGJqNVpX6bkUySGCnXxPQ=.502ae52b-f2f5-4af7-a217-3ca6972811f5@github.com>
References: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
 <HCQUYj1RCrVJUM6932iKXmRldCy7LX4fG9bCywibMa8=.cc1e280f-b761-4ef2-bb22-a9177d67d3e4@github.com>
 <YAKefTEoJtZY2wugdkmDhCrGJqNVpX6bkUySGCnXxPQ=.502ae52b-f2f5-4af7-a217-3ca6972811f5@github.com>
Message-ID: <LlX1kZ632CGrVEPbJbkWoSdKi6oU7ZoJ9JNJ47hiKKs=.fa5d8c6d-41a4-41f2-b036-19ac07902e95@github.com>

On Tue, 3 Jan 2023 05:53:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8251862-multi-screen-popup
>>  - 8251862: Wrong position of Popup windows at the intersection of 2 screens
>
> I noticed some wrong position of menu popup when tested with 2 external monitors.
> I have a monitors configured in portrait mode as:
> ![Screenshot 2022-12-09 145806](https://user-images.githubusercontent.com/11330676/210305749-d5073945-bfaa-44cc-98eb-172f6b344e22.png)
> 
> Screenshots of some observations:
> 1. 
> ![Screenshot 2022-12-09 144504](https://user-images.githubusercontent.com/11330676/210305790-61530649-eaec-441b-8262-ebd9f7bb877c.png)
> 2.
> ![Screenshot 2022-12-09 144624](https://user-images.githubusercontent.com/11330676/210305822-6b3aa883-bb2f-496d-9a0a-6f95fcffdddb.png)
> 3.
> ![Screenshot 2022-12-09 145645](https://user-images.githubusercontent.com/11330676/210305861-5249ee28-3898-4d5b-8b52-d3e1b3389af2.png)
> 4.
> ![Screenshot 2022-12-09 144722](https://user-images.githubusercontent.com/11330676/210305838-711ddcfa-a3ee-4b35-8b02-f1a510d080f9.png)
> 
> Similar behavior can also be observed if monitors are in landscape mode:
> ![Screenshot 2022-12-09 150231](https://user-images.githubusercontent.com/11330676/210305945-ba171790-4767-4cd2-96c4-2f6fb57b7e50.png)

@arapte Thanks for the additional testing and screenshots. This is similar to what I see, but it is helpful to have the additional configuration to confirm this.

To summarize, this PR fixes the Windows-specific screen scale bug reported in [JDK-8251862](https://bugs.openjdk.org/browse/JDK-8251862) by always taking the screen scales for popups windows from their owner window. This fixes most, but not all of the multi-screen problems when the screen scales are different.

The remaining issues seen in testing are in the code that adjusts the position of the popup to keep it on the same screen as the anchor. It is a separate issue, even though it presents in a similar manner. It is not platform-specific, so we need to test any changes in this code on other platforms.

As a note, I pushed some debugging changes to a new [`test-8251862-multi-screen-popup`](https://github.com/kevinrushforth/jfx/tree/test-8251862-multi-screen-popup) branch. This temporarily adds a system property, `com.sun.javafx.popup.autofix`, to override the autofix logic, which is responsible for keeping popup controls on the same screen. With this set to `false`, popups appear in the correct location, which supports the theory that the remaining problem is in the repositioning code. One exception to this is that the first time a context menu is opened from a TextArea, it is still positioned incorrectly, even when running with `-Dcom.sun.javafx.popup.autofix=false`, so there must be some other code that does a position adjustment besides the two places I modified.

The root cause of this new problem is that the coordinates of the anchor to be adjusted are scaled using the screen that most of the parent window is on (i.e., the "first" screen), while the bounds of the "second" screen that the anchor is on are relative to the scale of that screen. A likely fix for this problem is to adjust the bounds of the screen by the ratio of the two screen scales before comparing the coordinates with the screen bounds, but this might be somewhat tricky.

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

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

From tsayao at openjdk.org  Wed Jan  4 23:52:17 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 4 Jan 2023 23:52:17 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v11]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <kh73482anKXuXSYGbw73H6HpciDvzpXPpWn4tH7Hxq0=.bdde62ab-5625-4506-a590-96db4bf942a4@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Add testing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/665656a4..5f81a1ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=09-10

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

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

From mstrauss at openjdk.org  Thu Jan  5 00:45:01 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 5 Jan 2023 00:45:01 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <EtO5Jo_Nx1Nu9UAk3Zx_fITKe1LgguyWvTUTd3GIvXg=.e8423055-c18e-4af7-bcc2-b95a390bfd40@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
 <EtO5Jo_Nx1Nu9UAk3Zx_fITKe1LgguyWvTUTd3GIvXg=.e8423055-c18e-4af7-bcc2-b95a390bfd40@github.com>
Message-ID: <yr608iky0DVIhw4SCb7_43WViZ_5V-x8VSDccDp2ioA=.b0bc8668-c5c8-4bb4-85f5-52a1c512e0a5@github.com>

On Wed, 4 Jan 2023 23:30:32 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Can you reproduce Kevin's observation at [1f66f61](https://github.com/openjdk/jfx/pull/789/commits/1f66f613ae3ba2ffc553d29424dd5b553d85978a)? If yes, which commit fixed it for you? For me it's the one that changed the order of the fields.

With [1f66f61](https://github.com/openjdk/jfx/pull/789/commits/1f66f613ae3ba2ffc553d29424dd5b553d85978a), I can reproduce Kevin's first observation (ambient light doesn't go back to black), but not the other two.
Adding a second point light works just as I'd expect it, and the magenta point light also works as expected.

With the next commit [3142908](https://github.com/openjdk/jfx/pull/789/commits/31429086ea04d25631f285515fdf72c07bec46e2), I can confirm that the ambient light issue is fixed (it goes back to black when I uncheck the ambient light toggle). I've also triple-checked that I'm pointing the `LightingSample` application at the correct JavaFX build artifacts.

I'm running the application on a PC with a dedicated NVIDIA GeForce GTX 970 with driver version 511.23.
What are you and @kevinrushforth running this on? Maybe there's some undefined behavior going on, and changing the order of fields just happened to hide the issue on your machine?

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

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

From nlisker at openjdk.org  Thu Jan  5 00:56:58 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 5 Jan 2023 00:56:58 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <Ie1NcaxoJp8q7HOuMp8c8vT-PS2i_5eHbJOPk7_KB1w=.b6ee1222-c4ba-4d0d-8722-4c15b8994e38@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

The ambient light issue was on the Java side. The purple light is probably just a false observation because it starts in a position where it doesn't apply its light. The real mystery is the problem with the two point lights.

I have an AMD 470.

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

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

From nlisker at gmail.com  Thu Jan  5 04:06:13 2023
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 5 Jan 2023 06:06:13 +0200
Subject: CheckBoxTreeItem behavior - independent property
In-Reply-To: <CA+0ynh9Ly0yOXUQ=hc28N06JhYRZAexPYPZJshb4BMMmkdOOgQ@mail.gmail.com>
References: <CA+0ynh9Ly0yOXUQ=hc28N06JhYRZAexPYPZJshb4BMMmkdOOgQ@mail.gmail.com>
Message-ID: <CA+0ynh_W8oUtuA8ykcg+Ov_xw4CUdeVtqTJDO-wV4TJOo5oedQ@mail.gmail.com>

I would like to create an issue for changing the behavior of the
independent property to be independent both as a source and as a target.
That is, an independent item would no longer update when a parent or child
of it is updated.

Can I go forward with it or is there a risk of breaking current code that
makes it not worth doing this? To me it looks like a bug, but the docs
don't say anything about this point.

On Sat, Nov 19, 2022 at 9:28 AM Nir Lisker <nlisker at gmail.com> wrote:

> Hi,
>
> Another issue I stumbled across is the usage of the Independent property
> on CheckBoxTreeItem. The docs read:
>
> A BooleanProperty used to represent the independent state of this
>> CheckBoxTreeItem. The independent state is used to represent whether
>> changes to a single CheckBoxTreeItem should influence the state of its
>> parent and children.
>
>
> By default, the independent property is false, which means that when a
>> CheckBoxTreeItem has state changes to the selected or indeterminate
>> properties, the state of related CheckBoxTreeItems will possibly be
>> changed. If the independent property is set to true, the state of related
>> CheckBoxTreeItems will never change.
>
>
> It makes it clear that changes to this checkbox don't influence its
> children/parents, and in terms of usage, it means that clicking on the
> checkbox doesn't change the state of its parents/children. However:
>
> 1. Does it also include stopping the propagation of selection updates
> through it? If an independent item has a child and a parent, and the parent
> is selected, does the item stop its child from being selected? I think that
> the answer is yes, but I want to make sure the independent property wasn't
> just meant for direct clicks or direct changes to its own properties alone.
>
> 2. Do the parents/children affect this item? The docs only mention one
> direction: item -> parents/children, it doesn't mention parents/children ->
> item. As it stands currently, the item seems to be affected by other
> selections. I find it odd because this doesn't make the item really
> independent, and I can't think of a use case for this one-sided independent
> behavior.
>
> In any case, I think that the documentation should clarify these points,
> so I would like to know what the behavior should be.
>
> - Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230105/93d85381/attachment-0001.htm>

From kpk at openjdk.org  Thu Jan  5 08:00:11 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 5 Jan 2023 08:00:11 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v2]
In-Reply-To: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
Message-ID: <t8ArS067kLC7lNP1qP_fL1yhu0uUzoWlBwrYV_qMHK8=.814bce5e-57fe-4465-8006-928a8929cae8@github.com>

> When Text width was more than TextField width, condition to update `textTranslateX` was not getting satisfied as calculated value was negative. Hence the text was getting aligned to previous `textTranslateX` value.
> 
> Added else block to update the `textTranslateX` value when calculated value is negative.
> 
> 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 textfield right and center alignment issues

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/980/files
  - new: https://git.openjdk.org/jfx/pull/980/files/2238ec41..337ad7ac

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

  Stats: 63 lines in 2 files changed: 44 ins; 9 del; 10 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 kpk at openjdk.org  Thu Jan  5 08:17:58 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 5 Jan 2023 08:17:58 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v2]
In-Reply-To: <t8ArS067kLC7lNP1qP_fL1yhu0uUzoWlBwrYV_qMHK8=.814bce5e-57fe-4465-8006-928a8929cae8@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <t8ArS067kLC7lNP1qP_fL1yhu0uUzoWlBwrYV_qMHK8=.814bce5e-57fe-4465-8006-928a8929cae8@github.com>
Message-ID: <2AI2CtNR5pJu75uJsuNAFYHoMW3mXWgJwLKUSHGgYc0=.6648df9e-ba45-4818-a681-209000e038ea@github.com>

On Thu, 5 Jan 2023 08:00:11 GMT, Karthik P K <kpk at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   Fix textfield right and center alignment issues

Fixed the issues with RIGHT and CENTER alignment of text field. Updated the details in bug and PR. Please review

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

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

From arapte at openjdk.org  Thu Jan  5 08:33:56 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 5 Jan 2023 08:33:56 GMT
Subject: RFR: 8296413: Tree/TableView with null focus model throws NPE in
 queryAccessibleAttribute() [v3]
In-Reply-To: <IOVs2TFI-pP9BBSIRJt5FNQR5PrMmf0CaF-I5UOZN9s=.384d2b8b-68cc-4b63-bb70-6655fb8a5ced@github.com>
References: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
 <IOVs2TFI-pP9BBSIRJt5FNQR5PrMmf0CaF-I5UOZN9s=.384d2b8b-68cc-4b63-bb70-6655fb8a5ced@github.com>
Message-ID: <yaJK955SL_wzxkfdalJeLQrMdLsCjvJ8AHZbRy4TeI4=.4d6229f5-ea46-493b-9d81-11b8d781e5a8@github.com>

On Wed, 4 Jan 2023 18:38:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - added test to ensure no exception is thrown from Control.queryAccessibleAttribute() for all accessible attributes values
>> - fixed null focus model case in Tree/TableView
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8296413: 2023

LGTM

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

Marked as reviewed by arapte (Reviewer).

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

From fkirmaier at openjdk.org  Thu Jan  5 08:34:14 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 5 Jan 2023 08:34:14 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v3]
In-Reply-To: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
Message-ID: <9mG38YEJl4bw3a3O6JBXwHVbzRUKKzcGpWNdwQ5g3s4=.592e37bc-982d-4f97-a640-62da8b47c7bd@github.com>

> This PR fixes the leak in the mac system menu bar.
> 
> Inside the native code, NewGlobalRef is called for the callable.
> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
> 
> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
> 
> The unit test verifies, that this bug happened without this change, but no longer happens with this change.

Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision:

 - JDK-8299423
   reverted added newline
 - JDK-8299423
   reverted whitespace change,
   added missing copyright header

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/987/files
  - new: https://git.openjdk.org/jfx/pull/987/files/02d37146..61127b2e

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

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

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

From arapte at openjdk.org  Thu Jan  5 08:35:56 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 5 Jan 2023 08:35:56 GMT
Subject: RFR: 8231864: JavaFX Labels in Tab's VBox is not displayed until
 it is clicked [v2]
In-Reply-To: <kobZY2OAi18ltu9rbscuURg5zmYGPflHs1kNCHbUCh4=.e52a93c3-5a38-4749-8b55-f90d182cb312@github.com>
References: <w6sJUfz8XPa0ZyZ6zyPMb3lJ3hMBpyPLCwcTA0v4704=.5532aced-2817-4c1d-be8f-99effc0a2026@github.com>
 <kobZY2OAi18ltu9rbscuURg5zmYGPflHs1kNCHbUCh4=.e52a93c3-5a38-4749-8b55-f90d182cb312@github.com>
Message-ID: <ueA8eEaHeFUaOkgGKdb8f3no6GJb50FRZUMrJ_tfdvo=.70e273ee-71e2-4ccd-a71a-2e1ddbba815e@github.com>

On Mon, 2 Jan 2023 14:10:20 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Creating a not-displayed node and then modifying its contents caused JFX to not consume its old dirty region and thus not update it. When such node was displayed, its old dirty region was used for drawing, which in some cases (ex. new content taking more space - a Label having more text as in bug request) caused it to clip.
>> 
>> Resolved by always unionizing dirty regions with new bounds when calculating Node's transformed bounds.
>> 
>> Change was tested on macOS and Windows 10 and does not affect any tests.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NGNode: Change comment at dirty bounds update for clarification

LGTM

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

Marked as reviewed by arapte (Reviewer).

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

From fkirmaier at openjdk.org  Thu Jan  5 09:06:55 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 5 Jan 2023 09:06:55 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v3]
In-Reply-To: <9mG38YEJl4bw3a3O6JBXwHVbzRUKKzcGpWNdwQ5g3s4=.592e37bc-982d-4f97-a640-62da8b47c7bd@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <9mG38YEJl4bw3a3O6JBXwHVbzRUKKzcGpWNdwQ5g3s4=.592e37bc-982d-4f97-a640-62da8b47c7bd@github.com>
Message-ID: <huJ8STJNJLeLhxsMjSe2b7sRXpsrzLfJqXDV-52rpcg=.a753d4b2-b4b6-41db-b09f-b3eb5e132725@github.com>

On Thu, 5 Jan 2023 08:34:14 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR fixes the leak in the mac system menu bar.
>> 
>> Inside the native code, NewGlobalRef is called for the callable.
>> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
>> 
>> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
>> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
>> 
>> The unit test verifies, that this bug happened without this change, but no longer happens with this change.
>
> Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8299423
>    reverted added newline
>  - JDK-8299423
>    reverted whitespace change,
>    added missing copyright header

I've tested this version with explicit GC, and it still worked. So i guess it's stable.

Ok, so now there are multiple Solutions:

1. Revert to the previous version, and remove the WeakReference again.
2. Add an explicit reference to the Callable in the MacMenuDelegate. This would make proof reading much easier.
3. Keep it as is.

I guess I would prefer 2. Would that be ok for everyone?

@mstr2 
I guess this would have to be done in this method:


- (void)action:(id)sender
{
    if (self->jCallback != NULL)
    {
        GET_MAIN_JENV;
        if (env != NULL)
        {
            (*env)->CallVoidMethod(env, self->jCallback, jMenuActionMethod, NULL);
        }
    }
}

Do you have an example, of how this should look like? I'm neither familiar with C, Objective-C, or this JNI code.

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

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

From kpk at openjdk.org  Thu Jan  5 09:49:41 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 5 Jan 2023 09:49:41 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v3]
In-Reply-To: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
Message-ID: <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>

> 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 incrementally with one additional commit since the last revision:

  Update comments

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

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

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

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 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 lkostyra at openjdk.org  Thu Jan  5 10:30:56 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 5 Jan 2023 10:30:56 GMT
Subject: Integrated: 8231864: JavaFX Labels in Tab's VBox is not displayed
 until it is clicked
In-Reply-To: <w6sJUfz8XPa0ZyZ6zyPMb3lJ3hMBpyPLCwcTA0v4704=.5532aced-2817-4c1d-be8f-99effc0a2026@github.com>
References: <w6sJUfz8XPa0ZyZ6zyPMb3lJ3hMBpyPLCwcTA0v4704=.5532aced-2817-4c1d-be8f-99effc0a2026@github.com>
Message-ID: <LR883XLUuHxJ4cm-8r4D17OMf68BYqE20-mRv4cFRP4=.c6463f64-6162-43d2-8b68-a71d91be9b11@github.com>

On Mon, 19 Dec 2022 15:50:19 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Creating a not-displayed node and then modifying its contents caused JFX to not consume its old dirty region and thus not update it. When such node was displayed, its old dirty region was used for drawing, which in some cases (ex. new content taking more space - a Label having more text as in bug request) caused it to clip.
> 
> Resolved by always unionizing dirty regions with new bounds when calculating Node's transformed bounds.
> 
> Change was tested on macOS and Windows 10 and does not affect any tests.

This pull request has now been integrated.

Changeset: 0dbc4484
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
Committer: Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0dbc4484c96859c6106bb4c62bff261c7e901aed
Stats:     6 lines in 1 file changed: 3 ins; 1 del; 2 mod

8231864: JavaFX Labels in Tab's VBox is not displayed until it is clicked

Reviewed-by: arapte

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

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

From jvos at openjdk.org  Thu Jan  5 10:58:06 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 10:58:06 GMT
Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing [v3]
In-Reply-To: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
References: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
Message-ID: <9cY1p0bWJeYTq78O6oMfN0hVv9lslVsGlSGBhIiwjAI=.28cde11b-d565-4664-bae6-789ebcb1bc07@github.com>

> When recalculating sizes, we often don't want the current index and/or offset to change.
> 
> Allow to fix the index/offset when doing recalculations.
> 
> Fix JDK-8298728

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process reviewer comments: fix typos (add space)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/974/files
  - new: https://git.openjdk.org/jfx/pull/974/files/5d4474fb..4ce32b70

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

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

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

From jvos at openjdk.org  Thu Jan  5 10:58:07 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 10:58:07 GMT
Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing [v2]
In-Reply-To: <dqjMXkFKiQClpgCCjhIPsefMebT2JncJtIu6HqAPeI0=.b1e562c7-65af-4bf1-9ba3-00ce483912d6@github.com>
References: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
 <AbaGBLHuA_YL-I8hYhdnk2qPl7iFMbiIsjzOH6BQVZM=.268d1821-47ee-4dda-a4f7-a7bc59e4d5ea@github.com>
 <dqjMXkFKiQClpgCCjhIPsefMebT2JncJtIu6HqAPeI0=.b1e562c7-65af-4bf1-9ba3-00ce483912d6@github.com>
Message-ID: <wFr9J3oUajkarovwFqnP_yGQoLlSK2fwFerzTNnDmIU=.ab1bebe0-6291-4747-a6e3-a7710ee8d7e3@github.com>

On Tue, 3 Jan 2023 11:59:27 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move statements to new lines.
>>   Add another failing test, and a fix: when the cell that is positioned at the "current index"
>>   is resized, we also need to modify the offset (wich is calculated from the top of that cell
>>   to the start of the viewport).
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2329:
> 
>> 2327:             getOrCreateCellSize(index - 1);
>> 2328:         }
>> 2329:         if (index < getCellCount() -1) {
> 
> Minor : Need a space after `-`

fixed

> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1473:
> 
>> 1471: 
>> 1472: 
>> 1473:         for (int i =0 ; i < heights.length; i++) {
> 
> Minor : Need a space after `=`

fixed

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

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

From zjx001202 at gmail.com  Thu Jan  5 13:13:37 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 5 Jan 2023 21:13:37 +0800
Subject: Removing gtk2 support
In-Reply-To: <CAAP_wukordwrNtZXgcuqo3wC3EAZt4sO7ofXPTS6hQBZLwy6gQ@mail.gmail.com>
References: <CAAP_wum3WwEUSxmxAqLHDMsfMjg2Tp3gBi6Nt46WtQC0fx==LQ@mail.gmail.com>
 <CAJL5A3k3FE9uXcEoWtW_acpY9Hc14y3i-juKgdU4B2V3Q9KguA@mail.gmail.com>
 <CAAP_wukordwrNtZXgcuqo3wC3EAZt4sO7ofXPTS6hQBZLwy6gQ@mail.gmail.com>
Message-ID: <CAJL5A3kkZd0kpX0cFTkPDLgGFnbxdc4pBuaeacRzmagrti2_+g@mail.gmail.com>

This is our program:

    https://github.com/huanghongxun/HMCL

We called `System.setProperty("jdk.gtk.version", "2")` in the code to avoid
problems.
If we do not set jdk.gtk.version to 2, we cannot use the mouse wheel to
scroll up in the setting interface.

Strangely, this only happens when GTK3 is used on Linux, and it does not
happen when I set the DISPLAY env var
to forward the interface to the VcXsrv X Server running on my Windows
machine.
This problem does not occur on Windows/macOS or use GTK2 on Linux.

On Thu, Jan 5, 2023 at 3:10 AM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> Could you report a bug with a test sample? I can take a look.
>
> -- Thiago.
>
> Em qua., 4 de jan. de 2023 ?s 15:27, Glavo <zjx001202 at gmail.com> escreveu:
>
>> Our JavaFX application has some strange problems when using GTK3,
>> one of the problems is that some ScrollPanes cannot scroll up with the
>> mouse wheel.
>>
>> These problems only occur when GTK3 is used on Linux. To avoid this
>> problem, we have to set jdk.gtk.version to 2.
>>
>> I haven't found any information about this problem. Does anyone know what
>> may be the cause?
>>
>> On Wed, Jan 4, 2023 at 7:28 PM Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> wrote:
>>
>>>
>>> Would a merge request to remove gtk2 support on the JavaFX 21 release be
>>> welcome?
>>>
>>> --Thiago.
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230105/fdd1dabb/attachment.htm>

From jvos at openjdk.org  Thu Jan  5 14:16:27 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 14:16:27 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
Message-ID: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>

Retrieve libav sources from github.
Fix JDK-8282386

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

Commit messages:
 - Retrieve libav sources from github.

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

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

From kcr at openjdk.org  Thu Jan  5 14:30:57 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Jan 2023 14:30:57 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
Message-ID: <Q23Wf-CkOGjHrKBM6NBZdCHAGud6tua77HfUaLhNo-0=.c80b00b2-f639-4dae-913d-9201dab15b2b@github.com>

On Thu, 5 Jan 2023 14:11:10 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Retrieve libav sources from github.
> Fix JDK-8282386

I'll do a CI test build to validate this on our end. I'd also like @sashamatveev to review this.

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

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

From bae at openjdk.org  Thu Jan  5 15:12:59 2023
From: bae at openjdk.org (Andrew Brygin)
Date: Thu, 5 Jan 2023 15:12:59 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
Message-ID: <GxndVUEQtAtkVzKSj1Qle0ODx5vFdqlzo5q23gi2Kgo=.8a6153ab-bd1a-4819-ae00-1c0be2d1392d@github.com>

On Thu, 5 Jan 2023 14:11:10 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Retrieve libav sources from github.
> Fix JDK-8282386

Probably the name pattern of libav artifacts needs to be updated from `libav-${versions}` to `v${version}` on line 3066, and etc:

if (f.name.startsWith("libav-${version}")) {


Thanks,
Andrew

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

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

From kcr at openjdk.org  Thu Jan  5 15:34:56 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Jan 2023 15:34:56 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
Message-ID: <6SvioO50WWQ4-4I9EPPOzx6z7jEU389UnowbFhO7PIg=.cbe40b6e-8f5f-4c16-a4a6-ad2d7d0fce2c@github.com>

On Thu, 5 Jan 2023 14:11:10 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Retrieve libav sources from github.
> Fix JDK-8282386

Here are the additional changes needed:


diff --git a/build.gradle b/build.gradle
--- a/build.gradle
+++ b/build.gradle
@@ -3063,7 +3063,7 @@ project(":media") {
                         libav.versions.each { version ->
                             def libavDir = "${libav.basedir}/libav-${version}"
                             for (File f : configurations.media.files) {
-                                if (f.name.startsWith("libav-${version}")) {
+                                if (f.name.startsWith("v${version}")) {
                                     File dir = file(libavDir)
                                     dir.mkdirs()
                                     def libavTar = "${libav.basedir}/libav-${version}.tar"
@@ -3124,7 +3124,7 @@ project(":media") {
                         libav.versions.each { version ->
                             def libavDir = "${libav.basedir}/libav-${version}"
                             for (File f : configurations.media.files) {
-                                if (f.name.startsWith("libav-${version}")) {
+                                if (f.name.startsWith("v${version}")) {
                                     File dir = file(libavDir)
                                     dir.mkdirs()
                                     def libavTar = "${libav.basedir}/libav-${version}.tar"

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

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

From kcr at openjdk.org  Thu Jan  5 15:34:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Jan 2023 15:34:54 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <GxndVUEQtAtkVzKSj1Qle0ODx5vFdqlzo5q23gi2Kgo=.8a6153ab-bd1a-4819-ae00-1c0be2d1392d@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
 <GxndVUEQtAtkVzKSj1Qle0ODx5vFdqlzo5q23gi2Kgo=.8a6153ab-bd1a-4819-ae00-1c0be2d1392d@github.com>
Message-ID: <2SkueeH6ZyIdzmgXq7Xy98p7Kqes8xPpt7IdpJNgnLY=.fffe3162-2372-4922-911d-ef39e90ee92c@github.com>

On Thu, 5 Jan 2023 15:09:58 GMT, Andrew Brygin <bae at openjdk.org> wrote:

> Probably the name pattern of libav artifacts needs to be updated from libav-${versions} to v${version} on line 3066, and etc:

Good catch! Making this change on lines 3066 and 3127 are necessary and sufficient. My local build passes after these two changes.

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

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

From kcr at openjdk.org  Thu Jan  5 15:59:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Jan 2023 15:59:55 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
Message-ID: <yYpxovikfYgJ1xWQVQBk1cNV5cCGXDNLZ1xC2zQyC00=.56651344-9fb1-4601-aafa-d4c060910756@github.com>

On Thu, 5 Jan 2023 14:11:10 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Retrieve libav sources from github.
> Fix JDK-8282386

Since the .tar.gz source bundles on libav and github are not 100% identical (the checksums are different), I expanded and diffed them, and the sources themselves are identical; the only difference in the bundles is the absence of a `VERSION` file in the github bundles, and we don't use that.

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

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

From angorya at openjdk.org  Thu Jan  5 16:07:01 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 5 Jan 2023 16:07:01 GMT
Subject: Integrated: 8296413: Tree/TableView with null focus model throws NPE
 in queryAccessibleAttribute()
In-Reply-To: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
References: <TdnQ8M9OcYEktaCT5BHL5zU_J0-srUTosIE-CpAJccQ=.56bb9140-89cc-4185-82a3-73538cac72e7@github.com>
Message-ID: <2ewyCRKxpWi-wF1e9sW17T8GSzT7oXXIEdQeyo1I-PI=.2d7cf0ce-8332-41b1-b4f1-d34ae7a284bd@github.com>

On Fri, 4 Nov 2022 22:58:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> - added test to ensure no exception is thrown from Control.queryAccessibleAttribute() for all accessible attributes values
> - fixed null focus model case in Tree/TableView

This pull request has now been integrated.

Changeset: e866a6c3
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e866a6c35c9040115dd62c6c04fd4b3d4d0e1324
Stats:     235 lines in 8 files changed: 181 ins; 26 del; 28 mod

8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute()

Reviewed-by: arapte

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

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

From mstrauss at openjdk.org  Thu Jan  5 16:17:58 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 5 Jan 2023 16:17:58 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v3]
In-Reply-To: <huJ8STJNJLeLhxsMjSe2b7sRXpsrzLfJqXDV-52rpcg=.a753d4b2-b4b6-41db-b09f-b3eb5e132725@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <9mG38YEJl4bw3a3O6JBXwHVbzRUKKzcGpWNdwQ5g3s4=.592e37bc-982d-4f97-a640-62da8b47c7bd@github.com>
 <huJ8STJNJLeLhxsMjSe2b7sRXpsrzLfJqXDV-52rpcg=.a753d4b2-b4b6-41db-b09f-b3eb5e132725@github.com>
Message-ID: <3bCv9KXVk2oBwrKG2eZDIV5G5Pxk01CSMhPOopuN50w=.321e78e5-1542-46ed-ac5d-0c7c07929de9@github.com>

On Thu, 5 Jan 2023 09:03:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> I've tested this version with explicit GC, and it still worked. So i guess it's stable.
> 
> Ok, so now there are multiple Solutions:
> 
> 1. Revert to the previous version, and remove the WeakReference again.
> 2. Add an explicit reference to the Callable in the MacMenuDelegate. This would make proof reading much easier.
> 3. Keep it as is.
> 
> I guess I would prefer 2. Would that be ok for everyone?
> 
> @mstr2 I guess this would have to be done in this method:
> 
> ```
> 
> - (void)action:(id)sender
> {
>     if (self->jCallback != NULL)
>     {
>         GET_MAIN_JENV;
>         if (env != NULL)
>         {
>             (*env)->CallVoidMethod(env, self->jCallback, jMenuActionMethod, NULL);
>         }
>     }
> }
> ```
> 
> Do you have an example, of how this should look like? I'm neither familiar with C, Objective-C, or this JNI code.

The `action` method would look something like this:
```objective-c
- (void)action:(id)sender
{
    GET_MAIN_JENV;
    if (env != NULL) {
        jobject jCallback = (*env)->NewLocalRef(env, self->jCallback);
        if (jCallback != NULL) {
            (*env)->CallVoidMethod(env, jCallback, jMenuActionMethod, NULL);
            (*env)->DeleteLocalRef(env, jCallback);
        }
    }
}


I've found another use of `jCallback` in `validateMenuItem`.

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

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

From aghaisas at openjdk.org  Thu Jan  5 16:33:56 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 5 Jan 2023 16:33:56 GMT
Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing [v3]
In-Reply-To: <9cY1p0bWJeYTq78O6oMfN0hVv9lslVsGlSGBhIiwjAI=.28cde11b-d565-4664-bae6-789ebcb1bc07@github.com>
References: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
 <9cY1p0bWJeYTq78O6oMfN0hVv9lslVsGlSGBhIiwjAI=.28cde11b-d565-4664-bae6-789ebcb1bc07@github.com>
Message-ID: <AHaIk_o3ZLogQd6mMTsxD7wZwbqGqjy10JP3AvOY3nM=.dc2b4fc1-6934-49f2-991e-82c9829d3900@github.com>

On Thu, 5 Jan 2023 10:58:06 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> When recalculating sizes, we often don't want the current index and/or offset to change.
>> 
>> Allow to fix the index/offset when doing recalculations.
>> 
>> Fix JDK-8298728
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process reviewer comments: fix typos (add space)

Marked as reviewed by aghaisas (Reviewer).

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

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

From angorya at openjdk.org  Thu Jan  5 16:33:56 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 5 Jan 2023 16:33:56 GMT
Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing [v3]
In-Reply-To: <9cY1p0bWJeYTq78O6oMfN0hVv9lslVsGlSGBhIiwjAI=.28cde11b-d565-4664-bae6-789ebcb1bc07@github.com>
References: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
 <9cY1p0bWJeYTq78O6oMfN0hVv9lslVsGlSGBhIiwjAI=.28cde11b-d565-4664-bae6-789ebcb1bc07@github.com>
Message-ID: <_ykLTQisxZYScvrT9-KI_Ax0-xYpAQTgyTWj0l73t_I=.0fd2277d-27e3-481c-8471-82e68bc708ac@github.com>

On Thu, 5 Jan 2023 10:58:06 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> When recalculating sizes, we often don't want the current index and/or offset to change.
>> 
>> Allow to fix the index/offset when doing recalculations.
>> 
>> Fix JDK-8298728
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process reviewer comments: fix typos (add space)

lgtm

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

Marked as reviewed by angorya (Committer).

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

From kpk at openjdk.org  Thu Jan  5 17:18:59 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 5 Jan 2023 17:18:59 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v30]
In-Reply-To: <_hCSl1Rky86OzxQ3tg-ljVo3oisGdwGCD50rxHgMLBE=.56a7f969-f36f-458a-859a-103e5611f3cc@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <_hCSl1Rky86OzxQ3tg-ljVo3oisGdwGCD50rxHgMLBE=.56a7f969-f36f-458a-859a-103e5611f3cc@github.com>
Message-ID: <E7LfBtEaSpnczRNJ7GFeKVRSyHCOq54qrO-URJPmnig=.44c7a94a-e5aa-4d23-88df-bad4266c83cf@github.com>

On Wed, 4 Jan 2023 22:24:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - width indicator in tester
>  - 2023
>  - 2023
>  - small delta
>  - whitespace
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - shrink small
>  - snap after resize
>  - ... and 89 more: https://git.openjdk.org/jfx/compare/94fb7ede...e09246a3

I'm also seeing the mouse cursor tracking issue mentioned by Kevin while dragging the column divider.

I wanted to check about following behavior.
When AUTO_RESIZE_FLEX_LAST_COLUMN policy and pref only data are selected, column divider between C1 and C2 is dragged to the right. C4 size will be reduced first and reaches minimum. Then C3 and C2 column size reduces.
After all the 3 columns reach minimum width, if same divider is dragged to the left , C4 gets expanded first, then C3 and C2.
Where as in  AUTO_RESIZE_ALL_COLUMNS policy, the column whose width was reduced last gets expanded first. Should we keep the behavior consistent across all policies?
The behavior in CONSTRAINED_RESIZE_POLICY is same as FLEX policies.

I ran these test in Windows 11 system. I will try to do some more testing on the same machine.

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

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

From angorya at openjdk.org  Thu Jan  5 18:52:57 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 5 Jan 2023 18:52:57 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v3]
In-Reply-To: <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>
Message-ID: <hpPQlGa4UDld1fyRcRZWPnu2xv_5morCDb6nFNVtklg=.674f0d37-1b9c-4d4d-9891-8fb5b5885505@github.com>

On Thu, 5 Jan 2023 09:49:41 GMT, Karthik P K <kpk at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   Update comments

tested with the monkey tester

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java

works beautifully with all the alignment settings.  good job, Karthik!

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

Marked as reviewed by angorya (Committer).

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

From angorya at openjdk.org  Thu Jan  5 19:01:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 5 Jan 2023 19:01:00 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v30]
In-Reply-To: <E7LfBtEaSpnczRNJ7GFeKVRSyHCOq54qrO-URJPmnig=.44c7a94a-e5aa-4d23-88df-bad4266c83cf@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <_hCSl1Rky86OzxQ3tg-ljVo3oisGdwGCD50rxHgMLBE=.56a7f969-f36f-458a-859a-103e5611f3cc@github.com>
 <E7LfBtEaSpnczRNJ7GFeKVRSyHCOq54qrO-URJPmnig=.44c7a94a-e5aa-4d23-88df-bad4266c83cf@github.com>
Message-ID: <EFpzac7akZAkS6qEoveI0jj-tBPlMcsWcC4wM8sHNBg=.0e33e740-c436-4ccc-ac9b-2c30a908ce02@github.com>

On Thu, 5 Jan 2023 17:16:37 GMT, Karthik P K <kpk at openjdk.org> wrote:

> Where as in AUTO_RESIZE_ALL_COLUMNS policy, the column whose width was reduced last gets expanded first. Should we keep the behavior consistent across all policies?

thank you for testing, @karthikpandelu !

not really, the idea of providing several different policies with different behavior is that the app developer can choose the one that fits the requirements best.

AUTO_RESIZE_ALL_COLUMNS tries to allocate extra space proportionally to the preferred width of each column, so the behavior you are describing is expected.

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

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

From jvos at openjdk.org  Thu Jan  5 20:14:58 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 20:14:58 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <6SvioO50WWQ4-4I9EPPOzx6z7jEU389UnowbFhO7PIg=.cbe40b6e-8f5f-4c16-a4a6-ad2d7d0fce2c@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
 <6SvioO50WWQ4-4I9EPPOzx6z7jEU389UnowbFhO7PIg=.cbe40b6e-8f5f-4c16-a4a6-ad2d7d0fce2c@github.com>
Message-ID: <DXN8gUIBTVu00i6fScwMBdUjf73_MZGSuoqLAwAJqnw=.998c18f3-30c2-4eb6-b15d-d6e77555af5f@github.com>

On Thu, 5 Jan 2023 15:32:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Here are the additional changes needed:
> 
Right, it worked locally for me but failed on our CI as well. It worked locally as I have libavcodec.so in my standard library path, but indeed the new libav versions were not copied into the expected directories, hence CI failed.

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

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

From jvos at openjdk.org  Thu Jan  5 20:23:03 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 20:23:03 GMT
Subject: Integrated: 8298728: Cells in VirtualFlow jump after resizing
In-Reply-To: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
References: <t_YZYdT58enjxILSFgb6-E7ye4KQotUT3EaSwYnxXAE=.4796403f-ef12-4b76-9cfb-2c0ba2cbb610@github.com>
Message-ID: <DTE_0LDoXGhcYjlpnNbhz7AJyn0HpzhZmn8KSTEGvmw=.bd1f1628-5c87-430e-920f-68562fb44e0c@github.com>

On Wed, 14 Dec 2022 10:03:29 GMT, Johan Vos <jvos at openjdk.org> wrote:

> When recalculating sizes, we often don't want the current index and/or offset to change.
> 
> Allow to fix the index/offset when doing recalculations.
> 
> Fix JDK-8298728

This pull request has now been integrated.

Changeset: ca29cc61
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ca29cc6122010e4b94778cc658efd4fdddc8af67
Stats:     129 lines in 4 files changed: 111 ins; 2 del; 16 mod

8298728: Cells in VirtualFlow jump after resizing

Reviewed-by: aghaisas, angorya

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

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

From jvos at openjdk.org  Thu Jan  5 20:24:41 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 20:24:41 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org [v2]
In-Reply-To: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
Message-ID: <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>

> Retrieve libav sources from github.
> Fix JDK-8282386

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Use new naming convention when working with libav files downloaded via github

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/989/files
  - new: https://git.openjdk.org/jfx/pull/989/files/600c2f71..b2037246

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

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

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

From angorya at openjdk.org  Thu Jan  5 21:53:56 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 5 Jan 2023 21:53:56 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

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

 - Merge remote-tracking branch 'origin/master' into 8293119.constrained
 - 8293119: removed debug printouts
 - Merge remote-tracking branch 'origin/master' into 8293119.constrained
 - width indicator in tester
 - 2023
 - 2023
 - small delta
 - whitespace
 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8293119.constrained
 - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e

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

Changes: https://git.openjdk.org/jfx/pull/897/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=30
  Stats: 2371 lines in 14 files changed: 2130 ins; 226 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/897.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897

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

From jvos at openjdk.org  Thu Jan  5 22:18:57 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 5 Jan 2023 22:18:57 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <OC0RJP3TmGyQNQeEknB319xpvfwxREnT6q9Y7jCEK2Y=.15c67635-06c4-4c68-9229-7d8bf711e9fa@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
 <OC0RJP3TmGyQNQeEknB319xpvfwxREnT6q9Y7jCEK2Y=.15c67635-06c4-4c68-9229-7d8bf711e9fa@github.com>
Message-ID: <UyRqWEdKrvyuBYchl8bo5aDnVInH7VI3v-gbFcNCdxM=.de9e05e3-281e-48cb-a62f-647ffe86f5b5@github.com>

On Tue, 3 Jan 2023 06:37:14 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> I think this pull request is now ready for a final review. I welcome any other comments or suggestions.

Great. I'll review tomorrow.

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

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

From jgneff at openjdk.org  Thu Jan  5 22:25:57 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Thu, 5 Jan 2023 22:25:57 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <UyRqWEdKrvyuBYchl8bo5aDnVInH7VI3v-gbFcNCdxM=.de9e05e3-281e-48cb-a62f-647ffe86f5b5@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
 <OC0RJP3TmGyQNQeEknB319xpvfwxREnT6q9Y7jCEK2Y=.15c67635-06c4-4c68-9229-7d8bf711e9fa@github.com>
 <UyRqWEdKrvyuBYchl8bo5aDnVInH7VI3v-gbFcNCdxM=.de9e05e3-281e-48cb-a62f-647ffe86f5b5@github.com>
Message-ID: <Ps8rPzP3N4pgC0Mn3mjZZi99LZATWC4U248-w4NRcdk=.ca2a8880-5873-4078-920c-04df909f2914@github.com>

On Thu, 5 Jan 2023 22:16:24 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Great. I'll review tomorrow.

Thanks, Johan. I'll rerun my failing Linux build once your pull request #989 is integrated. (Thank you for doing that!) Are you seeing the [error I'm getting on Windows][1] with the [full production release build][2]?

[1]: https://mail.openjdk.org/pipermail/openjfx-dev/2023-January/037823.html
[2]: https://github.com/jgneff/jfxbuild/blob/main/bin/release.sh

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

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

From tsayao at openjdk.org  Fri Jan  6 00:37:40 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 6 Jan 2023 00:37:40 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v12]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <X9bhlrzsW_r7S9x8E44rkctAGdaYeE5SqY-7YfBZowA=.3a63949b-cdd9-49fd-8de5-7f370d125e88@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/5f81a1ce..9eb2e796

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=10-11

  Stats: 163 lines in 5 files changed: 158 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From tsayao at openjdk.org  Fri Jan  6 01:26:09 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 6 Jan 2023 01:26:09 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v13]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <4P1TS6iQqAY1YOFzXjZpvBXguZhDVj-nqRnZKXLH9mI=.ce173744-d459-4172-b68b-2b79cb59bdd4@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Replace g_warning
 - Improvements

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/9eb2e796..42c9ae9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=11-12

  Stats: 88 lines in 5 files changed: 31 ins; 30 del; 27 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From kpk at openjdk.org  Fri Jan  6 05:13:58 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 6 Jan 2023 05:13:58 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v30]
In-Reply-To: <EFpzac7akZAkS6qEoveI0jj-tBPlMcsWcC4wM8sHNBg=.0e33e740-c436-4ccc-ac9b-2c30a908ce02@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <_hCSl1Rky86OzxQ3tg-ljVo3oisGdwGCD50rxHgMLBE=.56a7f969-f36f-458a-859a-103e5611f3cc@github.com>
 <E7LfBtEaSpnczRNJ7GFeKVRSyHCOq54qrO-URJPmnig=.44c7a94a-e5aa-4d23-88df-bad4266c83cf@github.com>
 <EFpzac7akZAkS6qEoveI0jj-tBPlMcsWcC4wM8sHNBg=.0e33e740-c436-4ccc-ac9b-2c30a908ce02@github.com>
Message-ID: <QlKTmyYFF9RSXEVZL6bpQfyuoG4eSnwYWy_u_3MP8p4=.cbbb8fc3-c826-41cd-b070-2afc3afe1588@github.com>

On Thu, 5 Jan 2023 18:58:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> AUTO_RESIZE_ALL_COLUMNS tries to allocate extra space proportionally to the preferred width of each column, so the behavior you are describing is expected.

Understood. Thanks for the clarification.

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

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

From aghaisas at openjdk.org  Fri Jan  6 09:27:01 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 6 Jan 2023 09:27:01 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v3]
In-Reply-To: <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>
Message-ID: <4ntdaTv85zr_rx3FIZLHctZ38XSEmt81FHEr1F5EaEk=.a3f6d26c-af03-41eb-97c0-060335d497e5@github.com>

On Thu, 5 Jan 2023 09:49:41 GMT, Karthik P K <kpk at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   Update comments

What I have observed is - this fixes the alignment issues, but breaks the cursor movement in case of RIGHT and CENTER alignment.

Tested using MonkeyTester application provided by Andy.
- For a Textfield, select long text and alignment to RIGHT
- In the TextField, click after text "end>" and enter text such that the string becomes longer than that the TextField can display
- Now, start pressing Left arrow key - so that the text cursor starts moving left - if we continue this key press till beginning of the string - it is expected that beginning of the text string is visible. Cursor never reaches beginning of the string with changes done in this PR.

Similar cursor movement issue is observed with CENTER alignment as well.

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

Changes requested by aghaisas (Reviewer).

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

From arapte at openjdk.org  Fri Jan  6 09:37:01 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 6 Jan 2023 09:37:01 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes [v2]
In-Reply-To: <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
Message-ID: <rDuUvE3LLCFJx3e73InkrxF4A-PcxXZCI_7PhCbP2mE=.3beb517c-288c-441a-ac19-8e4d2cb55b40@github.com>

On Tue, 3 Jan 2023 09:54:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
>> 
>> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jfx into feature/unbind
>  - 8243115: Unregister bindings when unbind called multiple times
>    
>    This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.

> ```diff
>     /**
>      * Start observing the dependencies for changes. If the value of one of the
>      * dependencies changes, the binding is marked as invalid.
>      *
>      * @param dependencies
>      *            the dependencies to observe
> +    * @throws NullPointerException when dependencies is null, or any of its elements was null
>      */
>     protected final void bind(Observable... dependencies) {
> -       if ((dependencies != null) && (dependencies.length > 0)) {
> +       if (dependencies.length > 0) {
>             if (observer == null) {
>                 observer = new BindingHelperObserver(this);
>             }
>             for (final Observable dep : dependencies) {
>                 dep.addListener(observer);
>             }
>         }
>     }
> ```

I would not recommend to make this change as it may break any existing app, even though the app is at wrong to pass `null` Or atleast not to make this change as part of this PR, we can discuss it separately under a new bug.

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

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

From jvos at openjdk.org  Fri Jan  6 09:54:00 2023
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 6 Jan 2023 09:54:00 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org [v2]
In-Reply-To: <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
 <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
Message-ID: <-F6cotDhaVisLrVLR11xIihYBq8UkSEq4T-EeP02b6Y=.2f299c3c-62e1-4b02-a7b4-8cac8c62dcb3@github.com>

On Thu, 5 Jan 2023 20:24:41 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Retrieve libav sources from github.
>> Fix JDK-8282386
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new naming convention when working with libav files downloaded via github

@jgneff since you're building from source on Linux often as well, can you check if this patch fixes the libav.org unavailability for you?

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

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

From jhendrikx at openjdk.org  Fri Jan  6 09:57:59 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 6 Jan 2023 09:57:59 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes [v2]
In-Reply-To: <rDuUvE3LLCFJx3e73InkrxF4A-PcxXZCI_7PhCbP2mE=.3beb517c-288c-441a-ac19-8e4d2cb55b40@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
 <rDuUvE3LLCFJx3e73InkrxF4A-PcxXZCI_7PhCbP2mE=.3beb517c-288c-441a-ac19-8e4d2cb55b40@github.com>
Message-ID: <wX8oaYavw8dOj4Xg45ZotsiRkAeWXHsKHp-8OggOxYU=.5ff60e47-a072-4547-8bab-72f09efb0ecc@github.com>

On Fri, 6 Jan 2023 09:34:18 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> I would not recommend to make this change as it may break any existing app, even though the app is at wrong to pass `null` Or atleast not to make this change as part of this PR, we can discuss it separately under a new bug.

No, definitely not part of this fix, I was just replying to Nir.

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

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

From duke at openjdk.org  Fri Jan  6 15:39:17 2023
From: duke at openjdk.org (Chengen Zhao)
Date: Fri, 6 Jan 2023 15:39:17 GMT
Subject: RFR: 8274771: Map,
 FlatMap and OrElse fluent bindings for ObservableValue [v18]
In-Reply-To: <ADAK5rRnHeDZxOErXrM47EVUiMRNLS_n8SAx0GWD80I=.59b34740-cf3d-4bcf-a253-17dd469945c6@github.com>
References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com>
 <Dm3_jMInS0KMUXvoEIjhnVi5VzCqkAS0KtYgzuqo1t4=.bcc5a4fc-0225-46a7-9ce8-b20333acb7e1@github.com>
 <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com>
 <jGH84LG1YI2DV9V0mjU2yYltT13K1WOi9o6-68ss4Tc=.fea94729-4858-483f-8ca0-deb35e6d5ee8@github.com>
 <mdR1vthEu2TUGxav8HvBkbsW11g_4fzZZvRHLBXYwXs=.86591214-3472-4a8d-ada0-c2c92332d59c@github.com>
 <ADAK5rRnHeDZxOErXrM47EVUiMRNLS_n8SAx0GWD80I=.59b34740-cf3d-4bcf-a253-17dd469945c6@github.com>
Message-ID: <ytkWd3JcUP2tXY96u1r0UkMS0upblSs7-7XTsKQsmwQ=.0a2b8da4-aef5-43b9-8bb2-9e168df26591@github.com>

On Fri, 8 Jul 2022 21:00:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> I've done some experimenting using a `Cleaner` suggested by @nlisker;
>>> [...]
>>> From what I can see, we'd need to change all locations where `bind` is implemented using a weak listener, and add a `Cleaner`. 
>> 
>> Yes, this must be implemented for all `*PropertyBase` classes. We can save a few bytes for non-`ConcurrentListenerAccess` observables with an implementation like this:
>> 
>> private static class Listener implements InvalidationListener, WeakListener {
>>     private final WeakReference<StringPropertyBase> wref;
>>     private final Cleaner.Cleanable cleanable;
>> 
>>     public Listener(StringPropertyBase ref, Observable observable) {
>>         this.wref = new WeakReference<>(ref);
>> 
>>         if (observable instanceof ConcurrentListenerAccess) {
>>             cleanable = CLEANER.register(ref, this::removeListener);
>>         } else {
>>             cleanable = null;
>>         }
>>     }
>> 
>>     // Note: dispose() must be called in StringPropertyBase.unbind()
>>     public void dispose() {
>>         if (cleanable != null) {
>>             cleanable.clean();
>>         } else {
>>             removeListener();
>>         }
>>     }
>> 
>>     private void removeListener() {
>>         StringPropertyBase ref = wref.get();
>>         if (ref != null) {
>>             ref.observable.removeListener(this);
>>         }
>>     }
>> 
>>     @Override
>>     public void invalidated(Observable observable) {
>>         StringPropertyBase ref = wref.get();
>>         if (ref == null) {
>>             dispose();
>>         } else {
>>             ref.markInvalid();
>>         }
>>     }
>> 
>>     @Override
>>     public boolean wasGarbageCollected() {
>>         return wref.get() == null;
>>     }
>> }
>> 
>> 
>> 
>>> Those same classes need their add/remove listener methods synchronized (putting synchronized on the static helper methods in ExpressionListener doesn't look like a good idea as it would block listener changes to unrelated properties).
>> 
>> Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe.
>> 
>> Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods.
>> 
>> But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully.
>> 
>> However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`:
>> 
>> private volatile ConcurrentExpressionHelper<T> helper = null;
>> 
>> @Override
>> public synchronized void addListener(InvalidationListener listener) {
>>     helper = ConcurrentExpressionHelper.addListener(helper, this, listener);
>> }
>> 
>> @Override
>> public synchronized void removeListener(InvalidationListener listener) {
>>     helper = ConcurrentExpressionHelper.removeListener(helper, listener);
>> }
>> 
>> @Override
>> public synchronized void addListener(ChangeListener<? super T> listener) {
>>     helper = ConcurrentExpressionHelper.addListener(helper, this, listener);
>> }
>> 
>> @Override
>> public synchronized void removeListener(ChangeListener<? super T> listener) {
>>     helper = ConcurrentExpressionHelper.removeListener(helper, listener);
>> }
>> 
>> protected void fireValueChangedEvent() {
>>     ConcurrentExpressionHelper.fireValueChangedEvent(helper);
>> }
>> 
>> 
>> This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners.
>> 
>> `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution.
>
>> Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe.
> 
> Yes, true, only making it thread-safe for that class should remove a chain of fluent bindings.  I think however that it would be good to implement this for as many classes as we can as the stub cleaning is normally only triggered on invalidation/changes (and as I recently discovered, when `ExpressionHelper` resizes its backing list).
> 
>> Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods.
> 
> Yes, true, I only fixed synchronization issues in my experiment and didn't look much further than that yet.
> 
>> But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully.
> 
> Yeah, we shouldn't do that, it synchronizes all accesses to all property lists everywhere, it would be an easy "fix" as it's in one place, but it doesn't feel right.
> 
>> However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`:
>> 
>> This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners.
> 
> I see you have been playing with improving `ExpressionHelper` as well :) I noticed there is a bug in the current one, where a copy of the list is made each time when `locked` is `true`, even when the list was already copied for the "current" lock.  I ran into this problem right after I fixed the performance issue (it wasn't obvious before as it was already very slow, but basically an extra copy is happening in some circumstances on top of the array copying that is done to remove an entry).
> 
> The situation where `locked` is true doesn't happen that often for normal code, but it happens specifically in the case when a call to `invalidated` is cleaning up dead stubs...
> 
>> `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution.
> 
> Yes, I think that's a good idea, I considered using `ConcurrentLinkedQueue` as well since we don't need a structure with index based access, but I couldn't find one with good O performance for `remove(T)` that wouldn't subtly change the current semantics.  FWIW, here's the quick `Collection` implementation I whipped up: https://gist.github.com/hjohn/8fee1e5d1a9eacbbb3e021f8a37f582b
> 
> And the changes in `ExpressionHelper` (including different locking): https://gist.github.com/hjohn/f88362ea78adef96f3a54d97e2405076

@hjohn 
Sorry to append message here, but I don't know other places where we could talk about this topic
Is it a good idea if Binding class provide method like this?
Inspired by this PR
![69A930A1704FF89F6DE3E7F50785D8C1](https://user-images.githubusercontent.com/5525436/211044723-bea9dd1c-e1dd-4acb-8975-0e1787aa45fd.jpg)

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

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

From angorya at openjdk.org  Fri Jan  6 16:50:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 6 Jan 2023 16:50:00 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly [v3]
In-Reply-To: <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <OpXmcMuRML5a-FVh05Dy2hC_bWVtaRZnJlZQA13x-ug=.7a73e976-a85b-464b-9985-c5347e6d7439@github.com>
Message-ID: <Tm8TdSPBBNwCs6tP-nYcdh273cYTJ_S4oWz2JKyFXVM=.60c680cd-1fae-4e81-8bf2-e6a4f334a168@github.com>

On Thu, 5 Jan 2023 09:49:41 GMT, Karthik P K <kpk at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   Update comments

see above

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

Changes requested by angorya (Committer).

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

From angorya at openjdk.org  Fri Jan  6 16:50:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 6 Jan 2023 16:50:00 GMT
Subject: RFR: 8178368: Right and Center alignment of text field works
 incorrectly
In-Reply-To: <MRgwrjIUs1XamCaztC5qJ9-_7CYP2iNm88jhvJlaaZY=.0574f715-0c7f-4aab-9e25-3e05c92a6487@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <MRgwrjIUs1XamCaztC5qJ9-_7CYP2iNm88jhvJlaaZY=.0574f715-0c7f-4aab-9e25-3e05c92a6487@github.com>
Message-ID: <a74N7CRzZyc1K6U0kXIsbZDNTipXHzuBrz7isn0zfJE=.30f9c4e8-bca2-4672-97cc-62bcf54e5e2c@github.com>

On Thu, 22 Dec 2022 10:33:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> 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.

You are right @aghaisas !
Small correction: the cursor operates correctly, the TextField just does not scroll the text so the caret remains visible.  Neither keyboard nor mouse operation (i.e. drag to select) auto-scroll the text.

For the mouse case:
- select long text
- select right or center alignment
- make the text field narrow
- click on the right end of text
- drag the mouse to the left to select
expected behavior is the text is scrolled to keep the caret always visible.

in the case of center alignment, the text does scroll when dragging to the right, but not to the left.

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

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

From tsayao at openjdk.org  Fri Jan  6 16:57:56 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 6 Jan 2023 16:57:56 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v13]
In-Reply-To: <4P1TS6iQqAY1YOFzXjZpvBXguZhDVj-nqRnZKXLH9mI=.ce173744-d459-4172-b68b-2b79cb59bdd4@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
 <4P1TS6iQqAY1YOFzXjZpvBXguZhDVj-nqRnZKXLH9mI=.ce173744-d459-4172-b68b-2b79cb59bdd4@github.com>
Message-ID: <eUjdCRHbT8cgkjlEk4vy3czoZoISNhZChVZlc8cHd1c=.26636559-7152-4c84-ad1d-87a6c73c264d@github.com>

On Fri, 6 Jan 2023 01:26:09 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
>> 
>> To do general testing:
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace g_warning
>  - Improvements

There are still some issues I've found testing:
- Closing the Application while dragging
- Drag begin sometimes doesn't set the cursor

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

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

From angorya at openjdk.org  Fri Jan  6 17:20:04 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 6 Jan 2023 17:20:04 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
Message-ID: <l8hB1i7h8ey0xOJO_XPXFT3rxGNjZuHhOsfG3BJ1aJE=.e80cf58b-ed12-4f56-8333-b331e42d4468@github.com>

On Thu, 5 Jan 2023 21:53:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - 8293119: removed debug printouts
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - width indicator in tester
>  - 2023
>  - 2023
>  - small delta
>  - whitespace
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e

I realized that, in presence of snapping and fractional scale, the implemented algorithm would never work correctly.  The reason is that the distance between snapped positions is not the same.  As a result, changing a single column width requires shifting of subsequent or all the columns, which in turn might require a change in their widths, and so on.

This makes me think that a different algorithm might be needed, a simulated annealing perhaps.

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

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

From jgneff at openjdk.org  Fri Jan  6 17:29:54 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Fri, 6 Jan 2023 17:29:54 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org [v2]
In-Reply-To: <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
 <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
Message-ID: <mT730UY8-1uHLYDnToR4cE4fJTsGQSQI5qa9CydcbYU=.06deb38d-34c1-4503-9460-0e38370f8fcf@github.com>

On Thu, 5 Jan 2023 20:24:41 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Retrieve libav sources from github.
>> Fix JDK-8282386
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new naming convention when working with libav files downloaded via github

The *Release* build and unit tests are now successful for me on Linux.

I ran the following commands on Ubuntu 20.04.5 LTS using the `8282386-libav` branch of `johanvos/jfx`, and both the build and unit tests were successful:


$ unset SOURCE_DATE_EPOCH
$ bash gradlew --no-daemon -PCONF=Release -PPROMOTED_BUILD_NUMBER=11 \
    -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx \
    -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true \
    sdk jmods javadoc test
  ...
BUILD SUCCESSFUL in 1h 11m 58s
228 actionable tasks: 228 executed


The build environment was set up by sourcing the following file:


#!/bin/bash
# Sets up the environment for building JavaFX
syspath=/usr/sbin:/usr/bin:/sbin:/bin

export CMAKE_HOME=$HOME/opt/cmake-3.25.1-linux-x86_64
export JAVA_HOME=$HOME/opt/jdk-19.0.1
export ANT_HOME=$HOME/opt/apache-ant-1.10.12

SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH

# JDK_HOME and PATH are required by the build
export JDK_HOME=$JAVA_HOME
export PATH=$ANT_HOME/bin:$JAVA_HOME/bin:$CMAKE_HOME/bin:$syspath

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

Marked as reviewed by jgneff (Committer).

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

From kcr at openjdk.org  Fri Jan  6 18:04:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Jan 2023 18:04:38 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <l8hB1i7h8ey0xOJO_XPXFT3rxGNjZuHhOsfG3BJ1aJE=.e80cf58b-ed12-4f56-8333-b331e42d4468@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <l8hB1i7h8ey0xOJO_XPXFT3rxGNjZuHhOsfG3BJ1aJE=.e80cf58b-ed12-4f56-8333-b331e42d4468@github.com>
Message-ID: <LS_tqw5UvgqZe2vNdsxtzDom8VfWWpLh1bPXzmSCvcg=.61a8c764-ad8f-402e-add4-451a65aa9584@github.com>

On Fri, 6 Jan 2023 17:17:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I realized that, in presence of snapping and fractional scale, the implemented algorithm would never work correctly. The reason is that the distance between snapped positions is not the same.

Can you file a follow-on bug so we don't lose track of it? It doesn't need to be fixed for JavaFX 20, but it would be good to fix it when we can.

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

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

From angorya at openjdk.org  Fri Jan  6 19:14:10 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 6 Jan 2023 19:14:10 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
Message-ID: <xxYqWmFJXCl5Gi94-8nfkr63ofDMSTb72t851_QdUCk=.70fec570-0829-4afb-a27e-9d0dd65b5269@github.com>

On Thu, 5 Jan 2023 21:53:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - 8293119: removed debug printouts
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - width indicator in tester
>  - 2023
>  - 2023
>  - small delta
>  - whitespace
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e

Logged two follow-up tickets:

[JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753) Tree/TableView: Column Resizing With Fractional Scale

[JDK-8299755](https://bugs.openjdk.org/browse/JDK-8299755) Tree/TableView: Cursor Decouples From Divider When Resizing With Fractional Scale

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

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

From jhendrikx at openjdk.org  Fri Jan  6 19:37:09 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 6 Jan 2023 19:37:09 GMT
Subject: RFR: 8274771: Map,
 FlatMap and OrElse fluent bindings for ObservableValue [v18]
In-Reply-To: <ADAK5rRnHeDZxOErXrM47EVUiMRNLS_n8SAx0GWD80I=.59b34740-cf3d-4bcf-a253-17dd469945c6@github.com>
References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com>
 <Dm3_jMInS0KMUXvoEIjhnVi5VzCqkAS0KtYgzuqo1t4=.bcc5a4fc-0225-46a7-9ce8-b20333acb7e1@github.com>
 <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com>
 <jGH84LG1YI2DV9V0mjU2yYltT13K1WOi9o6-68ss4Tc=.fea94729-4858-483f-8ca0-deb35e6d5ee8@github.com>
 <mdR1vthEu2TUGxav8HvBkbsW11g_4fzZZvRHLBXYwXs=.86591214-3472-4a8d-ada0-c2c92332d59c@github.com>
 <ADAK5rRnHeDZxOErXrM47EVUiMRNLS_n8SAx0GWD80I=.59b34740-cf3d-4bcf-a253-17dd469945c6@github.com>
Message-ID: <ADTwRxMB09Y-s_A790ah5vnpTjgLVMYcECpNLeOFzYw=.9603ac1f-daaf-4205-9aa2-5f9417aa44f7@github.com>

On Fri, 8 Jul 2022 21:00:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> I've done some experimenting using a `Cleaner` suggested by @nlisker;
>>> [...]
>>> From what I can see, we'd need to change all locations where `bind` is implemented using a weak listener, and add a `Cleaner`. 
>> 
>> Yes, this must be implemented for all `*PropertyBase` classes. We can save a few bytes for non-`ConcurrentListenerAccess` observables with an implementation like this:
>> 
>> private static class Listener implements InvalidationListener, WeakListener {
>>     private final WeakReference<StringPropertyBase> wref;
>>     private final Cleaner.Cleanable cleanable;
>> 
>>     public Listener(StringPropertyBase ref, Observable observable) {
>>         this.wref = new WeakReference<>(ref);
>> 
>>         if (observable instanceof ConcurrentListenerAccess) {
>>             cleanable = CLEANER.register(ref, this::removeListener);
>>         } else {
>>             cleanable = null;
>>         }
>>     }
>> 
>>     // Note: dispose() must be called in StringPropertyBase.unbind()
>>     public void dispose() {
>>         if (cleanable != null) {
>>             cleanable.clean();
>>         } else {
>>             removeListener();
>>         }
>>     }
>> 
>>     private void removeListener() {
>>         StringPropertyBase ref = wref.get();
>>         if (ref != null) {
>>             ref.observable.removeListener(this);
>>         }
>>     }
>> 
>>     @Override
>>     public void invalidated(Observable observable) {
>>         StringPropertyBase ref = wref.get();
>>         if (ref == null) {
>>             dispose();
>>         } else {
>>             ref.markInvalid();
>>         }
>>     }
>> 
>>     @Override
>>     public boolean wasGarbageCollected() {
>>         return wref.get() == null;
>>     }
>> }
>> 
>> 
>> 
>>> Those same classes need their add/remove listener methods synchronized (putting synchronized on the static helper methods in ExpressionListener doesn't look like a good idea as it would block listener changes to unrelated properties).
>> 
>> Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe.
>> 
>> Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods.
>> 
>> But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully.
>> 
>> However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`:
>> 
>> private volatile ConcurrentExpressionHelper<T> helper = null;
>> 
>> @Override
>> public synchronized void addListener(InvalidationListener listener) {
>>     helper = ConcurrentExpressionHelper.addListener(helper, this, listener);
>> }
>> 
>> @Override
>> public synchronized void removeListener(InvalidationListener listener) {
>>     helper = ConcurrentExpressionHelper.removeListener(helper, listener);
>> }
>> 
>> @Override
>> public synchronized void addListener(ChangeListener<? super T> listener) {
>>     helper = ConcurrentExpressionHelper.addListener(helper, this, listener);
>> }
>> 
>> @Override
>> public synchronized void removeListener(ChangeListener<? super T> listener) {
>>     helper = ConcurrentExpressionHelper.removeListener(helper, listener);
>> }
>> 
>> protected void fireValueChangedEvent() {
>>     ConcurrentExpressionHelper.fireValueChangedEvent(helper);
>> }
>> 
>> 
>> This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners.
>> 
>> `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution.
>
>> Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe.
> 
> Yes, true, only making it thread-safe for that class should remove a chain of fluent bindings.  I think however that it would be good to implement this for as many classes as we can as the stub cleaning is normally only triggered on invalidation/changes (and as I recently discovered, when `ExpressionHelper` resizes its backing list).
> 
>> Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods.
> 
> Yes, true, I only fixed synchronization issues in my experiment and didn't look much further than that yet.
> 
>> But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully.
> 
> Yeah, we shouldn't do that, it synchronizes all accesses to all property lists everywhere, it would be an easy "fix" as it's in one place, but it doesn't feel right.
> 
>> However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`:
>> 
>> This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners.
> 
> I see you have been playing with improving `ExpressionHelper` as well :) I noticed there is a bug in the current one, where a copy of the list is made each time when `locked` is `true`, even when the list was already copied for the "current" lock.  I ran into this problem right after I fixed the performance issue (it wasn't obvious before as it was already very slow, but basically an extra copy is happening in some circumstances on top of the array copying that is done to remove an entry).
> 
> The situation where `locked` is true doesn't happen that often for normal code, but it happens specifically in the case when a call to `invalidated` is cleaning up dead stubs...
> 
>> `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution.
> 
> Yes, I think that's a good idea, I considered using `ConcurrentLinkedQueue` as well since we don't need a structure with index based access, but I couldn't find one with good O performance for `remove(T)` that wouldn't subtly change the current semantics.  FWIW, here's the quick `Collection` implementation I whipped up: https://gist.github.com/hjohn/8fee1e5d1a9eacbbb3e021f8a37f582b
> 
> And the changes in `ExpressionHelper` (including different locking): https://gist.github.com/hjohn/f88362ea78adef96f3a54d97e2405076

> @hjohn Sorry to append message here, but I don't know other places where we could talk about this topic Is it a good idea if Binding class provide method like this? Inspired by this PR

@chengenzhao The only way to do this right now using the fluent bindings is like this:

    Rectangle rect = new Rectangle();

    rect.widthProperty()
      .flatMap(x -> rect.heightProperty())
      .map(y -> rect.getWidth() * rect.getHeight())
      .addListener((obs, old, a) -> System.out.println("Area = " + a));

It is not very pretty.

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

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

From kcr at openjdk.org  Sat Jan  7 00:33:04 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 7 Jan 2023 00:33:04 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
Message-ID: <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>

On Thu, 5 Jan 2023 21:53:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - 8293119: removed debug printouts
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - width indicator in tester
>  - 2023
>  - 2023
>  - small delta
>  - whitespace
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>  - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e

I did some additional testing, and other than the minor issues already identified with fractional screen scales (and tracked by follow-up bugs), everything looks good.

I left a few mostly minor comments inline. The only thing I'd definitely like to see is at least some testing of `TreeTableView`.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 36:

> 34:  * Helper class for constrained column resize policies.
> 35:  *
> 36:  * https://bugs.openjdk.org/browse/JDK-8293119

Minor: I don't see the need to put a pointer to the JBS bug here.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 146:

> 144:                 }
> 145:             }
> 146:         } while (needsAnotherPass);

I presume this won't get stuck in an infinite loop? I think it's fine, since the only time it will set `needsAnotherPass` is when it removes a column from consideration, and eventually, if all columns get removed, it will return anyway because `total` will be zero. So I think this is fine.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 310:

> 308:     protected boolean distributeDelta(int ix, double delta) {
> 309:         int ct = count - skip.cardinality();
> 310:         switch(ct) {

Minor: add space after `switch`

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 322:

> 320:             double adj;
> 321: 
> 322:             switch(mode) {

Minor: add space after `switch`

modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java line 49:

> 47:  *
> 48:  * TODO rename
> 49:  * TODO parallel class with TreeTableView, or as part of each test?

What is your plan to test `TreeTableView`?

modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java line 214:

> 212:      */
> 213:     //@Test // this test takes too much time!
> 214:     public void testWidthChange() {

Do you think testing a pseudo-random subset of the combinations would be interesting?

Loosely related to this, it might be useful follow-up test enhancement to add a generic `long.running.test` system property (or similar) that could be set when a `LONG_RUNNING_TEST` gradle property is set (similar to what we do for `unstable.test`). That way this, and other similarly exhaustive tests, could be run explicitly when desired.

tests/manual/tester/src/com/oracle/javafx/tester/ATableViewResizeTester.java line 63:

> 61:  * Tests TableView/JTable constrained column resize modes.
> 62:  */
> 63: public class ATableViewResizeTester extends Application {

Minor: Maybe drop the initial `A` and just call it `ATableViewResizeTester`? The "A" seems odd.

Suggestion: it would be useful to have a `TreeTableView` tester. I presume you have done at least some testing with `TreeTableView`?

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

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

From duke at openjdk.org  Sat Jan  7 02:46:12 2023
From: duke at openjdk.org (Chengen Zhao)
Date: Sat, 7 Jan 2023 02:46:12 GMT
Subject: RFR: 8274771: Map,
 FlatMap and OrElse fluent bindings for ObservableValue [v18]
In-Reply-To: <ADTwRxMB09Y-s_A790ah5vnpTjgLVMYcECpNLeOFzYw=.9603ac1f-daaf-4205-9aa2-5f9417aa44f7@github.com>
References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com>
 <Dm3_jMInS0KMUXvoEIjhnVi5VzCqkAS0KtYgzuqo1t4=.bcc5a4fc-0225-46a7-9ce8-b20333acb7e1@github.com>
 <-4ZjlSo1l7YrQ3m664vyYUaWebiNwcvj0KPefS2s6LU=.bec585fe-c45f-4f3d-8e1b-be8e0c589686@github.com>
 <jGH84LG1YI2DV9V0mjU2yYltT13K1WOi9o6-68ss4Tc=.fea94729-4858-483f-8ca0-deb35e6d5ee8@github.com>
 <mdR1vthEu2TUGxav8HvBkbsW11g_4fzZZvRHLBXYwXs=.86591214-3472-4a8d-ada0-c2c92332d59c@github.com>
 <ADAK5rRnHeDZxOErXrM47EVUiMRNLS_n8SAx0GWD80I=.59b34740-cf3d-4bcf-a253-17dd469945c6@github.com>
 <ADTwRxMB09Y-s_A790ah5vnpTjgLVMYcECpNLeOFzYw=.9603ac1f-daaf-4205-9aa2-5f9417aa44f7@github.com>
Message-ID: <hn3IvLIAiIo_xbbtACt3feObgp5-LqMJnoBPsmqt4I8=.d02bd7c7-3ba4-400f-911e-728825b02729@github.com>

On Fri, 6 Jan 2023 19:34:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> Not sure I'm following here. Do you want to implement this pattern for all property implementations? If we just want to implement it for mapped bindings, only the `LazyObjectBinding` class needs to be thread-safe.
>> 
>> Yes, true, only making it thread-safe for that class should remove a chain of fluent bindings.  I think however that it would be good to implement this for as many classes as we can as the stub cleaning is normally only triggered on invalidation/changes (and as I recently discovered, when `ExpressionHelper` resizes its backing list).
>> 
>>> Note that it's not enough for the `addListener` and `removeListener` methods to be `synchronized`. _All_ reads and writes must be protected, which (in the case of `LazyObjectBinding`) includes the `invalidate` and `isObserved` methods.
>> 
>> Yes, true, I only fixed synchronization issues in my experiment and didn't look much further than that yet.
>> 
>>> But if we do that, the lock tax must be paid on every single access to the `ExpressionHelper` field (because `ExpressionHelper` is not thread-safe). Locking any and all usages of `ExpressionHelper` can have performance implications that we need to evaluate carefully.
>> 
>> Yeah, we shouldn't do that, it synchronizes all accesses to all property lists everywhere, it would be an easy "fix" as it's in one place, but it doesn't feel right.
>> 
>>> However, I think we might get away with an implementation that only requires locking for the `addListener`/`removeListener` methods, but (crucially) not for `fireValueChangedEvent`:
>>> 
>>> This implementation works by creating immutable specializations of [ConcurrentExpressionHelper](https://gist.github.com/mstr2/1efc9e866f81622253711a963bd272fc). When a listener is added, a new `ConcurrentExpressionHelper` instance is created, which doesn't interfere with an existing instance that is currently in use by `ConcurrentExpressionHelper.fireValueChangedEvent`. The`ConcurrentExpressionHelper.Generic` specialization is mutable, but uses the lock-free `ConcurrentLinkedQueue` to store its listeners.
>> 
>> I see you have been playing with improving `ExpressionHelper` as well :) I noticed there is a bug in the current one, where a copy of the list is made each time when `locked` is `true`, even when the list was already copied for the "current" lock.  I ran into this problem right after I fixed the performance issue (it wasn't obvious before as it was already very slow, but basically an extra copy is happening in some circumstances on top of the array copying that is done to remove an entry).
>> 
>> The situation where `locked` is true doesn't happen that often for normal code, but it happens specifically in the case when a call to `invalidated` is cleaning up dead stubs...
>> 
>>> `ConcurrentExpressionHelper` avoids locking the (probably most frequently invoked) `fireValueChangedEvent` method, but sacrifices cache locality when a large number of listeners is added. We should probably benchmark all of these proposals before deciding on a solution.
>> 
>> Yes, I think that's a good idea, I considered using `ConcurrentLinkedQueue` as well since we don't need a structure with index based access, but I couldn't find one with good O performance for `remove(T)` that wouldn't subtly change the current semantics.  FWIW, here's the quick `Collection` implementation I whipped up: https://gist.github.com/hjohn/8fee1e5d1a9eacbbb3e021f8a37f582b
>> 
>> And the changes in `ExpressionHelper` (including different locking): https://gist.github.com/hjohn/f88362ea78adef96f3a54d97e2405076
>
>> @hjohn Sorry to append message here, but I don't know other places where we could talk about this topic Is it a good idea if Binding class provide method like this? Inspired by this PR
> 
> @chengenzhao The only way to do this right now using the fluent bindings is like this:
> 
>     Rectangle rect = new Rectangle();
> 
>     rect.widthProperty()
>       .flatMap(x -> rect.heightProperty())
>       .map(y -> rect.getWidth() * rect.getHeight())
>       .addListener((obs, old, a) -> System.out.println("Area = " + a));
> 
> It is not very pretty.

@hjohn 
Is it that what we really need here is a reduce function?
since we already have map(thanks to this PR) then we probably need a reduce function to zip those map products?
e.g.

textProperty.bind(Binding.reduce(widthProperty, heightProperty, (w, h) -> "Area is "+w.doubleValue()*h.doubleValue()));

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

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

From kcr at openjdk.org  Sat Jan  7 13:04:05 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 7 Jan 2023 13:04:05 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org [v2]
In-Reply-To: <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
 <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
Message-ID: <Pqs6UThFtzJF9I5cWYgVPtD0cVdnINQpLgLbYdUEI2U=.35834180-ae6b-4803-8c85-deddadc1d028@github.com>

On Thu, 5 Jan 2023 20:24:41 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Retrieve libav sources from github.
>> Fix JDK-8282386
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new naming convention when working with libav files downloaded via github

A local build and a CI build both pass now. This looks good.

@sashamatveev Do you also want to take a look at this?

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

Marked as reviewed by kcr (Lead).

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

From michaelstrau2 at gmail.com  Sat Jan  7 18:35:33 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 7 Jan 2023 19:35:33 +0100
Subject: Style themes API
Message-ID: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>

The following PR introduces new APIs to support style themes in JavaFX:
https://github.com/openjdk/jfx/pull/511

As Kevin already indicated, we need to finish the discussion on the
proposed API. I'd like to invite comments or suggestions with regards
to the API to hopefully get a bit of momentum for this feature to make
it into the 21 release.

Michael

From tsayao at openjdk.org  Mon Jan  9 00:55:11 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 9 Jan 2023 00:55:11 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v14]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <H3pOvdluqFWJPyZj3G4mi_cLbT6-W4jHhK-l6dnvZnE=.120686fa-a899-44e3-8363-90a3392850c8@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Adjustments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/42c9ae9c..08d05af8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=12-13

  Stats: 22 lines in 3 files changed: 9 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From arapte at openjdk.org  Mon Jan  9 05:07:02 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 9 Jan 2023 05:07:02 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes [v2]
In-Reply-To: <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
Message-ID: <AS7iaCTlw0Fv4Ix1pUHpZVfxVyijoAJk2qcnORfY2Qg=.861f0cb8-2716-4972-8c63-07772f6d14b2@github.com>

On Tue, 3 Jan 2023 09:54:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
>> 
>> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jfx into feature/unbind
>  - 8243115: Unregister bindings when unbind called multiple times
>    
>    This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.

LGTM

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

Marked as reviewed by arapte (Reviewer).

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

From mstrauss at openjdk.org  Mon Jan  9 05:32:01 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Jan 2023 05:32:01 GMT
Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding
 and other classes [v2]
In-Reply-To: <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
 <__YBB24n7xNFRWhFm50WYiFLIpQlD0wEjeNJloSSg38=.4f248ae5-58a6-4092-b93e-916ee10b3a03@github.com>
Message-ID: <IpUAd-jTlyC5AvkqnL1qaWQmX-P7UvL-oPsSEIA5Wq8=.8745c346-d101-495d-b0a3-bcefe71aa3d3@github.com>

On Tue, 3 Jan 2023 09:54:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
>> 
>> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jfx into feature/unbind
>  - 8243115: Unregister bindings when unbind called multiple times
>    
>    This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.

The patch looks good, and I can confirm that it fixes the bug.

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

Marked as reviewed by mstrauss (Committer).

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

From jhendrikx at openjdk.org  Mon Jan  9 14:53:14 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 9 Jan 2023 14:53:14 GMT
Subject: Integrated: 8243115: Spurious invalidations due to bug in
 IntegerBinding and other classes
In-Reply-To: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
References: <HhtPRBSA99iDFCyZZaOJCpfhKsHj0afV8blJUjh4mus=.545d447c-e342-4ac9-ac24-c96678172990@github.com>
Message-ID: <tDu1WWkO6wVxOPOJuq8Qv0xdgP4opU6p4jiuF7bJ0vg=.681a1625-4590-4fcd-b14c-953003bbf7e2@github.com>

On Mon, 27 Apr 2020 11:43:28 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
> 
> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.

This pull request has now been integrated.

Changeset: bca1bfc5
Author:    John Hendrikx <jhendrikx at openjdk.org>
Committer: Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bca1bfc5e3b04293c13417fd923d99864cdd9147
Stats:     206 lines in 9 files changed: 147 ins; 43 del; 16 mod

8243115: Spurious invalidations due to bug in IntegerBinding and other classes

Reviewed-by: arapte, mstrauss

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

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

From angorya at openjdk.org  Mon Jan  9 17:01:08 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 17:01:08 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
Message-ID: <lL0JMceVJPwhCubPjw73MC5uCOdEGp1jswImv-UduMo=.f2fa2fdd-5761-4728-9a81-023d10f8bb97@github.com>

On Fri, 6 Jan 2023 23:59:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - 8293119: removed debug printouts
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - width indicator in tester
>>  - 2023
>>  - 2023
>>  - small delta
>>  - whitespace
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 146:
> 
>> 144:                 }
>> 145:             }
>> 146:         } while (needsAnotherPass);
> 
> I presume this won't get stuck in an infinite loop? I think it's fine, since the only time it will set `needsAnotherPass` is when it removes a column from consideration, and eventually, if all columns get removed, it will return anyway because `total` will be zero. So I think this is fine.

you are right - this code always finishes.

> tests/manual/tester/src/com/oracle/javafx/tester/ATableViewResizeTester.java line 63:
> 
>> 61:  * Tests TableView/JTable constrained column resize modes.
>> 62:  */
>> 63: public class ATableViewResizeTester extends Application {
> 
> Minor: Maybe drop the initial `A` and just call it `TableViewResizeTester`? The "A" seems odd.
> 
> Suggestion: it would be useful to have a `TreeTableView` tester. I presume you have done at least some testing with `TreeTableView`?

With your permission, I'll keep it unchanged in this PR, but will make it a part of the monkey tester [JDK-8299335](https://bugs.openjdk.org/browse/JDK-8299335) later.

(it's already implemented in a temp repo, both TableView and TreeTableView:

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/pages/TableViewPage.java
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/pages/TreeTableViewPage.java

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

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

From kcr at openjdk.org  Mon Jan  9 17:17:04 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 17:17:04 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
Message-ID: <jcQE_hrQdDADEeAM4Er3JipI-bfZjNk3EoBQYB9YRe0=.fc45dda5-abcc-4a3d-aca9-dccba8848454@github.com>

On Fri, 6 Jan 2023 23:06:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - 8293119: removed debug printouts
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - width indicator in tester
>>  - 2023
>>  - 2023
>>  - small delta
>>  - whitespace
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java line 49:
> 
>> 47:  *
>> 48:  * TODO rename
>> 49:  * TODO parallel class with TreeTableView, or as part of each test?
> 
> What is your plan to test `TreeTableView`?

Unless I missed something, this is not yet resolved. We need automated tests of `TreeTableView` in addition to the automated tests of `TableView`.

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

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

From kcr at openjdk.org  Mon Jan  9 17:17:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 17:17:06 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <lL0JMceVJPwhCubPjw73MC5uCOdEGp1jswImv-UduMo=.f2fa2fdd-5761-4728-9a81-023d10f8bb97@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
 <lL0JMceVJPwhCubPjw73MC5uCOdEGp1jswImv-UduMo=.f2fa2fdd-5761-4728-9a81-023d10f8bb97@github.com>
Message-ID: <kOoy5EEdPbfJ-MBRoOVxjYVbR_bgAAb-9ZsR6OCE24Y=.68311a37-d6d6-4cb7-9105-6510c6fddded@github.com>

On Mon, 9 Jan 2023 16:56:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/manual/tester/src/com/oracle/javafx/tester/ATableViewResizeTester.java line 63:
>> 
>>> 61:  * Tests TableView/JTable constrained column resize modes.
>>> 62:  */
>>> 63: public class ATableViewResizeTester extends Application {
>> 
>> Minor: Maybe drop the initial `A` and just call it `TableViewResizeTester`? The "A" seems odd.
>> 
>> Suggestion: it would be useful to have a `TreeTableView` tester. I presume you have done at least some testing with `TreeTableView`?
>
> With your permission, I'll keep it unchanged in this PR, but will make it a part of the monkey tester [JDK-8299335](https://bugs.openjdk.org/browse/JDK-8299335) later.
> 
> (it's already implemented in a temp repo, both TableView and TreeTableView:
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/pages/TableViewPage.java
> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/pages/TreeTableViewPage.java

OK, this is fine then.

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

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

From angorya at openjdk.org  Mon Jan  9 17:39:14 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 17:39:14 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <jcQE_hrQdDADEeAM4Er3JipI-bfZjNk3EoBQYB9YRe0=.fc45dda5-abcc-4a3d-aca9-dccba8848454@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
 <jcQE_hrQdDADEeAM4Er3JipI-bfZjNk3EoBQYB9YRe0=.fc45dda5-abcc-4a3d-aca9-dccba8848454@github.com>
Message-ID: <tA02COOZTyHcWp_9xpnseU7gqyeKF7G8ieFaGZ67U2E=.99fb32a1-70c5-4e5e-a01b-21e196564546@github.com>

On Mon, 9 Jan 2023 17:14:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java line 49:
>> 
>>> 47:  *
>>> 48:  * TODO rename
>>> 49:  * TODO parallel class with TreeTableView, or as part of each test?
>> 
>> What is your plan to test `TreeTableView`?
>
> Unless I missed something, this is not yet resolved. We need automated tests of `TreeTableView` in addition to the automated tests of `TableView`.

have not pushed the code yet.  please stand by.

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

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

From kcr at openjdk.org  Mon Jan  9 17:47:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 17:47:09 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <yr608iky0DVIhw4SCb7_43WViZ_5V-x8VSDccDp2ioA=.b0bc8668-c5c8-4bb4-85f5-52a1c512e0a5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
 <EtO5Jo_Nx1Nu9UAk3Zx_fITKe1LgguyWvTUTd3GIvXg=.e8423055-c18e-4af7-bcc2-b95a390bfd40@github.com>
 <yr608iky0DVIhw4SCb7_43WViZ_5V-x8VSDccDp2ioA=.b0bc8668-c5c8-4bb4-85f5-52a1c512e0a5@github.com>
Message-ID: <74PeVJqCoFdBLnvuQgvmePGxuqt1WUzEuY0ONFRvkVw=.5cf14ca8-cdf9-4063-8af1-b8085793d18b@github.com>

On Thu, 5 Jan 2023 00:41:48 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Can you reproduce Kevin's observation at [1f66f61](https://github.com/openjdk/jfx/pull/789/commits/1f66f613ae3ba2ffc553d29424dd5b553d85978a)? If yes, which commit fixed it for you? For me it's the one that changed the order of the fields.

Btw, I can confirm that yes, this fixed it for me. Specifically, commit 55fe2dc7371f6dcb12c414c5d672728e47e9c504 has resolved my issue.

I'll re-review it now.

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

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

From kcr at openjdk.org  Mon Jan  9 17:47:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 17:47:11 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <H6uwiSCPLNfunLprQMOaYFAEGMq-NB0A3EGpZF8gxNU=.b58d8384-f251-46be-8ba9-987d474179eb@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

Btw, I am running this on an Intel UHD Graphics 630.

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

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

From angorya at openjdk.org  Mon Jan  9 17:55:53 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 17:55:53 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v32]
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <bf-e9vmt6xSVXUG4sgauQgYYXlhk52ENc2nqrlrO8rw=.826fd383-64c7-44be-acbb-5a385ffa5955@github.com>

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - 8293119: added tree table view tests
 - 8293119: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/897/files
  - new: https://git.openjdk.org/jfx/pull/897/files/795d196e..6a607f93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=31
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=30-31

  Stats: 887 lines in 5 files changed: 571 ins; 313 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/897.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897

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

From angorya at openjdk.org  Mon Jan  9 18:03:16 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 18:03:16 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
Message-ID: <vsu-hWtk7mOe-QH1pc17PsktJUQmokQAn1XMSoD8WVE=.ebe322d2-0e31-49ff-b71e-9dde4b9084c4@github.com>

On Fri, 6 Jan 2023 23:18:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - 8293119: removed debug printouts
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - width indicator in tester
>>  - 2023
>>  - 2023
>>  - small delta
>>  - whitespace
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - ... and 91 more: https://git.openjdk.org/jfx/compare/ca29cc61...795d196e
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java line 214:
> 
>> 212:      */
>> 213:     //@Test // this test takes too much time!
>> 214:     public void testWidthChange() {
> 
> Do you think testing a pseudo-random subset of the combinations would be interesting?
> 
> Loosely related to this, it might be useful follow-up test enhancement to add a generic `long.running.test` system property (or similar) that could be set when a `LONG_RUNNING_TEST` gradle property is set (similar to what we do for `unstable.test`). That way this, and other similarly exhaustive tests, could be run explicitly when desired.

Perhaps a combination of a number of typical tree/table configurations and a pseudo-random set could be added.  I would rather add it as a part of [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), since the new algorithm (simulated annealing) would have the constraint checks embedded in it on one hand, and on the other it would need a different set of tests, for example to verify that it converges.

A LONG_RUNNING_TEST is a good idea in general, I agree.  The problem with this particular test, and the reason why i did not pursue it, is that it does not finish in 40 minutes, which is way too long for a test.  I would like to think about it a bit longer, if I may.

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

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

From angorya at openjdk.org  Mon Jan  9 18:06:14 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 18:06:14 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <tA02COOZTyHcWp_9xpnseU7gqyeKF7G8ieFaGZ67U2E=.99fb32a1-70c5-4e5e-a01b-21e196564546@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
 <jcQE_hrQdDADEeAM4Er3JipI-bfZjNk3EoBQYB9YRe0=.fc45dda5-abcc-4a3d-aca9-dccba8848454@github.com>
 <tA02COOZTyHcWp_9xpnseU7gqyeKF7G8ieFaGZ67U2E=.99fb32a1-70c5-4e5e-a01b-21e196564546@github.com>
Message-ID: <73Os-j9dzwXMkV8Ku6QnrrEIrvH59CAUEFgwoFKro_M=.b9f474a6-f68e-41b3-9559-ee29b8e97874@github.com>

On Mon, 9 Jan 2023 17:36:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Unless I missed something, this is not yet resolved. We need automated tests of `TreeTableView` in addition to the automated tests of `TableView`.
>
> have not pushed the code yet.  please stand by.

also, sorry for my using 'Resolve Conversation' feature as a poor man to-do list.

Ideally, the 'Resolve Conversation' button in JIRA should be available to the originator of the comment, not to the owner of the PR.

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

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

From mstrauss at openjdk.org  Mon Jan  9 18:33:40 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Jan 2023 18:33:40 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v18]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <qMP5OXS48mZCPQ1mFF9gPQaOpSQwlbyLNvHn_gqsIEA=.41b65dcf-80db-4f82-ab65-484d15574c63@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the user-agent stylesheet of the application.
>      * <p>
>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>      * It can be used to provide default styling for UI controls and other nodes.
>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>      * <p>
>      * Before JavaFX 21, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>      * scene graph.
>      * <p>
>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. PlatformPreferences
> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface PlatformPreferences extends Map<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> 
>     void addListener(PlatformPreferencesListener listener);
>     void removeListener(PlatformPreferencesListener listener);
> }
> 
> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`.
> 
> Here's a list of the preferences available for Windows, as reported by the [SystemParametersInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow), [GetSysColor](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor) and [Windows.UI.ViewManagement.UISettings.GetColorValue](https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.getcolorvalue) APIs. Deprecated colors are not included.
> | Windows preferences                                  | Type    |
> |--------------------------------------|---------|
> | Windows.SPI.HighContrast             | Boolean |
> | Windows.SPI.HighContrastColorScheme  | String  |
> | Windows.SysColor.COLOR_3DFACE        | Color   |
> | Windows.SysColor.COLOR_BTNTEXT       | Color   |
> | Windows.SysColor.COLOR_GRAYTEXT      | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHT     | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHTTEXT | Color   |
> | Windows.SysColor.COLOR_HOTLIGHT      | Color   |
> | Windows.SysColor.COLOR_WINDOW        | Color   |
> | Windows.SysColor.COLOR_WINDOWTEXT    | Color   |
> | Windows.UIColor.Background           | Color   |
> | Windows.UIColor.Foreground           | Color   |
> | Windows.UIColor.AccentDark3          | Color   |
> | Windows.UIColor.AccentDark2          | Color   |
> | Windows.UIColor.AccentDark1          | Color   |
> | Windows.UIColor.Accent               | Color   |
> | Windows.UIColor.AccentLight1         | Color   |
> | Windows.UIColor.AccentLight2         | Color   |
> | Windows.UIColor.AccentLight3         | Color   |
> 
> Here is a list of macOS preferences as reported by `NSColor`'s [UI Element Colors](https://developer.apple.com/documentation/appkit/nscolor/ui_element_colors) and [Adaptable System Colors](https://developer.apple.com/documentation/appkit/nscolor/standard_colors). Deprecated colors are not included.
> | macOS preferences                                                      | Type    |
> |----------------------------------------------------------|---------|
> | macOS.NSColor.labelColor                                 | Color   |
> | macOS.NSColor.secondaryLabelColor                        | Color   |
> | macOS.NSColor.tertiaryLabelColor                         | Color   |
> | macOS.NSColor.quaternaryLabelColor                       | Color   |
> | macOS.NSColor.textColor                                  | Color   |
> | macOS.NSColor.placeholderTextColor                       | Color   |
> | macOS.NSColor.selectedTextColor                          | Color   |
> | macOS.NSColor.textBackgroundColor                        | Color   |
> | macOS.NSColor.selectedTextBackgroundColor                | Color   |
> | macOS.NSColor.keyboardFocusIndicatorColor                | Color   |
> | macOS.NSColor.unemphasizedSelectedTextColor              | Color   |
> | macOS.NSColor.unemphasizedSelectedTextBackgroundColor    | Color   |
> | macOS.NSColor.linkColor                                  | Color   |
> | macOS.NSColor.separatorColor                             | Color   |
> | macOS.NSColor.selectedContentBackgroundColor             | Color   |
> | macOS.NSColor.unemphasizedSelectedContentBackgroundColor | Color   |
> | macOS.NSColor.selectedMenuItemTextColor                  | Color   |
> | macOS.NSColor.gridColor                                  | Color   |
> | macOS.NSColor.headerTextColor                            | Color   |
> | macOS.NSColor.alternatingContentBackgroundColors         | Color[] |
> | macOS.NSColor.controlAccentColor                         | Color   |
> | macOS.NSColor.controlColor                               | Color   |
> | macOS.NSColor.controlBackgroundColor                     | Color   |
> | macOS.NSColor.controlTextColor                           | Color   |
> | macOS.NSColor.disabledControlTextColor                   | Color   |
> | macOS.NSColor.selectedControlColor                       | Color   |
> | macOS.NSColor.selectedControlTextColor                   | Color   |
> | macOS.NSColor.alternateSelectedControlTextColor          | Color   |
> | macOS.NSColor.currentControlTint                         | String  |
> | macOS.NSColor.windowBackgroundColor                      | Color   |
> | macOS.NSColor.windowFrameTextColor                       | Color   |
> | macOS.NSColor.underPageBackgroundColor                   | Color   |
> | macOS.NSColor.findHighlightColor                         | Color   |
> | macOS.NSColor.highlightColor                             | Color   |
> | macOS.NSColor.shadowColor                                | Color   |
> | macOS.NSColor.systemBlueColor                            | Color   |
> | macOS.NSColor.systemBrownColor                           | Color   |
> | macOS.NSColor.systemGrayColor                            | Color   |
> | macOS.NSColor.systemGreenColor                           | Color   |
> | macOS.NSColor.systemIndigoColor                          | Color   |
> | macOS.NSColor.systemOrangeColor                          | Color   |
> | macOS.NSColor.systemPinkColor                            | Color   |
> | macOS.NSColor.systemPurpleColor                          | Color   |
> | macOS.NSColor.systemRedColor                             | Color   |
> | macOS.NSColor.systemTealColor                            | Color   |
> | macOS.NSColor.systemYellowColor                          | Color   |
> 
> On Linux, GTK's theme name and [public CSS colors](https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-22/gtk/theme/Adwaita/_colors-public.scss) are reported:
> | Linux preferences                                                | Type    |
> |----------------------------------------------------|---------|
> | Linux.GTK.ThemeName                                | String  |
> | Linux.GTK.Colors.theme_fg_color                    | Color   |
> | Linux.GTK.Colors.theme_bg_color                    | Color   |
> | Linux.GTK.Colors.theme_base_color                  | Color   |
> | Linux.GTK.Colors.theme_selected_bg_color           | Color   |
> | Linux.GTK.Colors.theme_selected_fg_color           | Color   |
> | Linux.GTK.Colors.insensitive_bg_color              | Color   |
> | Linux.GTK.Colors.insensitive_fg_color              | Color   |
> | Linux.GTK.Colors.insensitive_base_color            | Color   |
> | Linux.GTK.Colors.theme_unfocused_fg_color          | Color   |
> | Linux.GTK.Colors.theme_unfocused_bg_color          | Color   |
> | Linux.GTK.Colors.theme_unfocused_base_color        | Color   |
> | Linux.GTK.Colors.theme_unfocused_selected_bg_color | Color   |
> | Linux.GTK.Colors.theme_unfocused_selected_fg_color | Color   |
> | Linux.GTK.Colors.borders                           | Color   |
> | Linux.GTK.Colors.unfocused_borders                 | Color   |
> | Linux.GTK.Colors.warning_color                     | Color   |
> | Linux.GTK.Colors.error_color                       | Color   |
> | Linux.GTK.Colors.success_color                     | Color   |
> 
> ### Built-in themes
> The two built-in themes `CaspianTheme` and `ModenaTheme` are exposed as public API in the `javafx.scene.control.theme` package. Both classes extend `ThemeBase`, which is a simple `StyleTheme` implementation that allows developers to easily extend the built-in themes.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:

 - Changed GTK preference keys
 - Platform.Preferences implements ObservableMap

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/1304d252..757f7ff5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=16-17

  Stats: 751 lines in 14 files changed: 275 ins; 399 del; 77 mod
  Patch: https://git.openjdk.org/jfx/pull/511.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511

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

From kcr at openjdk.org  Mon Jan  9 18:49:07 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 18:49:07 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <05HIpkRAw8AGXFzHImvgFuQU9bRepieUymMMOC1f42E=.99322829-49c8-4c8b-92f6-81d1a2a64329@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

To close the loop on the three problems I reported earlier:

> 1. The ambient light doesn't go back to black when an ambient light is added then removed.
> 2. Adding a second point light (or spot light) causes no lighting to be done, as if there were no lights
> 3. The magenta point light (and spot light) no longer works at all.

I can confirm that 1 and 2 are fixed, and 3 isn't an issue, but is just how the test app works (it behaves the same with or without this patch, and shows up fine when I animate the sphere).

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

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

From kcr at openjdk.org  Mon Jan  9 18:53:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 18:53:11 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <Hi6aD4EELd3OfYrGuvahdXln_zjoFJ_WZEiL87luttA=.c70fcfda-8c30-44e2-9160-46880c8fb0cb@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

Marked as reviewed by kcr (Lead).

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

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

From duke at openjdk.org  Mon Jan  9 20:24:14 2023
From: duke at openjdk.org (JoachimSchriek)
Date: Mon, 9 Jan 2023 20:24:14 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport
Message-ID: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>

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.

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

Commit messages:
 - Replaces Tabs with Spaces
 - JDK-8173321: Click on trough has no effect when cell height > viewport

Changes: https://git.openjdk.org/jfx/pull/985/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=985&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8173321
  Stats: 38 lines in 2 files changed: 19 ins; 7 del; 12 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 kcr at openjdk.org  Mon Jan  9 20:34:03 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 20:34:03 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport
In-Reply-To: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
References: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
Message-ID: <au0g14bk8bw77FdxvtIhMU0pi_7RvSE3UksAchrEjf4=.a84695e1-454f-402c-8fa2-dbbdfdff63db@github.com>

On Mon, 26 Dec 2022 19:08:55 GMT, JoachimSchriek <duke at openjdk.org> 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.

Can you provide a unit test that fails without the fix and passes with it?

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

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

From almatvee at openjdk.org  Mon Jan  9 21:05:06 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 9 Jan 2023 21:05:06 GMT
Subject: RFR: 8282386: JavaFX media stubs rely on libav.org [v2]
In-Reply-To: <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
 <Pudasl3Uoi9sSkLvuh6pejkkg7naN8AhqO2rsL_DSJY=.d8fa2354-aab4-44e7-9282-bf818330b0f9@github.com>
Message-ID: <MiFYEkuY6iP9a2OUoYQIIPwbFZz-YUej2A0HOdWkkLk=.72e23429-7aec-4e60-a218-d16662e9184f@github.com>

On Thu, 5 Jan 2023 20:24:41 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Retrieve libav sources from github.
>> Fix JDK-8282386
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new naming convention when working with libav files downloaded via github

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

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

From kcr at openjdk.org  Mon Jan  9 22:57:04 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 22:57:04 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v32]
In-Reply-To: <bf-e9vmt6xSVXUG4sgauQgYYXlhk52ENc2nqrlrO8rw=.826fd383-64c7-44be-acbb-5a385ffa5955@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <bf-e9vmt6xSVXUG4sgauQgYYXlhk52ENc2nqrlrO8rw=.826fd383-64c7-44be-acbb-5a385ffa5955@github.com>
Message-ID: <0plYSZVBgjH0zj5KsVho-HGXQfBMTmkhK4K_UOoQPQg=.fa52b263-f70b-4953-acc5-bc8ed557793e@github.com>

On Mon, 9 Jan 2023 17:55:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8293119: added tree table view tests
>  - 8293119: review comments

Looks good with one minor formatting comment inline. I'll reapprove if you fix it.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTestBase.java line 27:

> 25: 
> 26: package test.javafx.scene.control;
> 27: import static org.junit.Assert.assertTrue;

Minor: add blank like before this line (to separate it from `package` statement).

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.org  Mon Jan  9 22:57:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Jan 2023 22:57:06 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v31]
In-Reply-To: <vsu-hWtk7mOe-QH1pc17PsktJUQmokQAn1XMSoD8WVE=.ebe322d2-0e31-49ff-b71e-9dde4b9084c4@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <WhBbQdlHMUtFXnkpalyOLoX_i-EnJYC3GFwQI_LgdOk=.91daa672-679d-4197-8a8b-18731d7e4c4b@github.com>
 <BNZ2gy3LmQn8VBEc_OEx9g3QVMW9DfFMb2ruFuX6wc4=.6f0ae475-8641-4c6b-aeb0-232f16542f15@github.com>
 <vsu-hWtk7mOe-QH1pc17PsktJUQmokQAn1XMSoD8WVE=.ebe322d2-0e31-49ff-b71e-9dde4b9084c4@github.com>
Message-ID: <FTAFvulNhLjPzOSsPDwSgPQlIcHPu8tEu0YrDj7hPAw=.31daaf27-fe6a-4f9c-bbd0-375d8d763981@github.com>

On Mon, 9 Jan 2023 18:00:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTest.java line 214:
>> 
>>> 212:      */
>>> 213:     //@Test // this test takes too much time!
>>> 214:     public void testWidthChange() {
>> 
>> Do you think testing a pseudo-random subset of the combinations would be interesting?
>> 
>> Loosely related to this, it might be useful follow-up test enhancement to add a generic `long.running.test` system property (or similar) that could be set when a `LONG_RUNNING_TEST` gradle property is set (similar to what we do for `unstable.test`). That way this, and other similarly exhaustive tests, could be run explicitly when desired.
>
> Perhaps a combination of a number of typical tree/table configurations and a pseudo-random set could be added.  I would rather add it as a part of [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), since the new algorithm (simulated annealing) would have the constraint checks embedded in it on one hand, and on the other it would need a different set of tests, for example to verify that it converges.
> 
> A LONG_RUNNING_TEST is a good idea in general, I agree.  The problem with this particular test, and the reason why i did not pursue it, is that it does not finish in 40 minutes, which is way too long for a test.  I would like to think about it a bit longer, if I may.

Yes, I do think this needs additional thought / discussion (and definitely not for this release).

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

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

From angorya at openjdk.org  Mon Jan  9 23:08:02 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 23:08:02 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v33]
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <_1MqrljpVjQSs9bXHbhwBg_lc9fwf7l8xzxcWl-mkpM=.38b0e182-8b7f-4cce-877e-f7f8717d40f5@github.com>

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

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

  8293119: whitespace

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/897/files
  - new: https://git.openjdk.org/jfx/pull/897/files/6a607f93..01b526a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=32
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=31-32

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

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

From angorya at openjdk.org  Mon Jan  9 23:08:07 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Jan 2023 23:08:07 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v32]
In-Reply-To: <0plYSZVBgjH0zj5KsVho-HGXQfBMTmkhK4K_UOoQPQg=.fa52b263-f70b-4953-acc5-bc8ed557793e@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <bf-e9vmt6xSVXUG4sgauQgYYXlhk52ENc2nqrlrO8rw=.826fd383-64c7-44be-acbb-5a385ffa5955@github.com>
 <0plYSZVBgjH0zj5KsVho-HGXQfBMTmkhK4K_UOoQPQg=.fa52b263-f70b-4953-acc5-bc8ed557793e@github.com>
Message-ID: <7jUc4OpciUvt04bDKwh-BfW5cKQD47UUxELLIKKuFLw=.761e4c35-3639-4288-982f-7fdc6c71f247@github.com>

On Mon, 9 Jan 2023 22:49:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8293119: added tree table view tests
>>  - 8293119: review comments
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ResizeHelperTestBase.java line 27:
> 
>> 25: 
>> 26: package test.javafx.scene.control;
>> 27: import static org.junit.Assert.assertTrue;
> 
> Minor: add blank like before this line (to separate it from `package` statement).

done.

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

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

From kcr at openjdk.org  Tue Jan 10 00:44:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Jan 2023 00:44:58 GMT
Subject: RFR: 8299681: Change JavaFX release version to 21
Message-ID: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>

Bump the version number of JavaFX to 21. I will integrate this to `master` as part of forking the `jfx20` stabilization branch, which is scheduled for Thursday, January 12, 2023 at 16:00 UTC.

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

Commit messages:
 - 8299681: Change JavaFX release version to 21

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

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

From kcr at openjdk.org  Tue Jan 10 00:48:13 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Jan 2023 00:48:13 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v33]
In-Reply-To: <_1MqrljpVjQSs9bXHbhwBg_lc9fwf7l8xzxcWl-mkpM=.38b0e182-8b7f-4cce-877e-f7f8717d40f5@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <_1MqrljpVjQSs9bXHbhwBg_lc9fwf7l8xzxcWl-mkpM=.38b0e182-8b7f-4cce-877e-f7f8717d40f5@github.com>
Message-ID: <alyLxIfJh_wttK2DPeSPffbBY43yOgkuU4SWrbKaLiE=.977178dd-1472-4008-aaa8-2434a8ad9d9b@github.com>

On Mon, 9 Jan 2023 23:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293119: whitespace

Marked as reviewed by kcr (Lead).

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

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

From angorya at openjdk.org  Tue Jan 10 00:48:16 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 10 Jan 2023 00:48:16 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v23]
In-Reply-To: <3m8REERzjHwKCQd7lvGPqehYBDbx6x--Kc06L6l5PxA=.b38bc270-9e77-4521-ac98-fda0491b2e13@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <h13WFeQV4cVgmgu7g6fOXArmu2-9lycg_4YYVRimsu8=.07debdb3-1bc0-45bf-bd95-c9e675852eff@github.com>
 <3m8REERzjHwKCQd7lvGPqehYBDbx6x--Kc06L6l5PxA=.b38bc270-9e77-4521-ac98-fda0491b2e13@github.com>
Message-ID: <1Gd2eK0AToF1o_PElbg4RRGUdQk1djBtMe8ScwLjQis=.82de155e-9ee1-4170-9dca-becb74bcea54@github.com>

On Mon, 19 Dec 2022 13:08:29 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - 8293119: review comments
>>  - 8293119: abstract
>>  - 8293119: <p>
>>  - 8293119: review comments
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - 8293119: small delta
>>  - Merge remote-tracking branch 'origin/master' into 8293119.constrained
>>  - 8293119: pref
>>  - ... and 67 more: https://git.openjdk.org/jfx/compare/8763e8b0...8bdae30e
>
> This has baked well. I tested on macOS and it looks good.
> 
> I see warnings on command line while trying to run `ATableViewResizeTester.java`. While the first warning is expected, we should fix others.
> 
> -----------------------------------------------------------------
> `javafx/tester/ATableViewResizeTester.java:224: warning: [deprecation] CONSTRAINED_RESIZE_POLICY in TableView has been deprecated
>             return TableView.CONSTRAINED_RESIZE_POLICY;
>                             ^
> javafx/tester/ATableViewResizeTester.java:456: warning: [unchecked] unchecked cast
>             TableColumn<String,String> c = (TableColumn<String,String>)t.getColumns().remove(ix);
>                                                                                             ^
>   required: TableColumn<String,String>
>   found:    TableColumn<String,CAP#1>
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object from capture of ?
> javafx/tester/ATableViewResizeTester.java:467: warning: [unchecked] unchecked conversion
>         TableView<String> table = new TableView();
>                                   ^
>   required: TableView<String>
>   found:    TableView
> javafx/tester/ATableViewResizeTester.java:640: warning: [unchecked] unchecked conversion
>             List<? extends TableColumnBase<?,?>> visibleLeafColumns = rf.getTable().getVisibleLeafColumns();
>                                                                                                          ^
>   required: List<? extends TableColumnBase<?,?>>
>   found:    ObservableList
> javafx/tester/ATableViewResizeTester.java:646: warning: [unchecked] unchecked call to setColumnWidth(TableColumnBase<S,?>,double) as a member of the raw type ResizeFeaturesBase
>                 rf.setColumnWidth(c, w);
>                                  ^
>   where S is a type-variable:
>     S extends Object declared in class ResizeFeaturesBase
> 5 warnings
> `

@aghaisas could you take a final look at this please?

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

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

From jvos at openjdk.org  Tue Jan 10 09:44:57 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 10 Jan 2023 09:44:57 GMT
Subject: Integrated: 8282386: JavaFX media stubs rely on libav.org
In-Reply-To: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
References: <kxPfcZYE0hD0hJUSsA797vl6OpFycPCxUrhg__dk5Q0=.89be0846-6b2b-459e-afcc-8127d4226900@github.com>
Message-ID: <MyWuIyd-HqftwaoJhiM3gyZev1TBH7gRjxUrtpNnHT4=.2f9484a2-b0a4-4b26-8c2f-56b5485565a5@github.com>

On Thu, 5 Jan 2023 14:11:10 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Retrieve libav sources from github.
> Fix JDK-8282386

This pull request has now been integrated.

Changeset: 357cd856
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/357cd8563bd6ca47afd28dd1481afbe2d2458827
Stats:     21 lines in 2 files changed: 15 ins; 0 del; 6 mod

8282386: JavaFX media stubs rely on libav.org

Reviewed-by: jgneff, kcr, almatvee

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

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

From aghaisas at openjdk.org  Tue Jan 10 11:03:09 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 10 Jan 2023 11:03:09 GMT
Subject: RFR: 8293119: Additional constrained resize policies for
 Tree/TableView [v33]
In-Reply-To: <_1MqrljpVjQSs9bXHbhwBg_lc9fwf7l8xzxcWl-mkpM=.38b0e182-8b7f-4cce-877e-f7f8717d40f5@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
 <_1MqrljpVjQSs9bXHbhwBg_lc9fwf7l8xzxcWl-mkpM=.38b0e182-8b7f-4cce-877e-f7f8717d40f5@github.com>
Message-ID: <s_3NlAPLFbUtQoOVL-_9Px7p0khenflzAxzK35Xo63I=.f391505d-3b4b-49d4-8eb1-157c74341573@github.com>

On Mon, 9 Jan 2023 23:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
>> 
>> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
>> 
>> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
>> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
>> - add corresponding public static constants to Tree/TableView
>> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
>> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
>> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
>> - update javadoc
>> 
>> 
>> Notes
>> 
>> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
>> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293119: whitespace

I have tested on macOS. This looks good!

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

Marked as reviewed by aghaisas (Reviewer).

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

From arapte at openjdk.org  Tue Jan 10 14:28:13 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 10 Jan 2023 14:28:13 GMT
Subject: RFR: 8299681: Change JavaFX release version to 21
In-Reply-To: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>
References: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>
Message-ID: <qWDFwPyLLeVvtZx7qMz_AoBWQMvRxC1TV9EaKch5leU=.ddb47be4-8653-496a-b0e4-77387c828937@github.com>

On Tue, 10 Jan 2023 00:37:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump the version number of JavaFX to 21. I will integrate this to `master` as part of forking the `jfx20` stabilization branch, which is scheduled for Thursday, January 12, 2023 at 16:00 UTC.

Marked as reviewed by arapte (Reviewer).

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

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

From arapte at openjdk.org  Tue Jan 10 14:43:12 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 10 Jan 2023 14:43:12 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <B_iMXMdt_4ugKO789qM4VZosAcf0nwRW2oeVVaOUg_U=.61a22dea-a7b7-4586-bc77-ca7ed54d158a@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

LGTM

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

Marked as reviewed by arapte (Reviewer).

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

From nlisker at openjdk.org  Tue Jan 10 14:50:22 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 10 Jan 2023 14:50:22 GMT
Subject: Integrated: 8217853: Cleanup in the D3D native pipeline
In-Reply-To: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
Message-ID: <DxSYRf7tSdL3e6l8267ZepvQ6XGVNUZkuezuLIhDV3Q=.5948f04a-dd47-4e13-b6c3-86f16bc2bc68@github.com>

On Mon, 2 May 2022 16:05:08 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
> 
> Since there are many small changes, I'm giving a full list here:
> 
> **Java**
> 
> * `NGShape3D.java`
>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>   * Normalized the direction here instead of in the native code.
>   * Ambient light is now only set when it exists (and is not black).
> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
> 
> **Native C++**
> 
> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
> * `D3DLight`
>   * Commented out unused methods. Were they supposed to be used at some point?
>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
> * `D3DPhongShader.h`
>   * Renamed some of the register constants for more clarity.
>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
> * `D3DMeshView.cc`
>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
> 
> **Native shaders**
> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
> * `vsConstants`
>   * Removed the light color from here since it's unused, only the position is.
>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
> * `vs2ps`
>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
> * `Mtl1PS` and `psMath`
>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
> 
> No changes in performance were measured and the behavior stayed the same.

This pull request has now been integrated.

Changeset: 4a278013
Author:    Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4a2780134b88e86e437ae2bdffe06b145788e61d
Stats:     685 lines in 22 files changed: 232 ins; 227 del; 226 mod

8217853: Cleanup in the D3D native pipeline

Reviewed-by: arapte, kcr

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

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

From angorya at openjdk.org  Tue Jan 10 16:38:05 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 10 Jan 2023 16:38:05 GMT
Subject: Integrated: 8293119: Additional constrained resize policies for
 Tree/TableView
In-Reply-To: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
References: <mqqilGqcHibFFcsH8GmEH8qzA0kYdvcZaCU0CpvI2CM=.2fd5c6b4-e43b-4000-b194-e4d1cea974e8@github.com>
Message-ID: <jSC3qsTj-zRd2jav75SLpZHvcWkPKWzGseVpVDkS8Kw=.80b2469f-6194-4b02-a772-1743bffbfc87@github.com>

On Mon, 12 Sep 2022 21:58:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810).
> 
> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically:
> 
> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class
> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS
> - add corresponding public static constants to Tree/TableView
> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss)
> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double width) methods to ResizeFeatureBase
> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase
> - update javadoc
> 
> 
> Notes
> 
> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value.
> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value.

This pull request has now been integrated.

Changeset: 1ac97fc5
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1ac97fc566591e413d67bc7230ea0b351271d7a8
Stats:     2629 lines in 16 files changed: 2388 ins; 226 del; 15 mod

8293119: Additional constrained resize policies for Tree/TableView

Reviewed-by: aghaisas, kcr

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

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

From angorya at openjdk.org  Tue Jan 10 16:43:10 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 10 Jan 2023 16:43:10 GMT
Subject: RFR: 8299681: Change JavaFX release version to 21
In-Reply-To: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>
References: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>
Message-ID: <KpKD4o-PSHynuvAjbhslRXAFobSeyc23cBufAfLFV08=.434bb267-7bbf-41a7-b972-3909172767b8@github.com>

On Tue, 10 Jan 2023 00:37:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump the version number of JavaFX to 21. I will integrate this to `master` as part of forking the `jfx20` stabilization branch, which is scheduled for Thursday, January 12, 2023 at 16:00 UTC.

checked against the older PR https://github.com/openjdk/jfx/pull/820/files

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

Marked as reviewed by angorya (Committer).

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

From jgneff at openjdk.org  Tue Jan 10 18:30:48 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 10 Jan 2023 18:30:48 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v9]
In-Reply-To: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
Message-ID: <KkAdILxBq_dDOOoiBSMN_xPWfH7v01vMkvP1DlPLhQY=.69d1494b-83b1-4220-aa74-a162157743d9@github.com>

> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
> 
> 
> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
> $ bash gradlew sdk jmods javadoc
> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
> 
> 
> The three commands:
> 
> 1. set the build timestamp to the date of the latest source code change,
> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
> 3. recreate the JMOD files with stable file modification times and ordering.
> 
> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
> 
> #### Fixes
> 
> There are at least four sources of non-determinism in the JavaFX builds:
> 
> 1. Build timestamp
> 
>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
> 
> 2. Modification times
> 
>     The JAR, JMOD, and ZIP archives store the modification time of each file.
> 
> 3. File ordering
> 
>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
> 
> 4. Build path
> 
>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
> 
> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
> 
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism

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

 - Merge branch 'master' into allow-reproducible-builds
 - Add '--date' argument for deterministic JMOD files
 - Merge branch 'master' into allow-reproducible-builds
 - Merge branch 'master' into allow-reproducible-builds
 - Comment out 'jmod --date' until building on JDK 19
   
   Support for the 'jmod --date' option was added to JDK 19 starting
   with the 19+2 early-access build, and it was backported to JDK 17
   starting with release 17.0.3. It is not available in JDK 18.
 - Merge 'master' into allow-reproducible-builds
 - Make minimal changes for new '--date' option
 - Add new '--date' option to JMOD task
 - Add '--source-date' option to JMOD task
 - Get build timestamp in UTC and set ZIP timestamps
   
   Create the build timestamp as a zoned date and time in UTC instead
   of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
   last modification time of ZIP and JAR entries to the local date and
   time in UTC of the instant defined by SOURCE_DATE_EPOCH.
   
   Add a comment as a reminder to make JMOD files deterministic when
   the following enhancements are complete:
   
   * Enable deterministic file content ordering for Jar and Jmod
     https://bugs.openjdk.java.net/browse/JDK-8276764
     https://github.com/openjdk/jdk/pull/6395
   
   * Enable jar and jmod to produce deterministic timestamped content
     https://bugs.openjdk.java.net/browse/JDK-8276766
     https://github.com/openjdk/jdk/pull/6481
 - ... and 8 more: https://git.openjdk.org/jfx/compare/4a278013...0a3dda22

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

Changes: https://git.openjdk.org/jfx/pull/446/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=446&range=08
  Stats: 145 lines in 7 files changed: 115 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/446.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/446/head:pull/446

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

From jgneff at openjdk.org  Tue Jan 10 18:30:54 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Tue, 10 Jan 2023 18:30:54 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
Message-ID: <VTmod1fcL0qPnPA3BR9L_gG17dMNwNhN87Jho0aL7uE=.35ed1549-29cd-40a4-90e7-75c20af402db@github.com>

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
>> 
>> 
>> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
>> $ bash gradlew sdk jmods javadoc
>> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
>> 
>> 
>> The three commands:
>> 
>> 1. set the build timestamp to the date of the latest source code change,
>> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
>> 3. recreate the JMOD files with stable file modification times and ordering.
>> 
>> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
>> 
>> #### Fixes
>> 
>> There are at least four sources of non-determinism in the JavaFX builds:
>> 
>> 1. Build timestamp
>> 
>>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
>> 
>> 2. Modification times
>> 
>>     The JAR, JMOD, and ZIP archives store the modification time of each file.
>> 
>> 3. File ordering
>> 
>>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
>> 
>> 4. Build path
>> 
>>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
>> 
>> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
>> 
>> [1]: https://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add '--date' argument for deterministic JMOD files
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Comment out 'jmod --date' until building on JDK 19
>    
>    Support for the 'jmod --date' option was added to JDK 19 starting
>    with the 19+2 early-access build, and it was backported to JDK 17
>    starting with release 17.0.3. It is not available in JDK 18.
>  - Merge 'master' into allow-reproducible-builds
>  - Make minimal changes for new '--date' option
>  - Add new '--date' option to JMOD task
>  - Add '--source-date' option to JMOD task
>  - Get build timestamp in UTC and set ZIP timestamps
>    
>    Create the build timestamp as a zoned date and time in UTC instead
>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>    last modification time of ZIP and JAR entries to the local date and
>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>    
>    Add a comment as a reminder to make JMOD files deterministic when
>    the following enhancements are complete:
>    
>    * Enable deterministic file content ordering for Jar and Jmod
>      https://bugs.openjdk.java.net/browse/JDK-8276764
>      https://github.com/openjdk/jdk/pull/6395
>    
>    * Enable jar and jmod to produce deterministic timestamped content
>      https://bugs.openjdk.java.net/browse/JDK-8276766
>      https://github.com/openjdk/jdk/pull/6481
>  - Merge branch 'master' into allow-reproducible-builds
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b

I tested the Linux "Release" build again now that pull request #989 is integrated. The updated results are shown below:

| System  | Develop | Actions | Release | Notes                        |
|:-------:|:-------:|:-------:|:-------:| ---------------------------- |
| Linux   |    ?    |    ?    |    ?    |                              |
| macOS   |    ?    |    ?    |    ?    | Some shared libraries differ |
| Windows |    ?    |    ?    |    ?    | Release build failed         |

where ?, ?, and ? have the meanings described earlier. I'll test the Windows "Release" build next to see whether it's still failing, and I'll update this comment directly if there are any changes.

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

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

From mstrauss at openjdk.org  Tue Jan 10 18:42:09 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Jan 2023 18:42:09 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v2]
In-Reply-To: <xGtY64jODQMpLVd0Jts1bPy_XEP6XnNHPZm2_uWI8Gs=.d0dacc8f-680b-47cb-9d80-cf95236de46a@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
 <fZciZ2o5RUjYyAYUk4HFGOqPCs7b2QhKlKsZdKhidNM=.f64b108c-4935-4d98-92b1-8561e6d65f4b@github.com>
 <ly5MlmTOQA0if2SIcSpa-U92pRYUb8NwwORzZzmyTjA=.216e0060-492e-4300-8db7-50b62d81af89@github.com>
 <xGtY64jODQMpLVd0Jts1bPy_XEP6XnNHPZm2_uWI8Gs=.d0dacc8f-680b-47cb-9d80-cf95236de46a@github.com>
Message-ID: <9cX0GZVxUyrJ689nlKRXA6dFz_6g9li0zBUR3YtR6QE=.cd81e55c-fb65-482a-ba3a-33a689c859b9@github.com>

On Fri, 11 Nov 2022 01:11:36 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/PlatformPreferences.java line 117:
>> 
>>> 115:  * @since 20
>>> 116:  */
>>> 117: public interface PlatformPreferences extends Map<String, Object> {
>> 
>> Are you sure it is a good idea to expose these as a `Map`?  It seems to me that this isn't that good a practice any more to have classes implement or extend lists/maps/sets as they pull in a huge amount of API surface that is mostly useless or too general for the class's purpose.
>> 
>> The addition of the listener management methods also has me wondering, as `ObservableMap` does something similar.
>
> All of the mutating methods are useless, since the implementation always returns a read-only map. However, the alternative would be to duplicate APIs to enumerate and inspect the contents of the `PlatformPreferences` map (applications might want to show a list of available preferences). I'm not sure that's preferable, mostly because `PlatformPreferences` _does_ represent a mapping of keys to values.
> 
> It's true that listener management makes it look like an `ObservableMap`. The difference is that `ObservableMap` doesn't support batch change notifications, which the current implementation relies on to minimize the number of style theme resets. Of course, that could be solved in a different way.

> The addition of the listener management methods also has me wondering, as `ObservableMap` does something similar.

I've switched to using `ObservableMap`.

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

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

From mstrauss at openjdk.org  Tue Jan 10 21:08:23 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Jan 2023 21:08:23 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
Message-ID: <LGLGGmmiTlztS1DNwgz3w0-pecDvpA4S6O-96O2n0Cw=.98f996ba-6fec-4f7e-819b-c710b620dd40@github.com>

On Fri, 19 Aug 2022 10:40:01 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> Florian Kirmaier 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 remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>  - JDK-8277848
>    Added tests to ensure no premature garbage collection is happening.
>  - JDK-8277848
>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>  - JDK-8277848
>    Added the 3 requests whitespaces
>  - JDK-8277848
>    Further optimization based code review.
>    This Bugfix should now event improve the performance
>  - JDK-8277848
>    Added missing change
>  - JDK-8277848
>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

The patch looks good and fixes the bug.

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

Marked as reviewed by mstrauss (Committer).

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

From nlisker at openjdk.org  Tue Jan 10 22:46:32 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 10 Jan 2023 22:46:32 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <RuPfV_O91aKYV_gyu6WkCZ67cDmJmKK4AF0FNV-1HaU=.783be47c-c42e-4e70-8380-5b45fb59101e@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

> Btw, I can confirm that yes, this fixed it for me. Specifically, commit [55fe2dc](https://github.com/openjdk/jfx/commit/55fe2dc7371f6dcb12c414c5d672728e47e9c504) has resolved my issue.

If you have time, it would be interesting check if it breaks for you by changing the order of the semantics. It might be worth adding a comment there because it's a rather surprising side effect.

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

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

From john at status6.com  Tue Jan 10 23:31:11 2023
From: john at status6.com (John Neffenger)
Date: Tue, 10 Jan 2023 15:31:11 -0800
Subject: Windows build fails at MediaCapabilities.cpp(323): error C2327
In-Reply-To: <c5073481-9483-5320-d056-a68854f6d65f@status6.com>
References: <c5073481-9483-5320-d056-a68854f6d65f@status6.com>
Message-ID: <f56edd6d-1391-d4ec-4a07-6b99c023251b@status6.com>

> modules\javafx.web\src\main\native\Source\WebCore\Modules/mediacapabilities/MediaCapabilities.cpp(323): error C2327: 'WebCore::MediaCapabilities::m_encodingTasks': is not a type name, static, or enumerator

Looking into it a bit more, it looks as if the compiler is failing to 
pick up the 'MediaCapabilities.h' header file that defines 
'm_encodingTasks', shown below:

MediaCapabilities.h
https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilities.h

In the build messages, the error occurs right after:

----------------------------
 > Task :web:compileNativeWin
Current settings: Configuration:Release Arch:x86_64
+  cmake --build 
C:/cygwin64/home/john/src/jfx/modules/javafx.web/build/win/Release 
--config Release --
----------------------------

The messages show the compiler invocation as:

----------------------------
C:\PROGRA~1\MICROS~1\2022\COMMUN~1\VC\Tools\MSVC\1434~1.319\bin\Hostx64\x64\cl.exe
...
-IC:\cygwin64\home\john\src\jfx\modules\javafx.web\src\main\native\Source\WebCore\Modules\mediacapabilities
...
-c 
C:\cygwin64\home\john\src\jfx\modules\javafx.web\build\win\Release\WebCore\DerivedSources\unified-sources\UnifiedSource-4babe430-14.cpp
----------------------------

It's as if the compiler is not picking up the '-I' option to include the 
header files in the 'mediacapabilities' directory.

Unfortunately, I don't have the log files from an earlier working build 
to see what's different.

John


From rmarchenko at openjdk.org  Wed Jan 11 07:39:24 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 07:39:24 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore
Message-ID: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>

There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 

GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.

Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

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

Commit messages:
 - Fixed the opacity issue

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

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

From rmarchenko at openjdk.org  Wed Jan 11 07:50:39 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 07:50:39 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
Message-ID: <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>

> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
> 
> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
> 
> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Fixed the opacity issue

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

Changes: https://git.openjdk.org/jfx/pull/992/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=992&range=01
  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/992.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/992/head:pull/992

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

From rmarchenko at openjdk.org  Wed Jan 11 07:52:21 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 07:52:21 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore
In-Reply-To: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
Message-ID: <wQPPoVBc0KfMZi9XcH1Z1VeuhOPT9cvjGub0Owa0KRA=.eb8b89ac-26e7-461f-ba6a-46a7bc52c080@github.com>

On Wed, 11 Jan 2023 07:32:20 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
> 
> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
> 
> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

force-pushed to trigger the tests.

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

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

From fkirmaier at openjdk.org  Wed Jan 11 09:22:07 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 11 Jan 2023 09:22:07 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v4]
In-Reply-To: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
Message-ID: <SjOgdrDoqwEhzjGMH24fs0Q09LUeJPugu14nXb7gSk0=.c2df3a10-0298-485c-be86-3f498295e82e@github.com>

> This PR fixes the leak in the mac system menu bar.
> 
> Inside the native code, NewGlobalRef is called for the callable.
> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
> 
> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
> 
> The unit test verifies, that this bug happened without this change, but no longer happens with this change.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8299423
  Added null check before using the callback

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/987/files
  - new: https://git.openjdk.org/jfx/pull/987/files/61127b2e..d1e26d47

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

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

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

From fkirmaier at openjdk.org  Wed Jan 11 09:24:26 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 11 Jan 2023 09:24:26 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v3]
In-Reply-To: <3bCv9KXVk2oBwrKG2eZDIV5G5Pxk01CSMhPOopuN50w=.321e78e5-1542-46ed-ac5d-0c7c07929de9@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <9mG38YEJl4bw3a3O6JBXwHVbzRUKKzcGpWNdwQ5g3s4=.592e37bc-982d-4f97-a640-62da8b47c7bd@github.com>
 <huJ8STJNJLeLhxsMjSe2b7sRXpsrzLfJqXDV-52rpcg=.a753d4b2-b4b6-41db-b09f-b3eb5e132725@github.com>
 <3bCv9KXVk2oBwrKG2eZDIV5G5Pxk01CSMhPOopuN50w=.321e78e5-1542-46ed-ac5d-0c7c07929de9@github.com>
Message-ID: <wYtwa0X9pqFGkGJ7cowHUBmhd7F3X4de_Xhes2IaGVI=.2d23b012-4830-4b82-b5fb-5ef10154f287@github.com>

On Thu, 5 Jan 2023 16:15:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I've tested this version with explicit GC, and it still worked. So i guess it's stable.
>> 
>> Ok, so now there are multiple Solutions:
>> 
>> 1. Revert to the previous version, and remove the WeakReference again.
>> 2. Add an explicit reference to the Callable in the MacMenuDelegate. This would make proof reading much easier.
>> 3. Keep it as is.
>> 
>> I guess I would prefer 2. Would that be ok for everyone?
>> 
>> @mstr2 
>> I guess this would have to be done in this method:
>> 
>> 
>> - (void)action:(id)sender
>> {
>>     if (self->jCallback != NULL)
>>     {
>>         GET_MAIN_JENV;
>>         if (env != NULL)
>>         {
>>             (*env)->CallVoidMethod(env, self->jCallback, jMenuActionMethod, NULL);
>>         }
>>     }
>> }
>> 
>> Do you have an example, of how this should look like? I'm neither familiar with C, Objective-C, or this JNI code.
>
>> I've tested this version with explicit GC, and it still worked. So i guess it's stable.
>> 
>> Ok, so now there are multiple Solutions:
>> 
>> 1. Revert to the previous version, and remove the WeakReference again.
>> 2. Add an explicit reference to the Callable in the MacMenuDelegate. This would make proof reading much easier.
>> 3. Keep it as is.
>> 
>> I guess I would prefer 2. Would that be ok for everyone?
>> 
>> @mstr2 I guess this would have to be done in this method:
>> 
>> ```
>> 
>> - (void)action:(id)sender
>> {
>>     if (self->jCallback != NULL)
>>     {
>>         GET_MAIN_JENV;
>>         if (env != NULL)
>>         {
>>             (*env)->CallVoidMethod(env, self->jCallback, jMenuActionMethod, NULL);
>>         }
>>     }
>> }
>> ```
>> 
>> Do you have an example, of how this should look like? I'm neither familiar with C, Objective-C, or this JNI code.
> 
> The `action` method would look something like this:
> ```objective-c
> - (void)action:(id)sender
> {
>     GET_MAIN_JENV;
>     if (env != NULL) {
>         jobject jCallback = (*env)->NewLocalRef(env, self->jCallback);
>         if (jCallback != NULL) {
>             (*env)->CallVoidMethod(env, jCallback, jMenuActionMethod, NULL);
>             (*env)->DeleteLocalRef(env, jCallback);
>         }
>     }
> }
> 
> 
> I've found another use of `jCallback` in `validateMenuItem`.

@mstr2
I've added the suggested nullcheck to the 2 places!

Adding a hard reference to the callback, in the MacMenuDelegate doesn't work without reverting to my original change, which was way more complicated. So I left this part.

As mentioned, I've tested this code with regularly forced "System.gc" and didn't find any issues.

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

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

From jhendrikx at openjdk.org  Wed Jan 11 11:13:34 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 11 Jan 2023 11:13:34 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
Message-ID: <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>

On Fri, 19 Aug 2022 10:40:01 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> Florian Kirmaier 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 remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>  - JDK-8277848
>    Added tests to ensure no premature garbage collection is happening.
>  - JDK-8277848
>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>  - JDK-8277848
>    Added the 3 requests whitespaces
>  - JDK-8277848
>    Further optimization based code review.
>    This Bugfix should now event improve the performance
>  - JDK-8277848
>    Added missing change
>  - JDK-8277848
>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

My question is the following. Isn't this expected behavior?

Let's say I have this program:

     X x = new X();
     ObjectProperty<X> a = new SimpleObjectProperty<>(x);
     ObjectProperty<X> b = new SimpleObjectProperty<>();

     b.bind(a);   // b takes on the value of a (x)
     b.unbind(); // b keeps last value (x)

     a = null;
     x = null;

Should I expect `x` here to be unreferenced? No, that's how properties work, `b` will keep its reference to `x`.

Now replace the above program with `X` being an `ObservableList` and the `ObjectProperty`s being `ListProperty`s.  Should the expected behavior change?

I think there is a far more fundamental issue with how `ListProperty`s behave that's poorly defined and documented.  While investigating, I found the main culprit to the `bind`/`unbind` test (`testBindingLeak`) to be the copy that is made in the `unbind` method:

    @Override
    public void unbind() {
        if (observable != null) {
            value = observable.getValue();   // <<< cause of "memory leak"
            observable.removeListener(listener);
            observable = null;
        }
    }

That line makes total sense from a property perspective; when a property is unbound, it copies the value of its source as the last known value.  Should this perhaps make a deep copy?  Perhaps it should, but these properties are so poorly defined that it is anyone's guess at what it should be doing here.

IMHO there is a conflict between the property like behavior of `ListProperty` and the list like behavior of the `ObservableList` that it wraps.  On the one hand, a list property is a reference to a list, and on the other hand we expect it to behave as only referring to the contents of the list.  The property like behavior that it inherits (perhaps it shouldn't have done that) has been subverted in that adding a change listener will pretend that a change to the list is the same as replacing the entire list object, so it is not quite a property any more.  You can see this in the fact that the "old value" of a change listener is incorrect:

        ObservableList<Object> list = FXCollections.observableArrayList();
        SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(list);

        simpleListProperty.addListener((obs, old, current) -> System.out.println("Changed: " + old + " -> " + current));

        list.add("B");
        simpleListProperty.set(FXCollections.observableArrayList("C"));

Prints:

     Changed: [B] -> [B]    // huh? so nothing changed then? but it did...
     Changed: [B] -> [C]

This is frustrating as change listener has very specific semantics that code would like to rely on, but here, again, the old value is just a best effort guess (there are other bugs in this area).

I think that because of these poorly defined semantics, one will keep finding surprises in the behavior of these properties, depending on your perspective (property or list).  I think therefore that the first thing that's need to be done is to clearly define how these observable wrapper properties are supposed to work before fixing what may or may not be bugs in this area.  I fear it may not be possible to have `ListProperty` behave property and list like at the same time, and if so this should be clearly marked in the documentation that `ListProperty` does not obey the general contract of `Property`.

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

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

From kcr at openjdk.org  Wed Jan 11 12:55:23 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 12:55:23 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
Message-ID: <MnZnFWxFuNgIdlXmr3DrGwTf6njWVcEvzfAcphJmg5U=.d844e3ac-efab-4448-a382-560d2702c1d8@github.com>

On Wed, 11 Jan 2023 07:50:39 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixed the opacity issue

This would be good to get into JavaFX 20 (although time is short). It will need a second reviewer.

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

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

From kcr at openjdk.org  Wed Jan 11 12:55:25 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 12:55:25 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore
In-Reply-To: <wQPPoVBc0KfMZi9XcH1Z1VeuhOPT9cvjGub0Owa0KRA=.eb8b89ac-26e7-461f-ba6a-46a7bc52c080@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <wQPPoVBc0KfMZi9XcH1Z1VeuhOPT9cvjGub0Owa0KRA=.eb8b89ac-26e7-461f-ba6a-46a7bc52c080@github.com>
Message-ID: <OBjQTaoPXXUdnEchGwQhTmCb864jYoQZ2tJ-8kfeWSw=.8aa85c68-b44b-4197-b83d-b52f921eb958@github.com>

On Wed, 11 Jan 2023 07:49:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> force-pushed to trigger the tests.

In the future, you can just push an empty commit.

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

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

From jvos at openjdk.org  Wed Jan 11 13:00:31 2023
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 11 Jan 2023 13:00:31 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v9]
In-Reply-To: <KkAdILxBq_dDOOoiBSMN_xPWfH7v01vMkvP1DlPLhQY=.69d1494b-83b1-4220-aa74-a162157743d9@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <KkAdILxBq_dDOOoiBSMN_xPWfH7v01vMkvP1DlPLhQY=.69d1494b-83b1-4220-aa74-a162157743d9@github.com>
Message-ID: <u8c-1YkGzAP9TE3gqfq_DhrpBBigY0IztPRPc7Pj39Y=.fa39206e-d79a-418f-93ba-cbaada209384@github.com>

On Tue, 10 Jan 2023 18:30:48 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
>> 
>> 
>> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
>> $ bash gradlew sdk jmods javadoc
>> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
>> 
>> 
>> The three commands:
>> 
>> 1. set the build timestamp to the date of the latest source code change,
>> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
>> 3. recreate the JMOD files with stable file modification times and ordering.
>> 
>> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
>> 
>> #### Fixes
>> 
>> There are at least four sources of non-determinism in the JavaFX builds:
>> 
>> 1. Build timestamp
>> 
>>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
>> 
>> 2. Modification times
>> 
>>     The JAR, JMOD, and ZIP archives store the modification time of each file.
>> 
>> 3. File ordering
>> 
>>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
>> 
>> 4. Build path
>> 
>>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
>> 
>> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
>> 
>> [1]: https://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into allow-reproducible-builds
>  - Add '--date' argument for deterministic JMOD files
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Comment out 'jmod --date' until building on JDK 19
>    
>    Support for the 'jmod --date' option was added to JDK 19 starting
>    with the 19+2 early-access build, and it was backported to JDK 17
>    starting with release 17.0.3. It is not available in JDK 18.
>  - Merge 'master' into allow-reproducible-builds
>  - Make minimal changes for new '--date' option
>  - Add new '--date' option to JMOD task
>  - Add '--source-date' option to JMOD task
>  - Get build timestamp in UTC and set ZIP timestamps
>    
>    Create the build timestamp as a zoned date and time in UTC instead
>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>    last modification time of ZIP and JAR entries to the local date and
>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>    
>    Add a comment as a reminder to make JMOD files deterministic when
>    the following enhancements are complete:
>    
>    * Enable deterministic file content ordering for Jar and Jmod
>      https://bugs.openjdk.java.net/browse/JDK-8276764
>      https://github.com/openjdk/jdk/pull/6395
>    
>    * Enable jar and jmod to produce deterministic timestamped content
>      https://bugs.openjdk.java.net/browse/JDK-8276766
>      https://github.com/openjdk/jdk/pull/6481
>  - ... and 8 more: https://git.openjdk.org/jfx/compare/4a278013...0a3dda22

This looks a good step towards reproducible builds.
At the very least, I can't spot any regression.

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

Marked as reviewed by jvos (Reviewer).

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

From fkirmaier at openjdk.org  Wed Jan 11 13:12:22 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 11 Jan 2023 13:12:22 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
 <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
Message-ID: <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>

On Wed, 11 Jan 2023 11:11:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Should I expect x here to be unreferenced? No, that's how properties work, b will keep its reference to x.

No, x is not dereferenced. But you should expect that a is no longer referencing b, but both a and b are referencing x.

But I don't see your point - it's worth mentioning, when you bind a ListProperty A, to another ListProperty B, then A doesn't get the value "B", but the value will be the value of the property B.

If you think the PR creates an unwanted behavior, I would appreciate seeing a **unit-test** for it, because it's way easier to discuss on the basis of a test.

Making tests for memory behavior (both for being collectible and being not-collectible) is easy with JMemoryBuddy, which I wrote exactly for this use case.

I'm also happy with an alternative solution - which makes the tests green, which I've provided. I'm not really opinionated.

> IMHO there is a conflict between the property-like behavior of ListProperty and the list-like behavior of the ObservableList that it wraps. On the one hand, a list property is a reference to a list, and on the other hand, we expect it to behave as only referring to the contents of the list. The property like behavior that it inherits (perhaps it shouldn't have done that) has been subverted in that adding a change listener will pretend that a change to the list is the same as replacing the entire list object, so it is not quite a property any more. 

Yes, I agree. I think - it's a complicated topic. I don't want to discuss any details, because I just want to add a fundamental bug, without discussing the whole Property/Collection design.

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

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

From kcr at openjdk.org  Wed Jan 11 13:43:19 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 13:43:19 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
Message-ID: <81gAtOCmHaS3hTJrQhX7ZF3HoRPh8FJ_rEjRmM-rOKU=.516cf0cf-fd18-4cf8-a221-e6685fa9ecdb@github.com>

On Wed, 11 Jan 2023 07:50:39 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixed the opacity issue

@jaybhaskar Can you also take a look? This might cause a merge conflict with the in-progress WebKit 615.1 update, but since this is a very targeted patch, I expect it would be an easy conflict to resolve, if it does.

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

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

From kcr at openjdk.org  Wed Jan 11 13:55:31 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 13:55:31 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <RuPfV_O91aKYV_gyu6WkCZ67cDmJmKK4AF0FNV-1HaU=.783be47c-c42e-4e70-8380-5b45fb59101e@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
 <RuPfV_O91aKYV_gyu6WkCZ67cDmJmKK4AF0FNV-1HaU=.783be47c-c42e-4e70-8380-5b45fb59101e@github.com>
Message-ID: <HVa-XEEzBWUvI_ORSeyPhal_v1KBAdnrFQlBX5JBuBI=.da1bb5b4-0e4e-48ce-bba3-15ef3d44432d@github.com>

On Tue, 10 Jan 2023 22:43:30 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > Btw, I can confirm that yes, this fixed it for me. Specifically, commit [55fe2dc](https://github.com/openjdk/jfx/commit/55fe2dc7371f6dcb12c414c5d672728e47e9c504) has resolved my issue.
> 
> If you have time, it would be interesting check if it breaks for you by changing the order of the semantics. It might be worth adding a comment there because it's a rather surprising side effect.

Which part of the change, exactly, do you mean? The part that moved `texcoord0` to the beginning of the struct? I could take a quick look after JavaFX 20 RDP1.

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

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

From jbhaskar at openjdk.org  Wed Jan 11 15:01:30 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 11 Jan 2023 15:01:30 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
Message-ID: <hTTag0h5nMj6oNjDcLWxA-Snbuzkrk12RyhYcRaNAnc=.76dbe04d-d823-43be-9420-305978e5a5ac@github.com>

On Wed, 11 Jan 2023 07:50:39 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixed the opacity issue

+looks good to me

The patch looks ok, as [GraphicsContextJava.h] needs to inherit methods from GraphicsContext.h  , the begin/endPlatformTransparencyLayers already modified in latest update. so it looks like there would not be conflict.

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

Marked as reviewed by jbhaskar (Author).

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

From kcr at openjdk.org  Wed Jan 11 15:01:32 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 15:01:32 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <hTTag0h5nMj6oNjDcLWxA-Snbuzkrk12RyhYcRaNAnc=.76dbe04d-d823-43be-9420-305978e5a5ac@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
 <hTTag0h5nMj6oNjDcLWxA-Snbuzkrk12RyhYcRaNAnc=.76dbe04d-d823-43be-9420-305978e5a5ac@github.com>
Message-ID: <v3TG4b7GsfEFXaZu-6eap-7KUZdAytV_A_ij4jRNbEI=.12e1d74c-4512-44ef-a7e8-a35c9cda9712@github.com>

On Wed, 11 Jan 2023 14:58:07 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Fixed the opacity issue
>
> The patch looks ok, as [GraphicsContextJava.h] needs to inherit methods from GraphicsContext.h  , the begin/endPlatformTransparencyLayers already modified in latest update. so it looks like there would not be conflict.

> @jaybhaskar Can you also take a look? This might cause a merge conflict with the in-progress WebKit 615.1 update, but since this is a very targeted patch, I expect it would be an easy conflict to resolve, if it does.

I did a quick test, and confirmed that this does fix the problem. I also confirmed that there will be no merge conflict with WebKit 615.1.

@wkia Would it be possible to provide a unit test that fails before and passes after this fix?

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

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

From jgneff at openjdk.org  Wed Jan 11 15:36:31 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Wed, 11 Jan 2023 15:36:31 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <OC0RJP3TmGyQNQeEknB319xpvfwxREnT6q9Y7jCEK2Y=.15c67635-06c4-4c68-9229-7d8bf711e9fa@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
 <OC0RJP3TmGyQNQeEknB319xpvfwxREnT6q9Y7jCEK2Y=.15c67635-06c4-4c68-9229-7d8bf711e9fa@github.com>
Message-ID: <nNZAXUuMHPhOzZ0FxT5pmbi2Rxpaf-qx6FO2gXDd7Yk=.748167f5-c7a2-4e58-bb55-f2909f37a502@github.com>

On Tue, 3 Jan 2023 06:37:14 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> I just discovered that the `--date` argument for the `jmod` tool was back-ported to JDK 17, so I didn't need to wait for JDK 19 after all! Oh well.

Actually, it turns out I did have to wait for JDK 19 after all. Before reaching version 19.0.1, the boot JDK for building JavaFX (`jfx.build.jdk.version`) went from version 17.0.2 to 18, 18.0.1, and 18.0.2, none of which had the feature. The feature was back ported from version 19 to 17.0.4 or later. See [JDK-8283182][1]. That makes me feel a little better about the delay. ?

[1]: https://bugs.openjdk.org/browse/JDK-8283182

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

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

From rmarchenko at openjdk.org  Wed Jan 11 15:52:21 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 15:52:21 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore
In-Reply-To: <wQPPoVBc0KfMZi9XcH1Z1VeuhOPT9cvjGub0Owa0KRA=.eb8b89ac-26e7-461f-ba6a-46a7bc52c080@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <wQPPoVBc0KfMZi9XcH1Z1VeuhOPT9cvjGub0Owa0KRA=.eb8b89ac-26e7-461f-ba6a-46a7bc52c080@github.com>
Message-ID: <PSTAG8Gpg01tqbvdVTMbvhJRv0Wf9B8LmwDFPeTD2cA=.e5fa9ee3-88b8-4c2b-8b3d-aac261698c64@github.com>

On Wed, 11 Jan 2023 07:49:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> force-pushed to trigger the tests.

> @wkia Would it be possible to provide a unit test that fails before and passes after this fix?

@kevinrushforth  I will try, I guess it will take time.

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

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

From kcr at openjdk.org  Wed Jan 11 15:52:21 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 15:52:21 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore
In-Reply-To: <PSTAG8Gpg01tqbvdVTMbvhJRv0Wf9B8LmwDFPeTD2cA=.e5fa9ee3-88b8-4c2b-8b3d-aac261698c64@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <wQPPoVBc0KfMZi9XcH1Z1VeuhOPT9cvjGub0Owa0KRA=.eb8b89ac-26e7-461f-ba6a-46a7bc52c080@github.com>
 <PSTAG8Gpg01tqbvdVTMbvhJRv0Wf9B8LmwDFPeTD2cA=.e5fa9ee3-88b8-4c2b-8b3d-aac261698c64@github.com>
Message-ID: <OpgbuEVCH1cjwTQ6m_WAaX1B9DbJxftEL_kINq0b4kg=.6f062e14-33df-4713-8deb-0c10ae050fb0@github.com>

On Wed, 11 Jan 2023 15:47:38 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> > @wkia Would it be possible to provide a unit test that fails before and passes after this fix?
> 
> @kevinrushforth I will try, I guess it will take time.

If it ends up being too difficult or time-consuming, it could be done in a follow-up issue. This is a safe and obvious fix, so the main reason for wanting it is to ensure that we don't regress again in the future.

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

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

From jhendrikx at openjdk.org  Wed Jan 11 15:57:27 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 11 Jan 2023 15:57:27 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
 <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
 <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>
Message-ID: <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>

On Wed, 11 Jan 2023 13:09:37 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> > Should I expect x here to be unreferenced? No, that's how properties work, b will keep its reference to x.
> 
> No, x is not dereferenced. But you should expect that a is no longer referencing b, but both a and b are referencing x.

I missed that the test was referencing only the properties, although I suppose the "list like behavior" people might find it surprising to see the previously bound property now suddenly referencing a different `ObservableList`. If that `ObservableList` is supposed to be short lived, then that might be a new kind of memory leak (but nothing that wasn't there before).

The above written as a test, people may find this surprising behavior:

    @Test
    public void testListsDontCrossPolinate() {
        ObservableList<Object> a = FXCollections.observableArrayList("A");
        ObservableList<Object> b = FXCollections.observableArrayList("A", "B", "C");

        SimpleListProperty<Object> propA = new SimpleListProperty<>(a);
        SimpleListProperty<Object> propB = new SimpleListProperty<>(b);

        propA.bind(propB);

        assertEquals(3, propA.get().size());  // Note: if you remove this line, the old code fails badly...

        propA.unbind();

        propA.get().add("A");

        assertEquals(4, propA.get().size());
        assertEquals(4, propB.get().size());
    }

> If you think the PR creates an unwanted behavior, I would appreciate seeing a **unit-test** for it, because it's way easier to discuss on the basis of a test.

Here is one that passed with the old version, which highlights the standard gotcha's of all uses of weak references:

    @Test
    public void testWeakRefDoesntDisappearUnexpectedly() {
        List<Object> changes = new ArrayList<>();

        ObservableList<Object> observableList = FXCollections.observableArrayList();

        SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(observableList);
        simpleListProperty.addListener((obs, old, current) -> changes.add(current));

        simpleListProperty = null;

        observableList.add("A");

        assertEquals(1, changes.size());

        System.gc();

        observableList.add("B");

        assertEquals(2, changes.size());
    }

This test highlights the following issues:
- Weak references don't disappear instantly; they may disappear at any time or never, at the digression of your JVM; the first change we do to `observableList` may be picked up or not, it's unpredictable.  In real applications, this exhibits itself as "works on my machine" or "seems to work for a while, but then breaks".
- The second change doesn't get picked up, but it still might.  It depends on the mood of the garbage collector.  This can show up in real applications as phantom changes being triggered by objects that are supposedly no longer in use.

And finally, why would we expect that the outcome is anything but what the test says?  I registered a listener, I didn't unregister it, it's there, it's registering changes made to an observable list and putting those in another list for later use.  Why would this test fail at all?  Explaining what's happening here to JavaFX novices is impossible. We're relying here on a fundamental JVM system, that is largely unspecified in how it behaves exactly (and with good reason), for a very basic but crucial feature.

The way I see it, `ListProperty` should work as follows:

1) When created, it registers nothing to anything; this will allow it to go out of scope (currently it can't, as it registers on `ObservableList` which will point back to it).

2) When any listener is registered to it (or to its `empty` or `size` properties), it registers on the underlying `ObservableList`; when all listeners are gone, it unregisters from the underlying `ObservableList`.  This is what you would want; if I'm listening to something, I don't want this to disappear for any reason.

3) `bind` / `unbind` can stay as they are; when you bind to another property, that other property gets a listener and registers with its underlying `ObservableList`.  When `unbind` gets called, that listener is removed again (and potentially, the other property unregisters from its underlying `ObservableList` if that was the only listener).  Before this would break, as the `ObservableList` would still be pointing to the other list property (as a listener is present) and the now unbound property, which also refers that `ObservableList` now (whether that's good or bad) will then keep an indirect reference to that other property (previously bound property -> observable list -> other property).

No weak listeners are needed anywhere now, and everything will be nice and predictable.

I'll attempt to make a PoC for this.

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

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

From duke at openjdk.org  Wed Jan 11 16:08:29 2023
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Wed, 11 Jan 2023 16:08:29 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
Message-ID: <ZiEx4ci5ZCFlqNLYbJ77rcxcNHE6wNtyUYO3aNAwVqQ=.2aa59fa2-6031-426c-866a-32d05284ed00@github.com>

On Wed, 11 Jan 2023 07:50:39 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixed the opacity issue

There is a small test in the ticket description that I've added to modules\javafx.web\src\test\java\test\javafx\scene\web\SVGTest.java when I tried to track down the problem. Maybe that is enough?

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

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

From kcr at openjdk.org  Wed Jan 11 16:26:26 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 16:26:26 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
Message-ID: <NtbWUfAjAqIrv2kdUIeqsRPUc8bhtrknDmiQ7YBGT4I=.d1a20082-8cca-4480-a18d-4c9091f4d680@github.com>

On Wed, 11 Jan 2023 07:50:39 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixed the opacity issue

I might add it elsewhere (either to a different test class or as a new test class), since it really isn't related to SVG rendering, but yes, something like this would be sufficient.

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

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

From kevin.rushforth at oracle.com  Wed Jan 11 16:29:18 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 11 Jan 2023 08:29:18 -0800
Subject: FINAL REMINDER: JavaFX 20 RDP1 starts tomorrow [was: Proposed
 schedule for JavaFX 20]
In-Reply-To: <9373bc9d-7fec-72b2-1414-e80e822b981e@oracle.com>
References: <7e1dcc31-ac9c-b5ff-75a6-cb504c77bdac@oracle.com>
 <9373bc9d-7fec-72b2-1414-e80e822b981e@oracle.com>
Message-ID: <b7626d1c-cc6d-3907-f3c9-219bff27b41b@oracle.com>

As a reminder, JavaFX 20 RDP1 starts tomorrow, January 12th. I will fork 
the 'jfx20' branch at 16:00 UTC (it might be 15 or 20 minutes after 
that, but don't count on it).

-- Kevin

On 12/19/2022 12:10 PM, Kevin Rushforth wrote:
> As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 20 starts on January 
> 12, 2023 at 16:00 UTC (08:00 Pacific time). Given the upcoming 
> holidays, that's a little over 2 working weeks from now.
>
> During rampdown of JavaFX 20, the "master" branch of the jfx repo will 
> be open for JavaFX 21 fixes.
>
> Please allow sufficient time for any feature that needs a CSR. New 
> features should be far enough along in the review process that you can 
> finalize the CSR no later than Thursday, January 5, or it is likely to 
> miss the window for this release, in which case it can be targeted for 
> JavaFX 21.
>
> We will follow the same process as in previous releases for getting 
> fixes into JavaFX 20 during rampdown. I'll send a message with 
> detailed information when we fork, but candidates for fixing during 
> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc 
> bugs of any priority. Some small enhancements might be considered 
> during RDP1, but they require explicit approval; the bar will be high 
> for such requests.
>
> -- Kevin
>
>
> On 11/1/2022 1:59 PM, Kevin Rushforth wrote:
>> Here is the proposed schedule for JavaFX 20.
>>
>> RDP1: Jan 12, 2023 (aka ?feature freeze?)
>> RDP2: Feb 2, 2023
>> Freeze: March 2, 2023
>> GA: March 21, 2023
>> We plan to fork a jfx20 stabilization branch at RDP1.
>>
>> The start of RDP1, the start of RDP2, and the code freeze will be 
>> 16:00 UTC on the respective dates.
>>
>> Please let Johan or me know if you have any questions.
>>
>> -- Kevin
>>
>


From mstrauss at openjdk.org  Wed Jan 11 16:43:21 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Jan 2023 16:43:21 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
 <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
 <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>
 <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>
Message-ID: <DVv8Yc4WHvHBS-K3sG8eJkiaNu4ntT0XqcnWJ4q7kmE=.450295ed-5656-4e8a-bb02-6830f32a8616@github.com>

On Wed, 11 Jan 2023 15:54:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Here is one that passed with the old version, which highlights the standard gotcha's of all uses of weak references:
> 
> ```
> @Test
> public void testWeakRefDoesntDisappearUnexpectedly() {
>     List<Object> changes = new ArrayList<>();
> 
>     ObservableList<Object> observableList = FXCollections.observableArrayList();
> 
>     SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(observableList);
>     simpleListProperty.addListener((obs, old, current) -> changes.add(current));
> 
>     simpleListProperty = null;
> 
>     observableList.add("A");
> 
>     assertEquals(1, changes.size());
> 
>     System.gc();
> 
>     observableList.add("B");
> 
>     assertEquals(2, changes.size());
> }
> ```
> 
> This test highlights the following issues:
> 
> * Weak references don't disappear instantly; they may disappear at any time or never, at the digression of your JVM; the first change we do to `observableList` may be picked up or not, it's unpredictable.  In real applications, this exhibits itself as "works on my machine" or "seems to work for a while, but then breaks".
> * The second change doesn't get picked up, but it still might.  It depends on the mood of the garbage collector.  This can show up in real applications as phantom changes being triggered by objects that are supposedly no longer in use.
> 
> And finally, why would we expect that the outcome is anything but what the test says? I registered a listener, I didn't unregister it, it's there, it's registering changes made to an observable list and putting those in another list for later use. Why would this test fail at all? Explaining what's happening here to JavaFX novices is impossible. We're relying here on a fundamental JVM system, that is largely unspecified in how it behaves exactly (and with good reason), for a very basic but crucial feature.

The test fails (or doesn't) because it relies on side-effects of a weakly reachable object. I don't think that this is a JavaFX-specific issue, it's a general issue with garbage-collected environments. More to the point: I think it's more surprising to find out that this test would actually consistently pass. Java developers know that they can't rely on weakly-reachable objects, so why would they suddenly expect such an object to have well-defined side effects?

> The way I see it, `ListProperty` should work as follows:
> 
> 1. When created, it registers nothing to anything; this will allow it to go out of scope (currently it can't, as it registers on `ObservableList` which will point back to it).
> 2. When any listener is registered to it (or to its `empty` or `size` properties), it registers on the underlying `ObservableList`; when all listeners are gone, it unregisters from the underlying `ObservableList`.  This is what you would want; if I'm listening to something, I don't want this to disappear for any reason.
> 3. `bind` / `unbind` can stay as they are; when you bind to another property, that other property gets a listener and registers with its underlying `ObservableList`.  When `unbind` gets called, that listener is removed again (and potentially, the other property unregisters from its underlying `ObservableList` if that was the only listener).  Before this would break, as the `ObservableList` would still be pointing to the other list property (as a listener is present) and the now unbound property, which also refers that `ObservableList` now (whether that's good or bad) will then keep an indirect reference to that other property (previously bound property -> observable list -> other property).
> 
> No weak listeners are needed anywhere now, and everything will be nice and predictable.
> 
> I'll attempt to make a PoC for this.

I don't think this is how ?ListProperty` should work.

Fundamentally, we're talking about this scenario:

ObservableList<Object> list = FXCollections.observableArrayList();
ListProperty<Object> listProperty = new SimpleListProperty<>(list);


Under no circumstance should `list` ever hold a strong reference to `listProperty`. Your proposal would make a strong reference contingent upon registering listeners on `listProperty`.

But that's not relevant: why should `listProperty` be kept alive if it is only weakly reachable from its subscribed listeners (or anyone else, for that matter)? As a user, that's not what I would expect if I only added listeners to `listProperty` (note: I didn't add any listeners to `list` itself). `ObjectProperty` doesn't behave like this; instead, `ObjectProperty` can become weakly reachable even if the contained object doesn't.

The purpose of this PR is to break the strong reference from `list` to `listProperty`, and I think that's the right thing to do.

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

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

From nlisker at openjdk.org  Wed Jan 11 17:19:29 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 11 Jan 2023 17:19:29 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
In-Reply-To: <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <scKK5X4m5xL_71Rwmzm9jXoTit3GR7qR66sUMy-GJVQ=.4bff6639-b6c6-4c8b-b277-48c2d39395f5@github.com>
Message-ID: <fINOjSd2y42kdLJvMs3rpOWWHmnzQ2v9WZyskTM6IS8=.02a3d284-646f-4ebc-9031-2d906bb5e414@github.com>

On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed comment as suggested
>  - Removed unused fields

The change that moved `float2 texD : texcoord0;` from the beginning to the end is the one that fixed it for me, and apparently for you. If you can move it back to the beginning of the struct and check if it fails, it would be helpful. I will add a comment there in a later PR.

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

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

From rmarchenko at openjdk.org  Wed Jan 11 17:33:59 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 17:33:59 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v3]
In-Reply-To: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
Message-ID: <2NquZSUs-pe7ONzJftwg4as0wNlikTt07wi3rOT-tro=.0c5c9098-122f-428a-984d-0d8a78a17a95@github.com>

> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
> 
> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
> 
> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  OpacityTest added

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/992/files
  - new: https://git.openjdk.org/jfx/pull/992/files/6a970278..a349829c

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

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

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

From rmarchenko at openjdk.org  Wed Jan 11 17:34:02 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 17:34:02 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <NtbWUfAjAqIrv2kdUIeqsRPUc8bhtrknDmiQ7YBGT4I=.d1a20082-8cca-4480-a18d-4c9091f4d680@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
 <NtbWUfAjAqIrv2kdUIeqsRPUc8bhtrknDmiQ7YBGT4I=.d1a20082-8cca-4480-a18d-4c9091f4d680@github.com>
Message-ID: <NuUT02B2aidJbIILXYUNNcTQZ__Za-70Rsk7mmXWA20=.5117fbce-78ab-4c23-8f63-d029844b722f@github.com>

On Wed, 11 Jan 2023 16:24:04 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Fixed the opacity issue
>
> I might add it elsewhere (either to a different test class or as a new test class), since it really isn't related to SVG rendering, but yes, something like this would be sufficient.

@kevinrushforth @Schmidor Test added
I'm not sure about comparing against GRAY and WHITE with 1% tolerance. 
It seems OK on my Win11.
Is it ok or should be changed?

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

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

From rmarchenko at openjdk.org  Wed Jan 11 17:57:16 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 17:57:16 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v4]
In-Reply-To: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
Message-ID: <Ly7mLCt0H_Oa3GVanNqD8rKu6fxTVuyJPsg7zVeG414=.b904aa06-8f6e-4d55-9dca-4a41890993cd@github.com>

> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
> 
> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
> 
> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  OpacityTest checks pixel color at the centre of areas

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/992/files
  - new: https://git.openjdk.org/jfx/pull/992/files/a349829c..e236741f

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

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

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

From rmarchenko at openjdk.org  Wed Jan 11 18:58:44 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 11 Jan 2023 18:58:44 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v5]
In-Reply-To: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
Message-ID: <xYPpzMUjr_wIqZB0O5zlr_Um81Zb9YQUWHAe_-a2-n8=.529b00c4-85ee-4efa-ba03-8e70bc5122ee@github.com>

> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
> 
> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
> 
> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Renamed vars in OpacityTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/992/files
  - new: https://git.openjdk.org/jfx/pull/992/files/e236741f..9eb388ca

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

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

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

From mstrauss at openjdk.org  Wed Jan 11 19:33:28 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Jan 2023 19:33:28 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v4]
In-Reply-To: <SjOgdrDoqwEhzjGMH24fs0Q09LUeJPugu14nXb7gSk0=.c2df3a10-0298-485c-be86-3f498295e82e@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <SjOgdrDoqwEhzjGMH24fs0Q09LUeJPugu14nXb7gSk0=.c2df3a10-0298-485c-be86-3f498295e82e@github.com>
Message-ID: <vcsIlQaDGRWceiZapFWaO2p-JbDC2nWFo6ZNqgojCzk=.6c50403c-e9ea-4b57-a7da-716380070092@github.com>

On Wed, 11 Jan 2023 09:22:07 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR fixes the leak in the mac system menu bar.
>> 
>> Inside the native code, NewGlobalRef is called for the callable.
>> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
>> 
>> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
>> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
>> 
>> The unit test verifies, that this bug happened without this change, but no longer happens with this change.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8299423
>   Added null check before using the callback

tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 36:

> 34: import javafx.scene.layout.VBox;
> 35: import javafx.stage.Stage;
> 36: import org.junit.*;

Since this a new class, can you use the JUnit5 API?

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

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

From kcr at openjdk.org  Wed Jan 11 23:07:31 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 23:07:31 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v9]
In-Reply-To: <KkAdILxBq_dDOOoiBSMN_xPWfH7v01vMkvP1DlPLhQY=.69d1494b-83b1-4220-aa74-a162157743d9@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <KkAdILxBq_dDOOoiBSMN_xPWfH7v01vMkvP1DlPLhQY=.69d1494b-83b1-4220-aa74-a162157743d9@github.com>
Message-ID: <Z6BIImPBHsB14zJmn5vBoJWsm8B75ixoysjXmOlN-4M=.5aeb32f3-52f3-42bd-817e-7fa76939bc06@github.com>

On Tue, 10 Jan 2023 18:30:48 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
>> 
>> 
>> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
>> $ bash gradlew sdk jmods javadoc
>> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
>> 
>> 
>> The three commands:
>> 
>> 1. set the build timestamp to the date of the latest source code change,
>> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
>> 3. recreate the JMOD files with stable file modification times and ordering.
>> 
>> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
>> 
>> #### Fixes
>> 
>> There are at least four sources of non-determinism in the JavaFX builds:
>> 
>> 1. Build timestamp
>> 
>>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
>> 
>> 2. Modification times
>> 
>>     The JAR, JMOD, and ZIP archives store the modification time of each file.
>> 
>> 3. File ordering
>> 
>>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
>> 
>> 4. Build path
>> 
>>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
>> 
>> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
>> 
>> [1]: https://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into allow-reproducible-builds
>  - Add '--date' argument for deterministic JMOD files
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Comment out 'jmod --date' until building on JDK 19
>    
>    Support for the 'jmod --date' option was added to JDK 19 starting
>    with the 19+2 early-access build, and it was backported to JDK 17
>    starting with release 17.0.3. It is not available in JDK 18.
>  - Merge 'master' into allow-reproducible-builds
>  - Make minimal changes for new '--date' option
>  - Add new '--date' option to JMOD task
>  - Add '--source-date' option to JMOD task
>  - Get build timestamp in UTC and set ZIP timestamps
>    
>    Create the build timestamp as a zoned date and time in UTC instead
>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>    last modification time of ZIP and JAR entries to the local date and
>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>    
>    Add a comment as a reminder to make JMOD files deterministic when
>    the following enhancements are complete:
>    
>    * Enable deterministic file content ordering for Jar and Jmod
>      https://bugs.openjdk.java.net/browse/JDK-8276764
>      https://github.com/openjdk/jdk/pull/6395
>    
>    * Enable jar and jmod to produce deterministic timestamped content
>      https://bugs.openjdk.java.net/browse/JDK-8276766
>      https://github.com/openjdk/jdk/pull/6481
>  - ... and 8 more: https://git.openjdk.org/jfx/compare/4a278013...0a3dda22

I'll need a bit more time to run CI test builds again. I'm thinking it might be better to get this in early in JavaFX 21 rather than late in JavaFX 20 anyway.

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

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

From kcr at openjdk.org  Wed Jan 11 23:07:37 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 23:07:37 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
Message-ID: <M2brODqDB9FY9S4QLyrkgWYWn1dLIaJWlbe51ouqaH0=.7caebc5d-2d76-47cc-9cc9-1fc873892d1a@github.com>

On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
>> 
>> 
>> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
>> $ bash gradlew sdk jmods javadoc
>> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
>> 
>> 
>> The three commands:
>> 
>> 1. set the build timestamp to the date of the latest source code change,
>> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
>> 3. recreate the JMOD files with stable file modification times and ordering.
>> 
>> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
>> 
>> #### Fixes
>> 
>> There are at least four sources of non-determinism in the JavaFX builds:
>> 
>> 1. Build timestamp
>> 
>>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
>> 
>> 2. Modification times
>> 
>>     The JAR, JMOD, and ZIP archives store the modification time of each file.
>> 
>> 3. File ordering
>> 
>>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
>> 
>> 4. Build path
>> 
>>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
>> 
>> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
>> 
>> [1]: https://reproducible-builds.org/docs/source-date-epoch/
>> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism
>
> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add '--date' argument for deterministic JMOD files
>  - Merge branch 'master' into allow-reproducible-builds
>  - Merge branch 'master' into allow-reproducible-builds
>  - Comment out 'jmod --date' until building on JDK 19
>    
>    Support for the 'jmod --date' option was added to JDK 19 starting
>    with the 19+2 early-access build, and it was backported to JDK 17
>    starting with release 17.0.3. It is not available in JDK 18.
>  - Merge 'master' into allow-reproducible-builds
>  - Make minimal changes for new '--date' option
>  - Add new '--date' option to JMOD task
>  - Add '--source-date' option to JMOD task
>  - Get build timestamp in UTC and set ZIP timestamps
>    
>    Create the build timestamp as a zoned date and time in UTC instead
>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>    last modification time of ZIP and JAR entries to the local date and
>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>    
>    Add a comment as a reminder to make JMOD files deterministic when
>    the following enhancements are complete:
>    
>    * Enable deterministic file content ordering for Jar and Jmod
>      https://bugs.openjdk.java.net/browse/JDK-8276764
>      https://github.com/openjdk/jdk/pull/6395
>    
>    * Enable jar and jmod to produce deterministic timestamped content
>      https://bugs.openjdk.java.net/browse/JDK-8276766
>      https://github.com/openjdk/jdk/pull/6481
>  - Merge branch 'master' into allow-reproducible-builds
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b

build.gradle line 5573:

> 5571:                         args(srcLegalDir)
> 5572:                         if (sourceDateEpoch != null) {
> 5573:                             args("--date", buildTimestamp)

Since the minimum boot JDK for building JavaFX is still JDK 17 GA, you will need to qualify this with a check for `if (jdk19OrLater)`. See the following for a pattern to use to define that flag:

https://github.com/openjdk/jfx/blob/1e4c083b90281e91b1e9cbbc615401e89bb933b1/build.gradle#L699-L704

Btw, the comment in that block should read "based on whether we are _building_ on JDK 18 or later".

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

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

From kcr at openjdk.org  Wed Jan 11 23:13:27 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 23:13:27 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v5]
In-Reply-To: <xYPpzMUjr_wIqZB0O5zlr_Um81Zb9YQUWHAe_-a2-n8=.529b00c4-85ee-4efa-ba03-8e70bc5122ee@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <xYPpzMUjr_wIqZB0O5zlr_Um81Zb9YQUWHAe_-a2-n8=.529b00c4-85ee-4efa-ba03-8e70bc5122ee@github.com>
Message-ID: <SjA6Q1nXfwRMkW7aPGwTJjlNXpJpS-w6hRqPbw9C7FI=.a39074e8-2342-4db8-8e77-99e5b3f39aa1@github.com>

On Wed, 11 Jan 2023 18:58:44 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed vars in OpacityTest

Looks good. I can confirm that the newly added test fails without the fix and passes with the fix. I ran a CI test build on all three platforms and it passes on all of them.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.org  Wed Jan 11 23:13:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 11 Jan 2023 23:13:30 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v2]
In-Reply-To: <hTTag0h5nMj6oNjDcLWxA-Snbuzkrk12RyhYcRaNAnc=.76dbe04d-d823-43be-9420-305978e5a5ac@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <2g7nVpsydprFWgas2p-lMSoZ-LfJe4b1CHI-kcltIkI=.8681da23-ff4d-4810-b918-36a41350dcf4@github.com>
 <hTTag0h5nMj6oNjDcLWxA-Snbuzkrk12RyhYcRaNAnc=.76dbe04d-d823-43be-9420-305978e5a5ac@github.com>
Message-ID: <uNJlagWJs39uoBmxEdjvIgyB47XgMOMfQjef-K4CprI=.d9bc2c48-b50f-41f5-ab54-930846f28566@github.com>

On Wed, 11 Jan 2023 14:58:07 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Fixed the opacity issue
>
> The patch looks ok, as [GraphicsContextJava.h] needs to inherit methods from GraphicsContext.h  , the begin/endPlatformTransparencyLayers already modified in latest update. so it looks like there would not be conflict.

@jaybhaskar Can you re-review (the only change since you reviewed was the addition of the unit test)

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

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

From jgneff at openjdk.org  Wed Jan 11 23:14:38 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Wed, 11 Jan 2023 23:14:38 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v9]
In-Reply-To: <Z6BIImPBHsB14zJmn5vBoJWsm8B75ixoysjXmOlN-4M=.5aeb32f3-52f3-42bd-817e-7fa76939bc06@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <KkAdILxBq_dDOOoiBSMN_xPWfH7v01vMkvP1DlPLhQY=.69d1494b-83b1-4220-aa74-a162157743d9@github.com>
 <Z6BIImPBHsB14zJmn5vBoJWsm8B75ixoysjXmOlN-4M=.5aeb32f3-52f3-42bd-817e-7fa76939bc06@github.com>
Message-ID: <CqquDZrcaMyZVpfZ9F-B-rveqjUC5jQIELkUNdUSSFM=.97de79c8-556a-4251-bd34-bfe78db0d59b@github.com>

On Wed, 11 Jan 2023 23:04:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I'll need a bit more time to run CI test builds again. I'm thinking it might be better to get this in early in JavaFX 21 rather than late in JavaFX 20 anyway.

I agree, especially considering the change required for JDK 17 GA. Besides, we're not going to have full cross-system reproducible builds until we start building JavaFX with JDK 20 due to [Bug JDK-8292892](https://bugs.openjdk.org/browse/JDK-8292892).

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

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

From mstrauss at openjdk.org  Thu Jan 12 03:16:01 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 12 Jan 2023 03:16:01 GMT
Subject: RFR: 8300013: Node.focusWithin doesn't account for nested focused
 nodes
Message-ID: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>

When a scene graph contains multiple nested focused nodes (this can happen with `TableView` and other controls), the `focusWithin` bits that are cleared when a focused node is de-focused must only be cleared when there is no other nested node in the scene graph that would also cause `focusWithin` to be set.

For example, consider a scene graph of nested nodes:
A -> B -> C -> D

When B and D are both focused, the scene graph looks like this:
A(`focusWithin`)
-> B(`focused`, `focusWithin`)
-> C(`focusWithin`)
-> D(`focused`, `focusWithin`)

When B is de-focused, the `focusWithin` flags must still be preserved because D remains focused.

This PR fixes the issue by counting the number of times `focusWithin` has been "set", and only clears it when it has been "un-set" an equal number of times.

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

Commit messages:
 - focusWithin fix
 - Failing test

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

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

From mstrauss at openjdk.org  Thu Jan 12 03:18:27 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 12 Jan 2023 03:18:27 GMT
Subject: RFR: 8300013: Node.focusWithin doesn't account for nested focused
 nodes
In-Reply-To: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
Message-ID: <ww_TVGm37cLMSjdbESAnEOvrh8Xtmzt7Jxd7a7kcAqE=.dbe35689-99f7-47c2-a66f-da0850c79fbd@github.com>

On Thu, 12 Jan 2023 03:08:30 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a scene graph contains multiple nested focused nodes (this can happen with `TableView` and other controls), the `focusWithin` bits that are cleared when a focused node is de-focused must only be cleared when there is no other nested node in the scene graph that would also cause `focusWithin` to be set.
> 
> For example, consider a scene graph of nested nodes:
> A -> B -> C -> D
> 
> When B and D are both focused, the scene graph looks like this:
> A(`focusWithin`)
> -> B(`focused`, `focusWithin`)
> -> C(`focusWithin`)
> -> D(`focused`, `focusWithin`)
> 
> When B is de-focused, the `focusWithin` flags must still be preserved because D remains focused.
> 
> This PR fixes the issue by counting the number of times `focusWithin` has been "set", and only clears it when it has been "un-set" an equal number of times.

I think this should go into JavaFX 20.

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

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

From fkirmaier at openjdk.org  Thu Jan 12 08:53:14 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 12 Jan 2023 08:53:14 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v8]
In-Reply-To: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
Message-ID: <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>

> Making the initial listener of the ListProperty weak fixes the problem.
> The same is fixed for Set and Map.
> Due to a smart implementation, this is done without any performance drawback.
> (The trick is to have an object, which is both the WeakReference and the Changelistener)
> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.

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:

 - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
   
   # Conflicts:
   #	modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java
   #	modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java
   #	modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java
 - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
 - JDK-8277848
   Added tests to ensure no premature garbage collection is happening.
 - JDK-8277848
   Added 3 more tests to verify that a bug discussed in the PR does not appear.
 - JDK-8277848
   Added the 3 requests whitespaces
 - JDK-8277848
   Further optimization based code review.
   This Bugfix should now event improve the performance
 - JDK-8277848
   Added missing change
 - JDK-8277848
   Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

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

Changes: https://git.openjdk.org/jfx/pull/689/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=07
  Stats: 247 lines in 6 files changed: 186 ins; 24 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/689.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/689/head:pull/689

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

From fkirmaier at openjdk.org  Thu Jan 12 09:17:31 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 12 Jan 2023 09:17:31 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
 <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
 <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>
 <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>
Message-ID: <ncsdE8dwT-BIA621nWybi2ZEkorEd5jica34ih2QWNE=.f3d86ae5-9fce-4641-8232-afeb2065567b@github.com>

On Wed, 11 Jan 2023 15:54:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> Should I expect x here to be unreferenced? No, that's how properties work, b will keep its reference to x.
>> 
>> No, x is not dereferenced. But you should expect that a is no longer referencing b, but both a and b are referencing x.
>> 
>> But I don't see your point - it's worth mentioning, when you bind a ListProperty A, to another ListProperty B, then A doesn't get the value "B", but the value will be the value of the property B.
>> 
>> If you think the PR creates an unwanted behavior, I would appreciate seeing a **unit-test** for it, because it's way easier to discuss on the basis of a test.
>> 
>> Making tests for memory behavior (both for being collectible and being not-collectible) is easy with JMemoryBuddy, which I wrote exactly for this use case.
>> 
>> I'm also happy with an alternative solution - which makes the tests green, which I've provided. I'm not really opinionated.
>> 
>>> IMHO there is a conflict between the property-like behavior of ListProperty and the list-like behavior of the ObservableList that it wraps. On the one hand, a list property is a reference to a list, and on the other hand, we expect it to behave as only referring to the contents of the list. The property like behavior that it inherits (perhaps it shouldn't have done that) has been subverted in that adding a change listener will pretend that a change to the list is the same as replacing the entire list object, so it is not quite a property any more. 
>> 
>> Yes, I agree. I think - it's a complicated topic. I don't want to discuss any details, because I just want to add a fundamental bug, without discussing the whole Property/Collection design.
>
>> > Should I expect x here to be unreferenced? No, that's how properties work, b will keep its reference to x.
>> 
>> No, x is not dereferenced. But you should expect that a is no longer referencing b, but both a and b are referencing x.
> 
> I missed that the test was referencing only the properties, although I suppose the "list like behavior" people might find it surprising to see the previously bound property now suddenly referencing a different `ObservableList`. If that `ObservableList` is supposed to be short lived, then that might be a new kind of memory leak (but nothing that wasn't there before).
> 
> The above written as a test, people may find this surprising behavior:
> 
>     @Test
>     public void testListsDontCrossPolinate() {
>         ObservableList<Object> a = FXCollections.observableArrayList("A");
>         ObservableList<Object> b = FXCollections.observableArrayList("A", "B", "C");
> 
>         SimpleListProperty<Object> propA = new SimpleListProperty<>(a);
>         SimpleListProperty<Object> propB = new SimpleListProperty<>(b);
> 
>         propA.bind(propB);
> 
>         assertEquals(3, propA.get().size());  // Note: if you remove this line, the old code fails badly...
> 
>         propA.unbind();
> 
>         propA.get().add("A");
> 
>         assertEquals(4, propA.get().size());
>         assertEquals(4, propB.get().size());
>     }
> 
>> If you think the PR creates an unwanted behavior, I would appreciate seeing a **unit-test** for it, because it's way easier to discuss on the basis of a test.
> 
> Here is one that passed with the old version, which highlights the standard gotcha's of all uses of weak references:
> 
>     @Test
>     public void testWeakRefDoesntDisappearUnexpectedly() {
>         List<Object> changes = new ArrayList<>();
> 
>         ObservableList<Object> observableList = FXCollections.observableArrayList();
> 
>         SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(observableList);
>         simpleListProperty.addListener((obs, old, current) -> changes.add(current));
> 
>         simpleListProperty = null;
> 
>         observableList.add("A");
> 
>         assertEquals(1, changes.size());
> 
>         System.gc();
> 
>         observableList.add("B");
> 
>         assertEquals(2, changes.size());
>     }
> 
> This test highlights the following issues:
> - Weak references don't disappear instantly; they may disappear at any time or never, at the digression of your JVM; the first change we do to `observableList` may be picked up or not, it's unpredictable.  In real applications, this exhibits itself as "works on my machine" or "seems to work for a while, but then breaks".
> - The second change doesn't get picked up, but it still might.  It depends on the mood of the garbage collector.  This can show up in real applications as phantom changes being triggered by objects that are supposedly no longer in use.
> 
> And finally, why would we expect that the outcome is anything but what the test says?  I registered a listener, I didn't unregister it, it's there, it's registering changes made to an observable list and putting those in another list for later use.  Why would this test fail at all?  Explaining what's happening here to JavaFX novices is impossible. We're relying here on a fundamental JVM system, that is largely unspecified in how it behaves exactly (and with good reason), for a very basic but crucial feature.
> 
> The way I see it, `ListProperty` should work as follows:
> 
> 1) When created, it registers nothing to anything; this will allow it to go out of scope (currently it can't, as it registers on `ObservableList` which will point back to it).
> 
> 2) When any listener is registered to it (or to its `empty` or `size` properties), it registers on the underlying `ObservableList`; when all listeners are gone, it unregisters from the underlying `ObservableList`.  This is what you would want; if I'm listening to something, I don't want this to disappear for any reason.
> 
> 3) `bind` / `unbind` can stay as they are; when you bind to another property, that other property gets a listener and registers with its underlying `ObservableList`.  When `unbind` gets called, that listener is removed again (and potentially, the other property unregisters from its underlying `ObservableList` if that was the only listener).  Before this would break, as the `ObservableList` would still be pointing to the other list property (as a listener is present) and the now unbound property, which also refers that `ObservableList` now (whether that's good or bad) will then keep an indirect reference to that other property (previously bound property -> observable list -> other property).
> 
> No weak listeners are needed anywhere now, and everything will be nice and predictable.
> 
> I'll attempt to make a PoC for this.

@hjohn 
I guess it would be possible to make "bind" use strong references. But then we must do the same for the "normal properties". And doing that would probably break half of JavaFX and many many projects. So for consistency, the bind in ListProperty has to be weak. And honestly, I prefer it to be weak - I guess it's a matter of opinion. But many things in JavaFX wouldn't work if bind wouldn't weak by default.

Since I'm writing unit tests for the "memory behavior" with my library JMemoryBuddy, getting WeakReferences correct is now also much easier! (It can write both tests to check whether something is collectible, or whether it's not collectible.) 




I've just merged the PR with master, so it's now possible again to merge it!

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

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

From lkostyra at openjdk.org  Thu Jan 12 11:22:17 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 12 Jan 2023 11:22:17 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
Message-ID: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>

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.

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

Commit messages:
 - GlassClipboard: Remove unnecessary changes and debugging leftovers
 - 8290092: Temporary files are kept when call Clipboard.getSystemClipboard().getImage()

Changes: https://git.openjdk.org/jfx/pull/994/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=994&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290092
  Stats: 1 line in 1 file changed: 0 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 jbhaskar at openjdk.org  Thu Jan 12 12:31:33 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Thu, 12 Jan 2023 12:31:33 GMT
Subject: RFR: 8298167: Opacity in WebView not working anymore [v5]
In-Reply-To: <xYPpzMUjr_wIqZB0O5zlr_Um81Zb9YQUWHAe_-a2-n8=.529b00c4-85ee-4efa-ba03-8e70bc5122ee@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
 <xYPpzMUjr_wIqZB0O5zlr_Um81Zb9YQUWHAe_-a2-n8=.529b00c4-85ee-4efa-ba03-8e70bc5122ee@github.com>
Message-ID: <c3KR-F837GsdFyQpTHCweohOM3wp1l87FVskGEOe1Lo=.fe30df96-819d-4a15-a631-f21f24231c0e@github.com>

On Wed, 11 Jan 2023 18:58:44 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
>> 
>> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
>> 
>> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed vars in OpacityTest

Test is ok, others files reviewed

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

Marked as reviewed by jbhaskar (Author).

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

From kcr at openjdk.org  Thu Jan 12 12:41:29 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 12 Jan 2023 12:41:29 GMT
Subject: RFR: 8300013: Node.focusWithin doesn't account for nested focused
 nodes
In-Reply-To: <ww_TVGm37cLMSjdbESAnEOvrh8Xtmzt7Jxd7a7kcAqE=.dbe35689-99f7-47c2-a66f-da0850c79fbd@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <ww_TVGm37cLMSjdbESAnEOvrh8Xtmzt7Jxd7a7kcAqE=.dbe35689-99f7-47c2-a66f-da0850c79fbd@github.com>
Message-ID: <_SIN_AunxcHmrOBU0RLpxdEhuPO9qUarLWRGu_xD5YE=.a851150a-acec-482c-901a-0988db2401b7@github.com>

On Thu, 12 Jan 2023 03:15:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I think this should go into JavaFX 20.

I agree. In the (very likely) case it doesn't get reviewed before the fork, I'll ask you to retarget it to the `jfx20` branch.

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

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

From jhendrikx at openjdk.org  Thu Jan 12 12:54:28 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 12 Jan 2023 12:54:28 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <DVv8Yc4WHvHBS-K3sG8eJkiaNu4ntT0XqcnWJ4q7kmE=.450295ed-5656-4e8a-bb02-6830f32a8616@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
 <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
 <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>
 <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>
 <DVv8Yc4WHvHBS-K3sG8eJkiaNu4ntT0XqcnWJ4q7kmE=.450295ed-5656-4e8a-bb02-6830f32a8616@github.com>
Message-ID: <_FFWa14Kw2k8fE3A8s2PzZ_gtx-DIXy6P5zJkidVE78=.264e84db-1062-4864-9fa2-f38da879acb8@github.com>

On Wed, 11 Jan 2023 16:41:04 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>> > Should I expect x here to be unreferenced? No, that's how properties work, b will keep its reference to x.
>>> 
>>> No, x is not dereferenced. But you should expect that a is no longer referencing b, but both a and b are referencing x.
>> 
>> I missed that the test was referencing only the properties, although I suppose the "list like behavior" people might find it surprising to see the previously bound property now suddenly referencing a different `ObservableList`. If that `ObservableList` is supposed to be short lived, then that might be a new kind of memory leak (but nothing that wasn't there before).
>> 
>> The above written as a test, people may find this surprising behavior:
>> 
>>     @Test
>>     public void testListsDontCrossPolinate() {
>>         ObservableList<Object> a = FXCollections.observableArrayList("A");
>>         ObservableList<Object> b = FXCollections.observableArrayList("A", "B", "C");
>> 
>>         SimpleListProperty<Object> propA = new SimpleListProperty<>(a);
>>         SimpleListProperty<Object> propB = new SimpleListProperty<>(b);
>> 
>>         propA.bind(propB);
>> 
>>         assertEquals(3, propA.get().size());  // Note: if you remove this line, the old code fails badly...
>> 
>>         propA.unbind();
>> 
>>         propA.get().add("A");
>> 
>>         assertEquals(4, propA.get().size());
>>         assertEquals(4, propB.get().size());
>>     }
>> 
>>> If you think the PR creates an unwanted behavior, I would appreciate seeing a **unit-test** for it, because it's way easier to discuss on the basis of a test.
>> 
>> Here is one that passed with the old version, which highlights the standard gotcha's of all uses of weak references:
>> 
>>     @Test
>>     public void testWeakRefDoesntDisappearUnexpectedly() {
>>         List<Object> changes = new ArrayList<>();
>> 
>>         ObservableList<Object> observableList = FXCollections.observableArrayList();
>> 
>>         SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(observableList);
>>         simpleListProperty.addListener((obs, old, current) -> changes.add(current));
>> 
>>         simpleListProperty = null;
>> 
>>         observableList.add("A");
>> 
>>         assertEquals(1, changes.size());
>> 
>>         System.gc();
>> 
>>         observableList.add("B");
>> 
>>         assertEquals(2, changes.size());
>>     }
>> 
>> This test highlights the following issues:
>> - Weak references don't disappear instantly; they may disappear at any time or never, at the digression of your JVM; the first change we do to `observableList` may be picked up or not, it's unpredictable.  In real applications, this exhibits itself as "works on my machine" or "seems to work for a while, but then breaks".
>> - The second change doesn't get picked up, but it still might.  It depends on the mood of the garbage collector.  This can show up in real applications as phantom changes being triggered by objects that are supposedly no longer in use.
>> 
>> And finally, why would we expect that the outcome is anything but what the test says?  I registered a listener, I didn't unregister it, it's there, it's registering changes made to an observable list and putting those in another list for later use.  Why would this test fail at all?  Explaining what's happening here to JavaFX novices is impossible. We're relying here on a fundamental JVM system, that is largely unspecified in how it behaves exactly (and with good reason), for a very basic but crucial feature.
>> 
>> The way I see it, `ListProperty` should work as follows:
>> 
>> 1) When created, it registers nothing to anything; this will allow it to go out of scope (currently it can't, as it registers on `ObservableList` which will point back to it).
>> 
>> 2) When any listener is registered to it (or to its `empty` or `size` properties), it registers on the underlying `ObservableList`; when all listeners are gone, it unregisters from the underlying `ObservableList`.  This is what you would want; if I'm listening to something, I don't want this to disappear for any reason.
>> 
>> 3) `bind` / `unbind` can stay as they are; when you bind to another property, that other property gets a listener and registers with its underlying `ObservableList`.  When `unbind` gets called, that listener is removed again (and potentially, the other property unregisters from its underlying `ObservableList` if that was the only listener).  Before this would break, as the `ObservableList` would still be pointing to the other list property (as a listener is present) and the now unbound property, which also refers that `ObservableList` now (whether that's good or bad) will then keep an indirect reference to that other property (previously bound property -> observable list -> other property).
>> 
>> No weak listeners are needed anywhere now, and everything will be nice and predictable.
>> 
>> I'll attempt to make a PoC for this.
>
>> Here is one that passed with the old version, which highlights the standard gotcha's of all uses of weak references:
>> 
>> ```
>> @Test
>> public void testWeakRefDoesntDisappearUnexpectedly() {
>>     List<Object> changes = new ArrayList<>();
>> 
>>     ObservableList<Object> observableList = FXCollections.observableArrayList();
>> 
>>     SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(observableList);
>>     simpleListProperty.addListener((obs, old, current) -> changes.add(current));
>> 
>>     simpleListProperty = null;
>> 
>>     observableList.add("A");
>> 
>>     assertEquals(1, changes.size());
>> 
>>     System.gc();
>> 
>>     observableList.add("B");
>> 
>>     assertEquals(2, changes.size());
>> }
>> ```
>> 
>> This test highlights the following issues:
>> 
>> * Weak references don't disappear instantly; they may disappear at any time or never, at the digression of your JVM; the first change we do to `observableList` may be picked up or not, it's unpredictable.  In real applications, this exhibits itself as "works on my machine" or "seems to work for a while, but then breaks".
>> * The second change doesn't get picked up, but it still might.  It depends on the mood of the garbage collector.  This can show up in real applications as phantom changes being triggered by objects that are supposedly no longer in use.
>> 
>> And finally, why would we expect that the outcome is anything but what the test says? I registered a listener, I didn't unregister it, it's there, it's registering changes made to an observable list and putting those in another list for later use. Why would this test fail at all? Explaining what's happening here to JavaFX novices is impossible. We're relying here on a fundamental JVM system, that is largely unspecified in how it behaves exactly (and with good reason), for a very basic but crucial feature.
> 
> The test fails (or doesn't) because it relies on side-effects of a weakly reachable object. I don't think that this is a JavaFX-specific issue, it's a general issue with garbage-collected environments. More to the point: I think it's more surprising to find out that this test would actually consistently pass. Java developers know that they can't rely on weakly-reachable objects, so why would they suddenly expect such an object to have well-defined side effects?
> 
>> The way I see it, `ListProperty` should work as follows:
>> 
>> 1. When created, it registers nothing to anything; this will allow it to go out of scope (currently it can't, as it registers on `ObservableList` which will point back to it).
>> 2. When any listener is registered to it (or to its `empty` or `size` properties), it registers on the underlying `ObservableList`; when all listeners are gone, it unregisters from the underlying `ObservableList`.  This is what you would want; if I'm listening to something, I don't want this to disappear for any reason.
>> 3. `bind` / `unbind` can stay as they are; when you bind to another property, that other property gets a listener and registers with its underlying `ObservableList`.  When `unbind` gets called, that listener is removed again (and potentially, the other property unregisters from its underlying `ObservableList` if that was the only listener).  Before this would break, as the `ObservableList` would still be pointing to the other list property (as a listener is present) and the now unbound property, which also refers that `ObservableList` now (whether that's good or bad) will then keep an indirect reference to that other property (previously bound property -> observable list -> other property).
>> 
>> No weak listeners are needed anywhere now, and everything will be nice and predictable.
>> 
>> I'll attempt to make a PoC for this.
> 
> I don't think this is how ?ListProperty` should work.
> 
> Fundamentally, we're talking about this scenario:
> 
> ObservableList<Object> list = FXCollections.observableArrayList();
> ListProperty<Object> listProperty = new SimpleListProperty<>(list);
> 
> 
> Under no circumstance should `list` ever hold a strong reference to `listProperty`. Your proposal would make a strong reference contingent upon registering listeners on `listProperty`.
> 
> But that's not relevant: why should `listProperty` be kept alive if it is only weakly reachable from its subscribed listeners (or anyone else, for that matter)? As a user, that's not what I would expect if I only added listeners to `listProperty` (note: I didn't add any listeners to `list` itself). `ObjectProperty` doesn't behave like this; instead, `ObjectProperty` can become weakly reachable even if the contained object doesn't.
> 
> The purpose of this PR is to break the strong reference from `list` to `listProperty`, and I think that's the right thing to do.

@mstr2 

> The test fails (or doesn't) because it relies on side-effects of a weakly reachable object. 

I know, because JavaFX made it so, other frameworks do not have this problem.  This problem does not happen with other Java code where things are handed off to be done in the background or via call back. Java threads for example don't need to be referenced to keep working, nor do Animations or Timelines, nor do other property based solutions (reactfx) nor do a hundred other examples where a callback is registered via some intermediate object. The intermediate object does not need to be referenced for it to keep working.

What's worse, this is everywhere. My example is just the most banal, but it happens unpredictably in JavaFX with little warning. Let's say I expose something that you might want to observe:

      ObservableValue<String> currentTimeOfDay() {  ...  }

And I add a listener to it:

      x.currentTimeOfDay().addListener((obs, old, current) -> System.out.println("Time now is: " + current));

You can say exactly **nothing** about the functioning of this code when working with JavaFX.  You **must** look at the implementation of `currentTimeOfDay` to infer anything about this code.  It may work forever, or it may break randomly.  To make it work for sure, you would need to store the reference you got from `currentTimeOfDay()`.  This is because it depends on the runtime type of what `currentTimeOfDay` returns -- the promises made by the `ObservableValue` interface are taken very lightly by JavaFX.

For example, does it return a property (`instanceof StringProperty`), like `SimpleStringProperty`, which must be a direct field somewhere so it can be updated?  It will keep working fine.  Does it perhaps build the time of day for you with a few `concat`s using separate fields?

     return hours.concat(":").concat(minutes).concat(":").concat(seconds);

Or perhaps we refactored it as such later?  Now the caller code breaks.  Or perhaps some of the callers break, but others don't.  Some of the callers may be in another module.  Perhaps used by another team.

In isolation this may all seem reasonable (certainly not trivial) and you should "keep in mind that JavaFX uses weak references", but in larger applications, there are more and more abstractions, properties are not always what they seem and may change.  There's nothing worse than bugs that will pass most unit tests and fail randomly in production (on user machines) when GC has time to run.  

We've traded potential memory leaks for concurrency issues.  Memory leaks which can be relatively easily and deterministically analyzed with heap dumps VS higher level application logic breaking randomly defying easy analysis, similar to concurrency issues (I've had to run JavaFX applications with `System.gc()` being called every second to find such bugs).  Such bugs can be so hard to debug for even experienced developers that they give up and blame bugs in the framework for the random behavior -- they may give up on JavaFX entirely after such an experience and see it as something to avoid for their next project.

> I don't think that this is a JavaFX-specific issue, it's a general issue with garbage-collected environments. 

I'm not sure what you're getting at, GC'd environments have nothing to do with this. GC is transparent, does not affect normal operations of code and doesn't generally act as a concurrent thread that can change the state of your objects randomly. It's weak reference use that is the culprit... most GC'd languages don't even support weak references. The test even proofs the problem is weak references, it worked before this change introduced additional weak references.

> More to the point: I think it's more surprising to find out that this test would actually consistently pass. Java developers know that they can't rely on weakly-reachable objects, so why would they suddenly expect such an object to have well-defined side effects?

We will have to disagree here. The surprising part is definitely that this magically stops working (and unpredictably at that). How you could possibly think that "keeps working" vs "stops randomly due to background thread interaction with GC" is the more surprising outcome here I find hard to follow.

I tell the system:

- Wrap this list in a property
- Add a listener to the property to monitor the list
- Listener prints changes

In JavaFX, that can break if I didn't:

- Hold a strong reference to the property that wraps the list (because multiple other threads that I didn't create and run in the background and which normally never visibly interfere with any Java code may decide to "undo" the work I just did)

It's about the same as:

- I create a background function
- I wrap this in a thread
- I start the thread

It would be rather annoying if that stopped working randomly if I forgot to keep a strong reference to the thread.

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

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

From jhendrikx at openjdk.org  Thu Jan 12 13:09:22 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 12 Jan 2023 13:09:22 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: <_FFWa14Kw2k8fE3A8s2PzZ_gtx-DIXy6P5zJkidVE78=.264e84db-1062-4864-9fa2-f38da879acb8@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <oXL5NL5UuSrgQSr89nzO518QKFXgk4MgfSw48BtUkZw=.7a04e078-72e9-430a-bd4c-e25e0d78c163@github.com>
 <4V6fnCAcqUjWDR6rI2yVL-0-Y3a8I8J7nL648G051ns=.4d6a244b-46d7-477f-be33-7285b6e5be60@github.com>
 <twGYycjkbEn2iKjtvgVfEl25qpt3-QMCsV2S9esMkhw=.088c4fac-f387-41c8-973c-f92e24cd434b@github.com>
 <Ni1CyblJbadaYqQbnUttipmD0gxhP4wbsnqmYSNVwgs=.e0f1601b-b021-48c4-983b-1aa1a2eb58f1@github.com>
 <DVv8Yc4WHvHBS-K3sG8eJkiaNu4ntT0XqcnWJ4q7kmE=.450295ed-5656-4e8a-bb02-6830f32a8616@github.com>
 <_FFWa14Kw2k8fE3A8s2PzZ_gtx-DIXy6P5zJkidVE78=.264e84db-1062-4864-9fa2-f38da879acb8@github.com>
Message-ID: <b4GkfRzNBTWt77JoUf7rvFfIHi7Qf07GT75_fobX3Kw=.2c615110-17eb-4ec5-acbd-b3964943f64b@github.com>

On Thu, 12 Jan 2023 12:51:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> Here is one that passed with the old version, which highlights the standard gotcha's of all uses of weak references:
>>> 
>>> ```
>>> @Test
>>> public void testWeakRefDoesntDisappearUnexpectedly() {
>>>     List<Object> changes = new ArrayList<>();
>>> 
>>>     ObservableList<Object> observableList = FXCollections.observableArrayList();
>>> 
>>>     SimpleListProperty<Object> simpleListProperty = new SimpleListProperty<>(observableList);
>>>     simpleListProperty.addListener((obs, old, current) -> changes.add(current));
>>> 
>>>     simpleListProperty = null;
>>> 
>>>     observableList.add("A");
>>> 
>>>     assertEquals(1, changes.size());
>>> 
>>>     System.gc();
>>> 
>>>     observableList.add("B");
>>> 
>>>     assertEquals(2, changes.size());
>>> }
>>> ```
>>> 
>>> This test highlights the following issues:
>>> 
>>> * Weak references don't disappear instantly; they may disappear at any time or never, at the digression of your JVM; the first change we do to `observableList` may be picked up or not, it's unpredictable.  In real applications, this exhibits itself as "works on my machine" or "seems to work for a while, but then breaks".
>>> * The second change doesn't get picked up, but it still might.  It depends on the mood of the garbage collector.  This can show up in real applications as phantom changes being triggered by objects that are supposedly no longer in use.
>>> 
>>> And finally, why would we expect that the outcome is anything but what the test says? I registered a listener, I didn't unregister it, it's there, it's registering changes made to an observable list and putting those in another list for later use. Why would this test fail at all? Explaining what's happening here to JavaFX novices is impossible. We're relying here on a fundamental JVM system, that is largely unspecified in how it behaves exactly (and with good reason), for a very basic but crucial feature.
>> 
>> The test fails (or doesn't) because it relies on side-effects of a weakly reachable object. I don't think that this is a JavaFX-specific issue, it's a general issue with garbage-collected environments. More to the point: I think it's more surprising to find out that this test would actually consistently pass. Java developers know that they can't rely on weakly-reachable objects, so why would they suddenly expect such an object to have well-defined side effects?
>> 
>>> The way I see it, `ListProperty` should work as follows:
>>> 
>>> 1. When created, it registers nothing to anything; this will allow it to go out of scope (currently it can't, as it registers on `ObservableList` which will point back to it).
>>> 2. When any listener is registered to it (or to its `empty` or `size` properties), it registers on the underlying `ObservableList`; when all listeners are gone, it unregisters from the underlying `ObservableList`.  This is what you would want; if I'm listening to something, I don't want this to disappear for any reason.
>>> 3. `bind` / `unbind` can stay as they are; when you bind to another property, that other property gets a listener and registers with its underlying `ObservableList`.  When `unbind` gets called, that listener is removed again (and potentially, the other property unregisters from its underlying `ObservableList` if that was the only listener).  Before this would break, as the `ObservableList` would still be pointing to the other list property (as a listener is present) and the now unbound property, which also refers that `ObservableList` now (whether that's good or bad) will then keep an indirect reference to that other property (previously bound property -> observable list -> other property).
>>> 
>>> No weak listeners are needed anywhere now, and everything will be nice and predictable.
>>> 
>>> I'll attempt to make a PoC for this.
>> 
>> I don't think this is how ?ListProperty` should work.
>> 
>> Fundamentally, we're talking about this scenario:
>> 
>> ObservableList<Object> list = FXCollections.observableArrayList();
>> ListProperty<Object> listProperty = new SimpleListProperty<>(list);
>> 
>> 
>> Under no circumstance should `list` ever hold a strong reference to `listProperty`. Your proposal would make a strong reference contingent upon registering listeners on `listProperty`.
>> 
>> But that's not relevant: why should `listProperty` be kept alive if it is only weakly reachable from its subscribed listeners (or anyone else, for that matter)? As a user, that's not what I would expect if I only added listeners to `listProperty` (note: I didn't add any listeners to `list` itself). `ObjectProperty` doesn't behave like this; instead, `ObjectProperty` can become weakly reachable even if the contained object doesn't.
>> 
>> The purpose of this PR is to break the strong reference from `list` to `listProperty`, and I think that's the right thing to do.
>
> @mstr2 
> 
>> The test fails (or doesn't) because it relies on side-effects of a weakly reachable object. 
> 
> I know, because JavaFX made it so, other frameworks do not have this problem.  This problem does not happen with other Java code where things are handed off to be done in the background or via call back. Java threads for example don't need to be referenced to keep working, nor do Animations or Timelines, nor do other property based solutions (reactfx) nor do a hundred other examples where a callback is registered via some intermediate object. The intermediate object does not need to be referenced for it to keep working.
> 
> What's worse, this is everywhere. My example is just the most banal, but it happens unpredictably in JavaFX with little warning. Let's say I expose something that you might want to observe:
> 
>       ObservableValue<String> currentTimeOfDay() {  ...  }
> 
> And I add a listener to it:
> 
>       x.currentTimeOfDay().addListener((obs, old, current) -> System.out.println("Time now is: " + current));
> 
> You can say exactly **nothing** about the functioning of this code when working with JavaFX.  You **must** look at the implementation of `currentTimeOfDay` to infer anything about this code.  It may work forever, or it may break randomly.  To make it work for sure, you would need to store the reference you got from `currentTimeOfDay()`.  This is because it depends on the runtime type of what `currentTimeOfDay` returns -- the promises made by the `ObservableValue` interface are taken very lightly by JavaFX.
> 
> For example, does it return a property (`instanceof StringProperty`), like `SimpleStringProperty`, which must be a direct field somewhere so it can be updated?  It will keep working fine.  Does it perhaps build the time of day for you with a few `concat`s using separate fields?
> 
>      return hours.concat(":").concat(minutes).concat(":").concat(seconds);
> 
> Or perhaps we refactored it as such later?  Now the caller code breaks.  Or perhaps some of the callers break, but others don't.  Some of the callers may be in another module.  Perhaps used by another team.
> 
> In isolation this may all seem reasonable (certainly not trivial) and you should "keep in mind that JavaFX uses weak references", but in larger applications, there are more and more abstractions, properties are not always what they seem and may change.  There's nothing worse than bugs that will pass most unit tests and fail randomly in production (on user machines) when GC has time to run.  
> 
> We've traded potential memory leaks for concurrency issues.  Memory leaks which can be relatively easily and deterministically analyzed with heap dumps VS higher level application logic breaking randomly defying easy analysis, similar to concurrency issues (I've had to run JavaFX applications with `System.gc()` being called every second to find such bugs).  Such bugs can be so hard to debug for even experienced developers that they give up and blame bugs in the framework for the random behavior -- they may give up on JavaFX entirely after such an experience and see it as something to avoid for their next project.
> 
>> I don't think that this is a JavaFX-specific issue, it's a general issue with garbage-collected environments. 
> 
> I'm not sure what you're getting at, GC'd environments have nothing to do with this. GC is transparent, does not affect normal operations of code and doesn't generally act as a concurrent thread that can change the state of your objects randomly. It's weak reference use that is the culprit... most GC'd languages don't even support weak references. The test even proofs the problem is weak references, it worked before this change introduced additional weak references.
> 
>> More to the point: I think it's more surprising to find out that this test would actually consistently pass. Java developers know that they can't rely on weakly-reachable objects, so why would they suddenly expect such an object to have well-defined side effects?
> 
> We will have to disagree here. The surprising part is definitely that this magically stops working (and unpredictably at that). How you could possibly think that "keeps working" vs "stops randomly due to background thread interaction with GC" is the more surprising outcome here I find hard to follow.
> 
> I tell the system:
> 
> - Wrap this list in a property
> - Add a listener to the property to monitor the list
> - Listener prints changes
> 
> In JavaFX, that can break if I didn't:
> 
> - Hold a strong reference to the property that wraps the list (because multiple other threads that I didn't create and run in the background and which normally never visibly interfere with any Java code may decide to "undo" the work I just did)
> 
> It's about the same as:
> 
> - I create a background function
> - I wrap this in a thread
> - I start the thread
> 
> It would be rather annoying if that stopped working randomly if I forgot to keep a strong reference to the thread.

> @hjohn I guess it would be possible to make "bind" use strong references. But then we must do the same for the "normal properties". And doing that would probably break half of JavaFX and many many projects. So for consistency, the bind in ListProperty has to be weak. And honestly, I prefer it to be weak - I guess it's a matter of opinion. But many things in JavaFX wouldn't work if bind wouldn't weak by default.

@FlorianKirmaier I'm sorry for burdening your PR with this; weak references are something I think make a framework hard to work with and unpredictable, and every time I see more added I cringe. It's the old "now you have two problems" saying:

- We had memory leak problems (not unexpected when you forgot to clean something up)
- So we added weak references.  
- Now we still have memory leak problems, but we've got hard to debug concurrency problems now as well thanks to interactions with GC background threads.

The fix didn't fix it, and introduced a new, far more illusive, category of problems. How anyone can view this as a win is beyond me.

In the spirit of the "current" way JavaFX does things, I guess this PR is fine.  Perhaps it's too late to do anything about it now.  I still had hopes.

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

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

From rmarchenko at openjdk.org  Thu Jan 12 13:22:27 2023
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 12 Jan 2023 13:22:27 GMT
Subject: Integrated: 8298167: Opacity in WebView not working anymore
In-Reply-To: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
References: <_ZOke42RoMbBlUB7dDTP1BurfhgHukM0a_8WPljgkI4=.a51f3d40-b875-40c6-b2e5-399ab7e74e8d@github.com>
Message-ID: <p1a9Jdfk8DU6CTnZTNjyMUqnZcSbqKgb6xWHsAjy8JE=.36af5e3d-7016-42fb-8376-e33eeb9a68f9@github.com>

On Wed, 11 Jan 2023 07:32:20 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 
> 
> GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue.
> 
> Now the methods are fixed to be used properly in GraphicsContext inheritance chain.

This pull request has now been integrated.

Changeset: 8136b11f
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/8136b11fdc75aba64d8b77cf286097db3e12d6c9
Stats:     76 lines in 3 files changed: 72 ins; 0 del; 4 mod

8298167: Opacity in WebView not working anymore

Reviewed-by: jbhaskar, kcr

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

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

From kcr at openjdk.org  Thu Jan 12 16:22:41 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 12 Jan 2023 16:22:41 GMT
Subject: Integrated: 8299681: Change JavaFX release version to 21
In-Reply-To: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>
References: <JzU3IG2LyR_mw7Ue_opzDTvez7hFzIrOj4yfmBLi3VI=.062d5f7b-8a0d-4ea8-92c2-59baeb4913cd@github.com>
Message-ID: <Ioh3yW6kUh9mjfs9or7Hl1cYNN3wEzI9gaGEnJb5E3M=.2318829b-ce21-420c-b8b5-d005e8f58fd0@github.com>

On Tue, 10 Jan 2023 00:37:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump the version number of JavaFX to 21. I will integrate this to `master` as part of forking the `jfx20` stabilization branch, which is scheduled for Thursday, January 12, 2023 at 16:00 UTC.

This pull request has now been integrated.

Changeset: 23004367
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/23004367dbe18ca9d6747b571744a3d4ab2c13c8
Stats:     5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8299681: Change JavaFX release version to 21

Reviewed-by: arapte, angorya

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

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

From kevin.rushforth at oracle.com  Thu Jan 12 16:43:24 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 12 Jan 2023 08:43:24 -0800
Subject: JavaFX 20 is in Rampdown Phase One (RDP1)
Message-ID: <9bc29f9d-e9fb-37f8-0ec0-80e3547a276f@oracle.com>

 ?JavaFX 20 is now in Rampdown Phase One (RDP1) [1]. We have forked a 
new jfx20 branch [2] for stabilizing the JavaFX 20 release.

Here is the short summary of what this means:

- The master branch of the jfx repo is available for integrating bug 
fixes or enhancements for openjfx21. Most fixes will be integrated to 
master for 21.

- The jfx20 branch of the jfx repo is now open for integrating fixes for 
openjfx20 that meet the RDP1 criteria as outlined below.

- Reviewers and Committers now have an additional responsibility to 
verify the target branch of each pull request.

- I will periodically sync jfx20 --> master, meaning that developers 
should integrate fixes to one or the other, not both


DETAILS:

P1-P3 bug fixes, and test or doc fixes of any priority are good 
candidates for integrating to jfx20 during RDP1. The only hard 
restriction is that enhancements need explicit approval, over and above 
the review of the PR, to go into jfx20. The bar for such approval is 
appropriately high. We also need to be careful to avoid potentially 
risky fixes during this time. Note that these restrictions apply to the 
jfx20 branch. The master branch is open for all openjfx21 fixes, 
including enhancements.

As a reminder, we use a single openjdk/jfx GitHub repo with 
stabilization branches [3] rather than a separate stabilization repo. 
The jfx20 branch is used to stabilize the upcoming openjfx20 release. 
Please be aware of this, especially if you are a Reviewer or Committer 
in the Project. This allows all pull requests to be in the same place, 
but care needs to be taken for any PR that is targeted to jfx20 to 
ensure that it doesn't contain any commits from master after the jfx20 
fork date. What that means is that if you intend a PR to be for jfx20, 
don't merge master into your local source branch!

IMPORTANT: Reviewers and Committers now have an extra responsibility to 
double-check the target branch of each PR that they review, integrate, 
or sponsor. By default a PR will be targeted to `master` which is the 
main development line (OpenJFX 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 OpenJFX 20 and meets the criteria for the current rampdown phase 
(we're in RDP1 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.

We will use the same rules for RDP1 that the JDK uses [4], with the same 
three modifications we did for the previous release:

1. Approval is needed from one of the OpenJFX project leads (not the 
OpenJDK project lead)

2. Since we are not part of the JDK, we need to use labels that do not 
collide with the JDK 20 release. As an obvious choice, derived from the 
JBS fix version, we will use "openjfx20-enhancement-request", 
"openjfx20-enhancement-yes", "openjfx20-enhancement-no" and 
"openjfx20-enhancement-nmi" as corresponding labels.

3. No explicit approval (no JBS label) is needed to integrate P4 bugs to 
the jfx20 branch during RDP1, as long as those bugs have otherwise met 
the usual code review criteria. Having said that, most P4 bugs should 
now go into master for openjfx21, since we do not want to risk anything 
that would destabilize the openjfx20 release without a compelling 
reason. Also, we have only 3 weeks until RDP2 of openjfx20 and we would 
be better served fixing higher priority bugs. Note that doc bugs and 
test bugs of any priority are fine to fix for openjfx20 during this time.

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] https://github.com/openjdk/jfx/branches/all

[4] http://openjdk.org/jeps/3



From angorya at openjdk.org  Thu Jan 12 16:48:22 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 12 Jan 2023 16:48:22 GMT
Subject: RFR: 8137244: Empty Tree/TableView with CONSTRAINED_RESIZE_POLICY is
 not properly resized
Message-ID: <SsYExJCUj8zNt4qxNCMN7QeixSp3AGkViM7W_HCPp_s=.7837a284-ec99-477d-a7b1-0b478f36a5ad@github.com>

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Add data to the tree/table with a constrained resize policy
2. Clear the table
3. Try to resize the tree/table
Expected:
- the tree/table columns get resized
Observed:
- columns are not resized

Caused by an incomplete fix for RT-14855 / JDK-8113886

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

Commit messages:
 - 8137244: cleanup
 - 8137244: constrained resize when empty

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

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

From mstrauss at openjdk.org  Fri Jan 13 04:04:54 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 13 Jan 2023 04:04:54 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes [v2]
In-Reply-To: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
Message-ID: <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>

> When a scene graph contains multiple nested focused nodes (this can happen with `TableView` and other controls), the `focusWithin` bits that are cleared when a focused node is de-focused must only be cleared when there is no other nested node in the scene graph that would also cause `focusWithin` to be set.
> 
> For example, consider a scene graph of nested nodes:
> A -> B -> C -> D
> 
> When B and D are both focused, the scene graph looks like this:
> A(`focusWithin`)
> -> B(`focused`, `focusWithin`)
> -> C(`focusWithin`)
> -> D(`focused`, `focusWithin`)
> 
> When B is de-focused, the `focusWithin` flags must still be preserved because D remains focused.
> 
> This PR fixes the issue by counting the number of times `focusWithin` has been "set", and only clears it when it has been "un-set" an equal number of times.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  refactoring

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/993/files
  - new: https://git.openjdk.org/jfx/pull/993/files/96661623..1508cdbf

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

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

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

From fkirmaier at openjdk.org  Fri Jan 13 09:18:56 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 13 Jan 2023 09:18:56 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v5]
In-Reply-To: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
Message-ID: <aznZwi1BVBlnRt0Ns0YOViO-xwG_WDVbDYQLzQ-rT64=.aab106ca-6588-478c-a8bf-5eb38eb0e0b0@github.com>

> This PR fixes the leak in the mac system menu bar.
> 
> Inside the native code, NewGlobalRef is called for the callable.
> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
> 
> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
> 
> The unit test verifies, that this bug happened without this change, but no longer happens with this change.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8299423
  we now use the junit5 api

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/987/files
  - new: https://git.openjdk.org/jfx/pull/987/files/d1e26d47..5368b802

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

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

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

From fkirmaier at openjdk.org  Fri Jan 13 09:28:36 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 13 Jan 2023 09:28:36 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v8]
In-Reply-To: <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
Message-ID: <N3O9i0DgkpS95L9PXkF9ZAK1wQXNuL85S-5PzzFWTdw=.7cd4f3c3-7a21-41bd-832c-2e44f343b4d7@github.com>

On Thu, 12 Jan 2023 08:53:14 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> 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:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>    
>    # Conflicts:
>    #	modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java
>    #	modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java
>    #	modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>  - JDK-8277848
>    Added tests to ensure no premature garbage collection is happening.
>  - JDK-8277848
>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>  - JDK-8277848
>    Added the 3 requests whitespaces
>  - JDK-8277848
>    Further optimization based code review.
>    This Bugfix should now event improve the performance
>  - JDK-8277848
>    Added missing change
>  - JDK-8277848
>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

To my knowledge, many memory leaks, are not really possible to implement elegantly without weak references.
For that reason, I usually come from the opposite direction, and ask myself, how can I test code with WeakReferences properly.

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

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

From fkirmaier at openjdk.org  Fri Jan 13 09:53:27 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 13 Jan 2023 09:53:27 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v5]
In-Reply-To: <aznZwi1BVBlnRt0Ns0YOViO-xwG_WDVbDYQLzQ-rT64=.aab106ca-6588-478c-a8bf-5eb38eb0e0b0@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <aznZwi1BVBlnRt0Ns0YOViO-xwG_WDVbDYQLzQ-rT64=.aab106ca-6588-478c-a8bf-5eb38eb0e0b0@github.com>
Message-ID: <mePAIFcavq9wPTLhPRdLbv9Zofat7DtG2rH5Vdbr6Rg=.a4246c1a-070e-4a07-82c9-562ac1924cce@github.com>

On Fri, 13 Jan 2023 09:18:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR fixes the leak in the mac system menu bar.
>> 
>> Inside the native code, NewGlobalRef is called for the callable.
>> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
>> 
>> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
>> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
>> 
>> The unit test verifies, that this bug happened without this change, but no longer happens with this change.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8299423
>   we now use the junit5 api

I'm now using the junit5 API, the one CI test failed, due to a connection problem, not related to the PR.

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

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

From fkirmaier at openjdk.org  Fri Jan 13 09:53:31 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 13 Jan 2023 09:53:31 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v4]
In-Reply-To: <vcsIlQaDGRWceiZapFWaO2p-JbDC2nWFo6ZNqgojCzk=.6c50403c-e9ea-4b57-a7da-716380070092@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <SjOgdrDoqwEhzjGMH24fs0Q09LUeJPugu14nXb7gSk0=.c2df3a10-0298-485c-be86-3f498295e82e@github.com>
 <vcsIlQaDGRWceiZapFWaO2p-JbDC2nWFo6ZNqgojCzk=.6c50403c-e9ea-4b57-a7da-716380070092@github.com>
Message-ID: <oTfIt06vqxveLZf8YivM3M7i5wfk0-CIZ4Wfbd_cc3c=.03da40fa-8765-4d44-a492-3616229d4a57@github.com>

On Wed, 11 Jan 2023 19:31:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8299423
>>   Added null check before using the callback
>
> tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 36:
> 
>> 34: import javafx.scene.layout.VBox;
>> 35: import javafx.stage.Stage;
>> 36: import org.junit.*;
> 
> Since this a new class, can you use the JUnit5 API?

done

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

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

From jhendrikx at openjdk.org  Fri Jan 13 12:37:30 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 13 Jan 2023 12:37:30 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v8]
In-Reply-To: <N3O9i0DgkpS95L9PXkF9ZAK1wQXNuL85S-5PzzFWTdw=.7cd4f3c3-7a21-41bd-832c-2e44f343b4d7@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
 <N3O9i0DgkpS95L9PXkF9ZAK1wQXNuL85S-5PzzFWTdw=.7cd4f3c3-7a21-41bd-832c-2e44f343b4d7@github.com>
Message-ID: <2wNSIfztUFGk7iqm9l_lctMsPGC-5ypKBWXoZG7Huuo=.4ea75cd4-5e0c-435a-a75c-64f296fd6a49@github.com>

On Fri, 13 Jan 2023 09:25:24 GMT, Florian Kirmaier <fkirmaier at openjdk.org> 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:
>> 
>>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>>    
>>    # Conflicts:
>>    #	modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java
>>    #	modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java
>>    #	modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java
>>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>>  - JDK-8277848
>>    Added tests to ensure no premature garbage collection is happening.
>>  - JDK-8277848
>>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>>  - JDK-8277848
>>    Added the 3 requests whitespaces
>>  - JDK-8277848
>>    Further optimization based code review.
>>    This Bugfix should now event improve the performance
>>  - JDK-8277848
>>    Added missing change
>>  - JDK-8277848
>>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.
>
> To my knowledge, many memory leaks, are not really possible to implement elegantly without weak references.
> For that reason, I usually come from the opposite direction, and ask myself, how can I test code with WeakReferences properly.

@FlorianKirmaier

> To my knowledge, many memory leaks, are not really possible to implement elegantly without weak references. For that reason, I usually come from the opposite direction, and ask myself, how can I test code with WeakReferences properly.

They aren't leaks when you asked for them to be created. Unexpected memory leaks are the real problem, and JavaFX is the culprit because it does lots of unexpected things:

It stems from the standard classes JavaFX gives us. A `ListProperty` registers **eagerly** upon construction with an `ObservableList`.  If I create a 100 of them in a loop, none of them disappear (assuming no weak listeners are used).  Why does it do this when those properties are unused?  The problem of memory leaks is not so much that they're real memory leaks, the problem is that the user doesn't **expect** there to be leaks from just the construction of a component, because that's not how Java works (even `new Thread` requires `start` before the thread "leaks"):

     new ListProperty<>(observableList);   // -> memory leak, eager listener registration occurred

The above causing a leak is indeed unexpected.  But now take this:

     new ListProperty<>(observableList).emptyProperty().addListener( ... );

This is not a leak.  The listener was added by the user, and it should keep working until the user removes it.  The user expects this to work, and can reasonable expect there to be some memory allocated to keep it working, until such time the user undoes this action.

Now, the first example can be fixed in two ways:

1) Use weak listeners.
2) Don't register listeners until the user actually needs them

Option 1 breaks the second example and leads to **new** problems; those new problems are even harder to debug than a simple memory leak, as all the elaborate tests all over the JavaFX code base that rely on `System.gc()` clearly show.  It doesn't solve the problem fully either, so now we have two problems: Unexpected memory leaks are still a problem (as JavaFX keeps doing things that are "unexpected" from a user perspective), and we now have to deal with unexpected memory reclamation because some vague rule was broken that you must keep a reference to some things, but not others (see other post that you can't rely on this at all when dealing with API's that provide properties).

Option 2 leads to several benefits; no listeners being registered until needed means less memory use, less "events" being send between components unnecessarily and the main benefit, no memory leaks that the user didn't specifically ask for.  This is how a major problem was fixed in `Node` where listeners were registered on `Scene` and `Window` for each and every node in a scene.  Those listeners weren't necessary as they weren't actually used by the user, yet they were eagerly registered causing tens of thousands of listeners (on a single property) for large scenes.

Use of weak listeners are a cure worse than the disease, because the second case now breaks randomly. We've traded a fairly tractable problem with a far worse problem.  Weak references have their place, but using them to second guess the users idea of what should be in memory and what shouldn't be is not one of them.  Their use cases are limited to associating data with objects whose life times or fields you do not control, and to respond to memory pressure.  Using them to clean up eagerly registered listeners to fix unexpected coupling between components is beyond ridiculous. Memory leaks have been replaced with overzealous memory reclamation, to great surprise of the user.

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

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

From aghaisas at openjdk.org  Fri Jan 13 12:44:32 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 13 Jan 2023 12:44:32 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized controls
 to include the best practice of not using Nodes directly in the item list
Message-ID: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>

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.

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

Commit messages:
 - Doc updates

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

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

From angorya at openjdk.org  Fri Jan 13 16:45:28 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 13 Jan 2023 16:45:28 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <TbCsq_HEK7hB51k5vViUQFPn3-vw-BWDwn_OJ9tjQ4s=.e559216c-6528-42e4-96de-b8c1e5aabc08@github.com>

On Fri, 13 Jan 2023 12:32:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.

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

> 194:  * <p> This example has an anonymous custom {@code ListCell} class in the custom cell factory.
> 195:  * Note that the Rectangle (Node) object needs to be created in the custom {@code ListCell} class
> 196:  * or in it's constructor and updated/used in it's updateItem method.

Do we *really* need a code sample to emphasize the fact that Nodes should not be a part of the data model?  
Would it be better to create a bulleted list which briefly, but succinctly describes the rules that should be followed by the developer?
Having said that, there is a certain benefit of having a code sample as it simplifies writing code via copy-paste.

modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 295:

> 293:  * given cell and update them on demand using the data stored in the item for that cell.
> 294:  *
> 295:  * <p>For example, rather than use the following code:

perhaps instead of dedicating space to incorrect code, we should provide a correct code block only, emphasizing the fact that the data model must not contain Nodes, in text?

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

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

From kcr at openjdk.org  Fri Jan 13 16:52:42 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 13 Jan 2023 16:52:42 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list
In-Reply-To: <TbCsq_HEK7hB51k5vViUQFPn3-vw-BWDwn_OJ9tjQ4s=.e559216c-6528-42e4-96de-b8c1e5aabc08@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <TbCsq_HEK7hB51k5vViUQFPn3-vw-BWDwn_OJ9tjQ4s=.e559216c-6528-42e4-96de-b8c1e5aabc08@github.com>
Message-ID: <lgWga_hPO9jhUqHB-GJOo9iFAu-aDa42EvpBJwDWDjo=.73bcd39f-babb-4377-8c79-a08580501729@github.com>

On Fri, 13 Jan 2023 16:39:37 GMT, Andy Goryachev <angorya at openjdk.org> 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.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 196:
> 
>> 194:  * <p> This example has an anonymous custom {@code ListCell} class in the custom cell factory.
>> 195:  * Note that the Rectangle (Node) object needs to be created in the custom {@code ListCell} class
>> 196:  * or in it's constructor and updated/used in it's updateItem method.
> 
> Do we *really* need a code sample to emphasize the fact that Nodes should not be a part of the data model?  
> Would it be better to create a bulleted list which briefly, but succinctly describes the rules that should be followed by the developer?
> Having said that, there is a certain benefit of having a code sample as it simplifies writing code via copy-paste.

I do think having a code sample of the best practices is helpful in this case, given how frequently we see anti-patterns.

> modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 295:
> 
>> 293:  * given cell and update them on demand using the data stored in the item for that cell.
>> 294:  *
>> 295:  * <p>For example, rather than use the following code:
> 
> perhaps instead of dedicating space to incorrect code, we should provide a correct code block only, emphasizing the fact that the data model must not contain Nodes, in text?

After thinking about it further, I agree with Andy. Having a bulleted list of what to avoid, and a code sample of the right way to do it, seems best.

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

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

From andy.goryachev at oracle.com  Fri Jan 13 17:31:41 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 13 Jan 2023 17:31:41 +0000
Subject: Style themes API
In-Reply-To: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
References: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
Message-ID: <DM5PR1001MB2172B6157DB71975064A2A04E5C29@DM5PR1001MB2172.namprd10.prod.outlook.com>

Dear Michael:

Thank you for initiating this discussion and providing a pull request!

I would like to make a few comments and ask your opinion on some of the difficulties the application developers face when confronted with requirements to provide a custom styling or even a completely different look and feel.  I'll try to number the individual topics, but please forgive me if this message turns out to be long and jumbled.


#1 Theme

I wonder if we need to clarify what we mean by the word "theme" in the context of a javaFX application.  Are we talking about colors, fonts, spacing, graphics, or all of the above?  Would a completely different stylesheet like Caspian or Modena be considered a separate theme, or would we rather have a way to modify the standard stylesheet by adding ability to redefine the different aspects such as colors and spacing without making structural changes to the stylesheet itself?


#2 Colors

When talking about colors specifically, the main requirements might be:

  *   change the base colors used by the standard stylesheets, or just Modena
  *   derived colors might use different logic for light and dark themes
  *   have ability to select a group of colors, or "color themes" - such as Light, Dark, Solarized, High Contrast, etc.
  *   pick up the user-defined color preferences from the platform
  *   track the user-defined color preferences at run time
I think most of these (except for platform colors) can be implemented currently at the application level (that is, without introducing new APIs) simply by loading a stylesheet that redefines base colors (e.g. -fx-base), however, it gets complicated when we start deriving colors.  For example, the use of derive() will need to change in order to obtain an esthetically pleasing colors in the dark theme.


#3 Platform Colors

Thank you for researching the preferences provided by the three different platforms.  I wonder if it would make sense to extract that into a separate PR, perhaps as an implementation detail, to be further refined as a part of Desktop replacement for JavaFX?  And, if we are talking about exposing platform colors via APIs, do we want to make it as a part of one giant facility like java.swt.Desktop equivalent, or via individual methods in Platform, or perhaps some other lookup scheme that allows for future extension?
Do you think it could be possible to describe the individual platform properties (what is Windows.UIColor.AccentDark3?), and possibly attempt to map platform-specific properties to a platform-independent set of properties which represent a union of the three major platforms?
There is one more complication - constant changes in the platform design language.  Ideally, any new APIs would support gradual evolution of the platform by, for example, providing methods to query whether particular item is available or not.


#4 Spacing and Font Size

A lot of modern UIs introduced the concept of density (for example, in MS Outlook, Preferences -> General -> Density preference), by making spacing between UI elements larger or smaller (at run time).  Similarly, the font size can be made larger or smaller (Ctrl-+ / Ctrl-- in Firefox).  The font size change affects "em" units, perhaps we need a parallel construct like "space-em" units that is applied to spacing?  Even then, we might need special logic to switch from pixels to fractions of "space-em" for large scales.
How can we enable this functionality, ideally without making drastic changes to the base stylesheet?  Is it even possible?


#5 Programmatic Stylesheet Generation

Somewhere in this discussion we might also consider adding a possibility of generating a stylesheet programmatically, ideally in a type-safe manner, compatible with auto-completion.  jfx17 (I think) added a way to load a stylesheet data url, so it is much easier now, but I think a better way would be to skip the encoding/decoding step and just generate the stylesheet object directly.
Perhaps the ideal scenario, one that makes it possible to adjust every aspect of the application styling, is to generate the complete stylesheet at run time, and possibly passing it to JavaFx in a binary form that does not require parsing.
I understand this is totally separate issue which will no doubt require its own discussion.


What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Saturday, 2023/01/07 at 10:35
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Style themes API
The following PR introduces new APIs to support style themes in JavaFX:
https://github.com/openjdk/jfx/pull/511

As Kevin already indicated, we need to finish the discussion on the
proposed API. I'd like to invite comments or suggestions with regards
to the API to hopefully get a bit of momentum for this feature to make
it into the 21 release.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230113/19da996d/attachment-0001.htm>

From duke at openjdk.org  Fri Jan 13 21:06:34 2023
From: duke at openjdk.org (Pedro Duque Vieira)
Date: Fri, 13 Jan 2023 21:06:34 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v18]
In-Reply-To: <qMP5OXS48mZCPQ1mFF9gPQaOpSQwlbyLNvHn_gqsIEA=.41b65dcf-80db-4f82-ab65-484d15574c63@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
 <qMP5OXS48mZCPQ1mFF9gPQaOpSQwlbyLNvHn_gqsIEA=.41b65dcf-80db-4f82-ab65-484d15574c63@github.com>
Message-ID: <MOwiufYAMtf3i3wQc-7112CPJ2hQbKF9ZgvBsS2seGE=.f817b0ef-1099-4894-ad77-346e06e51f3c@github.com>

On Mon, 9 Jan 2023 18:33:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
>> 
>> ### New APIs in `javafx.graphics`
>> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
>> #### 1. StyleTheme
>> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
>> 
>> /**
>>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>>  * JavaFX nodes in the scene graph.
>>  * <p>
>>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>>  * enabling applications to create dynamic themes that respond to changing user preferences.
>>  * <p>
>>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>>  */
>> public interface StyleTheme {
>>     /**
>>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>>      * <p>
>>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>>      * change notifications.
>>      * 
>>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>>      *           change notifications on the JavaFX application thread.
>>      *
>>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>>      *           to minimize the number of subsequent list change notifications that are fired by the
>>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>>      *           stylesheets.
>>      */
>>     List<String> getStylesheets();
>> }
>> 
>> 
>> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
>> 
>> public class Application {
>>     ...
>>     /**
>>      * Specifies the user-agent stylesheet of the application.
>>      * <p>
>>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>>      * It can be used to provide default styling for UI controls and other nodes.
>>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>>      * <p>
>>      * Before JavaFX 21, built-in themes were selectable using the special user-agent stylesheet constants
>>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>>      * property to a new instance of the corresponding theme class.
>>      * <p>
>>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>>      */
>>     public static StringProperty userAgentStylesheetProperty();
>>     public static String getUserAgentStylesheet();
>>     public static void setUserAgentStylesheet(String url);
>> 
>>     /**
>>      * Specifies the {@link StyleTheme} of the application.
>>      * <p>
>>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>>      * scene graph.
>>      * <p>
>>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>>      * <p>
>>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>>      */
>>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>>     public static StyleTheme getStyleTheme();
>>     public static void setStyleTheme(StyleTheme theme);
>>     ...
>> }
>> 
>> 
>> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
>> 
>> #### 2. Preferences
>> `javafx.application.Platform.Preferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `ObservableMap` and adds several useful methods, as well as the option to register a listener for change notifications:
>> 
>> /**
>>  * Contains UI preferences of the current platform.
>>  * <p>
>>  * {@code Preferences} extends {@link ObservableMap} to expose platform preferences as key-value pairs.
>>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>>  * alternatives to the untyped {@link #get} method.
>>  * <p>
>>  * The preferences that are reported by the platform may be dependent on the operating system version.
>>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>>  * value if the preference is not available.
>>  */
>> public interface Preferences extends ObservableMap<String, Object> {
>>     String getString(String key);
>>     String getString(String key, String fallbackValue);
>> 
>>     Boolean getBoolean(String key);
>>     boolean getBoolean(String key, boolean fallbackValue);
>> 
>>     Color getColor(String key);
>>     Color getColor(String key, Color fallbackValue);
>> }
>> 
>> An instance of `Preferences` can be retrieved via `Platform.getPreferences()`.
>> 
>> Here's a list of the preferences available for Windows, as reported by the [SystemParametersInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow), [GetSysColor](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor) and [Windows.UI.ViewManagement.UISettings.GetColorValue](https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.getcolorvalue) APIs. Deprecated colors are not included.
>> | Windows preferences                                  | Type    |
>> |--------------------------------------|---------|
>> | Windows.SPI.HighContrast             | Boolean |
>> | Windows.SPI.HighContrastColorScheme  | String  |
>> | Windows.SysColor.COLOR_3DFACE        | Color   |
>> | Windows.SysColor.COLOR_BTNTEXT       | Color   |
>> | Windows.SysColor.COLOR_GRAYTEXT      | Color   |
>> | Windows.SysColor.COLOR_HIGHLIGHT     | Color   |
>> | Windows.SysColor.COLOR_HIGHLIGHTTEXT | Color   |
>> | Windows.SysColor.COLOR_HOTLIGHT      | Color   |
>> | Windows.SysColor.COLOR_WINDOW        | Color   |
>> | Windows.SysColor.COLOR_WINDOWTEXT    | Color   |
>> | Windows.UIColor.Background           | Color   |
>> | Windows.UIColor.Foreground           | Color   |
>> | Windows.UIColor.AccentDark3          | Color   |
>> | Windows.UIColor.AccentDark2          | Color   |
>> | Windows.UIColor.AccentDark1          | Color   |
>> | Windows.UIColor.Accent               | Color   |
>> | Windows.UIColor.AccentLight1         | Color   |
>> | Windows.UIColor.AccentLight2         | Color   |
>> | Windows.UIColor.AccentLight3         | Color   |
>> 
>> Here is a list of macOS preferences as reported by `NSColor`'s [UI Element Colors](https://developer.apple.com/documentation/appkit/nscolor/ui_element_colors) and [Adaptable System Colors](https://developer.apple.com/documentation/appkit/nscolor/standard_colors). Deprecated colors are not included.
>> | macOS preferences                                                      | Type    |
>> |----------------------------------------------------------|---------|
>> | macOS.NSColor.labelColor                                 | Color   |
>> | macOS.NSColor.secondaryLabelColor                        | Color   |
>> | macOS.NSColor.tertiaryLabelColor                         | Color   |
>> | macOS.NSColor.quaternaryLabelColor                       | Color   |
>> | macOS.NSColor.textColor                                  | Color   |
>> | macOS.NSColor.placeholderTextColor                       | Color   |
>> | macOS.NSColor.selectedTextColor                          | Color   |
>> | macOS.NSColor.textBackgroundColor                        | Color   |
>> | macOS.NSColor.selectedTextBackgroundColor                | Color   |
>> | macOS.NSColor.keyboardFocusIndicatorColor                | Color   |
>> | macOS.NSColor.unemphasizedSelectedTextColor              | Color   |
>> | macOS.NSColor.unemphasizedSelectedTextBackgroundColor    | Color   |
>> | macOS.NSColor.linkColor                                  | Color   |
>> | macOS.NSColor.separatorColor                             | Color   |
>> | macOS.NSColor.selectedContentBackgroundColor             | Color   |
>> | macOS.NSColor.unemphasizedSelectedContentBackgroundColor | Color   |
>> | macOS.NSColor.selectedMenuItemTextColor                  | Color   |
>> | macOS.NSColor.gridColor                                  | Color   |
>> | macOS.NSColor.headerTextColor                            | Color   |
>> | macOS.NSColor.alternatingContentBackgroundColors         | Color[] |
>> | macOS.NSColor.controlAccentColor                         | Color   |
>> | macOS.NSColor.controlColor                               | Color   |
>> | macOS.NSColor.controlBackgroundColor                     | Color   |
>> | macOS.NSColor.controlTextColor                           | Color   |
>> | macOS.NSColor.disabledControlTextColor                   | Color   |
>> | macOS.NSColor.selectedControlColor                       | Color   |
>> | macOS.NSColor.selectedControlTextColor                   | Color   |
>> | macOS.NSColor.alternateSelectedControlTextColor          | Color   |
>> | macOS.NSColor.currentControlTint                         | String  |
>> | macOS.NSColor.windowBackgroundColor                      | Color   |
>> | macOS.NSColor.windowFrameTextColor                       | Color   |
>> | macOS.NSColor.underPageBackgroundColor                   | Color   |
>> | macOS.NSColor.findHighlightColor                         | Color   |
>> | macOS.NSColor.highlightColor                             | Color   |
>> | macOS.NSColor.shadowColor                                | Color   |
>> | macOS.NSColor.systemBlueColor                            | Color   |
>> | macOS.NSColor.systemBrownColor                           | Color   |
>> | macOS.NSColor.systemGrayColor                            | Color   |
>> | macOS.NSColor.systemGreenColor                           | Color   |
>> | macOS.NSColor.systemIndigoColor                          | Color   |
>> | macOS.NSColor.systemOrangeColor                          | Color   |
>> | macOS.NSColor.systemPinkColor                            | Color   |
>> | macOS.NSColor.systemPurpleColor                          | Color   |
>> | macOS.NSColor.systemRedColor                             | Color   |
>> | macOS.NSColor.systemTealColor                            | Color   |
>> | macOS.NSColor.systemYellowColor                          | Color   |
>> 
>> On Linux, GTK's theme name and [public CSS colors](https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-22/gtk/theme/Adwaita/_colors-public.scss) are reported:
>> | Linux preferences                                                | Type    |
>> |----------------------------------------------------|---------|
>> | GTK.theme_name                                | String  |
>> | GTK.theme_fg_color                    | Color   |
>> | GTK.theme_bg_color                    | Color   |
>> | GTK.theme_base_color                  | Color   |
>> | GTK.theme_selected_bg_color           | Color   |
>> | GTK.theme_selected_fg_color           | Color   |
>> | GTK.insensitive_bg_color              | Color   |
>> | GTK.insensitive_fg_color              | Color   |
>> | GTK.insensitive_base_color            | Color   |
>> | GTK.theme_unfocused_fg_color          | Color   |
>> | GTK.theme_unfocused_bg_color          | Color   |
>> | GTK.theme_unfocused_base_color        | Color   |
>> | GTK.theme_unfocused_selected_bg_color | Color   |
>> | GTK.theme_unfocused_selected_fg_color | Color   |
>> | GTK.borders                           | Color   |
>> | GTK.unfocused_borders                 | Color   |
>> | GTK.warning_color                     | Color   |
>> | GTK.error_color                       | Color   |
>> | GTK.success_color                     | Color   |
>> 
>> ### Built-in themes
>> The two built-in themes `CaspianTheme` and `ModenaTheme` are exposed as public API in the `javafx.scene.control.theme` package. Both classes extend `ThemeBase`, which is a simple `StyleTheme` implementation that allows developers to easily extend the built-in themes.
>> 
>> ### Usage
>> In its simplest form, a style theme is just a static collection of stylesheets:
>> 
>> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
>> 
>> A dynamic theme can be created by returning an instance of `ObservableList`:
>> 
>> public class MyCustomTheme implements StyleTheme {
>>     private final ObservableList<String> stylesheets =
>>         FXCollections.observableArrayList("colors-light.css", "controls.css");
>> 
>>     @Override
>>     public List<String> getStylesheets() {
>>         return stylesheets;
>>     }
>> 
>>     public void setDarkMode(boolean enabled) {
>>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>>     }
>> }
>> 
>> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
>> 
>> Application.setStyleTheme(new ModenaTheme() {
>>     {
>>         addFirst("stylesheet1.css");
>>         addLast("stylesheet2.css");
>>     }
>> });
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed GTK preference keys
>  - Platform.Preferences implements ObservableMap

Hi all,

I?ve seen in the mailing list a request for commenting on this PR and as a long-time theme developer (JMetro and other themes) I'd thought I'd give my 2 cents.

I think it?s a good idea to add the concept of a theme to the JavaFX API! So, thanks for this.

1 - Reading through the javadocs in this PR and the description, I think it?s not clear whether the stylesheets of a StyleTheme will be used as user agent stylesheets or as author stylesheets. It says that StyleThemes have higher precedence than a user agent stylesheet so I suppose they are going to be author stylesheets (?), but there?s no point in the Javadoc where that is explicitly said. If that?s not the case, then I think the opposite should then be explicitly written. I.e. that it will have higher precedence than a user agent stylesheet but it?s not an author stylesheet.

2 ? I think the ability to specify in the StyleTheme whether it is a user agent stylesheet, or an author stylesheet could be of interest. Most of the themes I know are composed of author stylesheets (they use the getStylesheets() API in Scene) so migration to using the StyleTheme API would be easier if one could specify this. Conversely specifying that the StyleTheme is a user agent stylesheet will also be very useful in the cases where we?re creating a theme but don?t want it to override styles specified through code, etc.

3 ? I would really love for JavaFX to have first class support for dark and light modes, and I think this would be the ideal place for it.  One of the problems with how things are right now is that if you create a dark theme with this API or the previous API (using stylesheets) the frames of windows (main windows and dialogs) will still show with a light theme (I see this on Windows, haven?t tested on Mac but I suppose it will be the same). 
So as it is, you can?t fully create a dark theme in JavaFX. The only way would be to call on native code to change the frame of windows (by making a request for the native window to change its appearance to dark mode) which isn?t trivial and would have to be done for the various operating systems and it?s subject to break. 
The other way would be to create your own frames of the windows which I think would be even worse. You?d have to create the frame buttons yourself and all other decorations. If they don?t visually exactly match the ones from the native platform they?re going to look off. You?d also have to do this for all operating systems and for their various versions (various versions of the same OS might have different frame decorations, e.g. win10 vs win11). 
Given that dark and light theme concepts are pervasive across all major operating systems (Windows, Mac, iOS, Android, etc) and it?s a concept that has lasted for years and continues to exist, I think it would be of value to fully support this.

Thanks

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

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

From jgneff at openjdk.org  Fri Jan 13 23:04:58 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Fri, 13 Jan 2023 23:04:58 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v10]
In-Reply-To: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
Message-ID: <Z0eijqD40jR9vY57nuBt_CZ-eknR9ihSXBMGNcBmwh4=.8b17e8c4-2bb1-4d89-9a06-45f78971fde1@github.com>

> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build:
> 
> 
> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
> $ bash gradlew sdk jmods javadoc
> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod
> 
> 
> The three commands:
> 
> 1. set the build timestamp to the date of the latest source code change,
> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and
> 3. recreate the JMOD files with stable file modification times and ordering.
> 
> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18.
> 
> #### Fixes
> 
> There are at least four sources of non-determinism in the JavaFX builds:
> 
> 1. Build timestamp
> 
>     The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`.
> 
> 2. Modification times
> 
>     The JAR, JMOD, and ZIP archives store the modification time of each file.
> 
> 3. File ordering
> 
>     The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing.
> 
> 4. Build path
> 
>     The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module.
> 
> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth.
> 
> [1]: https://reproducible-builds.org/docs/source-date-epoch/
> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism

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

  Support JDK 17 GA or later for building JavaFX

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/446/files
  - new: https://git.openjdk.org/jfx/pull/446/files/0a3dda22..00ece7e5

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

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

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

From jgneff at openjdk.org  Fri Jan 13 23:13:26 2023
From: jgneff at openjdk.org (John Neffenger)
Date: Fri, 13 Jan 2023 23:13:26 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <M2brODqDB9FY9S4QLyrkgWYWn1dLIaJWlbe51ouqaH0=.7caebc5d-2d76-47cc-9cc9-1fc873892d1a@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
 <M2brODqDB9FY9S4QLyrkgWYWn1dLIaJWlbe51ouqaH0=.7caebc5d-2d76-47cc-9cc9-1fc873892d1a@github.com>
Message-ID: <Gu-R5psSrAqFHq0VleW-xWg42tQBio_Jkqx-AX8pg2c=.87ffdc07-f1ab-42a1-8265-9157efddfb0e@github.com>

On Wed, 11 Jan 2023 23:00:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Add '--date' argument for deterministic JMOD files
>>  - Merge branch 'master' into allow-reproducible-builds
>>  - Merge branch 'master' into allow-reproducible-builds
>>  - Comment out 'jmod --date' until building on JDK 19
>>    
>>    Support for the 'jmod --date' option was added to JDK 19 starting
>>    with the 19+2 early-access build, and it was backported to JDK 17
>>    starting with release 17.0.3. It is not available in JDK 18.
>>  - Merge 'master' into allow-reproducible-builds
>>  - Make minimal changes for new '--date' option
>>  - Add new '--date' option to JMOD task
>>  - Add '--source-date' option to JMOD task
>>  - Get build timestamp in UTC and set ZIP timestamps
>>    
>>    Create the build timestamp as a zoned date and time in UTC instead
>>    of a local date and time. If SOURCE_DATE_EPOCH is defined, set the
>>    last modification time of ZIP and JAR entries to the local date and
>>    time in UTC of the instant defined by SOURCE_DATE_EPOCH.
>>    
>>    Add a comment as a reminder to make JMOD files deterministic when
>>    the following enhancements are complete:
>>    
>>    * Enable deterministic file content ordering for Jar and Jmod
>>      https://bugs.openjdk.java.net/browse/JDK-8276764
>>      https://github.com/openjdk/jdk/pull/6395
>>    
>>    * Enable jar and jmod to produce deterministic timestamped content
>>      https://bugs.openjdk.java.net/browse/JDK-8276766
>>      https://github.com/openjdk/jdk/pull/6481
>>  - Merge branch 'master' into allow-reproducible-builds
>>  - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b
>
> build.gradle line 5573:
> 
>> 5571:                         args(srcLegalDir)
>> 5572:                         if (sourceDateEpoch != null) {
>> 5573:                             args("--date", buildTimestamp)
> 
> Since the minimum boot JDK for building JavaFX is still JDK 17 GA, you will need to qualify this with a check for `if (jdk19OrLater)`. See the following for a pattern to use to define that flag:
> 
> https://github.com/openjdk/jfx/blob/1e4c083b90281e91b1e9cbbc615401e89bb933b1/build.gradle#L699-L704
> 
> Btw, the comment in that block should read "based on whether we are _building_ on JDK 18 or later".

Done. The `jmodTask` checks for JDK 19 or later. Let me know if you think we should add the `--date` argument also for versions of JDK 17 later than 17.0.4. My tests indicate that JDK 17.0.5, for example, has enough back-ported features to get reproducible builds of JavaFX in some limited circumstances. I figured it wasn't worth it, though, considering we'll need JDK 20 eventually, anyway.

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

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

From kcr at openjdk.org  Sat Jan 14 00:13:19 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 14 Jan 2023 00:13:19 GMT
Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
 [v8]
In-Reply-To: <Gu-R5psSrAqFHq0VleW-xWg42tQBio_Jkqx-AX8pg2c=.87ffdc07-f1ab-42a1-8265-9157efddfb0e@github.com>
References: <xfSRSFq3M4XJVRE3f2lwPz_uhuBn8GX6YmY6XJwDKA0=.d86490a3-3132-4164-aef5-6b3ec1b88019@github.com>
 <ZR-S6_IZpch9nhndszI1jOZjO9Kuv5bsGd8yg227LBk=.cd53bf20-5d2b-401d-80aa-05c1619ab30e@github.com>
 <M2brODqDB9FY9S4QLyrkgWYWn1dLIaJWlbe51ouqaH0=.7caebc5d-2d76-47cc-9cc9-1fc873892d1a@github.com>
 <Gu-R5psSrAqFHq0VleW-xWg42tQBio_Jkqx-AX8pg2c=.87ffdc07-f1ab-42a1-8265-9157efddfb0e@github.com>
Message-ID: <iv_IxSvgb1--cPPDU2kg5QM226UQOYkTlX41XGqHkC0=.15cea65d-207a-492d-890c-52f442f2a146@github.com>

On Fri, 13 Jan 2023 23:10:24 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> build.gradle line 5573:
>> 
>>> 5571:                         args(srcLegalDir)
>>> 5572:                         if (sourceDateEpoch != null) {
>>> 5573:                             args("--date", buildTimestamp)
>> 
>> Since the minimum boot JDK for building JavaFX is still JDK 17 GA, you will need to qualify this with a check for `if (jdk19OrLater)`. See the following for a pattern to use to define that flag:
>> 
>> https://github.com/openjdk/jfx/blob/1e4c083b90281e91b1e9cbbc615401e89bb933b1/build.gradle#L699-L704
>> 
>> Btw, the comment in that block should read "based on whether we are _building_ on JDK 18 or later".
>
> Done. The `jmodTask` checks for JDK 19 or later. Let me know if you think we should add the `--date` argument also for versions of JDK 17 later than 17.0.4. My tests indicate that JDK 17.0.5, for example, has enough back-ported features to get reproducible builds of JavaFX in some limited circumstances. I figured it wasn't worth it, though, considering we'll need JDK 20 eventually, anyway.

I agree that it isn't worth it. The goal is to make it still buildable with JDK 17, and what you've done does that. Thanks.

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

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

From michaelstrau2 at gmail.com  Sat Jan 14 00:13:47 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 14 Jan 2023 01:13:47 +0100
Subject: Style themes API
In-Reply-To: <DM5PR1001MB2172B6157DB71975064A2A04E5C29@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
 <DM5PR1001MB2172B6157DB71975064A2A04E5C29@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXSW4pt72LmpGgWMQgHDNt=us+RbU0_BnjOjaKdSDz4HhQ@mail.gmail.com>

Hi Andy!

please see my comments below:


On Fri, Jan 13, 2023 at 6:31 PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> #1 Theme
> I wonder if we need to clarify what we mean by the word "theme" in the context of a javaFX application.  Are we talking about colors, fonts, spacing, graphics, or all of the above?  Would a completely different stylesheet like Caspian or Modena be considered a separate theme, or would we rather have a way to modify the standard stylesheet by adding ability to redefine the different aspects such as colors and spacing without making structural changes to the stylesheet itself?


The proposed documentation defines it as: "StyleTheme is a collection
of stylesheets that specify the appearance of UI controls and other
nodes in the application."
So we're talking about everything that can be set via CSS. Caspian and
Modena are two separate themes, but they can be extended by prepending
or appending custom stylesheets.
One way to achieve this is by subclassing the
`javafx.scene.control.theme.CaspianTheme` or
`javafx.scene.control.theme.ModenaTheme` class and using the
`addFirst` and `addLast` methods to add custom stylesheets:

    public class MyTheme extends ModenaTheme {
        public MyTheme() {
            addLast("myColors.css");
        }
    }

Note that `addFirst` and `addLast` are two methods that are specific
to the implementation of Caspian and Modena, these are not
general-purpose methods available for all `StyleTheme`
implementations.
Since both themes are implemented using a single CSS file, there is no
way to fundamentally change the structure of the theme.

However, other theme implementations may offer a different API that
may allow changing the stylesheets that comprise the theme in a
structural way.
For example, a theme implementation might use one stylesheet per
control instead of a single stylesheet for the entire theme, and offer
a way to override or modify individual control stylesheets.



> #2 Colors
> When talking about colors specifically, the main requirements might be:
> change the base colors used by the standard stylesheets, or just Modena
> derived colors might use different logic for light and dark themes
> have ability to select a group of colors, or "color themes" - such as Light, Dark, Solarized, High Contrast, etc.
> pick up the user-defined color preferences from the platform
> track the user-defined color preferences at run time
>
> I think most of these (except for platform colors) can be implemented currently at the application level (that is, without introducing new APIs) simply by loading a stylesheet that redefines base colors (e.g. -fx-base), however, it gets complicated when we start deriving colors.  For example, the use of derive() will need to change in order to obtain an esthetically pleasing colors in the dark theme.


All of these things (except as you say, querying and tracking changes
of platform colors) can be currently implemented by programmatically
composing a monolithic user-agent stylesheet. The advantage of this
approach is that you can use any kind of logic, not just what's
supported by JavaFX CSS functions like derive().



> #3 Platform Colors
> Thank you for researching the preferences provided by the three different platforms.  I wonder if it would make sense to extract that into a separate PR, perhaps as an implementation detail, to be further refined as a part of Desktop replacement for JavaFX?  And, if we are talking about exposing platform colors via APIs, do we want to make it as a part of one giant facility like java.swt.Desktop equivalent, or via individual methods in Platform, or perhaps some other lookup scheme that allows for future extension?
> Do you think it could be possible to describe the individual platform properties (what is Windows.UIColor.AccentDark3?), and possibly attempt to map platform-specific properties to a platform-independent set of properties which represent a union of the three major platforms?
> There is one more complication - constant changes in the platform design language.  Ideally, any new APIs would support gradual evolution of the platform by, for example, providing methods to query whether particular item is available or not.


The platform preferences API is an integral part of the value
proposition of style themes. JavaFX has long included a very limited
form of this (not as public API), built specifically to support
Windows high contrast themes.
I don't think that it makes sense to separate the platform preferences
API from style themes, because
a) the existing support for Windows high contrast themes must continue
to work with the new first-class theme implementations, which requires
new code that will instantly be rendered irrelevant when the platform
preferences API arrives. Not a good investment of our time.
b) leveraging the platform preferences API to support platform
dark/light modes will probably be the first thing that theme
implementers will want to do anyway.

Note that the proposed platform preferences API exposes all kinds of
properties as mappings of key-value pairs. The API reports properties
that are available on the current platform, which might depend on any
number of factors, including the operating system version.
For example, all of the Windows.UIColor properties are not available
on Windows systems running earlier versions than Windows 10 Build
10240. Similarly, properties might be deprecated or removed in future
OS versions.
That's why the documentation of `Platform.Preferences` explains:

    * The preferences that are reported by the platform may be
dependent on the operating system version.
    * Applications should always test whether a preference is
available, or use the {@link #getString(String, String)},
    * {@link #getBoolean(String, boolean)} or {@link #getColor(String,
Color)} overloads that accept a fallback
    * value if the preference is not available.

Another approach to expose platform preferences would be to have Java
classes that mirror platform APIs (for example, something like a
javafx.application.windows.UIColor class).
But I don't see any clear advantage of that, and it's probably not a
good idea to promote platform implementation details to
front-and-center APIs.

One might ask why we should expose platform preferences in JavaFX at
all. Applications could just query the relevant properties themselves.
But that's easier said than done: many platform preferences can only
be queried from native code, and tracking changes of these properties
often requires a level of integration into windowing toolkits (for
example, event loops) that is hard or impossible to achieve in
application code.

Regarding documentation: "Windows.UIColor.AccentDark3" is whatever
Microsoft says it is. I don't think we should interpret what this
means, but we could point users to a relevant Microsoft documentation.
What is the policy of linking to external resources in Javadoc
comments?

Regarding platform-independent properties: Yes, that would be very
useful, but I don't think it should be a core part of JavaFX. As you
already noted, platforms constantly evolve and design trends come and
go. We shouldn't aim for this moving target. Third-party libraries can
build on top of the platform preferences API to provide developers
with platform-independent APIs for common OS features. The question
"what is a meaningful set of common properties" might also have
different answers depending on what theme implementers want to
achieve.



> #4 Spacing and Font Size
> A lot of modern UIs introduced the concept of density (for example, in MS Outlook, Preferences -> General -> Density preference), by making spacing between UI elements larger or smaller (at run time).  Similarly, the font size can be made larger or smaller (Ctrl-+ / Ctrl-- in Firefox).  The font size change affects "em" units, perhaps we need a parallel construct like "space-em" units that is applied to spacing?  Even then, we might need special logic to switch from pixels to fractions of "space-em" for large scales.
>
> How can we enable this functionality, ideally without making drastic changes to the base stylesheet?  Is it even possible?


Some platforms have a text scale preference that can be different from
general UI scale. For example, in Windows this is the
UISettings.TextScaleFactor preference, which is currently not reported
in the style themes PR. I think this should be added to the list of
reported preferences.
That being said, I don't plan on making any changes at all to the
existing themes (Caspian and Modena). These themes are implemented as
monoliths, and it would be a lot of work to refactor them into
reusable, composable parts.

Of course, new theme implementations might support multiple densities,
for example by programmatically composing the stylesheets.



> #5 Programmatic Stylesheet Generation
> Somewhere in this discussion we might also consider adding a possibility of generating a stylesheet programmatically, ideally in a type-safe manner, compatible with auto-completion.  jfx17 (I think) added a way to load a stylesheet data url, so it is much easier now, but I think a better way would be to skip the encoding/decoding step and just generate the stylesheet object directly.
> Perhaps the ideal scenario, one that makes it possible to adjust every aspect of the application styling, is to generate the complete stylesheet at run time, and possibly passing it to JavaFx in a binary form that does not require parsing.
> I understand this is totally separate issue which will no doubt require its own discussion.


That's an interesting option, but it's not a good fit with the
existing stylesheet API, which generally expects a String with either
an inline data-URI or a link to a CSS file.
There's a bit of design space with the new StyleTheme interface, which
is currently defined as:

    interface StyleTheme {
        List<String> getStylesheets();
    }

If the getStylesheets() method returned a List<Object>, we could also
accept user-provided Stylesheet objects (in addition to Strings). What
do you think?

From michaelstrau2 at gmail.com  Sat Jan 14 00:52:19 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 14 Jan 2023 01:52:19 +0100
Subject: Style themes API
In-Reply-To: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
References: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
Message-ID: <CAJEpuXQ5QwBjhn0hTdPFM_r6jhX17rWCqoCCE7qa+vndkovR7A@mail.gmail.com>

Hi Pedro,

please see my comments below:


On Fri, Jan 13, 2023 at 10:06 PM Pedro Duque Vieira <duke at openjdk.org> wrote:
>
> Hi all,
>
> I?ve seen in the mailing list a request for commenting on this PR and as a long-time theme developer (JMetro and other themes) I'd thought I'd give my 2 cents.
>
> I think it?s a good idea to add the concept of a theme to the JavaFX API! So, thanks for this.
>
> 1 - Reading through the javadocs in this PR and the description, I think it?s not clear whether the stylesheets of a StyleTheme will be used as user agent stylesheets or as author stylesheets. It says that StyleThemes have higher precedence than a user agent stylesheet so I suppose they are going to be author stylesheets (?), but there?s no point in the Javadoc where that is explicitly said. If that?s not the case, then I think the opposite should then be explicitly written. I.e. that it will have higher precedence than a user agent stylesheet but it?s not an author stylesheet.


Theme stylesheets have a higher precedence than the application's
user-agent stylesheet, but a lower precedence than author stylesheets.
This is stated in the JavaFX CSS reference (cssref.html):

    * The JavaFX CSS implementation applies the following
    * order of precedence: a style from a user agent style sheet or a
style theme has lower
    * priority than a value set from code, which has lower priority than a Scene
    * or Parent style sheet.

We could include similar language in the javadoc.



> 2 ? I think the ability to specify in the StyleTheme whether it is a user agent stylesheet, or an author stylesheet could be of interest. Most of the themes I know are composed of author stylesheets (they use the getStylesheets() API in Scene) so migration to using the StyleTheme API would be easier if one could specify this. Conversely specifying that the StyleTheme is a user agent stylesheet will also be very useful in the cases where we?re creating a theme but don?t want it to override styles specified through code, etc.


I deliberately wanted to minimize changes to the CSS subsystem in
order to prevent introducing regressions in that area of the codebase.
As a result, the proposed implementation treats theme stylesheets as a
list of user-agent stylesheets, and optionally adds the application's
user-agent stylesheet as the first item in that list. Note that
`javafx.css.StyleOrigin` is also unchanged; you won't know whether a
`StyleOrigin.USER_AGENT` stylesheet is the application's user-agent
stylesheet, or one of its theme stylesheets.



> 3 ? I would really love for JavaFX to have first class support for dark and light modes, and I think this would be the ideal place for it.  One of the problems with how things are right now is that if you create a dark theme with this API or the previous API (using stylesheets) the frames of windows (main windows and dialogs) will still show with a light theme (I see this on Windows, haven?t tested on Mac but I suppose it will be the same).
> So as it is, you can?t fully create a dark theme in JavaFX. The only way would be to call on native code to change the frame of windows (by making a request for the native window to change its appearance to dark mode) which isn?t trivial and would have to be done for the various operating systems and it?s subject to break.
> The other way would be to create your own frames of the windows which I think would be even worse. You?d have to create the frame buttons yourself and all other decorations. If they don?t visually exactly match the ones from the native platform they?re going to look off. You?d also have to do this for all operating systems and for their various versions (various versions of the same OS might have different frame decorations, e.g. win10 vs win11).
> Given that dark and light theme concepts are pervasive across all major operating systems (Windows, Mac, iOS, Android, etc) and it?s a concept that has lasted for years and continues to exist, I think it would be of value to fully support this.

There's a role for third-party libraries here, and I think APIs for
dark/light mode and other things can be done there.
Supporting dark/light window frames is quite independent from the
proposed style theme API, and should be done in a separate PR.
I understand that it might be nice to have a comprehensive dark/light
mode API in JavaFX, but there's a value in not going there and leaving
that to libraries instead. I'd rather keep this feature as simple as
it gets without sacrificing its unique capabilities. We can always
come back and add more API surface if it turns out that we're really
missing something.

From nlisker at openjdk.org  Sat Jan 14 10:31:12 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 14 Jan 2023 10:31:12 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <ezDs8_jL-WjBI0tvz1SV2YyqIF3F7xxu6lLCpEIHYX8=.562a77a8-725e-4e00-afca-60489f60e466@github.com>

On Fri, 13 Jan 2023 12:32:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.

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

> 194:  * <p> This example has an anonymous custom {@code ListCell} class in the custom cell factory.
> 195:  * Note that the Rectangle (Node) object needs to be created in the custom {@code ListCell} class
> 196:  * or in it's constructor and updated/used in it's updateItem method.

* it's -> its (both places)
* `updateItem` should be in `@code`.

Same for the other classes.

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

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

From nlisker at openjdk.org  Sat Jan 14 10:46:12 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 14 Jan 2023 10:46:12 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <9NPNQpFM10G3fbrgI7ojbTgAWpgjLt-yCOKL8Debb1w=.26f09845-117b-4707-a2ff-2952a4f47847@github.com>

On Fri, 13 Jan 2023 12:32:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.

Instead of repeating this in every class, maybe writing it once in `Cell` and linking to it from these classes will be better?

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

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

From swpalmer at gmail.com  Sun Jan 15 00:31:00 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Sat, 14 Jan 2023 19:31:00 -0500
Subject: CSS Color functions
Message-ID: <CAL3e5iHJg0ntJRFtL08jPwgh53CYm_bQ7_j3Sw7i2RmPZ27Eqg@mail.gmail.com>

I was looking at Modena.css and came across this:

    /* A bright blue for the focus indicator of objects. Typically used as
the
     * first color in -fx-background-color for the "focused" pseudo-class.
Also
     * typically used with insets of -1.4 to provide a glowing effect.
     */
    -fx-focus-color: #039ED3;
    -fx-faint-focus-color: #039ED322;

I noticed two things pertaining to -fx-faint-focus-color.  Although I've
used this form to specify colors myself, the JavaFX CSS Reference Guide at
https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor
does
not mention being able to use an 8-digit form of #rrggbbaa when using hex
digits. Only the 3- and 6-digit forms of hexadecimal RGB are mentioned. RGB
+ Alpha colors are only documented in the form of rgba(#,#,#,#) and
rgba(#%,#%,#%,#).

More importantly, this is a copy of -fx-focus-color with an added alpha
channel, but it's created by repeating the literal color value and
appending the alpha component, rather than somehow deriving it from
-fx-focus-color.  Similar repetition is needed for the semi-transparent
chart colors.

Would it make sense to add support for something similar to derive( <color>
, <number>% ) to specify a color based on an existing color with a new
value for the alpha channel (or any other) value? Maybe a color-transform
method that would do for an RGBA color vector what other transforms do for
spatial coordinates?*

Regards,

Scott

* Note: It seems future CSS standards are looking for ways to do similar
things.  A color-mod function was proposed in
https://www.w3.org/TR/2016/WD-css-color-4-20160705/#funcdef-color-mod but
removed in the next revision
https://www.w3.org/TR/2022/CRD-css-color-4-20221101/#changes-from-20160705.
I'm not following CSS development closely, but some googling suggests the
next proposal is based on a new keyword 'from' to create derived colors.
E.g rgb(from skyblue, 255 g b) to get a color based on skyblue with a red
component of 255.  This is mentioned here
https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198  I'm
skeptical that it is worth waiting for the dust to settle on the CSS
standard, but supporting whatever they come up with is a possibility.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230114/8449a802/attachment-0001.htm>

From pedro.duquevieira at gmail.com  Sun Jan 15 12:25:48 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sun, 15 Jan 2023 12:25:48 +0000
Subject: Style themes API
Message-ID: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>

Hi Michael,

Thanks again for taking the time to answer my questions/comments and for
your efforts in coming forward with this new API proposal. And also thanks
for your patience as I can be a bit annoying at times. :)
There's of course a bunch of things I liked about your API proposal but for
the sake of time I specifically only commented on what I thought could
change and not on what I liked (I don't have much free spare time at the
moment, unfortunately). There's of course your idea itself of adding a
Theme API which I agree with.

Answering your comments below:

Theme stylesheets have a higher precedence than the application's
> user-agent stylesheet, but a lower precedence than author stylesheets.
> This is stated in the JavaFX CSS reference (cssref.html):


    * The JavaFX CSS implementation applies the following
>     * order of precedence: a style from a user agent style sheet or a
> style theme has lower
>     * priority than a value set from code, which has lower priority than a
> Scene
>     * or Parent style sheet.


We could include similar language in the javadoc.


I think we could add that it has higher precedence than a user agent
stylesheets but that's it's not an author stylesheet. We can also possibly
briefly say what a user agent stylesheet and author stylesheet are or
perhaps better yet, point to the css reference doc section that states it?

I deliberately wanted to minimize changes to the CSS subsystem in
> order to prevent introducing regressions in that area of the codebase.
> As a result, the proposed implementation treats theme stylesheets as a
> list of user-agent stylesheets, and optionally adds the application's
> user-agent stylesheet as the first item in that list. Note that
> `javafx.css.StyleOrigin` is also unchanged; you won't know whether a
> `StyleOrigin.USER_AGENT` stylesheet is the application's user-agent
> stylesheet, or one of its theme stylesheets.


Yes, I think minimizing changes to the CSS subsystem is a good idea.
I didn't mean we should make changes to the CSS subsystem, I meant/proposed
to add a flag or property in StyleThemes (the new API) that programmers
would then set in their StyleThemes and would define whether the StyleTheme
he's creating is a user agent stylesheet or an author stylesheet.

There's a role for third-party libraries here, and I think APIs for
> dark/light mode and other things can be done there.
> Supporting dark/light window frames is quite independent from the
> proposed style theme API, and should be done in a separate PR.
> I understand that it might be nice to have a comprehensive dark/light
> mode API in JavaFX, but there's a value in not going there and leaving
> that to libraries instead. I'd rather keep this feature as simple as
> it gets without sacrificing its unique capabilities. We can always
> come back and add more API surface if it turns out that we're really
> missing something.


I disagree here. I think this would be too low level for third party apps
to add support for, and as of today there isn't still yet any third party
library that adds it (which can itself be an indication that it's not a
good fit for third party libraries).
You'd need third party libraries to call on native code to change the frame
decoration of Windows that JavaFX spawns itself.
This API will already add some nice support to query platform preferences
(dark mode, accent color, etc) so I think it makes perfect sense to also
add API here to set the programmers preferences about these properties,
that JavaFX should then abide by.

Yes we could come back later to add that API.
As a theme developer and focusing on theme development only, this has been
on top of my wish list for a while. :)
Given that light/dark theme, etc feature is pervasive across all Oses I
think it's a shame that JavaFX doesn't yet fully support the development of
light/dark themes (especially dark themes).

4 - After reading Andy's comments I thought about a 4th point.
I agree with him in the part that we could have some of the platform
preference properties as Java properties. At least the things that are
pervasive across platforms, like whether the platform is set to dark or
light mode and the accent color.
I mean this in addition to the API that queries for platform properties
(i.e. I don't mean to remove the API you proposed to query for platform
properties).

Thanks again!



-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230115/66b010a9/attachment.htm>

From michaelstrau2 at gmail.com  Mon Jan 16 04:01:18 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 16 Jan 2023 05:01:18 +0100
Subject: Style themes API
In-Reply-To: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
Message-ID: <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>

My comments below:

On Sun, Jan 15, 2023 at 1:25 PM Pedro Duque Vieira
<pedro.duquevieira at gmail.com> wrote:
>
> I think we could add that it has higher precedence than a user agent stylesheets but that's it's not an author stylesheet. We can also possibly briefly say what a user agent stylesheet and author stylesheet are or perhaps better yet, point to the css reference doc section that states it?

Sure, I'll add some additional documentation.



> Yes, I think minimizing changes to the CSS subsystem is a good idea.
> I didn't mean we should make changes to the CSS subsystem, I meant/proposed to add a flag or property in StyleThemes (the new API) that programmers would then set in their StyleThemes and would define whether the StyleTheme he's creating is a user agent stylesheet or an author stylesheet.

I don't quite understand this. Can you elaborate on what the
advantages would be, and how (and for what purpose) users of the API
would use such a flag?



> I disagree here. I think this would be too low level for third party apps to add support for, and as of today there isn't still yet any third party library that adds it (which can itself be an indication that it's not a good fit for third party libraries).
> You'd need third party libraries to call on native code to change the frame decoration of Windows that JavaFX spawns itself.
> This API will already add some nice support to query platform preferences (dark mode, accent color, etc) so I think it makes perfect sense to also add API here to set the programmers preferences about these properties, that JavaFX should then abide by.
>
> Yes we could come back later to add that API.
> As a theme developer and focusing on theme development only, this has been on top of my wish list for a while. :)
> Given that light/dark theme, etc feature is pervasive across all Oses I think it's a shame that JavaFX doesn't yet fully support the development of light/dark themes (especially dark themes).

I don't think that we need any new API for dark mode window frames.
On macOS, the color of the window frame is already adjusted to match
the system-wide dark/light mode.
On Windows, this is not the case:

https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes

    "Not all Win32 applications support Dark mode, so
    Windows gives Win32 apps a light title bar by
    default. If you are prepared to support Dark mode,
    you can ask Windows to draw the dark title bar
    instead when Dark mode is enabled."

Since JavaFX already uses dark frames on macOS, why not do the same on Windows?
We can simply enable this behavior in general, and provide a system
property to revert to the old behavior of always using light frames,
even if dark mode is enabled.



> 4 - After reading Andy's comments I thought about a 4th point.
> I agree with him in the part that we could have some of the platform preference properties as Java properties. At least the things that are pervasive across platforms, like whether the platform is set to dark or light mode and the accent color.
> I mean this in addition to the API that queries for platform properties (i.e. I don't mean to remove the API you proposed to query for platform properties).

Here's a simple implementation that exposes dark mode and accent
coloring as JavaFX properties on a theme base class:
https://gist.github.com/mstr2/ba2f9cba659953788008fed1e9b2a031

We might consider adding something like this to JavaFX in the future,
but for the time being, I'd rather let third-party libraries explore
higher-level APIs first.

From aghaisas at openjdk.org  Mon Jan 16 05:50:15 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 16 Jan 2023 05:50:15 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <eLwbuHMpCNSvEyB0DaZzZCsy8IfWcQthatxXEd_bWu4=.c057852d-b309-4949-87cc-63b5df57c569@github.com>

On Fri, 13 Jan 2023 12:32:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.

Thanks @andy-goryachev-oracle, @kevinrushforth and @nlisker for your review. My responses are inline -

> After thinking about it further, I agree with Andy. Having a bulleted list of what to avoid, and a code sample of the right way to do it, seems best.

I am convinced that we should avoid writing out the non-recommended code snippet in documentation. I will replace it with bulleted list as suggested.


> Instead of repeating this in every class, maybe writing it once in Cell and linking to it from these classes will be better?

@kevinrushforth and I did think about this suggestion before deciding to put the warning explicitly in each of the virtualized controls. Each of `ListView`, `TreeView`, `TableView` and `TreeTableView` control documentation has a section about "Customizing Visuals" which has a link to `Cell` documentation.
- The documentation for `Cell` already has an example of custom cell factory and also a bulleted list of key design goals.
Despite this we see multiple occurrences of `Node`s being put directly in the item list of virtualized controls. Hence, it was decided to replicate the explicit warning similar to the one we already have in the documentation of ComboBox.
- I feel it is better to have an example of custom factory specific to each of the virtualized controls which we cannot put in generic `Cell` documentation.

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

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

From kpk at openjdk.org  Mon Jan 16 10:53:08 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 16 Jan 2023 10:53:08 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY
Message-ID: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@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.

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

Commit messages:
 - Label height issue fix

Changes: https://git.openjdk.org/jfx/pull/996/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8230833
  Stats: 31 lines in 2 files changed: 6 ins; 8 del; 17 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 aghaisas at openjdk.org  Mon Jan 16 11:24:46 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 16 Jan 2023 11:24:46 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v2]
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <x23fvxdgfHaTwzYQz_RI8xNs7X5sYk9opExR5z-wqAI=.8193b574-f787-4a70-8560-aaf1860a41ac@github.com>

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

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/995/files
  - new: https://git.openjdk.org/jfx/pull/995/files/4325a8e4..e46e31b4

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

  Stats: 116 lines in 4 files changed: 9 ins; 74 del; 33 mod
  Patch: https://git.openjdk.org/jfx/pull/995.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/995/head:pull/995

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

From pedro.duquevieira at gmail.com  Mon Jan 16 12:10:03 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 16 Jan 2023 12:10:03 +0000
Subject: Style themes API
In-Reply-To: <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
 <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
Message-ID: <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>

Hi again Michael,

Thanks for taking the time to answer my comments.
As always, it's easier to comment on and criticize than to do the actual
work of implementing the feature. So thanks again for the patience.

My comments below:


I don't quite understand this. Can you elaborate on what the
> advantages would be, and how (and for what purpose) users of the API
> would use such a flag?


No problem, I mentioned those in my first comment but probably got lost in
this conversation.
2 ? I think the ability to specify in the StyleTheme whether it is a user
agent stylesheet, or an author stylesheet could be of interest. Most of the
themes I know are composed of author stylesheets (they use the
getStylesheets() API in Scene) so migration to using the StyleTheme API
would be easier if one could specify this. Conversely specifying that the
StyleTheme is a user agent stylesheet will also be very useful in the cases
where we?re creating a theme but don?t want it to override styles specified
through code, etc.

I'll now also add that you might want to create a theme, from the get go,
that doesn't get trumped by any rule set through code, either code itself
on in FXML files (which will be code anyway). So that the theme css is what
always drives the presentation of your app (it has priority).
This is already possible by choosing to add your stylesheets to the Scene
getStylesheets() method or by using the setUserAgentStylesheet() method.


I don't think that we need any new API for dark mode window frames.
> On macOS, the color of the window frame is already adjusted to match
> the system-wide dark/light mode.
> On Windows, this is not the case:


https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes


    "Not all Win32 applications support Dark mode, so
>     Windows gives Win32 apps a light title bar by
>     default. If you are prepared to support Dark mode,
>     you can ask Windows to draw the dark title bar
>     instead when Dark mode is enabled."


Since JavaFX already uses dark frames on macOS, why not do the same on
> Windows?
> We can simply enable this behavior in general, and provide a system
> property to revert to the old behavior of always using light frames,
> even if dark mode is enabled.


Ok thanks for clarifying what happens on Mac. Yes on the Windows OS, JavaFX
won't honor your system wide settings. If your system is in dark mode the
frames will still be shown in light mode.
But anyways, I think, the programmer should be able to toggle the
dark/light mode setting irrespective of what is defined in the system.
There are many apps where you, as a user, can choose dark or light mode in
the app itself and it will honor it regardless of what you have defined in
the system (e.g. Intellij, Slack, etc, etc). Some will allow you to set
whether you want to use the system setting for light/dark mode or your own
setting in the app.
This can be of value in cases where you, as a user, prefer to use an app in
dark mode and others in some other mode, so you can choose themes on an app
by app basis.
Or perhaps the developer wants to design an app that's just dark. In that
case you'd want the ability to toggle the frame decorations to being dark
(all the time).


Here's a simple implementation that exposes dark mode and accent
> coloring as JavaFX properties on a theme base class:
> https://gist.github.com/mstr2/ba2f9cba659953788008fed1e9b2a031


We might consider adding something like this to JavaFX in the future,
> but for the time being, I'd rather let third-party libraries explore
> higher-level APIs first.


Just to be clear I was just talking about how we would present this API
(platform preferences). This property would be a way to more easily know if
the system is in dark/light mode, the accent color, without needing to know
the specific "key".

Thanks again!

On Mon, Jan 16, 2023 at 4:01 AM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> My comments below:
>
> On Sun, Jan 15, 2023 at 1:25 PM Pedro Duque Vieira
> <pedro.duquevieira at gmail.com> wrote:
> >
> > I think we could add that it has higher precedence than a user agent
> stylesheets but that's it's not an author stylesheet. We can also possibly
> briefly say what a user agent stylesheet and author stylesheet are or
> perhaps better yet, point to the css reference doc section that states it?
>
> Sure, I'll add some additional documentation.
>
>
>
> > Yes, I think minimizing changes to the CSS subsystem is a good idea.
> > I didn't mean we should make changes to the CSS subsystem, I
> meant/proposed to add a flag or property in StyleThemes (the new API) that
> programmers would then set in their StyleThemes and would define whether
> the StyleTheme he's creating is a user agent stylesheet or an author
> stylesheet.
>
> I don't quite understand this. Can you elaborate on what the
> advantages would be, and how (and for what purpose) users of the API
> would use such a flag?
>
>
>
> > I disagree here. I think this would be too low level for third party
> apps to add support for, and as of today there isn't still yet any third
> party library that adds it (which can itself be an indication that it's not
> a good fit for third party libraries).
> > You'd need third party libraries to call on native code to change the
> frame decoration of Windows that JavaFX spawns itself.
> > This API will already add some nice support to query platform
> preferences (dark mode, accent color, etc) so I think it makes perfect
> sense to also add API here to set the programmers preferences about these
> properties, that JavaFX should then abide by.
> >
> > Yes we could come back later to add that API.
> > As a theme developer and focusing on theme development only, this has
> been on top of my wish list for a while. :)
> > Given that light/dark theme, etc feature is pervasive across all Oses I
> think it's a shame that JavaFX doesn't yet fully support the development of
> light/dark themes (especially dark themes).
>
> I don't think that we need any new API for dark mode window frames.
> On macOS, the color of the window frame is already adjusted to match
> the system-wide dark/light mode.
> On Windows, this is not the case:
>
>
> https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes
>
>     "Not all Win32 applications support Dark mode, so
>     Windows gives Win32 apps a light title bar by
>     default. If you are prepared to support Dark mode,
>     you can ask Windows to draw the dark title bar
>     instead when Dark mode is enabled."
>
> Since JavaFX already uses dark frames on macOS, why not do the same on
> Windows?
> We can simply enable this behavior in general, and provide a system
> property to revert to the old behavior of always using light frames,
> even if dark mode is enabled.
>
>
>
> > 4 - After reading Andy's comments I thought about a 4th point.
> > I agree with him in the part that we could have some of the platform
> preference properties as Java properties. At least the things that are
> pervasive across platforms, like whether the platform is set to dark or
> light mode and the accent color.
> > I mean this in addition to the API that queries for platform properties
> (i.e. I don't mean to remove the API you proposed to query for platform
> properties).
>
> Here's a simple implementation that exposes dark mode and accent
> coloring as JavaFX properties on a theme base class:
> https://gist.github.com/mstr2/ba2f9cba659953788008fed1e9b2a031
>
> We might consider adding something like this to JavaFX in the future,
> but for the time being, I'd rather let third-party libraries explore
> higher-level APIs first.
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230116/3792ae3a/attachment-0001.htm>

From tsayao at openjdk.org  Mon Jan 16 15:28:41 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 16 Jan 2023 15:28:41 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v15]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <OXq9rGo3O1A53b-dQ0x74scp_2gBgfXaY2inh2QtTVI=.ca524f89-4151-432a-b59e-bf4d603daae7@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao 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 47 additional commits since the last revision:

 - Rework
 - Rework events
 - Merge branch 'master' into 8273379-dnd-keys
 - Merge branch 'openjdk:master' into master
 - Device Grab Work
 - Adjustments
 - Replace g_warning
 - Improvements
 - Add test
 - Add testing
 - ... and 37 more: https://git.openjdk.org/jfx/compare/89f8ac54...f916a108

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/08d05af8..f916a108

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=13-14

  Stats: 4806 lines in 81 files changed: 3541 ins; 825 del; 440 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From tsayao at openjdk.org  Mon Jan 16 15:38:47 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 16 Jan 2023 15:38:47 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v16]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <GcBVpRP7rzOhJ-av_xh7C00v0jT-Adi9jspWYLtrTnw=.6b15e3be-9a1a-4e7a-8808-664051485a10@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> The most changed part is that I had to move `process_events` to `glass_evloop`  because it's reused in glass_dnd.
> 
> To do general testing:
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  It works!

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/f916a108..daade445

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=14-15

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

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

From tsayao at openjdk.org  Mon Jan 16 19:16:49 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 16 Jan 2023 19:16:49 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v17]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <SD91rJw0Tpumv70s2DVFhM4UFAOlsojJkHKeHgW0e5w=.a1653fe4-bc0b-4c79-bfe7-4ae62fdacc45@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It now uses a event hook when drag starts to listen to Drag/DragView events;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * It uses `gdk_threads_add_idle_full` to end drag so the `GDK_BUTTON_RELEASE` event will continue before ending the drag. This is needed because `WindowContext` will notify java about the button release;
> * It also notifies "Drag Dropped" on DND Source if the drop is on the same app, because it needs to do so before mouse button is released - this method is more straightforward;
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Stop DRAG on GDK_DELETE

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/daade445..b130e740

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=15-16

  Stats: 15 lines in 3 files changed: 10 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From tsayao at openjdk.org  Mon Jan 16 19:22:34 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 16 Jan 2023 19:22:34 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v18]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <SPy0feABK3VXySi06qsoaIwbdtHk4WRyaAeJ7-LUwkg=.60dd9e82-68c5-4469-abc2-d1bbec86cf49@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It now uses a event hook when drag starts to listen to Drag/DragView events;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * It uses `gdk_threads_add_idle_full` to end drag so the `GDK_BUTTON_RELEASE` event will continue before ending the drag. This is needed because `WindowContext` will notify java about the button release;
> * It also notifies "Drag Dropped" on DND Source if the drop is on the same app, because it needs to do so before mouse button is released - this method is more straightforward;
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix icon size on dragview

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/b130e740..a036ce6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=16-17

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

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

From tsayao at openjdk.org  Mon Jan 16 20:04:23 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 16 Jan 2023 20:04:23 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v19]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <NDtjS_DEuMspzUqNGJbe_zSCEWobpar2nCLCFydZxa0=.81b6b2e6-df25-4be4-be79-15f2420388b4@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It now uses a event hook when drag starts to listen to Drag/DragView events;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * It uses `gdk_threads_add_idle_full` to end drag so the `GDK_BUTTON_RELEASE` event will continue before ending the drag. This is needed because `WindowContext` will notify java about the button release;
> * It also notifies "Drag Dropped" on DND Source if the drop is on the same app, because it needs to do so before mouse button is released - this method is more straightforward;
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Fix drag leave
 - Fix cursor + improve drag move

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/a036ce6f..7fe6ff40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=18
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=17-18

  Stats: 36 lines in 1 file changed: 17 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From jvos at openjdk.org  Mon Jan 16 20:19:54 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 16 Jan 2023 20:19:54 GMT
Subject: [jfx19] RFR: 8300226: Change JavaFX release version to 19.0.2
Message-ID: <HWcEONv106IXecn87K_rHwqKxQh7qKoJStfDpzt9OZE=.eb7b40ce-cedd-4d1d-a3ec-5c76e6f50af4@github.com>

Bump JavaFX release version to 19.0.2

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

Commit messages:
 - Bump JavaFX release version to 19.0.2

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

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

From michaelstrau2 at gmail.com  Mon Jan 16 23:28:24 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 17 Jan 2023 00:28:24 +0100
Subject: Style themes API
In-Reply-To: <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
 <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
 <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>
Message-ID: <CAJEpuXR6XMLByDPGTnZfa+7vuFaeVaZsL8BsOFj6vGYNr2_ong@mail.gmail.com>

Hi Pedro,
see my comments below.


On Mon, Jan 16, 2023 at 1:10 PM Pedro Duque Vieira
<pedro.duquevieira at gmail.com> wrote:
>
> No problem, I mentioned those in my first comment but probably got lost in this conversation.
> 2 ? I think the ability to specify in the StyleTheme whether it is a user agent stylesheet, or an author stylesheet could be of interest. Most of the themes I know are composed of author stylesheets (they use the getStylesheets() API in Scene) so migration to using the StyleTheme API would be easier if one could specify this. Conversely specifying that the StyleTheme is a user agent stylesheet will also be very useful in the cases where we?re creating a theme but don?t want it to override styles specified through code, etc.
>
> I'll now also add that you might want to create a theme, from the get go, that doesn't get trumped by any rule set through code, either code itself on in FXML files (which will be code anyway). So that the theme css is what always drives the presentation of your app (it has priority).
> This is already possible by choosing to add your stylesheets to the Scene getStylesheets() method or by using the setUserAgentStylesheet() method.

Currently, the order of precedence is as follows (from highest to lowest):
1. Node.style
2. Parent.stylesheets
3. Scene.stylesheets
4. StyleableProperty values set from code
5. Application.styleTheme
6. Application.userAgentStylesheet

I understand you're suggesting that a style theme could effectively be
inserted between 3 and 4, such that it overrides local values set from
code, but not values set in Scene stylesheets.
I'm not sure that the added complexity is worth the marginal benefits.
As far as JavaFX has always had the concept of built-in "themes",
users could reliably override any StyleableProperty value from code.
Developers might be surprised to find out that they can't set the
value of a StyleableProperty from code because an application-wide
style theme overrides any local changes.
The migration story from Scene stylesheets to a StyleTheme might be a
little bit easier, but it complicates the mental model of how themes
interact with the CSS cascade.



> Ok thanks for clarifying what happens on Mac. Yes on the Windows OS, JavaFX won't honor your system wide settings. If your system is in dark mode the frames will still be shown in light mode.
> But anyways, I think, the programmer should be able to toggle the dark/light mode setting irrespective of what is defined in the system. There are many apps where you, as a user, can choose dark or light mode in the app itself and it will honor it regardless of what you have defined in the system (e.g. Intellij, Slack, etc, etc). Some will allow you to set whether you want to use the system setting for light/dark mode or your own setting in the app.
> This can be of value in cases where you, as a user, prefer to use an app in dark mode and others in some other mode, so you can choose themes on an app by app basis.
> Or perhaps the developer wants to design an app that's just dark. In that case you'd want the ability to toggle the frame decorations to being dark (all the time).

I agree that it would be nice to have a way to programmatically
control the appearance of system-provided window decorations.
It's not entirely related to style themes: a style theme is an
application-wide concept, while window decorations are specific to
each individual window.
Maybe we could do this similarly to the Stage.initStyle method, which
serves a similar purpose of setting up window decorations.



> Just to be clear I was just talking about how we would present this API (platform preferences). This property would be a way to more easily know if the system is in dark/light mode, the accent color, without needing to know the specific "key".

If we wanted to expose this front-and-center, we could add these
properties to the Platform.Properties interface:

    public interface Preferences extends ObservableMap<String, Object> {
        ReadOnlyBooleanProperty darkModeProperty();
        ReadOnlyObjectProperty<Color> accentColorProperty();
        ...
    }

From mstrauss at openjdk.org  Mon Jan 16 23:46:19 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 16 Jan 2023 23:46:19 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v8]
In-Reply-To: <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
Message-ID: <52gZnUTVx_i_i5XNyyfcG23hXETSBbX33ThcOYm6ToM=.6e278f15-9385-428d-893e-9b68b450161c@github.com>

On Thu, 12 Jan 2023 08:53:14 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> 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:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>    
>    # Conflicts:
>    #	modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java
>    #	modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java
>    #	modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>  - JDK-8277848
>    Added tests to ensure no premature garbage collection is happening.
>  - JDK-8277848
>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>  - JDK-8277848
>    Added the 3 requests whitespaces
>  - JDK-8277848
>    Further optimization based code review.
>    This Bugfix should now event improve the performance
>  - JDK-8277848
>    Added missing change
>  - JDK-8277848
>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

Marked as reviewed by mstrauss (Committer).

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

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

From mstrauss at openjdk.org  Mon Jan 16 23:47:15 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 16 Jan 2023 23:47:15 GMT
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v5]
In-Reply-To: <aznZwi1BVBlnRt0Ns0YOViO-xwG_WDVbDYQLzQ-rT64=.aab106ca-6588-478c-a8bf-5eb38eb0e0b0@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <aznZwi1BVBlnRt0Ns0YOViO-xwG_WDVbDYQLzQ-rT64=.aab106ca-6588-478c-a8bf-5eb38eb0e0b0@github.com>
Message-ID: <Vj-ybkp8k1cOMpnykfDxwfwclq77KiRExoxO6yFyqE0=.9095e63f-2eef-4ec2-9a61-859acb75ef0f@github.com>

On Fri, 13 Jan 2023 09:18:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR fixes the leak in the mac system menu bar.
>> 
>> Inside the native code, NewGlobalRef is called for the callable.
>> Which makes it into a "GC-Root" until DeleteGlobalRef is called.
>> 
>> The DeleteGlobalRef is never called for the MenuEntry, if it's removed from the menu without removing it's callable.
>> This PR adds logic, whether the Menu is inserted. If it's not inserted in a Menu anymore, then DeleteGlobalRef is called, by calling `_setCallback` with the callable "null".
>> 
>> The unit test verifies, that this bug happened without this change, but no longer happens with this change.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8299423
>   we now use the junit5 api

Marked as reviewed by mstrauss (Committer).

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

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

From mstrauss at openjdk.org  Mon Jan 16 23:48:22 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 16 Jan 2023 23:48:22 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v2]
In-Reply-To: <y09ysfJAlFMb1e4eX_qzflZYi4RLPOYYTbouvlxBdtA=.636c4cb1-9ffd-45df-9d21-a56156152c6e@github.com>
References: <xwo8k1JzKrv0twUDEX8KubKH3h9d9NUsm5N9-eMgSzY=.0ef1bf6b-c63b-4717-861e-dc5ba58ee7dd@github.com>
 <y09ysfJAlFMb1e4eX_qzflZYi4RLPOYYTbouvlxBdtA=.636c4cb1-9ffd-45df-9d21-a56156152c6e@github.com>
Message-ID: <ha_z_THMlAy5X6fT3M0aI-7P5y0F9U4wpA8vR5t9sME=.8464a603-9495-49ad-bf6c-dc5ffe34d696@github.com>

On Tue, 3 Jan 2023 09:42:05 GMT, John Hendrikx <jhendrikx at openjdk.org> 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

Marked as reviewed by mstrauss (Committer).

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

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

From mik3hall at gmail.com  Tue Jan 17 00:19:42 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 16 Jan 2023 18:19:42 -0600
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v5]
In-Reply-To: <Vj-ybkp8k1cOMpnykfDxwfwclq77KiRExoxO6yFyqE0=.9095e63f-2eef-4ec2-9a61-859acb75ef0f@github.com>
References: <UfkNaT2NkGUuRuaLz352uyzDl4n8M1KNmPuySvsUwKw=.8fd30489-edea-471f-a1a3-8cf04f2b5eb8@github.com>
 <aznZwi1BVBlnRt0Ns0YOViO-xwG_WDVbDYQLzQ-rT64=.aab106ca-6588-478c-a8bf-5eb38eb0e0b0@github.com>
 <Vj-ybkp8k1cOMpnykfDxwfwclq77KiRExoxO6yFyqE0=.9095e63f-2eef-4ec2-9a61-859acb75ef0f@github.com>
Message-ID: <A57C83E6-E5FC-4D23-A20C-5D36E5530FE3@gmail.com>

Not directly related but I recently was looking at the Mac system menubar for javaFX applications noticing that they do not get an ?About? menu item in the Application menu.

I filed a bug that was just accepted today.

JDK-8300180 : [macos] Default About menu item not shown for javaFX applications
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8300180 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8300180>

It involves changes to some of the legacy Apple code (ApplicationDelegate.m) and changes to the javaFX application to initialize this code and also to use java.awt.Desktop.
I was able to get javaFX applications an ?About? menu item by default, as all Mac applications including jpackage Swing ones do. 
Also with additional changes I was able to use java.awt.Desktop to get a custom aboutHandler for this menu item for applications that want to provide their own.

I had tried doing this with just javaFX by simply getting a menubar and setting it to system, but this didn?t work. Possibly there is more to this that I should of done?
I might look a little at what javaFX has for the Mac system menubar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230116/e8fbb921/attachment.htm>

From tsayao at openjdk.org  Tue Jan 17 01:38:37 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 17 Jan 2023 01:38:37 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v20]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <J2cYp02GYHAuxt8BkPzGG2KH_6pjXBoDhfCcf0w6aPs=.fe7574b0-0de1-4ad2-8fb5-bc185941621a@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It now uses a event hook when drag starts to listen to Drag/DragView events;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * It uses `gdk_threads_add_idle_full` to end drag so the `GDK_BUTTON_RELEASE` event will continue before ending the drag. This is needed because `WindowContext` will notify java about the button release;
> * It also notifies "Drag Dropped" on DND Source if the drop is on the same app, because it needs to do so before mouse button is released - this method is more straightforward;
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Rework 2

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/7fe6ff40..04c4c954

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=18-19

  Stats: 88 lines in 3 files changed: 42 ins; 24 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From tsayao at openjdk.org  Tue Jan 17 01:42:39 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 17 Jan 2023 01:42:39 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v21]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <9Blogr8VgfnSOh7pJn2veDmzreVev6n1O-PDIWPeCv8=.f4c07486-94ca-4d72-afb6-e0c94e4f893f@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It now uses a event hook when drag starts to listen to Drag/DragView events;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * It uses `gdk_threads_add_idle_full` to end drag so the `GDK_BUTTON_RELEASE` event will continue before ending the drag. This is needed because `WindowContext` will notify java about the button release;
> * It also notifies "Drag Dropped" on DND Source if the drop is on the same app, because it needs to do so before mouse button is released - this method is more straightforward;
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Remove commented out code

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/04c4c954..aa5d8ae2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=20
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=19-20

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

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

From mik3hall at gmail.com  Tue Jan 17 06:03:04 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 17 Jan 2023 00:03:04 -0600
Subject: RFR: 8299423: JavaFX Mac system menubar leaks [v5]
In-Reply-To: <4E466958-DBEF-4A9D-BBD5-C2F9C71AE0C5@gmail.com>
References: <A57C83E6-E5FC-4D23-A20C-5D36E5530FE3@gmail.com>
 <4E466958-DBEF-4A9D-BBD5-C2F9C71AE0C5@gmail.com>
Message-ID: <AC7E43F3-2556-4426-A9A0-493D6AB33B77@gmail.com>



> On Jan 16, 2023, at 10:33 PM, Scott Palmer <swpalmer at gmail.com> wrote:
> 
> There are third-party libraries for better integration with the Mac menu bar.
> 
> E.g. https://github.com/codecentric/NSMenuFX <https://github.com/codecentric/NSMenuFX>
> 
> Though I wish this wasn?t necessary and proper hooks were present in JavaFX to begin with.
> 

That does look like it provides the About menu item. In looking at this I didn?t determine why JavaFX app?s don?t get the default ?Cocoa? one Swing app?s do (free of charge, no need for java.awt.Desktop or any app changes at all). This should just work. If the changes I provided in the bug report were used you would get this by simply including?

	static {
		//java.awt.Toolkit.getDefaultToolkit(); // Start AppKit
		Thread t = new Thread(() -> { java.awt.Toolkit.getDefaultToolkit(); });
      	t.start();  
	}

The thread change seemed necessary to hit ApplicationDelegate with access to the menubar. I don?t know yet if it will be considered in the scope of the bug fix to determine why the code doesn?t work as-is and eliminate the need for this.

I think originally the setAboutHandler and other functionalities of java.awt.Desktop were the jdk?s attempt to get rid of the equivalent Apple API?s as a sort of 3rd party add on. I wondered if it might not be more generally useful for JavaFX to have full access to java.awt.Desktop. I did go so far as to verify that with the following?

public class HelloWorld extends Application implements AboutHandler {

	@Override
	public void init() {
    	Thread t = new Thread(() -> {
			Desktop desktop = Desktop.getDesktop();
			desktop.setAboutHandler((AboutHandler)this);   
		});
		t.start();		  				
	}

    public void handleAbout(AboutEvent evt) {
    	System.out.println("got to handleAbout");
    	Platform.runLater(() -> {
    		Alert alert = new Alert(AlertType.INFORMATION, "About HelloWorld");
			alert.showAndWait();
		});
    }

Again, the thread changes seemed necessary. 
I don?t make much other use of java.awt.Desktop anywhere myself. But possibly other JavaFX developers would find some of it?s functionality useful or necessary. So I think long term some determination might need to made if JavaFX will develop all of this themselves. Or, use of java.awt.Desktop can continue to be used. Whether any attempt to address that will be made in resolving the bug report I don?t know. From the jdk side they could possibly figure out some way to provide this without some of the Thread changes. Or indicate if any support for java.awt.Desktop for JavaFX applications will be made at all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230117/c9173a87/attachment.htm>

From john.hendrikx at gmail.com  Tue Jan 17 11:21:24 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 17 Jan 2023 12:21:24 +0100
Subject: CSS Color functions
In-Reply-To: <CAL3e5iHJg0ntJRFtL08jPwgh53CYm_bQ7_j3Sw7i2RmPZ27Eqg@mail.gmail.com>
References: <CAL3e5iHJg0ntJRFtL08jPwgh53CYm_bQ7_j3Sw7i2RmPZ27Eqg@mail.gmail.com>
Message-ID: <8bb4b2f4-abb0-0244-9af8-e0726fc83a52@gmail.com>

It would be nice to support something like LESS (https://lesscss.org/).

I've integrated a LESS parser in my personal project that takes .less 
files and converts them to CSS before giving them to JavaFX.? This 
allows me to use functions like "fade" and "lighten":

 ? ? -fx-background-color: fade(black, 40%);
 ??? -fx-background-color: lighten(@glass-color, 20%, relative);

It supports variables, and the & operator to repeat parent selectors, 
here a bigger example:

 ??? .group-heading {
 ????? @c1: rgba(255, 255, 255, 85%);
 ????? @c2: fade(@text-accent-highlight, 70%);

 ????? &.horizontal {
 ??????? -fx-background-color: linear-gradient(to right, transparent 0%, 
@c2 18%, transparent 48%, transparent),
 ????????????????????????????? linear-gradient(to right, transparent 0%, 
@c2 6%, @c2 35%, transparent 98%, transparent);
 ??????? -fx-border-color: linear-gradient(to right, transparent 0%, 
transparent 50%, @c1 93%, @c1 99%, transparent);
 ????? }

 ????? &.vertical {
 ??????? -fx-background-color: linear-gradient(to top, transparent 0%, 
@c2 18%, transparent 48%, transparent),
 ????????????????????????????? linear-gradient(to top, transparent 0%, 
@c2 6%, @c2 35%, transparent 98%, transparent);
 ??????? -fx-border-color: linear-gradient(to top, transparent 0%, 
transparent 50%, @c1 93%, @c1 99%, transparent);
 ????? }
 ??? }

It integrates relatively easily. I let it statically compile the less 
files and generate regular CSS file URL's:

 ??? private static final String ROOT_STYLES_URL = 
LessLoader.compile(RootNodeFactory.class, "root.less");
 ??? private static final String PROGRESS_STYLES_URL = 
LessLoader.compile(RootNodeFactory.class, "progress-pane.less");
 ??? private static final String CLOCK_STYLES_URL = 
LessLoader.compile(RootNodeFactory.class, "clock-pane.less");
 ??? private static final String LOGO_STYLES_URL = 
LessLoader.compile(RootNodeFactory.class, "logo-pane.less");
 ??? private static final String FPS_STYLES_URL = 
LessLoader.compile(RootNodeFactory.class, "fps-pane.less");

Then you can use it like any other stylesheet on a component:

 ??? clockPane.getStylesheets().add(CLOCK_STYLES_URL);


--John


On 15/01/2023 01:31, Scott Palmer wrote:
> I was looking at Modena.css and came across this:
>
> ? ? /* A bright blue for the focus indicator of objects. Typically 
> used as the
> ? ? ?* first color in -fx-background-color for the "focused" 
> pseudo-class. Also
> ? ? ?* typically used with insets of -1.4 to provide a glowing effect.
> ? ? ?*/
> ? ? -fx-focus-color: #039ED3;
> ? ? -fx-faint-focus-color: #039ED322;
>
> I noticed two things pertaining to -fx-faint-focus-color. Although 
> I've used this form to specify colors myself, the JavaFX CSS Reference 
> Guide at 
> https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor?does 
> not mention being able to use an 8-digit form of #rrggbbaa when using 
> hex digits. Only the 3- and 6-digit forms of hexadecimal RGB?are 
> mentioned. RGB + Alpha colors are only documented in the form of 
> rgba(#,#,#,#) and rgba(#%,#%,#%,#).
>
> More importantly, this is a copy of -fx-focus-color with an added 
> alpha channel, but it's created by repeating the literal color value 
> and appending the alpha component, rather than somehow deriving it 
> from -fx-focus-color.? Similar repetition is needed for the 
> semi-transparent chart colors.
>
> Would?it make sense to add support for something?similar to derive( 
> <color> , <number>% )?to specify a color based on an existing color 
> with a new value for the alpha channel (or any other) value? Maybe a 
> color-transform method that would do for an RGBA color vector what 
> other transforms do for spatial coordinates?*
>
> Regards,
>
> Scott
>
> * Note: It seems future CSS standards are looking for ways to do 
> similar things.? A color-modfunction was proposed in 
> https://www.w3.org/TR/2016/WD-css-color-4-20160705/#funcdef-color-mod 
> but removed in the next revision 
> https://www.w3.org/TR/2022/CRD-css-color-4-20221101/#changes-from-20160705. 
> I'm not following CSS development closely, but some googling suggests 
> the next proposal is based on a new keyword?'from' to create derived 
> colors.? E.g rgb(from skyblue, 255 g b) to get a color based on 
> skyblue with a red component of 255. This is mentioned here 
> https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198 
> ?I'm skeptical that it is worth waiting for the dust to settle on the 
> CSS standard, but supporting whatever they come up with is a possibility.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230117/c35410de/attachment-0001.htm>

From aghaisas at openjdk.org  Tue Jan 17 11:42:24 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 17 Jan 2023 11:42:24 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
In-Reply-To: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
References: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
Message-ID: <-5VgoR9iUpXHoSxhDAhJ-XfZqDhhllURN4rSNjV74_4=.121798a2-a9ad-4b13-9301-b13a2e684372@github.com>

On Thu, 12 Jan 2023 11:11:23 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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.

The fix is fine.

I think that a test can be developed.
The total number of files in "java.io.tmpdir" directory should match before and after calling "Clipboard.getSystemClipboard().getImage()". That way we do not need the exact name of the temporary file.

Something like-
`File path = new File(System.getProperty("java.io.tmpdir"));`
`File[] files = path.listFiles();`

Size of `files` - should be same before and after "Clipboard.getSystemClipboard().getImage()"

Do you think this is doable?

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

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

From jhendrikx at openjdk.org  Tue Jan 17 11:43:17 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 17 Jan 2023 11:43:17 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY
In-Reply-To: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@github.com>
References: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@github.com>
Message-ID: <t5dJBuYxFTfyLqOoFPplKtdwVde30xgUwBJa77dyZXs=.94f0385b-5118-4ea3-b786-a6b0a8709f75@github.com>

On Mon, 16 Jan 2023 10:46:12 GMT, Karthik P K <kpk at openjdk.org> 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.

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());

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

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

From aghaisas at openjdk.org  Tue Jan 17 11:57:23 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 17 Jan 2023 11:57:23 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes [v2]
In-Reply-To: <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>
Message-ID: <Lnf3A_I72lvMCVNYr4cYh8-_bmqkJoukxLCDZ-UWklM=.f667baf4-e9c7-4e02-8257-0dadf8ec8d55@github.com>

On Fri, 13 Jan 2023 04:04:54 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When a scene graph contains multiple nested focused nodes (this can happen with `TableView` and other controls), the `focusWithin` bits that are cleared when a focused node is de-focused must only be cleared when there is no other nested node in the scene graph that would also cause `focusWithin` to be set.
>> 
>> For example, consider a scene graph of nested nodes:
>> A -> B -> C -> D
>> 
>> When B and D are both focused, the scene graph looks like this:
>> A(`focusWithin`)
>> -> B(`focused`, `focusWithin`)
>> -> C(`focusWithin`)
>> -> D(`focused`, `focusWithin`)
>> 
>> When B is de-focused, the `focusWithin` flags must still be preserved because D remains focused.
>> 
>> This PR fixes the issue by counting the number of times `focusWithin` has been "set", and only clears it when it has been "un-set" an equal number of times.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactoring

The fix looks fine to me!

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

Marked as reviewed by aghaisas (Reviewer).

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

From aghaisas at openjdk.org  Tue Jan 17 12:34:21 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 17 Jan 2023 12:34:21 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
In-Reply-To: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
References: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
Message-ID: <vGOSZSfOAsiGJEuqFgBYjF1WyC1gytkNmTDOQnEY7KI=.6fee945c-e0e3-48a7-9475-dbc873000856@github.com>

On Thu, 12 Jan 2023 11:11:23 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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.

The test can be a windows only automated system test if needed.

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

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

From kcr at openjdk.org  Tue Jan 17 12:52:24 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 12:52:24 GMT
Subject: [jfx19] RFR: 8300226: Change JavaFX release version to 19.0.2
In-Reply-To: <HWcEONv106IXecn87K_rHwqKxQh7qKoJStfDpzt9OZE=.eb7b40ce-cedd-4d1d-a3ec-5c76e6f50af4@github.com>
References: <HWcEONv106IXecn87K_rHwqKxQh7qKoJStfDpzt9OZE=.eb7b40ce-cedd-4d1d-a3ec-5c76e6f50af4@github.com>
Message-ID: <V4l7eCTxgcWswadWEU44xVMGNiOrxgt31NaCf1Wx44w=.f75de9d0-0441-45e3-9c8f-f2fdda4e8bec@github.com>

On Mon, 16 Jan 2023 20:14:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump JavaFX release version to 19.0.2

Marked as reviewed by kcr (Lead).

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

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

From jvos at openjdk.org  Tue Jan 17 12:57:29 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 17 Jan 2023 12:57:29 GMT
Subject: [jfx19] Integrated: 8300226: Change JavaFX release version to 19.0.2
In-Reply-To: <HWcEONv106IXecn87K_rHwqKxQh7qKoJStfDpzt9OZE=.eb7b40ce-cedd-4d1d-a3ec-5c76e6f50af4@github.com>
References: <HWcEONv106IXecn87K_rHwqKxQh7qKoJStfDpzt9OZE=.eb7b40ce-cedd-4d1d-a3ec-5c76e6f50af4@github.com>
Message-ID: <HxZA8dZlTP0ZEfpONGjMZuqcDa4xPaktk7Pz0ngdrqI=.82a2107a-a59b-4ef9-880a-efcb62353ec1@github.com>

On Mon, 16 Jan 2023 20:14:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump JavaFX release version to 19.0.2

This pull request has now been integrated.

Changeset: 2e17f7ae
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/2e17f7ae78bf5d75812f862d0f04941be4222961
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8300226: Change JavaFX release version to 19.0.2

Reviewed-by: kcr

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

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

From lkostyra at openjdk.org  Tue Jan 17 13:20:32 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 17 Jan 2023 13:20:32 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
In-Reply-To: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
References: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
Message-ID: <1mw8t2Ey9hvdndy3inBDWV_GJtUE9cdL3baGwXKZ2-A=.5a1979c4-0b6b-4d1c-9b60-bd87876894c4@github.com>

On Thu, 12 Jan 2023 11:11:23 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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.

We could do it this way, my main worry is that during the test some other application running in the system will use the Temp directory (ex. add a temporary file of its own between pre- and post-`getImage()`) and disturb with the test result. The chances of that happening are very small, but still not zero.

If we did this only for Windows, we could eventually filter through the list and look only at files ending in `.TMP`. Then the above scenario will have even less chances of happening.

If such a situation is not a big cause of concern I can implement the test and add it to this PR.

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

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

From kcr at openjdk.org  Tue Jan 17 13:46:28 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 13:46:28 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
In-Reply-To: <1mw8t2Ey9hvdndy3inBDWV_GJtUE9cdL3baGwXKZ2-A=.5a1979c4-0b6b-4d1c-9b60-bd87876894c4@github.com>
References: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
 <1mw8t2Ey9hvdndy3inBDWV_GJtUE9cdL3baGwXKZ2-A=.5a1979c4-0b6b-4d1c-9b60-bd87876894c4@github.com>
Message-ID: <u5hSaMa24iah7zFw4eL_o-Q__RlcxXsF-aGV3FJBg_0=.76c32176-9963-4578-8d68-e38ef021e79a@github.com>

On Tue, 17 Jan 2023 13:18:10 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> We could do it this way, my main worry is that during the test some other application running in the system will use the Temp directory

I was going to make that same comment. This seems fragile to me.

> If we did this only for Windows, we could eventually filter through the list and look only at files ending in `.TMP`. Then the above scenario will have even less chances of happening.

This seems like it might be OK.

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

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

From kcr at openjdk.org  Tue Jan 17 13:57:19 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 13:57:19 GMT
Subject: RFR: 8290092: Temporary files are kept when call
 Clipboard.getSystemClipboard().getImage()
In-Reply-To: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
References: <BtJtlvBJwFjUVVuGesAyvsyLnMtyNgx8TY02GPMgnBU=.00265ac1-b51c-477c-8e4a-89ef357f4d0e@github.com>
Message-ID: <ef9xE09Nd8FZVQ9txpmyAwy4KfB0fOT_rI45KW2Es20=.25e93cf1-58b1-4f4d-9402-5e230e0d6a24@github.com>

On Thu, 12 Jan 2023 11:11:23 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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.

Another possibility would be a manual test, since any automated test will be at least somewhat fragile, given that you don't know for sure which `*.TMP` files were created by the system clipboard.

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

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

From angorya at openjdk.org  Tue Jan 17 16:49:40 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 17 Jan 2023 16:49:40 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v2]
In-Reply-To: <x23fvxdgfHaTwzYQz_RI8xNs7X5sYk9opExR5z-wqAI=.8193b574-f787-4a70-8560-aaf1860a41ac@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <x23fvxdgfHaTwzYQz_RI8xNs7X5sYk9opExR5z-wqAI=.8193b574-f787-4a70-8560-aaf1860a41ac@github.com>
Message-ID: <BsET7IsjMDk-KBPYB6u7yhlqZ0D4SEptSyhacadgncg=.a53db13e-7bb4-48b7-8006-1b0749911d43@github.com>

On Mon, 16 Jan 2023 11:24:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Have only minor suggestion, the extra space will not make any difference as it won't be seen in the browser.
Will re-approve should you decide to fix them.

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

> 155:  * <p>Important points to note:
> 156:  * <ul>
> 157:  * <li>Avoid inserting {@link Node}  instances directly into the items list or its data model.</li>

minor: extra space before 'instances'

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 267:

> 265:  * <p>Important points to note:
> 266:  * <ul>
> 267:  * <li>Avoid inserting {@link Node}  instances directly into the {@code TableView} cells or its data model.</li>

... and here, and I think in other places as well.

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

Marked as reviewed by angorya (Committer).

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

From kevin.rushforth at oracle.com  Tue Jan 17 16:55:38 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 17 Jan 2023 08:55:38 -0800
Subject: [jfx20] RFR: Request to sync January 2023 CPU changes into jfx:jfx20
 + backports to jfx19, jfx17u, jfx11u
Message-ID: <445d3af8-4d16-8bb6-294c-aa2a692e5642@oracle.com>

Hi Johan,

I request approval to sync changes from to the just-released January 
2023 CPU release into the 'jfx20' branch of the 'jfx' repo. Here is the 
aggregate set of changes for the fixes:

https://github.com/kevinrushforth/jfx/compare/8136b11fdc...cpu-2301-sync

NOTE: Since this is an integration of already-reviewed fixes, I will 
push it directly to the jfx20 branch of the jfx repo rather than via a 
pull request.

As a heads-up, I also plan to push the backports of these changes to 
jfx:jfx19 (for 19.0.2), jfx17u (for 17.0.6) and to jfx11u (for 11.0.18) .

https://github.com/kevinrushforth/jfx/compare/2e17f7ae78...19-cpu-2301-sync
https://github.com/kevinrushforth/jfx17u/compare/66626f5885...cpu-2301-sync
https://github.com/kevinrushforth/jfx11u/compare/2aa567dcdc...cpu-2301-sync

NOTE: As with the mainline, since each is an integration of 
already-reviewed fixes, I will push directly to the jfx19 branch of the 
jfx repo, and to the master branch of the jfx17u and jfx11u repos rather 
than via a pull request.

Thanks.

-- Kevin


From kevin.rushforth at oracle.com  Tue Jan 17 17:19:46 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 17 Jan 2023 09:19:46 -0800
Subject: Result: New OpenJFX Committer: John Hendrikx
Message-ID: <8ae43ab4-6151-97bb-c8bf-5150139dff39@oracle.com>

Voting for John Hendrikx [1] to OpenJFX Committer [2] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

-- Kevin

[1] https://openjdk.java.net/census#jhendrikx

[2] https://mail.openjdk.org/pipermail/openjfx-dev/2023-January/037845.html


From tsayao at openjdk.org  Tue Jan 17 17:22:06 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 17 Jan 2023 17:22:06 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v22]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <e1k_dr6MRBzovR4Ya0vhVi6pQ6Rn0pfi8vIqoH1I9Ws=.b7f3599f-300d-4222-9588-5b2e90ee74b7@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It now uses a event hook when drag starts to listen to Drag/DragView events;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * It uses `gdk_threads_add_idle_full` to end drag so the `GDK_BUTTON_RELEASE` event will continue before ending the drag. This is needed because `WindowContext` will notify java about the button release;
> * It also notifies "Drag Dropped" on DND Source if the drop is on the same app, because it needs to do so before mouse button is released - this method is more straightforward;
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with three additional commits since the last revision:

 - Fix DragView below cursor
 - Minor adjustments
 - Typo

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/aa5d8ae2..5ee52e69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=21
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=20-21

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

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

From michaelstrau2 at gmail.com  Tue Jan 17 17:34:38 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 17 Jan 2023 18:34:38 +0100
Subject: CSS Color functions
In-Reply-To: <CAL3e5iHJg0ntJRFtL08jPwgh53CYm_bQ7_j3Sw7i2RmPZ27Eqg@mail.gmail.com>
References: <CAL3e5iHJg0ntJRFtL08jPwgh53CYm_bQ7_j3Sw7i2RmPZ27Eqg@mail.gmail.com>
Message-ID: <CAJEpuXTbdg1fRofe99UTExzN=Fy5cXHFT5DNWyGNY-nQ4C_yjQ@mail.gmail.com>

I don't think it makes a lot of sense to add even more non-standard
functions to JavaFX CSS. Instead we should work towards bringing our
implementation closer to the web standard.
You wrote that it might not be worth to wait for the standard; does
that mean that you'd get a lot of value from this proposed feature?
Improving one line of code in Modena.css is probably not enough justification.

On Sun, Jan 15, 2023 at 1:31 AM Scott Palmer <swpalmer at gmail.com> wrote:
>
> I was looking at Modena.css and came across this:
>
>     /* A bright blue for the focus indicator of objects. Typically used as the
>      * first color in -fx-background-color for the "focused" pseudo-class. Also
>      * typically used with insets of -1.4 to provide a glowing effect.
>      */
>     -fx-focus-color: #039ED3;
>     -fx-faint-focus-color: #039ED322;
>
> I noticed two things pertaining to -fx-faint-focus-color.  Although I've used this form to specify colors myself, the JavaFX CSS Reference Guide at https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor does not mention being able to use an 8-digit form of #rrggbbaa when using hex digits. Only the 3- and 6-digit forms of hexadecimal RGB are mentioned. RGB + Alpha colors are only documented in the form of rgba(#,#,#,#) and rgba(#%,#%,#%,#).
>
> More importantly, this is a copy of -fx-focus-color with an added alpha channel, but it's created by repeating the literal color value and appending the alpha component, rather than somehow deriving it from -fx-focus-color.  Similar repetition is needed for the semi-transparent chart colors.
>
> Would it make sense to add support for something similar to derive( <color> , <number>% ) to specify a color based on an existing color with a new value for the alpha channel (or any other) value? Maybe a color-transform method that would do for an RGBA color vector what other transforms do for spatial coordinates?*
>
> Regards,
>
> Scott
>
> * Note: It seems future CSS standards are looking for ways to do similar things.  A color-mod function was proposed in https://www.w3.org/TR/2016/WD-css-color-4-20160705/#funcdef-color-mod but removed in the next revision https://www.w3.org/TR/2022/CRD-css-color-4-20221101/#changes-from-20160705.  I'm not following CSS development closely, but some googling suggests the next proposal is based on a new keyword 'from' to create derived colors.  E.g rgb(from skyblue, 255 g b) to get a color based on skyblue with a red component of 255.  This is mentioned here https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198  I'm skeptical that it is worth waiting for the dust to settle on the CSS standard, but supporting whatever they come up with is a possibility.
>

From tsayao at openjdk.org  Tue Jan 17 17:56:00 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 17 Jan 2023 17:56:00 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v43]
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: <zZ5d6FWyKJCqg5Izvs76T8besrLIarmoW3rDgD5t5IE=.741aaa17-2816-4151-b3e2-60428f477750@github.com>

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

 - Added (temporary) print statements to check size reporting
 - Remove duplicated set_events

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/915/files
  - new: https://git.openjdk.org/jfx/pull/915/files/79e7e4c4..1ef7d18a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=42
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=41-42

  Stats: 13 lines in 1 file changed: 11 ins; 2 del; 0 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 johan at lodgon.com  Tue Jan 17 18:09:30 2023
From: johan at lodgon.com (Johan Vos)
Date: Tue, 17 Jan 2023 19:09:30 +0100
Subject: [jfx20] RFR: Request to sync January 2023 CPU changes into
 jfx:jfx20 + backports to jfx19, jfx17u, jfx11u
In-Reply-To: <445d3af8-4d16-8bb6-294c-aa2a692e5642@oracle.com>
References: <445d3af8-4d16-8bb6-294c-aa2a692e5642@oracle.com>
Message-ID: <CAK7C+Xhg+zN1UesV62vOE7WmiFub_JnJ-GVRzMx127ebcZYxcw@mail.gmail.com>

approved.

Op di 17 jan. 2023 om 17:56 schreef Kevin Rushforth <
kevin.rushforth at oracle.com>:

> Hi Johan,
>
> I request approval to sync changes from to the just-released January
> 2023 CPU release into the 'jfx20' branch of the 'jfx' repo. Here is the
> aggregate set of changes for the fixes:
>
> https://github.com/kevinrushforth/jfx/compare/8136b11fdc...cpu-2301-sync
>
> NOTE: Since this is an integration of already-reviewed fixes, I will
> push it directly to the jfx20 branch of the jfx repo rather than via a
> pull request.
>
> As a heads-up, I also plan to push the backports of these changes to
> jfx:jfx19 (for 19.0.2), jfx17u (for 17.0.6) and to jfx11u (for 11.0.18) .
>
> https://github.com/kevinrushforth/jfx/compare/2e17f7ae78...19-cpu-2301-sync
> https://github.com/kevinrushforth/jfx17u/compare/66626f5885...cpu-2301-sync
> https://github.com/kevinrushforth/jfx11u/compare/2aa567dcdc...cpu-2301-sync
>
> NOTE: As with the mainline, since each is an integration of
> already-reviewed fixes, I will push directly to the jfx19 branch of the
> jfx repo, and to the master branch of the jfx17u and jfx11u repos rather
> than via a pull request.
>
> Thanks.
>
> -- Kevin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230117/00862f65/attachment-0001.htm>

From tsayao at openjdk.org  Tue Jan 17 18:52:33 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 17 Jan 2023 18:52:33 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v44]
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: <Qp5t6EHZ3eurEl5vglrH35zGF0X6Ig8Hh7fo4ilhi-I=.e0a779e9-c7dc-490e-9d12-86116839b1d5@github.com>

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

  Revert "Remove duplicated set_events"
  
  This reverts commit 077b8df9238679e05b491f015b89670c9ca332a4.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/915/files
  - new: https://git.openjdk.org/jfx/pull/915/files/1ef7d18a..55ff6318

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=43
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=42-43

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 kcr at openjdk.org  Tue Jan 17 19:42:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 19:42:33 GMT
Subject: RFR: Merge jfx20
Message-ID: <IJck5g-sAHEjHiG_yBV8xs0o4OdLHplyt70vwWoUwBQ=.41f9c85c-9b72-4d2a-ba8f-b6b2c80057af@github.com>

Merge `jfx20` branch into `master`.

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

Commit messages:
 - Merge jfx20
 - Merge
 - 8299628: BMP top-down images fail to load after JDK-8289336
 - Merge
 - Merge
 - Merge
 - Merge
 - 8294779: Improve FX pages
 - 8289336: Better platform image support
 - Merge
 - ... and 4 more: https://git.openjdk.org/jfx/compare/23004367...d64b546a

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

Changes: https://git.openjdk.org/jfx/pull/998/files
  Stats: 362 lines in 19 files changed: 301 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jfx/pull/998.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/998/head:pull/998

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

From kcr at openjdk.org  Tue Jan 17 19:51:44 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 19:51:44 GMT
Subject: RFR: Merge jfx20 [v2]
In-Reply-To: <IJck5g-sAHEjHiG_yBV8xs0o4OdLHplyt70vwWoUwBQ=.41f9c85c-9b72-4d2a-ba8f-b6b2c80057af@github.com>
References: <IJck5g-sAHEjHiG_yBV8xs0o4OdLHplyt70vwWoUwBQ=.41f9c85c-9b72-4d2a-ba8f-b6b2c80057af@github.com>
Message-ID: <cXqIbz7Jo8EDxhZjFilIkgBlDTDRjA3NEVIdmNN0O5E=.135a4bd8-5611-4325-8737-c82a720403a2@github.com>

> Merge `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 two additional commits since the last revision:

 - Merge jfx20
 - 8299681: Change JavaFX release version to 21
   
   Reviewed-by: arapte, angorya

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/998/files
  - new: https://git.openjdk.org/jfx/pull/998/files/d64b546a..d64b546a

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

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

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

From kcr at openjdk.org  Tue Jan 17 19:51:45 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 19:51:45 GMT
Subject: Integrated: Merge jfx20
In-Reply-To: <IJck5g-sAHEjHiG_yBV8xs0o4OdLHplyt70vwWoUwBQ=.41f9c85c-9b72-4d2a-ba8f-b6b2c80057af@github.com>
References: <IJck5g-sAHEjHiG_yBV8xs0o4OdLHplyt70vwWoUwBQ=.41f9c85c-9b72-4d2a-ba8f-b6b2c80057af@github.com>
Message-ID: <KeWHPWRPuYQs7M9j8_-npyErmSaAWomHI0cKvv0Im8c=.ad3d24da-b62f-47b4-8c11-b39e105e46a5@github.com>

On Tue, 17 Jan 2023 19:37:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Merge `jfx20` branch into `master`.

This pull request has now been integrated.

Changeset: 89219b70
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/89219b70f8760dc6bd4e827e22c8190fdf3fea99
Stats:     362 lines in 19 files changed: 301 ins; 7 del; 54 mod

Merge

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

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

From swpalmer at gmail.com  Tue Jan 17 21:22:00 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 17 Jan 2023 16:22:00 -0500
Subject: CSS Color functions
In-Reply-To: <CAJEpuXTbdg1fRofe99UTExzN=Fy5cXHFT5DNWyGNY-nQ4C_yjQ@mail.gmail.com>
References: <CAL3e5iHJg0ntJRFtL08jPwgh53CYm_bQ7_j3Sw7i2RmPZ27Eqg@mail.gmail.com>
 <CAJEpuXTbdg1fRofe99UTExzN=Fy5cXHFT5DNWyGNY-nQ4C_yjQ@mail.gmail.com>
Message-ID: <CAL3e5iFJO4rFby+seLGTj+aravU-v1iL3LQ_j_XiDFSGzwBDJw@mail.gmail.com>

I don't disagree.  It's a minor thing that I can workaround for now.
I would like to see improved support for CSS standards though. From
the little reading I did, it seems full CSS compliance would be very
complex, so I'm not sure what level of support to expect in JavaFX.
Standard functions for deriving colors though would be welcome.

Scott

On Tue, Jan 17, 2023 at 12:34 PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> I don't think it makes a lot of sense to add even more non-standard
> functions to JavaFX CSS. Instead we should work towards bringing our
> implementation closer to the web standard.
> You wrote that it might not be worth to wait for the standard; does
> that mean that you'd get a lot of value from this proposed feature?
> Improving one line of code in Modena.css is probably not enough
> justification.
>
> On Sun, Jan 15, 2023 at 1:31 AM Scott Palmer <swpalmer at gmail.com> wrote:
> >
> > I was looking at Modena.css and came across this:
> >
> >     /* A bright blue for the focus indicator of objects. Typically used
> as the
> >      * first color in -fx-background-color for the "focused"
> pseudo-class. Also
> >      * typically used with insets of -1.4 to provide a glowing effect.
> >      */
> >     -fx-focus-color: #039ED3;
> >     -fx-faint-focus-color: #039ED322;
> >
> > I noticed two things pertaining to -fx-faint-focus-color.  Although I've
> used this form to specify colors myself, the JavaFX CSS Reference Guide at
> https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor
> does not mention being able to use an 8-digit form of #rrggbbaa when using
> hex digits. Only the 3- and 6-digit forms of hexadecimal RGB are mentioned.
> RGB + Alpha colors are only documented in the form of rgba(#,#,#,#) and
> rgba(#%,#%,#%,#).
> >
> > More importantly, this is a copy of -fx-focus-color with an added alpha
> channel, but it's created by repeating the literal color value and
> appending the alpha component, rather than somehow deriving it from
> -fx-focus-color.  Similar repetition is needed for the semi-transparent
> chart colors.
> >
> > Would it make sense to add support for something similar to derive(
> <color> , <number>% ) to specify a color based on an existing color with a
> new value for the alpha channel (or any other) value? Maybe a
> color-transform method that would do for an RGBA color vector what other
> transforms do for spatial coordinates?*
> >
> > Regards,
> >
> > Scott
> >
> > * Note: It seems future CSS standards are looking for ways to do similar
> things.  A color-mod function was proposed in
> https://www.w3.org/TR/2016/WD-css-color-4-20160705/#funcdef-color-mod but
> removed in the next revision
> https://www.w3.org/TR/2022/CRD-css-color-4-20221101/#changes-from-20160705.
> I'm not following CSS development closely, but some googling suggests the
> next proposal is based on a new keyword 'from' to create derived colors.
> E.g rgb(from skyblue, 255 g b) to get a color based on skyblue with a red
> component of 255.  This is mentioned here
> https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198
> I'm skeptical that it is worth waiting for the dust to settle on the CSS
> standard, but supporting whatever they come up with is a possibility.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230117/9782dabb/attachment.htm>

From tsayao at openjdk.org  Tue Jan 17 23:04:10 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 17 Jan 2023 23:04:10 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
Message-ID: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>

Simple PR to remove gtk2 library compilation and loading.

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

Commit messages:
 - Remove gtk2
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 18 more: https://git.openjdk.org/jfx/compare/23004367...80aac162

Changes: https://git.openjdk.org/jfx/pull/999/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299595
  Stats: 127 lines in 5 files changed: 9 ins; 104 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/999/head:pull/999

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

From kcr at openjdk.org  Tue Jan 17 23:52:07 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 23:52:07 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <lGdM8UEElWt89Xd8pva9Z30V6DIhgiTMVOa-FBb7Uio=.d258833c-6b14-4d12-931a-ab52ec279897@github.com>

On Tue, 17 Jan 2023 22:57:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Simple PR to remove gtk2 library compilation and loading.

The changes are what I would expect. I left a few (fairly minor) inline comments. I haven't tested it yet.

.idea/misc.xml line 4:

> 2: <project version="4">
> 3:   <component name="ExternalStorageConfigurationManager" enabled="true" />
> 4:   <component name="FrameworkDetectionExcludesConfiguration">

This change is unrelated to this issue and should be reverted.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java line 27:

> 25: package com.sun.glass.ui.gtk;
> 26: 
> 27: import com.sun.glass.ui.*;

Please expand this into separate imports, rather than using a wildcard import.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java line 168:

> 166:         @SuppressWarnings("removal")
> 167:         boolean gtkVersionVerbose =
> 168:                 AccessController.doPrivileged((PrivilegedAction<Boolean>) () -> Boolean.getBoolean("jdk.gtk.verbose"));

Minor: Since you are not otherwise touching this block, it would be cleaner to revert this reformatting change.

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

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

From tsayao at openjdk.org  Wed Jan 18 00:04:22 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 18 Jan 2023 00:04:22 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v2]
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <xSbYcg4oe97Rx0rsFNP0bLlWrIV71b52cI0aZSWP0oY=.5b545e42-2a7d-41ef-9f06-798a90088eef@github.com>

> Simple PR to remove gtk2 library compilation and loading.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Pre-review adjustments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/999/files
  - new: https://git.openjdk.org/jfx/pull/999/files/80aac162..82eedc55

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

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

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

From tsayao at openjdk.org  Wed Jan 18 00:10:30 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 18 Jan 2023 00:10:30 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v2]
In-Reply-To: <lGdM8UEElWt89Xd8pva9Z30V6DIhgiTMVOa-FBb7Uio=.d258833c-6b14-4d12-931a-ab52ec279897@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <lGdM8UEElWt89Xd8pva9Z30V6DIhgiTMVOa-FBb7Uio=.d258833c-6b14-4d12-931a-ab52ec279897@github.com>
Message-ID: <5XteuFxYNbDE9K7QooVVa46A5zZlyie5BQDnsNuv89w=.7c371939-0e57-45ff-ab9e-a62c528451fe@github.com>

On Tue, 17 Jan 2023 23:42:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pre-review adjustments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java line 168:
> 
>> 166:         @SuppressWarnings("removal")
>> 167:         boolean gtkVersionVerbose =
>> 168:                 AccessController.doPrivileged((PrivilegedAction<Boolean>) () -> Boolean.getBoolean("jdk.gtk.verbose"));
> 
> Minor: Since you are not otherwise touching this block, it would be cleaner to revert this reformatting change.

I have a thing for lambdas.

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

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

From tsayao at openjdk.org  Wed Jan 18 00:34:48 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 18 Jan 2023 00:34:48 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v23]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <9-XtlyLG1bdTuY-n-ixfZx_UV5IENh-lEW01Zsb8Zhk=.97100848-3bee-4173-a036-68c9ffe158a7@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao 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 59 additional commits since the last revision:

 - Merge branch 'master' into 8273379-dnd-keys
 - Merge branch 'openjdk:master' into master
 - Fix DragView below cursor
 - Minor adjustments
 - Typo
 - Remove commented out code
 - Rework 2
 - Fix drag leave
 - Fix cursor + improve drag move
 - Fix icon size on dragview
 - ... and 49 more: https://git.openjdk.org/jfx/compare/0f417b5a...c7d88050

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/5ee52e69..c7d88050

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=22
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=21-22

  Stats: 362 lines in 19 files changed: 301 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From tsayao at openjdk.org  Wed Jan 18 00:51:27 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 18 Jan 2023 00:51:27 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v2]
In-Reply-To: <xSbYcg4oe97Rx0rsFNP0bLlWrIV71b52cI0aZSWP0oY=.5b545e42-2a7d-41ef-9f06-798a90088eef@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <xSbYcg4oe97Rx0rsFNP0bLlWrIV71b52cI0aZSWP0oY=.5b545e42-2a7d-41ef-9f06-798a90088eef@github.com>
Message-ID: <XDRdMMcK3xh0uIWsDxLquXHaj4eRrIvxUsVU6RiutMA=.ee166c38-f140-4922-a185-e11724144ae0@github.com>

On Wed, 18 Jan 2023 00:04:22 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pre-review adjustments

I need to figure it out how to test with SWT.

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

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

From tsayao at openjdk.org  Wed Jan 18 00:57:13 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 18 Jan 2023 00:57:13 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v23]
In-Reply-To: <9-XtlyLG1bdTuY-n-ixfZx_UV5IENh-lEW01Zsb8Zhk=.97100848-3bee-4173-a036-68c9ffe158a7@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
 <9-XtlyLG1bdTuY-n-ixfZx_UV5IENh-lEW01Zsb8Zhk=.97100848-3bee-4173-a036-68c9ffe158a7@github.com>
Message-ID: <Ygd9QTg218wJVyFz__HGIHXtkfrFDUGY7xZELVIhsCQ=.1367d794-8d5d-4e5d-b6c8-c0d375d38ee2@github.com>

On Wed, 18 Jan 2023 00:34:48 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> To do general testing (two tests were added):
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>> 
>> Information for reviewing:
>> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
>> * There's a new `DragSourceContext` instead of global variables;
>> * DragView were simplified;
>> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
>> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
>> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
>> * The Scenario were the drag source window closes during the drag is now covered;
>
> Thiago Milczarek Sayao 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 59 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8273379-dnd-keys
>  - Merge branch 'openjdk:master' into master
>  - Fix DragView below cursor
>  - Minor adjustments
>  - Typo
>  - Remove commented out code
>  - Rework 2
>  - Fix drag leave
>  - Fix cursor + improve drag move
>  - Fix icon size on dragview
>  - ... and 49 more: https://git.openjdk.org/jfx/compare/b0652d11...c7d88050

I'll do more testing, but so far it's working as expected on many scenarios:
` java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`

I have merged the latest changes from master.

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

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

From tsayao at openjdk.org  Wed Jan 18 00:59:41 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 18 Jan 2023 00:59:41 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v44]
In-Reply-To: <Qp5t6EHZ3eurEl5vglrH35zGF0X6Ig8Hh7fo4ilhi-I=.e0a779e9-c7dc-490e-9d12-86116839b1d5@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <Qp5t6EHZ3eurEl5vglrH35zGF0X6Ig8Hh7fo4ilhi-I=.e0a779e9-c7dc-490e-9d12-86116839b1d5@github.com>
Message-ID: <bDj2eLD2YKcksmPw5N0QgYLFxbK0H5cQVQ5e6VGFaCk=.53d27be5-f63b-42aa-81fa-960582873fb3@github.com>

On Tue, 17 Jan 2023 18:52:33 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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 one additional commit since the last revision:
> 
>   Revert "Remove duplicated set_events"
>   
>   This reverts commit 077b8df9238679e05b491f015b89670c9ca332a4.

I added some print statements to check on that drawing glitch when running on a VM, but couldn't test yet because my VM stopped working.

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

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

From kpk at openjdk.org  Wed Jan 18 06:56:57 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 18 Jan 2023 06:56:57 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v2]
In-Reply-To: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@github.com>
References: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@github.com>
Message-ID: <ChnRQNu8dvwZ2xxzMxVQEs__fw3WSxToOXdUOZBUsGk=.01ad16e3-04ce-42c3-a9d4-b69a9e5b48de@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:

  Use width while calling prefHeight method. Use graphicHeight instead of multiple calls to prefHeight

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/996/files
  - new: https://git.openjdk.org/jfx/pull/996/files/f59f1992..c2a2afa6

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

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 Jan 18 07:10:33 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 18 Jan 2023 07:10:33 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v2]
In-Reply-To: <t5dJBuYxFTfyLqOoFPplKtdwVde30xgUwBJa77dyZXs=.94f0385b-5118-4ea3-b786-a6b0a8709f75@github.com>
References: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@github.com>
 <t5dJBuYxFTfyLqOoFPplKtdwVde30xgUwBJa77dyZXs=.94f0385b-5118-4ea3-b786-a6b0a8709f75@github.com>
Message-ID: <WUbAQ4L5h-gHDNM76XMBQJkCGrBX8F8Vy7RjKYF5k9U=.3c0cd65d-ce18-4694-830c-11ad362c6daa@github.com>

On Tue, 17 Jan 2023 11:40:47 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

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

I used `-1` while calling `prefHeight` as I tried to make `computePrefHeight` in consistent with `computePrefWidth` method. But looking at the documentation in Node.java file, it looks like width should be used. So I made modifications to use width while calling `prefHeight`.


> 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 carried forward the conditions which were already present. I believe removing the condition like `graphic == null` or `txt == null` from `isIgnoreGraphic()` or `isIgnoreText()` methods will create more combinations of conditions combined with ContentDisplay value during height calculation and we have to consider which all the height components to be considered in these cases. Since `graphic==null` is as good as considering  ContentDisplay.TEXT_ONLY, I feel it is better to keep this check.

I have updated the code to use `graphicHeight` in other cases of if/else branch.

> I also wonder if a simple fix like this would have the same result:
> 
> ```diff
> -       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());
> ```

This fixes only the issue of height calculation when text height needs to be ignored. But the original if/else branch present, considers text gap when not required. So I believe modification to the if/else branch is necessary.

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

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

From aghaisas at openjdk.org  Wed Jan 18 09:25:08 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 18 Jan 2023 09:25:08 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>

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

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra spaces

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/995/files
  - new: https://git.openjdk.org/jfx/pull/995/files/e46e31b4..b4335b68

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

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

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

From duke at openjdk.org  Wed Jan 18 13:15:01 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Wed, 18 Jan 2023 13:15:01 GMT
Subject: [jfx19] RFR: 8300523: Create release notes for 19.0.2
Message-ID: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>

Add release notes for JavaFX 19.0.2 to the repository

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

Commit messages:
 - 8300523: Create release notes for 19.0.2

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

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

From kcr at openjdk.org  Wed Jan 18 13:39:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 18 Jan 2023 13:39:30 GMT
Subject: [jfx19] RFR: 8300523: Create release notes for 19.0.2
In-Reply-To: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
References: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
Message-ID: <t9q-qBODQ-HyVg3mLpGCKh6PHVVT5G4nV7hyEnuB2Ng=.a90af67b-510f-431a-9c9c-e6e998d6ad81@github.com>

On Wed, 18 Jan 2023 13:05:38 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

> Add release notes for JavaFX 19.0.2 to the repository

I left comments inline. Also, here is the list of security bugs fixed in 19.0.2:


JDK-8294779 (not public) | Improve FX pages | fxml
JDK-8289336 (not public) | Better platform image support | graphics
JDK-8289343 (not public) | Better GL support | graphics
JDK-8299628 (not public) | BMP top-down images fail to load after JDK-8289336 | graphics
JDK-8292097 (not public) | Better video decoding | media
JDK-8292105 (not public) | Improve Robot functionality | window-toolkit
JDK-8292112 (not public) | Better DragView handling | window-toolkit

doc-files/release-notes-19.0.2.md line 9:

> 7: These notes document the JavaFX 19.0.2 update release. As such, they complement the [JavaFX 19](https://github.com/openjdk/jfx/blob/jfx19/doc-files/release-notes-19.md) release notes.
> 8: 
> 9: ### FXML JavaScript Engine Disabled by Default

I recommend to add the following above this line:


## Important Changes


See [doc-files/release-notes-18.md#L9](https://github.com/openjdk/jfx/blob/2cec0369ffa74f0a09653261b443886492a29a4d/doc-files/release-notes-18.md?plain=1#L9)

doc-files/release-notes-19.0.2.md line 27:

> 25: [JDK-8283328](https://bugs.openjdk.java.net/browse/JDK-8283328)|Update libxml2 to 2.9.13|web
> 26: [JDK-8286256](https://bugs.openjdk.java.net/browse/JDK-8286256)|Update libxml2 to 2.9.14|web
> 27: [JDK-8286257](https://bugs.openjdk.java.net/browse/JDK-8286257)|Update libxslt to 1.1.35|web

These were all fixed in JavaFX 19, so don't need to be listed here.

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

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

From duke at openjdk.org  Wed Jan 18 13:49:40 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Wed, 18 Jan 2023 13:49:40 GMT
Subject: [jfx19] RFR: 8300523: Create release notes for 19.0.2 [v2]
In-Reply-To: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
References: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
Message-ID: <x_Z2s1yUeaaWkwmkFlljxUxY-MoXM6Icjpu3wNTJgOA=.f3dccd67-8cb1-4ba0-b9ca-0fd5c919e9fd@github.com>

> Add release notes for JavaFX 19.0.2 to the repository

Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:

  Add security fixes and remove redundant bug fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1000/files
  - new: https://git.openjdk.org/jfx/pull/1000/files/2cec0369..c95e1073

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

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

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

From zjx001202 at gmail.com  Wed Jan 18 15:23:54 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 18 Jan 2023 23:23:54 +0800
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
Message-ID: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>

After looking forward to it for a month, I was happy to see the release of
OpenJFX 19.0.2, but I was surprised to find that the update log did not
contain JDK-8296654.

I want to know whether this problem has been solved in OpenJFX 19.0.2?
I think this is a very serious problem that needs to be repaired urgently.
OpenJFX 20 will not be released until a few months later, and it is no
longer compatible with JDK 11, so we cannot wait until that time to update
it.
If 19.0.2 does not include the fix of JDK-8296654, can I ask you to release
19.0.2.1?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230118/0e4afaf2/attachment.htm>

From kcr at openjdk.org  Wed Jan 18 15:57:32 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 18 Jan 2023 15:57:32 GMT
Subject: [jfx19] RFR: 8300523: Create release notes for 19.0.2 [v2]
In-Reply-To: <x_Z2s1yUeaaWkwmkFlljxUxY-MoXM6Icjpu3wNTJgOA=.f3dccd67-8cb1-4ba0-b9ca-0fd5c919e9fd@github.com>
References: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
 <x_Z2s1yUeaaWkwmkFlljxUxY-MoXM6Icjpu3wNTJgOA=.f3dccd67-8cb1-4ba0-b9ca-0fd5c919e9fd@github.com>
Message-ID: <FEL5JdXOW6xn7EDTvDwXl9u-u3krzm0Mrv8W32nrUKA=.3f7d44af-bd18-4e36-8cce-c445bcf5c70f@github.com>

On Wed, 18 Jan 2023 13:49:40 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

>> Add release notes for JavaFX 19.0.2 to the repository
>
> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add security fixes and remove redundant bug fixes

Marked as reviewed by kcr (Lead).

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

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

From angorya at openjdk.org  Wed Jan 18 16:46:32 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 18 Jan 2023 16:46:32 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
Message-ID: <658BeBF0bz8g6stoFeTTFi7dj3B_3ZT03tk_nIsBfGM=.729f791b-94ec-41d0-aa7a-608bc6ba2c57@github.com>

On Wed, 18 Jan 2023 09:25:08 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra spaces

lg, thanks!

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

Marked as reviewed by angorya (Committer).

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

From duke at openjdk.org  Wed Jan 18 18:29:31 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Wed, 18 Jan 2023 18:29:31 GMT
Subject: [jfx19] Integrated: 8300523: Create release notes for 19.0.2
In-Reply-To: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
References: <WFymKvsK_l9eDkhsrjLdIbwxW-DhYnN9X_YM3phNKK4=.7e5b853f-5aad-4856-8610-4c0b5afc5369@github.com>
Message-ID: <vaNKCurPsSqYrnk3x8-C3fBZCYbWxldiHDU_Lgk3BzM=.d498f305-e0c4-4e83-8176-0fa3c7b0345c@github.com>

On Wed, 18 Jan 2023 13:05:38 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

> Add release notes for JavaFX 19.0.2 to the repository

This pull request has now been integrated.

Changeset: 65931493
Author:    Abhinay Agarwal <abhinay.agarwal at gluonhq.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/659314932bd08fe0f9ea59c17db8ae510041dc3a
Stats:     31 lines in 1 file changed: 31 ins; 0 del; 0 mod

8300523: Create release notes for 19.0.2

Reviewed-by: kcr

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

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

From johan.vos at gluonhq.com  Wed Jan 18 18:57:23 2023
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 18 Jan 2023 19:57:23 +0100
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
Message-ID: <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>

Hi,

I'm trying to understand the severity of this. If I understand it
correctly, the issue (which is really a bug, no question about that) only
occurs when running with a JDK that is built with XCode 14.1 (and MacOS SDK
13).

Is that correct? If so, are there JDK builds out there that are built with
XCode 14.1? From the docs/building.md file in openjdk, I believe the daily
builds (by Oracle) are done using Xcode 10.1. I don't know what Oracle and
others are using in their JDK releases, but I would be surprised if all of
them are building with XCode 14.1?

Do you control which JDK is used, or is it up to your users to pick a JDK
and then use that one? If users are using a really recent version of the
JDK (built with Xcode 14.1) it seems to me they can also easily use a
really recent version of JavaFX (20-ea)?

I am probably missing something, so it would be good to get a better
understanding of the context?
I totally agree that we have to make it as easy as possible for end-users
to run JavaFX applications, so we should consider whatever is required to
achieve this.

Thanks,

- Johan


On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:

> After looking forward to it for a month, I was happy to see the release of
> OpenJFX 19.0.2, but I was surprised to find that the update log did not
> contain JDK-8296654.
>
> I want to know whether this problem has been solved in OpenJFX 19.0.2?
> I think this is a very serious problem that needs to be repaired urgently.
> OpenJFX 20 will not be released until a few months later, and it is no
> longer compatible with JDK 11, so we cannot wait until that time to update
> it.
> If 19.0.2 does not include the fix of JDK-8296654, can I ask you to
> release 19.0.2.1?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230118/99cfbd0f/attachment-0001.htm>

From zjx001202 at gmail.com  Wed Jan 18 19:59:55 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 19 Jan 2023 03:59:55 +0800
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
 <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
Message-ID: <CAJL5A3kgOm6qSAxoL7GYr8kSx68fhusWmrNyf+VQVBeVwuUR+Q@mail.gmail.com>

We allow users to use their native JDK (8~19) to start the program.

A crash log we received indicates that JDK from Homebrew will cause a crash.
Because Homebrew is a widely used package manager on MacOS, I think this
problem has a very wide impact.


On Thu, Jan 19, 2023 at 2:57 AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> I'm trying to understand the severity of this. If I understand it
> correctly, the issue (which is really a bug, no question about that) only
> occurs when running with a JDK that is built with XCode 14.1 (and MacOS SDK
> 13).
>
> Is that correct? If so, are there JDK builds out there that are built with
> XCode 14.1? From the docs/building.md file in openjdk, I believe the daily
> builds (by Oracle) are done using Xcode 10.1. I don't know what Oracle and
> others are using in their JDK releases, but I would be surprised if all of
> them are building with XCode 14.1?
>
> Do you control which JDK is used, or is it up to your users to pick a JDK
> and then use that one? If users are using a really recent version of the
> JDK (built with Xcode 14.1) it seems to me they can also easily use a
> really recent version of JavaFX (20-ea)?
>
> I am probably missing something, so it would be good to get a better
> understanding of the context?
> I totally agree that we have to make it as easy as possible for end-users
> to run JavaFX applications, so we should consider whatever is required to
> achieve this.
>
> Thanks,
>
> - Johan
>
>
> On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:
>
>> After looking forward to it for a month, I was happy to see the release
>> of OpenJFX 19.0.2, but I was surprised to find that the update log did not
>> contain JDK-8296654.
>>
>> I want to know whether this problem has been solved in OpenJFX 19.0.2?
>> I think this is a very serious problem that needs to be repaired urgently.
>> OpenJFX 20 will not be released until a few months later, and it is no
>> longer compatible with JDK 11, so we cannot wait until that time to update
>> it.
>> If 19.0.2 does not include the fix of JDK-8296654, can I ask you to
>> release 19.0.2.1?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/093a4f10/attachment.htm>

From kevin.rushforth at oracle.com  Wed Jan 18 20:02:45 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 18 Jan 2023 12:02:45 -0800
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
 <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
Message-ID: <72cd9c4a-9629-b020-0f0b-6b816606a45a@oracle.com>

One small correction: Oracle builds of JDK 20 are built using Xcode 12.4 
+ MacOSX SDK 11. The result is the same: builds of JDK from Oracle will 
not hit this problem (at least not yet; we will likely update the 
compiler some time in the JDK 21 time frame).

-- Kevin


On 1/18/2023 10:57 AM, Johan Vos wrote:
> Hi,
>
> I'm trying to understand the severity of this. If I understand it 
> correctly, the issue (which is really a bug, no question about that) 
> only occurs when running with a JDK that is built with XCode 14.1 (and 
> MacOS SDK 13).
>
> Is that correct? If so, are there JDK builds out there that are built 
> with XCode 14.1? From the docs/building.md file in openjdk, I believe 
> the daily builds (by Oracle) are done using Xcode 10.1. I don't know 
> what Oracle and others are using in their JDK releases, but I would be 
> surprised if all of them are building with XCode 14.1?
>
> Do you control which JDK is used, or is it up to your users to pick a 
> JDK and then use that one? If users are using a really recent version 
> of the JDK (built with Xcode 14.1) it seems to me they can also easily 
> use a really recent version of JavaFX (20-ea)?
>
> I am probably missing something, so it would be good to get a better 
> understanding of the context?
> I totally agree that we have to make it as easy as possible for 
> end-users to run JavaFX applications, so we should consider whatever 
> is required to achieve this.
>
> Thanks,
>
> - Johan
>
>
> On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:
>
>     After looking forward to it for a month, I was happy to see the
>     release of OpenJFX 19.0.2, but I was surprised to find that the
>     update log did not contain JDK-8296654.
>
>     I want to know whether this problem has been solved in OpenJFX
>     19.0.2?
>     I think this is a very serious problem that needs to be repaired
>     urgently.
>     OpenJFX 20 will not be released until a few months later, and it
>     is no longer compatible with JDK 11, so we cannot wait until that
>     time to update it.
>     If 19.0.2 does not include the fix of JDK-8296654, can I ask you
>     to release 19.0.2.1?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230118/72019d91/attachment.htm>

From zjx001202 at gmail.com  Wed Jan 18 20:10:29 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 19 Jan 2023 04:10:29 +0800
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
 <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
Message-ID: <CAJL5A3mXn1UV+Mof8GwiKvZO4nYj59JNjP1Vv3sX=oJGwtTGfw@mail.gmail.com>

I just tried to test on my M1 Mac Mini, and successfully reproduced the
problem.
OpenJDK 11/17/19 installed through Homebrew will cause this problem.
For users who use OpenJDK 11, they cannot easily upgrade to OpenJFX 20.

On Thu, Jan 19, 2023 at 2:57 AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> I'm trying to understand the severity of this. If I understand it
> correctly, the issue (which is really a bug, no question about that) only
> occurs when running with a JDK that is built with XCode 14.1 (and MacOS SDK
> 13).
>
> Is that correct? If so, are there JDK builds out there that are built with
> XCode 14.1? From the docs/building.md file in openjdk, I believe the daily
> builds (by Oracle) are done using Xcode 10.1. I don't know what Oracle and
> others are using in their JDK releases, but I would be surprised if all of
> them are building with XCode 14.1?
>
> Do you control which JDK is used, or is it up to your users to pick a JDK
> and then use that one? If users are using a really recent version of the
> JDK (built with Xcode 14.1) it seems to me they can also easily use a
> really recent version of JavaFX (20-ea)?
>
> I am probably missing something, so it would be good to get a better
> understanding of the context?
> I totally agree that we have to make it as easy as possible for end-users
> to run JavaFX applications, so we should consider whatever is required to
> achieve this.
>
> Thanks,
>
> - Johan
>
>
> On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:
>
>> After looking forward to it for a month, I was happy to see the release
>> of OpenJFX 19.0.2, but I was surprised to find that the update log did not
>> contain JDK-8296654.
>>
>> I want to know whether this problem has been solved in OpenJFX 19.0.2?
>> I think this is a very serious problem that needs to be repaired urgently.
>> OpenJFX 20 will not be released until a few months later, and it is no
>> longer compatible with JDK 11, so we cannot wait until that time to update
>> it.
>> If 19.0.2 does not include the fix of JDK-8296654, can I ask you to
>> release 19.0.2.1?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/d9d264b3/attachment-0001.htm>

From swpalmer at gmail.com  Wed Jan 18 20:18:26 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Wed, 18 Jan 2023 15:18:26 -0500
Subject: Build issue: error: option --upgrade-module-path cannot be used
 together with --release
Message-ID: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>

I'm trying to build OpenJFX on my Mac.  I figured out an issue with the
Gradle scripts, they fail if there is a stale mac_tools.properties file. A
'clean' also fails for the same reason so you have to manually delete the
file to get it to be re-built.  But now the build fails with the following
error:

> Task :graphics:compileJava FAILED
You specified both --module-source-path and a sourcepath. These options are
mutually exclusive. Ignoring sourcepath.
error: option --upgrade-module-path cannot be used together with --release
Usage: javac <options> <source files>
use --help for a list of possible options

FAILURE: Build failed with an exception.

I'm not sure why I would be seeing this error if the build is working for
everyone else.  I'm using JDK 19.

Any hints?

Btw, the Mac section of
https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX still mentions
needing Mercurial.  I don't think that's true anymore.

Regards,

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230118/8b82650a/attachment.htm>

From zjx001202 at gmail.com  Wed Jan 18 20:18:12 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 19 Jan 2023 04:18:12 +0800
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <72cd9c4a-9629-b020-0f0b-6b816606a45a@oracle.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
 <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
 <72cd9c4a-9629-b020-0f0b-6b816606a45a@oracle.com>
Message-ID: <CAJL5A3=SDtzOn05yBpnYC1LxS_s7=YgwWdrp0-S8Q0BwCN81GA@mail.gmail.com>

Homebrew seems to be using xcode 14.1 for macOS 13, so most of the reports
we receive are from macOS 13/13.1.


https://github.com/Homebrew/brew/blob/260ee0ee6af21d31e8c57f6855d661ff6b325fb9/Library/Homebrew/os/mac/xcode.rb#L49

On Thu, Jan 19, 2023 at 4:13 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> One small correction: Oracle builds of JDK 20 are built using Xcode 12.4 +
> MacOSX SDK 11. The result is the same: builds of JDK from Oracle will not
> hit this problem (at least not yet; we will likely update the compiler some
> time in the JDK 21 time frame).
>
> -- Kevin
>
>
> On 1/18/2023 10:57 AM, Johan Vos wrote:
>
> Hi,
>
> I'm trying to understand the severity of this. If I understand it
> correctly, the issue (which is really a bug, no question about that) only
> occurs when running with a JDK that is built with XCode 14.1 (and MacOS SDK
> 13).
>
> Is that correct? If so, are there JDK builds out there that are built with
> XCode 14.1? From the docs/building.md file in openjdk, I believe the daily
> builds (by Oracle) are done using Xcode 10.1. I don't know what Oracle and
> others are using in their JDK releases, but I would be surprised if all of
> them are building with XCode 14.1?
>
> Do you control which JDK is used, or is it up to your users to pick a JDK
> and then use that one? If users are using a really recent version of the
> JDK (built with Xcode 14.1) it seems to me they can also easily use a
> really recent version of JavaFX (20-ea)?
>
> I am probably missing something, so it would be good to get a better
> understanding of the context?
> I totally agree that we have to make it as easy as possible for end-users
> to run JavaFX applications, so we should consider whatever is required to
> achieve this.
>
> Thanks,
>
> - Johan
>
>
> On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:
>
>> After looking forward to it for a month, I was happy to see the release
>> of OpenJFX 19.0.2, but I was surprised to find that the update log did not
>> contain JDK-8296654.
>>
>> I want to know whether this problem has been solved in OpenJFX 19.0.2?
>> I think this is a very serious problem that needs to be repaired urgently.
>> OpenJFX 20 will not be released until a few months later, and it is no
>> longer compatible with JDK 11, so we cannot wait until that time to update
>> it.
>> If 19.0.2 does not include the fix of JDK-8296654, can I ask you to
>> release 19.0.2.1?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/2555d7b9/attachment.htm>

From kcr at openjdk.org  Wed Jan 18 23:54:40 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 18 Jan 2023 23:54:40 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
Message-ID: <Jormo-JldSDAmAH8X-jNWx-0FDZbmSx99a3aKtb-3Ds=.f00562fd-8b7d-446d-817b-b2077ace9a8a@github.com>

On Wed, 18 Jan 2023 09:25:08 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra spaces

Overall it looks great. I left a few comments on the wording.

I presume all of the newly added examples compile?

modules/javafx.controls/src/main/java/javafx/scene/control/ComboBox.java line 126:

> 124:  * necessary to specify a custom {@link StringConverter}.
> 125:  *
> 126:  * <h2>Warning: Nodes should not be inserted directly into the ComboBox items list</h2>

Can you also add the bulleted list of "Important points to note" to `ComboBox`?

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

> 159:  * provide a custom {@link #cellFactoryProperty() cell factory} to create the nodes for a
> 160:  * given cell and update them on demand using the data stored in the item for that cell.</li>
> 161:  * <li>Avoid creating new {@link Node}s in custom {@link #cellFactoryProperty() cell factory} {@code updateItem} method.</li>

I think it would read better to move this bullet above the previous so that the two "avoid"s are next to each other.

Also, that should either be "a custom cell factory updateItem method" (adding the missing article) or maybe "the updateItem method of a custom cell factory"

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

> 189:  * <p> This example has an anonymous custom {@code ListCell} class in the custom cell factory.
> 190:  * Note that the {@code Rectangle} ({@code Node}) object needs to be created in the custom {@code ListCell} class
> 191:  * or in its constructor and updated/used in its {@code updateItem} method.

I might just say "created in the constructor of the custom ListCell" and leave it at that. Saying "in the ... class or ... constructor" might be confusing, since the node is an instance field. The example uses an instance initialization block, which you could mention if you want to be more precise than just saying "in the constructor".

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

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

From kpk at openjdk.org  Thu Jan 19 06:12:41 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 19 Jan 2023 06:12:41 GMT
Subject: RFR: 8230833: LabeledSkinBase computes wrong height with
 ContentDisplay.GRAPHIC_ONLY [v2]
In-Reply-To: <ChnRQNu8dvwZ2xxzMxVQEs__fw3WSxToOXdUOZBUsGk=.01ad16e3-04ce-42c3-a9d4-b69a9e5b48de@github.com>
References: <hJByJdp15YZ6J2A9bpYUFesTcsngqAZ_R22rkf6vLSM=.c68b519b-2801-42d0-9425-3804f253cb87@github.com>
 <ChnRQNu8dvwZ2xxzMxVQEs__fw3WSxToOXdUOZBUsGk=.01ad16e3-04ce-42c3-a9d4-b69a9e5b48de@github.com>
Message-ID: <FNl_CsDaNCyj4SUbeeo2wT4TLa_lJNDSG4rPnhPYQzE=.6e417204-7e81-4849-a554-fa5c30ddb2ad@github.com>

On Wed, 18 Jan 2023 06:56:57 GMT, Karthik P K <kpk at openjdk.org> 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

Expected values of tests listed below have been changed in this PR. Justification for the change is given below.

When text is null or empty, it is considered as ignore text (GRAPHIC_ONLY) condition. So only graphic height along with top and bottom inset value should be considered for height calculation. Hence changed tests are:

1. whenTextIsNullAndGraphicIsSetWithTOPContentDisplay_computePrefHeight_ReturnsRightAnswer
2. whenTextIsEmptyAndGraphicIsSetWithTOPContentDisplay_computePrefHeight_ReturnsRightAnswer
3. whenTextIsNullAndGraphicIsSetWithBOTTOMContentDisplay_computePrefHeight_ReturnsRightAnswer
4. whenTextIsEmptyAndGraphicIsSetWithBOTTOMContentDisplay_computePrefHeight_ReturnsRightAnswer
5. whenTextIsNullAndGraphicIsSetWithTOPContentDisplay_computeMaxHeight_ReturnsRightAnswer
6. whenTextIsEmptyAndGraphicIsSetWithTOPContentDisplay_computeMaxHeight_ReturnsRightAnswer
7. whenTextIsNullAndGraphicIsSetWithBOTTOMContentDisplay_computeMaxHeight_ReturnsRightAnswer
8. whenTextIsEmptyAndGraphicIsSetWithBOTTOMContentDisplay_computeMaxHeight_ReturnsRightAnswer

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

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

From johan.vos at gluonhq.com  Thu Jan 19 09:46:12 2023
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 19 Jan 2023 10:46:12 +0100
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <CAJL5A3mXn1UV+Mof8GwiKvZO4nYj59JNjP1Vv3sX=oJGwtTGfw@mail.gmail.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
 <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
 <CAJL5A3mXn1UV+Mof8GwiKvZO4nYj59JNjP1Vv3sX=oJGwtTGfw@mail.gmail.com>
Message-ID: <CABxFH2FcDd-J775n-sjL36+G4zTStGtg9ckzS=jtB1PRFPQ6pQ@mail.gmail.com>

Hi,

If the JDK installed by Homebrew (is there a public build recipe that
Homebrew is using?) in combination with JavaFX causes apps to crash, then
the situation is really bad indeed.
Kevin and myself will work on the administration to have a 19.0.2.1 patch
update.

- Johan

On Wed, Jan 18, 2023 at 9:11 PM Glavo <zjx001202 at gmail.com> wrote:

> I just tried to test on my M1 Mac Mini, and successfully reproduced the
> problem.
> OpenJDK 11/17/19 installed through Homebrew will cause this problem.
> For users who use OpenJDK 11, they cannot easily upgrade to OpenJFX 20.
>
> On Thu, Jan 19, 2023 at 2:57 AM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>> Hi,
>>
>> I'm trying to understand the severity of this. If I understand it
>> correctly, the issue (which is really a bug, no question about that) only
>> occurs when running with a JDK that is built with XCode 14.1 (and MacOS SDK
>> 13).
>>
>> Is that correct? If so, are there JDK builds out there that are built
>> with XCode 14.1? From the docs/building.md file in openjdk, I believe the
>> daily builds (by Oracle) are done using Xcode 10.1. I don't know what
>> Oracle and others are using in their JDK releases, but I would be surprised
>> if all of them are building with XCode 14.1?
>>
>> Do you control which JDK is used, or is it up to your users to pick a JDK
>> and then use that one? If users are using a really recent version of the
>> JDK (built with Xcode 14.1) it seems to me they can also easily use a
>> really recent version of JavaFX (20-ea)?
>>
>> I am probably missing something, so it would be good to get a better
>> understanding of the context?
>> I totally agree that we have to make it as easy as possible for end-users
>> to run JavaFX applications, so we should consider whatever is required to
>> achieve this.
>>
>> Thanks,
>>
>> - Johan
>>
>>
>> On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:
>>
>>> After looking forward to it for a month, I was happy to see the release
>>> of OpenJFX 19.0.2, but I was surprised to find that the update log did not
>>> contain JDK-8296654.
>>>
>>> I want to know whether this problem has been solved in OpenJFX 19.0.2?
>>> I think this is a very serious problem that needs to be repaired
>>> urgently.
>>> OpenJFX 20 will not be released until a few months later, and it is no
>>> longer compatible with JDK 11, so we cannot wait until that time to update
>>> it.
>>> If 19.0.2 does not include the fix of JDK-8296654, can I ask you to
>>> release 19.0.2.1?
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/2f434faf/attachment.htm>

From johan.vos at gluonhq.com  Thu Jan 19 10:01:32 2023
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 19 Jan 2023 11:01:32 +0100
Subject: backport fix for crash on macos to JavaFX 19
Message-ID: <CABxFH2FbX+CabpfJVJnO=ewyy5qEd0aadqT8Hu1CEzspW1LQhg@mail.gmail.com>

Hi Kevin,

I request permission to backport the fix for JDK-8296654 [1] to jfx/jfx19
(after the version has been increased to 19.0.2.1 [2]).

Thanks,

- Johan

[1] https://bugs.openjdk.org/browse/JDK-8296654
[2] https://bugs.openjdk.org/browse/JDK-8300640
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/d96e53a0/attachment.htm>

From jvos at openjdk.org  Thu Jan 19 10:06:41 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 19 Jan 2023 10:06:41 GMT
Subject: [jfx19] RFR: 8300640: Update JavaFX release to 19.0.2.1 in jfx/jfx19
 branch
Message-ID: <jBO02iSk82U2KZABNvGehk4hH-asDcqBihcIT3qUdXk=.9b52b4bb-1be2-48ee-acf0-e5fc2cb17a58@github.com>

set release version to 19.0.2.1
Fix for JDK-8300640

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

Commit messages:
 - Bump JavaFX patch version to 19.0.2.1 for jfx19

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

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

From kevin.rushforth at oracle.com  Thu Jan 19 12:43:37 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 04:43:37 -0800
Subject: Does OpenJFX 19.0.2 fix the crash on macOS?
In-Reply-To: <CABxFH2FcDd-J775n-sjL36+G4zTStGtg9ckzS=jtB1PRFPQ6pQ@mail.gmail.com>
References: <CAJL5A3n+rd_PKjbzb8Lz2qEr-Gf8ahxr9=8h2N8Uu3E9GEEZnA@mail.gmail.com>
 <CABxFH2E=ev2pkHhCQoxwDWci6qoXkw0zNThAqUdB3HX_zQh=3w@mail.gmail.com>
 <CAJL5A3mXn1UV+Mof8GwiKvZO4nYj59JNjP1Vv3sX=oJGwtTGfw@mail.gmail.com>
 <CABxFH2FcDd-J775n-sjL36+G4zTStGtg9ckzS=jtB1PRFPQ6pQ@mail.gmail.com>
Message-ID: <d8e05f6b-86e3-5e86-5ae7-345f6f0e0ffd@oracle.com>

+1

On 1/19/2023 1:46 AM, Johan Vos wrote:
> Hi,
>
> If the JDK installed by Homebrew (is there a public build recipe that 
> Homebrew is using?) in combination with JavaFX causes apps to crash, 
> then the situation is really bad indeed.
> Kevin and myself will work on the administration to have a 19.0.2.1 
> patch update.
>
> - Johan
>
> On Wed, Jan 18, 2023 at 9:11 PM Glavo <zjx001202 at gmail.com> wrote:
>
>     I just tried to test on my M1 Mac Mini, and successfully
>     reproduced the problem.
>     OpenJDK 11/17/19 installed through Homebrew will cause this problem.
>     For users who use OpenJDK 11, they cannot easily upgrade to
>     OpenJFX 20.
>
>     On Thu, Jan 19, 2023 at 2:57 AM Johan Vos <johan.vos at gluonhq.com>
>     wrote:
>
>         Hi,
>
>         I'm trying to understand the severity of this. If I understand
>         it correctly, the issue (which is really a bug, no question
>         about that) only occurs when running with a JDK that is built
>         with XCode 14.1 (and MacOS SDK 13).
>
>         Is that correct? If so, are there JDK builds out there that
>         are built with XCode 14.1? From the docs/building.md file in
>         openjdk, I believe the daily builds (by Oracle) are done using
>         Xcode 10.1. I don't know what Oracle and others are using in
>         their JDK releases, but I would be surprised if all of them
>         are building with XCode 14.1?
>
>         Do you control which JDK is used, or is it up to your users to
>         pick a JDK and then use that one? If users are using a really
>         recent version of the JDK (built with Xcode 14.1) it seems to
>         me they can also easily use a really recent version of JavaFX
>         (20-ea)?
>
>         I am probably missing something, so it would be good to get a
>         better understanding of the context?
>         I totally agree that we have to make it as easy as possible
>         for end-users to run JavaFX applications, so we should
>         consider whatever is required to achieve this.
>
>         Thanks,
>
>         - Johan
>
>
>         On Wed, Jan 18, 2023 at 5:04 PM Glavo <zjx001202 at gmail.com> wrote:
>
>             After looking forward to it for a month, I was happy to
>             see the release of OpenJFX 19.0.2, but I was surprised to
>             find that the update log did not contain JDK-8296654.
>
>             I want to know whether this problem has been solved in
>             OpenJFX 19.0.2?
>             I think this is a very serious problem that needs to be
>             repaired urgently.
>             OpenJFX 20 will not be released until a few months later,
>             and it is no longer compatible with JDK 11, so we cannot
>             wait until that time to update it.
>             If 19.0.2 does not include the fix of JDK-8296654, can I
>             ask you to release 19.0.2.1?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/dc18b115/attachment.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 12:43:49 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 04:43:49 -0800
Subject: [External] : backport fix for crash on macos to JavaFX 19
In-Reply-To: <CABxFH2FbX+CabpfJVJnO=ewyy5qEd0aadqT8Hu1CEzspW1LQhg@mail.gmail.com>
References: <CABxFH2FbX+CabpfJVJnO=ewyy5qEd0aadqT8Hu1CEzspW1LQhg@mail.gmail.com>
Message-ID: <8dec1afa-00e6-7bdc-4b9e-cc5728afccc4@oracle.com>

Approved.

-- Kevin

On 1/19/2023 2:01 AM, Johan Vos wrote:
> Hi Kevin,
>
> I request permission to backport the fix for JDK-8296654 [1] to 
> jfx/jfx19 (after the version has been increased to 19.0.2.1 [2]).
>
> Thanks,
>
> - Johan
>
> [1] https://bugs.openjdk.org/browse/JDK-8296654
> [2] https://bugs.openjdk.org/browse/JDK-8300640


From kcr at openjdk.org  Thu Jan 19 12:48:27 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 19 Jan 2023 12:48:27 GMT
Subject: [jfx19] RFR: 8300640: Update JavaFX release to 19.0.2.1 in
 jfx/jfx19 branch
In-Reply-To: <jBO02iSk82U2KZABNvGehk4hH-asDcqBihcIT3qUdXk=.9b52b4bb-1be2-48ee-acf0-e5fc2cb17a58@github.com>
References: <jBO02iSk82U2KZABNvGehk4hH-asDcqBihcIT3qUdXk=.9b52b4bb-1be2-48ee-acf0-e5fc2cb17a58@github.com>
Message-ID: <UjKkYavqdxNoa3W3JFJM5tz79R4IbMd7j7NwfshNJOs=.5fe8f193-d47e-4af1-99de-d3f0276eac51@github.com>

On Thu, 19 Jan 2023 09:59:30 GMT, Johan Vos <jvos at openjdk.org> wrote:

> set release version to 19.0.2.1
> Fix for JDK-8300640

Marked as reviewed by kcr (Lead).

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

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

From kpk at openjdk.org  Thu Jan 19 13:00:48 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 19 Jan 2023 13:00:48 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on accelerator
Message-ID: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>

No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.

Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.

Added test to validate the change.

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

Commit messages:
 - Fix RadioMenuItem in ToggleGroup deselection on Accelerator issue

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

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

From jvos at openjdk.org  Thu Jan 19 13:01:21 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 19 Jan 2023 13:01:21 GMT
Subject: [jfx19] Integrated: 8300640: Update JavaFX release to 19.0.2.1 in
 jfx/jfx19 branch
In-Reply-To: <jBO02iSk82U2KZABNvGehk4hH-asDcqBihcIT3qUdXk=.9b52b4bb-1be2-48ee-acf0-e5fc2cb17a58@github.com>
References: <jBO02iSk82U2KZABNvGehk4hH-asDcqBihcIT3qUdXk=.9b52b4bb-1be2-48ee-acf0-e5fc2cb17a58@github.com>
Message-ID: <MZr_0BfmKryqeETVz6ktCf9Jzx4yPTrr5PMIxQqWGQo=.932d08b8-621f-4dd1-86e6-d2e5f805068e@github.com>

On Thu, 19 Jan 2023 09:59:30 GMT, Johan Vos <jvos at openjdk.org> wrote:

> set release version to 19.0.2.1
> Fix for JDK-8300640

This pull request has now been integrated.

Changeset: 06e167ad
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/06e167adf9e737308ebd4b9d6ba3ff76bcc00a53
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8300640: Update JavaFX release to 19.0.2.1 in jfx/jfx19 branch

Reviewed-by: kcr

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

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

From jvos at openjdk.org  Thu Jan 19 13:49:24 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 19 Jan 2023 13:49:24 GMT
Subject: [jfx19] RFR: 8296654: [macos] Crash when launching JavaFX app with JDK
 that targets SDK 13
Message-ID: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>

8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13

Reviewed-by: aghaisas, jvos, mstrauss

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

Commit messages:
 - 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13

Changes: https://git.openjdk.org/jfx/pull/1003/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1003&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/jfx/pull/1003.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1003/head:pull/1003

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

From kcr at openjdk.org  Thu Jan 19 13:49:24 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 19 Jan 2023 13:49:24 GMT
Subject: [jfx19] RFR: 8296654: [macos] Crash when launching JavaFX app with
 JDK that targets SDK 13
In-Reply-To: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>
References: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>
Message-ID: <wXSttOtJH_tlKEf6nXIt3OepefIY4rgQLWx57ytp3o0=.a9f5edf7-67ab-4afc-89e3-fdc13138d5b4@github.com>

On Thu, 19 Jan 2023 13:05:49 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13
> 
> Reviewed-by: aghaisas, jvos, mstrauss

@johanvos I think that "Backport" must be capitalized in the PR title (not 100% sure, but it seems like Skara doesn't recognize this as a backport).

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

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

From tsayao at openjdk.org  Thu Jan 19 13:56:32 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 19 Jan 2023 13:56:32 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v24]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <6FSTu8jTPhJOqSaz23p3XhK_0LKpnSKQUZzb9d9kCc8=.48f757a9-b9b3-4f41-a605-4be549222e86@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Add test scenario

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/c7d88050..fb65199f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=23
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=22-23

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

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

From kcr at openjdk.org  Thu Jan 19 14:51:43 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 19 Jan 2023 14:51:43 GMT
Subject: [jfx19] RFR: 8296654: [macos] Crash when launching JavaFX app with
 JDK that targets SDK 13
In-Reply-To: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>
References: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>
Message-ID: <7GiTEy2lAv45C1Q9hr4rEELbj-MG0uqPmKFIQhqcstg=.a3390aba-da62-45c1-b5eb-ac75711f53bc@github.com>

On Thu, 19 Jan 2023 13:05:49 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13
> 
> Reviewed-by: aghaisas, jvos, mstrauss

Marked as reviewed by kcr (Lead).

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

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

From jvos at openjdk.org  Thu Jan 19 15:14:55 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 19 Jan 2023 15:14:55 GMT
Subject: [jfx19] Integrated: 8296654: [macos] Crash when launching JavaFX app
 with JDK that targets SDK 13
In-Reply-To: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>
References: <eyiYkXgSP5hi_zDU7d-wHucnwnLkK03JWv_MHYg_9ck=.5c9fd3be-5ba7-4da1-9ee5-6f02d700eada@github.com>
Message-ID: <5CjpNDcQdKTVaNa3H7RaBNnx4WkA9T4Y_xsTXYC8_j0=.2b229c36-74d0-4670-a53c-b4716d002a65@github.com>

On Thu, 19 Jan 2023 13:05:49 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8296654: [macos] Crash when launching JavaFX app with JDK that targets SDK 13
> 
> Reviewed-by: aghaisas, jvos, mstrauss

This pull request has now been integrated.

Changeset: 795ed10e
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/795ed10ef358d62635589bb1d5b74f2425e5bc80
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

Reviewed-by: kcr
Backport-of: 5b96d348ebcabb4b6d2e1d95937de3c82a1f6876

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

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

From tsayao at openjdk.org  Thu Jan 19 15:25:54 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 19 Jan 2023 15:25:54 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v25]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <dat9lm_VwuNRoITwZfm87VZcyf0-dFYMksOvubkcvkg=.7feb17bc-0f29-4ee3-a7d0-04cb09bb1a4f@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Revert unnecessary changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/fb65199f..5aba566e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=24
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=23-24

  Stats: 81 lines in 1 file changed: 37 ins; 15 del; 29 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From john.hendrikx at gmail.com  Thu Jan 19 15:49:31 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 19 Jan 2023 16:49:31 +0100
Subject: Feedback requested for infrastructure for properties that wish to
 delay registering listeners
Message-ID: <1d619d0d-c6c1-d98f-935d-47dfcdf1e185@gmail.com>

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 tsayao at openjdk.org  Thu Jan 19 16:23:44 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 19 Jan 2023 16:23:44 GMT
Subject: RFR: 8275033: Drag and drop a file produces NullPointerException
 Cannot read field "dragboard"
Message-ID: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>

When running on Wayland the `GDK_DRAG_LEAVE` is sent just after `GDK_DROP_START`. The leave event causes java to set dragGesture to null. On Xorg this event is not sent. 

The fix just ignore the leave event if a drop occurred.

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

Commit messages:
 - Fix JDK-8275033
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 19 more: https://git.openjdk.org/jfx/compare/89219b70...26f4f22d

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

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

From tsayao at openjdk.org  Thu Jan 19 17:22:38 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 19 Jan 2023 17:22:38 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v26]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <HISpjbhmV3Svy9_KpOYA63Z5VkUInjTVLZRTV_alYkI=.ac4013aa-1412-4dc5-97c0-9e1ed47802bf@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Do not rely on gdk_threads_add_idle_full to end drag as it might lead to inconsistent behaviour.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/5aba566e..a6ca8952

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=25
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=24-25

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

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

From tsayao at openjdk.org  Thu Jan 19 17:25:40 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 19 Jan 2023 17:25:40 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v26]
In-Reply-To: <HISpjbhmV3Svy9_KpOYA63Z5VkUInjTVLZRTV_alYkI=.ac4013aa-1412-4dc5-97c0-9e1ed47802bf@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
 <HISpjbhmV3Svy9_KpOYA63Z5VkUInjTVLZRTV_alYkI=.ac4013aa-1412-4dc5-97c0-9e1ed47802bf@github.com>
Message-ID: <P5V6mtaa6tmgFli3ABD7iWiI1syKyV22DZv_GCvuRqE=.cf3175d8-f42f-4fb5-8cf8-0a3c7e5dd760@github.com>

On Thu, 19 Jan 2023 17:22:38 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> To do general testing (two tests were added):
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>> 
>> Information for reviewing:
>> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
>> * There's a new `DragSourceContext` instead of global variables;
>> * DragView were simplified;
>> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
>> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
>> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
>> * The Scenario were the drag source window closes during the drag is now covered;
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not rely on gdk_threads_add_idle_full to end drag as it might lead to inconsistent behaviour.

Did many tests on Ubuntu 22.04 (Xorg and Wayland) and Ubuntu 16.04. Looking good.

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

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

From swpalmer at gmail.com  Thu Jan 19 18:17:19 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 19 Jan 2023 13:17:19 -0500
Subject: Build issue: error: option --upgrade-module-path cannot be used
 together with --release
In-Reply-To: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
Message-ID: <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>

Tried again with JDK 17.0.5, just in case... still not working.

On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer <swpalmer at gmail.com> wrote:

> I'm trying to build OpenJFX on my Mac.  I figured out an issue with the
> Gradle scripts, they fail if there is a stale mac_tools.properties file. A
> 'clean' also fails for the same reason so you have to manually delete the
> file to get it to be re-built.  But now the build fails with the following
> error:
>
> > Task :graphics:compileJava FAILED
> You specified both --module-source-path and a sourcepath. These options
> are mutually exclusive. Ignoring sourcepath.
> error: option --upgrade-module-path cannot be used together with --release
> Usage: javac <options> <source files>
> use --help for a list of possible options
>
> FAILURE: Build failed with an exception.
>
> I'm not sure why I would be seeing this error if the build is working for
> everyone else.  I'm using JDK 19.
>
> Any hints?
>
> Btw, the Mac section of
> https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX still mentions
> needing Mercurial.  I don't think that's true anymore.
>
> Regards,
>
> Scott
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/ad53b522/attachment.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 18:19:50 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 10:19:50 -0800
Subject: Build issue: error: option --upgrade-module-path cannot be used
 together with --release
In-Reply-To: <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
Message-ID: <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>

I recommend removing the entire build directory (although if you managed 
to get "gradle clean" working, then it will do that).

What version of gradle are you using? You will need gradle 7.6 to use 
JDK 19.

-- Kevin


On 1/19/2023 10:17 AM, Scott Palmer wrote:
> Tried again with JDK 17.0.5, just in case... still not working.
>
> On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>     I'm trying to build OpenJFX on my Mac.? I figured out an issue
>     with the Gradle scripts, they fail if there is a stale
>     mac_tools.properties file. A 'clean' also fails for the same
>     reason so you have to manually delete the file to get it to be
>     re-built.? But now the build fails with the following error:
>
>     > Task :graphics:compileJava FAILED
>     You specified both --module-source-path and a sourcepath. These
>     options are mutually exclusive. Ignoring sourcepath.
>     error: option --upgrade-module-path cannot be used together with
>     --release
>     Usage: javac <options> <source files>
>     use --help for a list of possible options
>
>     FAILURE: Build failed with an exception.
>
>     I'm not sure why I would be seeing this error if the build is
>     working for everyone else.? I'm using JDK 19.
>
>     Any hints?
>
>     Btw, the Mac section of
>     https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX still
>     mentions needing Mercurial.? I don't think that's true anymore.
>
>     Regards,
>
>     Scott
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/431e970e/attachment.htm>

From swpalmer at gmail.com  Thu Jan 19 18:29:36 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 19 Jan 2023 13:29:36 -0500
Subject: Build issue: error: option --upgrade-module-path cannot be used
 together with --release
In-Reply-To: <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
Message-ID: <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>

Tried a gradle clean (which works fine after manually deleting the stale
mac_tools.properties file) and confirmed the build folder was gone from the
graphics module and elsewhere, no difference.  I'm running the gradle
wrapper, so it's using Gradle as defined by the project.  I'm also usually
on the bleeding edge with Gradle, so if I didn't use gradlew it would have
been Gradle 8.0-rc-2 :-)

Scott


On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> I recommend removing the entire build directory (although if you managed
> to get "gradle clean" working, then it will do that).
>
> What version of gradle are you using? You will need gradle 7.6 to use JDK
> 19.
>
> -- Kevin
>
>
> On 1/19/2023 10:17 AM, Scott Palmer wrote:
>
> Tried again with JDK 17.0.5, just in case... still not working.
>
> On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>> I'm trying to build OpenJFX on my Mac.  I figured out an issue with the
>> Gradle scripts, they fail if there is a stale mac_tools.properties file. A
>> 'clean' also fails for the same reason so you have to manually delete the
>> file to get it to be re-built.  But now the build fails with the following
>> error:
>>
>> > Task :graphics:compileJava FAILED
>> You specified both --module-source-path and a sourcepath. These options
>> are mutually exclusive. Ignoring sourcepath.
>> error: option --upgrade-module-path cannot be used together with --release
>> Usage: javac <options> <source files>
>> use --help for a list of possible options
>>
>> FAILURE: Build failed with an exception.
>>
>> I'm not sure why I would be seeing this error if the build is working for
>> everyone else.  I'm using JDK 19.
>>
>> Any hints?
>>
>> Btw, the Mac section of
>> https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX still mentions
>> needing Mercurial.  I don't think that's true anymore.
>>
>> Regards,
>>
>> Scott
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/efb18c48/attachment-0001.htm>

From swpalmer at gmail.com  Thu Jan 19 18:30:03 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 19 Jan 2023 13:30:03 -0500
Subject: Minor: Misleading comment (and typo) in build.gradle
Message-ID: <CAL3e5iF3HMwK2W1-Pgnjarrkmn_-V6jrPjAbLjbUSDX3G04K=w@mail.gmail.com>

This isn't affecting anything, but while trying to figure out my build
issues I noticed this typo and mismatch between the comment and the code..
 "verion" at https://github.com/openjdk/jfx/blob/master/build.gradle#L617
But more significant, the actual command issued is "java -fullversion"
which outputs something substantially different.

// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// java version "1.7.0_45"
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// We need to parse the second line
def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, "-fullversion").start().getErrorStream()));
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/d11269b7/attachment.htm>

From swpalmer at gmail.com  Thu Jan 19 19:17:09 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 19 Jan 2023 14:17:09 -0500
Subject: Build issue: error: option --upgrade-module-path cannot be used
 together with --release
In-Reply-To: <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
 <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
Message-ID: <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>

I found the problem.  I'm using a build of OpenJDK from Azul that includes
the javafx modules.  You probably aren't, which means the
--upgrade-module-path option isn't being used so there is no conflict with
javac parameters.
I downloaded a JDK17 without the JavaFX modules and teh build worked.
I think this will have to be fixed somehow or the documentation needs to
change to forbid a JDK with built-in JavaFX modules.  The current attempts
in the build script to deal with existing javafx modules are not working.
A fix would be better.

Scott

On Thu, Jan 19, 2023 at 1:29 PM Scott Palmer <swpalmer at gmail.com> wrote:

> Tried a gradle clean (which works fine after manually deleting the stale
> mac_tools.properties file) and confirmed the build folder was gone from the
> graphics module and elsewhere, no difference.  I'm running the gradle
> wrapper, so it's using Gradle as defined by the project.  I'm also usually
> on the bleeding edge with Gradle, so if I didn't use gradlew it would have
> been Gradle 8.0-rc-2 :-)
>
> Scott
>
>
> On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>> I recommend removing the entire build directory (although if you managed
>> to get "gradle clean" working, then it will do that).
>>
>> What version of gradle are you using? You will need gradle 7.6 to use JDK
>> 19.
>>
>> -- Kevin
>>
>>
>> On 1/19/2023 10:17 AM, Scott Palmer wrote:
>>
>> Tried again with JDK 17.0.5, just in case... still not working.
>>
>> On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer <swpalmer at gmail.com> wrote:
>>
>>> I'm trying to build OpenJFX on my Mac.  I figured out an issue with the
>>> Gradle scripts, they fail if there is a stale mac_tools.properties file. A
>>> 'clean' also fails for the same reason so you have to manually delete the
>>> file to get it to be re-built.  But now the build fails with the following
>>> error:
>>>
>>> > Task :graphics:compileJava FAILED
>>> You specified both --module-source-path and a sourcepath. These options
>>> are mutually exclusive. Ignoring sourcepath.
>>> error: option --upgrade-module-path cannot be used together with
>>> --release
>>> Usage: javac <options> <source files>
>>> use --help for a list of possible options
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> I'm not sure why I would be seeing this error if the build is working
>>> for everyone else.  I'm using JDK 19.
>>>
>>> Any hints?
>>>
>>> Btw, the Mac section of
>>> https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX still
>>> mentions needing Mercurial.  I don't think that's true anymore.
>>>
>>> Regards,
>>>
>>> Scott
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/9dd18169/attachment.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 19:29:46 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 11:29:46 -0800
Subject: [External] : Re: Build issue: error: option --upgrade-module-path
 cannot be used together with --release
In-Reply-To: <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
 <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
Message-ID: <1234e457-e802-c712-a9c1-9ef8fffd9d40@oracle.com>

You're up to date with the latest jfx master, right?

Our CI builds are working fine, as are the GitHub actions builds (on all 
platforms).

Oh, I see your problem.

 > error: option --upgrade-module-path cannot be used together with 
--release

The "--upgrade-module-path" option is only set if you are running a 
build using a boot JDK that includes the JavaFX modules (see the 
"HAS_JAVAFX_MODULES" variable in build.gradle). We never build that way, 
but the code is still there to support such a build. It looks like you 
may have discovered an incompatibility with the "--release" option 
(which we recently switch to) and building the javafx.* modules for 
inclusion into a JDK build. Are you trying to build a set of JavaFX 
modules for inclusion into your own JDK build? If not, then you will 
need to get a build of the JDK that doesn't have JavaFX modules and use 
that as your boot JDK. If so, then we will need to fix the bug.

I should file a bug anyway, since the HAS_JAVAFX_MODULES case should 
still work.

The solution should be as simple as locally setting 
"project.ext.skipJavaCompilerOptionRelease = true" for all projects. The 
eventual fix is likely to do that if "HAS_JAVAFX_MODULES" is true.

-- Kevin


On 1/19/2023 10:29 AM, Scott Palmer wrote:
> Tried a gradle clean (which works fine after manually deleting the 
> stale mac_tools.properties file) and confirmed the build folder was 
> gone from the graphics?module and elsewhere,?no difference.? I'm 
> running the gradle wrapper, so it's using Gradle as defined by the 
> project.? I'm also usually on the bleeding edge with Gradle, so if I 
> didn't use gradlew it would?have been Gradle 8.0-rc-2 :-)
>
> Scott
>
>
> On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     I recommend removing the entire build directory (although if you
>     managed to get "gradle clean" working, then it will do that).
>
>     What version of gradle are you using? You will need gradle 7.6 to
>     use JDK 19.
>
>     -- Kevin
>
>
>     On 1/19/2023 10:17 AM, Scott Palmer wrote:
>>     Tried again with JDK 17.0.5, just in case... still not working.
>>
>>     On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer <swpalmer at gmail.com>
>>     wrote:
>>
>>         I'm trying to build OpenJFX on my Mac. I figured out an issue
>>         with the Gradle scripts, they fail if there is a stale
>>         mac_tools.properties file. A 'clean' also fails for the same
>>         reason so you have to manually delete the file to get it to
>>         be re-built.? But now the build fails with the following error:
>>
>>         > Task :graphics:compileJava FAILED
>>         You specified both --module-source-path and a sourcepath.
>>         These options are mutually exclusive. Ignoring sourcepath.
>>         error: option --upgrade-module-path cannot be used together
>>         with --release
>>         Usage: javac <options> <source files>
>>         use --help for a list of possible options
>>
>>         FAILURE: Build failed with an exception.
>>
>>         I'm not sure why I would be seeing this error if the build is
>>         working for everyone else.? I'm using JDK 19.
>>
>>         Any hints?
>>
>>         Btw, the Mac section of
>>         https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX
>>         still mentions needing Mercurial.? I don't think that's true
>>         anymore.
>>
>>         Regards,
>>
>>         Scott
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/3dbef0c7/attachment-0001.htm>

From swpalmer at gmail.com  Thu Jan 19 19:45:04 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 19 Jan 2023 14:45:04 -0500
Subject: Build issue: error: option --upgrade-module-path cannot be used
 together with --release
In-Reply-To: <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
 <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
 <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>
Message-ID: <CAL3e5iHK6crG_BQED3AqU=F1JDR5garK-4At4TZZ8bJ+566_Sg@mail.gmail.com>

I guess --patch-module should be used instead of --update-module-path ? It
seems to be a little more complicated.

On Thu, Jan 19, 2023 at 2:17 PM Scott Palmer <swpalmer at gmail.com> wrote:

> I found the problem.  I'm using a build of OpenJDK from Azul that includes
> the javafx modules.  You probably aren't, which means the
> --upgrade-module-path option isn't being used so there is no conflict with
> javac parameters.
> I downloaded a JDK17 without the JavaFX modules and teh build worked.
> I think this will have to be fixed somehow or the documentation needs to
> change to forbid a JDK with built-in JavaFX modules.  The current attempts
> in the build script to deal with existing javafx modules are not working.
> A fix would be better.
>
> Scott
>
> On Thu, Jan 19, 2023 at 1:29 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>> Tried a gradle clean (which works fine after manually deleting the stale
>> mac_tools.properties file) and confirmed the build folder was gone from the
>> graphics module and elsewhere, no difference.  I'm running the gradle
>> wrapper, so it's using Gradle as defined by the project.  I'm also usually
>> on the bleeding edge with Gradle, so if I didn't use gradlew it would have
>> been Gradle 8.0-rc-2 :-)
>>
>> Scott
>>
>>
>> On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth <
>> kevin.rushforth at oracle.com> wrote:
>>
>>> I recommend removing the entire build directory (although if you managed
>>> to get "gradle clean" working, then it will do that).
>>>
>>> What version of gradle are you using? You will need gradle 7.6 to use
>>> JDK 19.
>>>
>>> -- Kevin
>>>
>>>
>>> On 1/19/2023 10:17 AM, Scott Palmer wrote:
>>>
>>> Tried again with JDK 17.0.5, just in case... still not working.
>>>
>>> On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer <swpalmer at gmail.com> wrote:
>>>
>>>> I'm trying to build OpenJFX on my Mac.  I figured out an issue with the
>>>> Gradle scripts, they fail if there is a stale mac_tools.properties file. A
>>>> 'clean' also fails for the same reason so you have to manually delete the
>>>> file to get it to be re-built.  But now the build fails with the following
>>>> error:
>>>>
>>>> > Task :graphics:compileJava FAILED
>>>> You specified both --module-source-path and a sourcepath. These options
>>>> are mutually exclusive. Ignoring sourcepath.
>>>> error: option --upgrade-module-path cannot be used together with
>>>> --release
>>>> Usage: javac <options> <source files>
>>>> use --help for a list of possible options
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>> I'm not sure why I would be seeing this error if the build is working
>>>> for everyone else.  I'm using JDK 19.
>>>>
>>>> Any hints?
>>>>
>>>> Btw, the Mac section of
>>>> https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX still
>>>> mentions needing Mercurial.  I don't think that's true anymore.
>>>>
>>>> Regards,
>>>>
>>>> Scott
>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/b8de0c8b/attachment.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 20:11:51 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 12:11:51 -0800
Subject: [External] : Re: Build issue: error: option --upgrade-module-path
 cannot be used together with --release
In-Reply-To: <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
 <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
 <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>
Message-ID: <b7f0878c-ddfa-4f63-997e-ef27e1232d63@oracle.com>

Looks like our replies crossed in the mail. I replied with basically the 
same conclusion.

-- Kevin


On 1/19/2023 11:17 AM, Scott Palmer wrote:
> I found the problem.? I'm using a build of OpenJDK from Azul that 
> includes the javafx modules.? You probably aren't, which means the 
> --upgrade-module-path option isn't being used so there is no conflict 
> with javac parameters.
> I downloaded a JDK17 without the JavaFX modules and teh build worked.
> I think this will?have to be fixed somehow or the documentation needs 
> to change to forbid a JDK with built-in JavaFX modules.? The current 
> attempts in the build script to deal with existing javafx modules are 
> not working.
> A fix would be better.
>
> Scott
>
> On Thu, Jan 19, 2023 at 1:29 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>     Tried a gradle clean (which works fine after manually deleting the
>     stale mac_tools.properties file) and confirmed the build folder
>     was gone from the graphics?module and elsewhere,?no difference.?
>     I'm running the gradle wrapper, so it's using Gradle as defined by
>     the project. I'm also usually on the bleeding edge with Gradle, so
>     if I didn't use gradlew it would?have been Gradle 8.0-rc-2 :-)
>
>     Scott
>
>
>     On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth
>     <kevin.rushforth at oracle.com> wrote:
>
>         I recommend removing the entire build directory (although if
>         you managed to get "gradle clean" working, then it will do that).
>
>         What version of gradle are you using? You will need gradle 7.6
>         to use JDK 19.
>
>         -- Kevin
>
>
>         On 1/19/2023 10:17 AM, Scott Palmer wrote:
>>         Tried again with JDK 17.0.5, just in case... still not working.
>>
>>         On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer
>>         <swpalmer at gmail.com> wrote:
>>
>>             I'm trying to build OpenJFX on my Mac.? I figured out an
>>             issue with the Gradle scripts, they fail if there is a
>>             stale mac_tools.properties file. A 'clean' also fails for
>>             the same reason so you have to manually delete the file
>>             to get it to be re-built.? But now the build fails with
>>             the following error:
>>
>>             > Task :graphics:compileJava FAILED
>>             You specified both --module-source-path and a sourcepath.
>>             These options are mutually exclusive. Ignoring sourcepath.
>>             error: option --upgrade-module-path cannot be used
>>             together with --release
>>             Usage: javac <options> <source files>
>>             use --help for a list of possible options
>>
>>             FAILURE: Build failed with an exception.
>>
>>             I'm not sure why I would be seeing this error if the
>>             build is working for everyone else.? I'm using JDK 19.
>>
>>             Any hints?
>>
>>             Btw, the Mac section of
>>             https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX
>>             still mentions needing Mercurial.? I don't think that's
>>             true anymore.
>>
>>             Regards,
>>
>>             Scott
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/38bfdb40/attachment-0001.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 20:15:36 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 12:15:36 -0800
Subject: [External] : Re: Build issue: error: option --upgrade-module-path
 cannot be used together with --release
In-Reply-To: <CAL3e5iHK6crG_BQED3AqU=F1JDR5garK-4At4TZZ8bJ+566_Sg@mail.gmail.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
 <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
 <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>
 <CAL3e5iHK6crG_BQED3AqU=F1JDR5garK-4At4TZZ8bJ+566_Sg@mail.gmail.com>
Message-ID: <a8019b74-06d8-5736-ff4e-25778f4847f8@oracle.com>

I'm not sure that will work in general. The more important thing to note 
is that we really can't build and run an actual standalone JavaFX SDK if 
the JDK already has the javafx.* modules. I'll file a bug and we can 
think about possible solutions.

Basically, though, unless you are intending to build a set of javafx.* 
modules to import into your own local custom build of the JDK, you need 
to use a boot JDK that doesn't have the javafx.* modules.

-- Kevin


On 1/19/2023 11:45 AM, Scott Palmer wrote:
> I guess --patch-module should?be used instead of --update-module-path 
> ? It seems to be a little more complicated.
>
> On Thu, Jan 19, 2023 at 2:17 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>     I found the problem.? I'm using a build of OpenJDK from Azul that
>     includes the javafx modules.? You probably aren't, which means the
>     --upgrade-module-path option isn't being used so there is no
>     conflict with javac parameters.
>     I downloaded a JDK17 without the JavaFX modules and teh build worked.
>     I think this will?have to be fixed somehow or the documentation
>     needs to change to forbid a JDK with built-in JavaFX modules.? The
>     current attempts in the build script to deal with existing javafx
>     modules are not working.
>     A fix would be better.
>
>     Scott
>
>     On Thu, Jan 19, 2023 at 1:29 PM Scott Palmer <swpalmer at gmail.com>
>     wrote:
>
>         Tried a gradle clean (which works fine after manually deleting
>         the stale mac_tools.properties file) and confirmed the build
>         folder was gone from the graphics?module and elsewhere,?no
>         difference.? I'm running the gradle wrapper, so it's using
>         Gradle as defined by the project.? I'm also usually on the
>         bleeding edge with Gradle, so if I didn't use gradlew it
>         would?have been Gradle 8.0-rc-2 :-)
>
>         Scott
>
>
>         On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth
>         <kevin.rushforth at oracle.com> wrote:
>
>             I recommend removing the entire build directory (although
>             if you managed to get "gradle clean" working, then it will
>             do that).
>
>             What version of gradle are you using? You will need gradle
>             7.6 to use JDK 19.
>
>             -- Kevin
>
>
>             On 1/19/2023 10:17 AM, Scott Palmer wrote:
>>             Tried again with JDK 17.0.5, just in case... still not
>>             working.
>>
>>             On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer
>>             <swpalmer at gmail.com> wrote:
>>
>>                 I'm trying to build OpenJFX on my Mac.? I figured out
>>                 an issue with the Gradle scripts, they fail if there
>>                 is a stale mac_tools.properties file. A 'clean' also
>>                 fails for the same reason so you have to manually
>>                 delete the file to get it to be re-built.? But now
>>                 the build fails with the following error:
>>
>>                 > Task :graphics:compileJava FAILED
>>                 You specified both --module-source-path and a
>>                 sourcepath. These options are mutually exclusive.
>>                 Ignoring sourcepath.
>>                 error: option --upgrade-module-path cannot be used
>>                 together with --release
>>                 Usage: javac <options> <source files>
>>                 use --help for a list of possible options
>>
>>                 FAILURE: Build failed with an exception.
>>
>>                 I'm not sure why I would be seeing this error if the
>>                 build is working for everyone else.? I'm using JDK 19.
>>
>>                 Any hints?
>>
>>                 Btw, the Mac section of
>>                 https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX
>>                 still mentions needing Mercurial.? I don't think
>>                 that's true anymore.
>>
>>                 Regards,
>>
>>                 Scott
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/57115b76/attachment.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 21:49:20 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 13:49:20 -0800
Subject: [External] : Re: Build issue: error: option --upgrade-module-path
 cannot be used together with --release
In-Reply-To: <a8019b74-06d8-5736-ff4e-25778f4847f8@oracle.com>
References: <CAL3e5iGUML1Hm8-pU_8MsW7yTT2Fcc4dP=wuktNHdqm3Cu-ydw@mail.gmail.com>
 <CAL3e5iFzkkknyVDqpZ0GfDH50sjTudtTzfVkc-4Hd3ohKNoKqg@mail.gmail.com>
 <81d10538-e59d-6ac9-3ae3-5f62ea2db620@oracle.com>
 <CAL3e5iEgowQfDjwV4ctrG-1r=i=s2dyhGy=FAEkqRXMz4CRMjQ@mail.gmail.com>
 <CAL3e5iFSLaTvbLscsf7ubEDsWufx0B2qvXv647MMVK-swdYNrw@mail.gmail.com>
 <CAL3e5iHK6crG_BQED3AqU=F1JDR5garK-4At4TZZ8bJ+566_Sg@mail.gmail.com>
 <a8019b74-06d8-5736-ff4e-25778f4847f8@oracle.com>
Message-ID: <c6a08b39-8cb6-a4a0-258e-7b8ff338ce7e@oracle.com>

I filed https://bugs.openjdk.org/browse/JDK-8300697 to track this. In 
addition to fixing it, I propose to add a very visible warning so that 
developers know they are building in this "HAS_JAVAFX_MODULES" mode, 
since it could otherwise be a surprise when no standalone build 
artifacts are produced.

-- Kevin


On 1/19/2023 12:15 PM, Kevin Rushforth wrote:
> I'm not sure that will work in general. The more important thing to 
> note is that we really can't build and run an actual standalone JavaFX 
> SDK if the JDK already has the javafx.* modules. I'll file a bug and 
> we can think about possible solutions.
>
> Basically, though, unless you are intending to build a set of javafx.* 
> modules to import into your own local custom build of the JDK, you 
> need to use a boot JDK that doesn't have the javafx.* modules.
>
> -- Kevin
>
>
> On 1/19/2023 11:45 AM, Scott Palmer wrote:
>> I guess --patch-module should?be used instead of --update-module-path 
>> ? It seems to be a little more complicated.
>>
>> On Thu, Jan 19, 2023 at 2:17 PM Scott Palmer <swpalmer at gmail.com> wrote:
>>
>>     I found the problem.? I'm using a build of OpenJDK from Azul that
>>     includes the javafx modules.? You probably aren't, which means
>>     the --upgrade-module-path option isn't being used so there is no
>>     conflict with javac parameters.
>>     I downloaded a JDK17 without the JavaFX modules and teh build worked.
>>     I think this will?have to be fixed somehow or the documentation
>>     needs to change to forbid a JDK with built-in JavaFX modules.?
>>     The current attempts in the build script to deal with existing
>>     javafx modules are not working.
>>     A fix would be better.
>>
>>     Scott
>>
>>     On Thu, Jan 19, 2023 at 1:29 PM Scott Palmer <swpalmer at gmail.com>
>>     wrote:
>>
>>         Tried a gradle clean (which works fine after manually
>>         deleting the stale mac_tools.properties file) and confirmed
>>         the build folder was gone from the graphics?module and
>>         elsewhere,?no difference.? I'm running the gradle wrapper, so
>>         it's using Gradle as defined by the project.? I'm also
>>         usually on the bleeding edge with Gradle, so if I didn't use
>>         gradlew it would?have been Gradle 8.0-rc-2 :-)
>>
>>         Scott
>>
>>
>>         On Thu, Jan 19, 2023 at 1:20 PM Kevin Rushforth
>>         <kevin.rushforth at oracle.com> wrote:
>>
>>             I recommend removing the entire build directory (although
>>             if you managed to get "gradle clean" working, then it
>>             will do that).
>>
>>             What version of gradle are you using? You will need
>>             gradle 7.6 to use JDK 19.
>>
>>             -- Kevin
>>
>>
>>             On 1/19/2023 10:17 AM, Scott Palmer wrote:
>>>             Tried again with JDK 17.0.5, just in case... still not
>>>             working.
>>>
>>>             On Wed, Jan 18, 2023 at 3:18 PM Scott Palmer
>>>             <swpalmer at gmail.com> wrote:
>>>
>>>                 I'm trying to build OpenJFX on my Mac.? I figured
>>>                 out an issue with the Gradle scripts, they fail if
>>>                 there is a stale mac_tools.properties file. A
>>>                 'clean' also fails for the same reason so you have
>>>                 to manually delete the file to get it to be
>>>                 re-built.? But now the build fails with the
>>>                 following error:
>>>
>>>                 > Task :graphics:compileJava FAILED
>>>                 You specified both --module-source-path and a
>>>                 sourcepath. These options are mutually exclusive.
>>>                 Ignoring sourcepath.
>>>                 error: option --upgrade-module-path cannot be used
>>>                 together with --release
>>>                 Usage: javac <options> <source files>
>>>                 use --help for a list of possible options
>>>
>>>                 FAILURE: Build failed with an exception.
>>>
>>>                 I'm not sure why I would be seeing this error if the
>>>                 build is working for everyone else.? I'm using JDK 19.
>>>
>>>                 Any hints?
>>>
>>>                 Btw, the Mac section of
>>>                 https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX
>>>                 still mentions needing Mercurial.? I don't think
>>>                 that's true anymore.
>>>
>>>                 Regards,
>>>
>>>                 Scott
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/5ebd46ca/attachment-0001.htm>

From kevin.rushforth at oracle.com  Thu Jan 19 21:55:52 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Jan 2023 13:55:52 -0800
Subject: Minor: Misleading comment (and typo) in build.gradle
In-Reply-To: <CAL3e5iF3HMwK2W1-Pgnjarrkmn_-V6jrPjAbLjbUSDX3G04K=w@mail.gmail.com>
References: <CAL3e5iF3HMwK2W1-Pgnjarrkmn_-V6jrPjAbLjbUSDX3G04K=w@mail.gmail.com>
Message-ID: <a758797f-6104-61cf-4e6f-c7e6df8b0175@oracle.com>

Thanks for reporting this. I think a lot of the comments in build.gradle 
are outdated. I filed https://bugs.openjdk.org/browse/JDK-8300700 to 
track this.

-- Kevin


On 1/19/2023 10:30 AM, Scott Palmer wrote:
> This isn't affecting anything, but while trying to figure out my build 
> issues I noticed this typo and mismatch between the comment and the code..
> ?"verion" at https://github.com/openjdk/jfx/blob/master/build.gradle#L617
> But more significant, the actual command issued is "java -fullversion" 
> which outputs something substantially different.
>
> // Determine the verion of Java in JDK_HOME. It looks like this:
> //
> // $ java -version
> // java version "1.7.0_45"
> // Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> //
> // We need to parse the second line
> def inStream = new java.io.BufferedReader(new 
> java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, 
> "-fullversion").start().getErrorStream()));
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230119/6faffec4/attachment.htm>

From aghaisas at openjdk.org  Fri Jan 20 10:06:44 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 20 Jan 2023 10:06:44 GMT
Subject: RFR: 8137244: Empty Tree/TableView with CONSTRAINED_RESIZE_POLICY
 is not properly resized
In-Reply-To: <SsYExJCUj8zNt4qxNCMN7QeixSp3AGkViM7W_HCPp_s=.7837a284-ec99-477d-a7b1-0b478f36a5ad@github.com>
References: <SsYExJCUj8zNt4qxNCMN7QeixSp3AGkViM7W_HCPp_s=.7837a284-ec99-477d-a7b1-0b478f36a5ad@github.com>
Message-ID: <Xz3OwYb4pGpLV0C_ng-monJruC3NtliDNnTbwkcusw4=.8d114b8a-d05a-4df5-aec8-58b5b0d8a33e@github.com>

On Tue, 10 Jan 2023 19:34:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
> 1. Add data to the tree/table with a constrained resize policy
> 2. Clear the table
> 3. Try to resize the tree/table
> Expected:
> - the tree/table columns get resized
> Observed:
> - columns are not resized
> 
> Caused by an incomplete fix for RT-14855 / JDK-8113886

The fix looks good to me!

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

Marked as reviewed by aghaisas (Reviewer).

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

From aghaisas at openjdk.org  Fri Jan 20 11:16:04 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 20 Jan 2023 11:16:04 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>

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

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Additional review fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/995/files
  - new: https://git.openjdk.org/jfx/pull/995/files/b4335b68..7b441fbf

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

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

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

From aghaisas at openjdk.org  Fri Jan 20 11:16:05 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 20 Jan 2023 11:16:05 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
Message-ID: <jbLNZIsJU5gPDwfsa7iq5uNWH8JNt9_sG8huzG5MwUk=.15d6d061-89c7-4b1e-bf3c-e870d46841b0@github.com>

On Wed, 18 Jan 2023 09:25:08 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra spaces

> Overall it looks great. I left a few comments on the wording.
> 
> I presume all of the newly added examples compile?

Yes. They do compile.

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

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

From aghaisas at openjdk.org  Fri Jan 20 11:16:07 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 20 Jan 2023 11:16:07 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <Jormo-JldSDAmAH8X-jNWx-0FDZbmSx99a3aKtb-3Ds=.f00562fd-8b7d-446d-817b-b2077ace9a8a@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
 <Jormo-JldSDAmAH8X-jNWx-0FDZbmSx99a3aKtb-3Ds=.f00562fd-8b7d-446d-817b-b2077ace9a8a@github.com>
Message-ID: <KHxSzQ_QM7unzbrhtF4ZPYLWUv7owIM9E46wHBy9AKA=.394db06c-95a9-4d97-8e6d-9b36d1d7735b@github.com>

On Wed, 18 Jan 2023 23:20:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra spaces
>
> modules/javafx.controls/src/main/java/javafx/scene/control/ComboBox.java line 126:
> 
>> 124:  * necessary to specify a custom {@link StringConverter}.
>> 125:  *
>> 126:  * <h2>Warning: Nodes should not be inserted directly into the ComboBox items list</h2>
> 
> Can you also add the bulleted list of "Important points to note" to `ComboBox`?

Added the bulleted list.

> I think it would read better to move this bullet above the previous so that the two "avoid"s are next to each other.

The current flow of 3 bullets seems natural to me.
The first point says - what to avoid?
The second point says - what is our recommendation.
The third point says - what to avoid in our recommendation.


> Also, that should either be "a custom cell factory updateItem method" (adding the missing article) or maybe "the updateItem method of a custom cell factory"

Fixed.

> modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 191:
> 
>> 189:  * <p> This example has an anonymous custom {@code ListCell} class in the custom cell factory.
>> 190:  * Note that the {@code Rectangle} ({@code Node}) object needs to be created in the custom {@code ListCell} class
>> 191:  * or in its constructor and updated/used in its {@code updateItem} method.
> 
> I might just say "created in the constructor of the custom ListCell" and leave it at that. Saying "in the ... class or ... constructor" might be confusing, since the node is an instance field. The example uses an instance initialization block, which you could mention if you want to be more precise than just saying "in the constructor".

Reworded the description to include "instance initialisation block"

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

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

From kcr at openjdk.org  Fri Jan 20 12:44:43 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 20 Jan 2023 12:44:43 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
Message-ID: <v8DA8mEXLD8nmC6kWo3WAWAu4kfe8XZCK_vRaQ4ygjg=.86745814-34fe-4c0b-b031-fa7f2d0e82fb@github.com>

On Fri, 20 Jan 2023 11:16:04 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional review fixes

Looks good apart from one more missing "the". Once you add it, go ahead and create the CSR and move it to "Proposed".

modules/javafx.controls/src/main/java/javafx/scene/control/ComboBox.java line 147:

> 145:  * a custom {@link #cellFactoryProperty() cell factory}.</li>
> 146:  * </ul>
> 147:  * <p>The following minimal example shows how to create a custom cell factory for {@code ComboBox} containing {@link Node}s:

Can you also add the final note, after the example, about creating the Rectangle in the instance init block or constructor?

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

> 189:  * <p> This example has an anonymous custom {@code ListCell} class in the custom cell factory.
> 190:  * Note that the {@code Rectangle} ({@code Node}) object needs to be created in the instance initialization block
> 191:  * or the constructor of custom {@code ListCell} class and updated/used in its {@code updateItem} method.

of _the_ custom ...

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

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

From duke at openjdk.org  Fri Jan 20 12:57:33 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Fri, 20 Jan 2023 12:57:33 GMT
Subject: [jfx19] RFR: 8300771: Create release notes for 19.0.2.1
Message-ID: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>

Add release notes for JavaFX 19.0.2.1

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

Commit messages:
 - 8300771: Create release notes for 19.0.2.1

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

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

From kcr at openjdk.org  Fri Jan 20 13:09:44 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 20 Jan 2023 13:09:44 GMT
Subject: [jfx19] RFR: 8300771: Create release notes for 19.0.2.1
In-Reply-To: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>
References: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>
Message-ID: <jxGeMyL50xB6uSoTiWceiBGdICbhLDOal3BiCU1yC6c=.7520c2d5-8fd0-451a-a8c5-109163c3db46@github.com>

On Fri, 20 Jan 2023 12:51:04 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

> Add release notes for JavaFX 19.0.2.1

Marked as reviewed by kcr (Lead).

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

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

From jvos at openjdk.org  Fri Jan 20 13:26:44 2023
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 20 Jan 2023 13:26:44 GMT
Subject: [jfx19] RFR: 8300771: Create release notes for 19.0.2.1
In-Reply-To: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>
References: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>
Message-ID: <aOfcYKeNalJAGTEURFVajcJoeVMG5zqaSV9SWRErMa0=.ffab7ad6-4a0e-4612-849c-1cb37fe00a39@github.com>

On Fri, 20 Jan 2023 12:51:04 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

> Add release notes for JavaFX 19.0.2.1

Marked as reviewed by jvos (Reviewer).

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

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

From duke at openjdk.org  Fri Jan 20 13:39:44 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Fri, 20 Jan 2023 13:39:44 GMT
Subject: [jfx19] Integrated: 8300771: Create release notes for 19.0.2.1
In-Reply-To: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>
References: <jv8ra2YPIDPekmJZlR4Co_tjpAUZmzrTluL9e8iUzkI=.1beb62af-f978-4cd0-90ac-3a6eb03c2e33@github.com>
Message-ID: <hou09c639tNiutv_MSkkSj3D4IWX5XCTOaNmqmymsCA=.25aaea09-530a-4e91-9ba6-4186c88177b2@github.com>

On Fri, 20 Jan 2023 12:51:04 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

> Add release notes for JavaFX 19.0.2.1

This pull request has now been integrated.

Changeset: 34ca36f5
Author:    Abhinay Agarwal <abhinay.agarwal at gluonhq.com>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/34ca36f59ae101e40cab08c041446020713f64d1
Stats:     13 lines in 1 file changed: 13 ins; 0 del; 0 mod

8300771: Create release notes for 19.0.2.1

Reviewed-by: kcr, jvos

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

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

From nlisker at openjdk.org  Fri Jan 20 14:47:52 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 20 Jan 2023 14:47:52 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
Message-ID: <DUFGdT_jjv4o7g5JYZyikHe2CBKYLTmPbpJw3NQzvKM=.394cf1ad-64ff-4f6b-8190-654922167900@github.com>

On Fri, 20 Jan 2023 11:16:04 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional review fixes

Left some minor inline comments that are relevant for the other classes here as well.

Looking at the current `ListView` docs, I think it's not very informative. The main paragraph talks about generics in Java:

> A ListView is able to have its generic type set to represent the type of data in the backing model. Doing this has the benefit of making various methods in the ListView, as well as the supporting classes (mentioned below), type-safe. In addition, making use of the generic type supports substantially simplified development of applications making use of ListView, as all modern IDEs are able to auto-complete far more successfully with the additional type information.

I think that all of that should be removed, and your explanation on how to actually use `ListView` should be added instead. While it's tied to the "Customizing Visuals" section, the points of `ListView` is for it contain data/model instances which are interpreted as a visual `Node` by the `ListView`, so it should belong in the main paragraph.

I can come up with a redistribution of the paragraphs if you want and if you don't consider this out of scope.

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

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

From nlisker at openjdk.org  Fri Jan 20 14:47:58 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 20 Jan 2023 14:47:58 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
Message-ID: <8fVW43vR9cC1IfM2CsJGHjRmCG7ax36XQ-lGoMo2VtQ=.01fd7983-927b-419d-9801-60d33a9d1678@github.com>

On Wed, 18 Jan 2023 09:25:08 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra spaces

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

> 149:  *
> 150:  * <h3>Warning: Nodes should not be inserted directly into the items list</h3>
> 151:  * ListView allows for the items list to contain elements of any type, including

`ListView` should be in `@code`

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

> 150:  * <h3>Warning: Nodes should not be inserted directly into the items list</h3>
> 151:  * ListView allows for the items list to contain elements of any type, including
> 152:  * {@link Node} instances. Putting nodes into

`Node` is already linked above so there's no need for it, but it's fine to leave as is.

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

> 161:  * <li>Avoid creating new {@link Node}s in custom {@link #cellFactoryProperty() cell factory} {@code updateItem} method.</li>
> 162:  * </ul>
> 163:  * <p>The following minimal example shows how to create a custom cell factory for {@code ListView} containing {@link Node}s:

No need to link `Node` here again.

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

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

From swpalmer at gmail.com  Fri Jan 20 14:51:24 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 20 Jan 2023 09:51:24 -0500
Subject: Small changes to Gradle build scripts
Message-ID: <CAL3e5iGTV56yssHbEq4xToVLYjqnhAjV7FzE_ao2AxFEHZrivA@mail.gmail.com>

Are small simplifying changes to the gradle scripts welcome?

E.g. instead of:
def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, "-fullversion").start().getErrorStream()));
try {
String v = inStream.readLine().trim();
if (v != null) {
int ib = v.indexOf("full version \"");
if (ib != -1) {
String str = v.substring(ib);
String ver = str.substring(str.indexOf("\"") + 1, str.size() - 1);

defineProperty("jdkRuntimeVersion", ver)
def jdkVersionInfo = parseJavaVersion(ver)
defineProperty("jdkVersion", jdkVersionInfo[0])
defineProperty("jdkBuildNumber", jdkVersionInfo[1])

// Define global properties based on the version of Java
// For example, we could define a "jdk18OrLater" property as
// follows that could then be used to implement conditional build
// logic based on whether we were running on JDK 18 or later,
// should the need arise.
// def status = compareJdkVersion(jdkVersion, "18")
// ext.jdk18OrLater = (status >= 0)
}
}
} finally {
inStream.close();
}

this:
def verMatch = [JAVA, "-fullversion"].execute().err.text =~ /full version
"([^"]+)/
if (verMatch.find()) {
String ver = verMatch.group(1);
defineProperty("jdkRuntimeVersion", ver)
def jdkVersionInfo = parseJavaVersion(ver)
defineProperty("jdkVersion", jdkVersionInfo[0])
defineProperty("jdkBuildNumber", jdkVersionInfo[1])

// Define global properties based on the version of Java
// For example, we could define a "jdk18OrLater" property as
// follows that could then be used to implement conditional build
// logic based on whether we were running on JDK 18 or later,
// should the need arise.
// def status = compareJdkVersion(jdkVersion, "18")
// ext.jdk18OrLater = (status >= 0)
}

or instead of:
ext.HAS_JAVAFX_MODULES = false;
def inStream2 = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, "--list-modules").start().getInputStream()));
try {
String v;
while ((v = inStream2.readLine()) != null) {
v = v.trim();
if (v.startsWith("javafx.base")) ext.HAS_JAVAFX_MODULES = true;
}
} finally {
inStream2.close();
}

this:
ext.HAS_JAVAFX_MODULES = [JAVA, '--list-modules'].execute().text.contains(
'javafx.base')

... much simpler and seems to work just as well.

They don't do much more than improve readability and reduce the line count
though, so I'm not sure if anyone cares.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230120/ac602013/attachment.htm>

From kcr at openjdk.org  Fri Jan 20 14:52:48 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 20 Jan 2023 14:52:48 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <DUFGdT_jjv4o7g5JYZyikHe2CBKYLTmPbpJw3NQzvKM=.394cf1ad-64ff-4f6b-8190-654922167900@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
 <DUFGdT_jjv4o7g5JYZyikHe2CBKYLTmPbpJw3NQzvKM=.394cf1ad-64ff-4f6b-8190-654922167900@github.com>
Message-ID: <X9-QNGOszU5Y5LvNAAMqAcVqjSHn33XKtfguEO3M5NE=.0a3d75ff-48c1-41ad-818f-cabaf81e9cbf@github.com>

On Fri, 20 Jan 2023 14:44:51 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Looking at the current `ListView` docs, I think it's not very informative. The main paragraph talks about generics in Java:

This would be better done as a separate follow-up issue.

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

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

From kcr at openjdk.org  Fri Jan 20 16:09:46 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 20 Jan 2023 16:09:46 GMT
Subject: RFR: 8275033: Drag and drop a file produces NullPointerException
 Cannot read field "dragboard"
In-Reply-To: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
References: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
Message-ID: <we8x5AwQPrZUktoNAyo3PerbhRMYrJgFc7SXWvTSl1I=.51556705-0efc-48fd-a7eb-e5663bca4066@github.com>

On Thu, 19 Jan 2023 16:16:18 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> When running on Wayland the `GDK_DRAG_LEAVE` is sent just after `GDK_DROP_START`. The leave event causes java to set `dragGesture` to `null`. On Xorg this event is not sent. 
> 
> The fix just ignores the leave event if a drop occurred.

Looks good. I reproduced the bug on Wayland, and can confirm that this fixes the problem

@andy-goryachev-oracle Can you also review this?

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

Marked as reviewed by kcr (Lead).

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

From angorya at openjdk.org  Fri Jan 20 16:23:58 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 20 Jan 2023 16:23:58 GMT
Subject: Integrated: 8137244: Empty Tree/TableView with
 CONSTRAINED_RESIZE_POLICY is not properly resized
In-Reply-To: <SsYExJCUj8zNt4qxNCMN7QeixSp3AGkViM7W_HCPp_s=.7837a284-ec99-477d-a7b1-0b478f36a5ad@github.com>
References: <SsYExJCUj8zNt4qxNCMN7QeixSp3AGkViM7W_HCPp_s=.7837a284-ec99-477d-a7b1-0b478f36a5ad@github.com>
Message-ID: <Au8DuKB_lwlonbGKN2eX5tCJikEg1B_LcmF0WWoVPg0=.311042cd-b37b-4521-884e-a32465f64168@github.com>

On Tue, 10 Jan 2023 19:34:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
> 1. Add data to the tree/table with a constrained resize policy
> 2. Clear the table
> 3. Try to resize the tree/table
> Expected:
> - the tree/table columns get resized
> Observed:
> - columns are not resized
> 
> Caused by an incomplete fix for RT-14855 / JDK-8113886

This pull request has now been integrated.

Changeset: be89e3e3
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/be89e3e3c6c3a4479ee16b6e805a4a10fba6f7ab
Stats:     111 lines in 5 files changed: 106 ins; 2 del; 3 mod

8137244: Empty Tree/TableView with CONSTRAINED_RESIZE_POLICY is not properly resized

Reviewed-by: aghaisas

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

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

From angorya at openjdk.org  Fri Jan 20 19:17:57 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 20 Jan 2023 19:17:57 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator
In-Reply-To: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
Message-ID: <GzI3sSkm1rPQWe_u9Q3kdVN35X6KOMntuK0KJzYttXo=.0b8e55c8-54c2-4094-bd7e-b25279b308e0@github.com>

On Thu, 19 Jan 2023 12:54:55 GMT, Karthik P K <kpk at openjdk.org> wrote:

> No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.
> 
> Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.
> 
> Added test to validate the change.

Tested with the MonkeyTester app.

I'd like to have a discussion on a new ToggleGroup's property (i'll send an email to the mailing list).

This looks good, given the decision to not to allow deselection by an accelerator.

But I wonder if the right approach is to have a property in the ToggleGroup which determines whether to allow all items to be deselected.  If set, the radio menu items should be allowed to be deselected by both keyboard and mouse; if not set, the first item added to a group should be automatically selected, and radio menu items would not get deselected by the mouse or keyboard.

I think it might qualify as a separate enhancement (and a welcome one, since it saves some boilerplate code).

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 178:

> 176:                         if (!menuitem.isDisable()) {
> 177:                             if (menuitem instanceof RadioMenuItem) {
> 178:                                 if(((RadioMenuItem)menuitem).getToggleGroup() == null){

minor: this group insists on adding spaces after "if" and before "{"

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

Marked as reviewed by angorya (Committer).

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

From andy.goryachev at oracle.com  Fri Jan 20 19:31:12 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 20 Jan 2023 19:31:12 +0000
Subject: RFC: new property in ToggleGroup
Message-ID: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>

Dear colleagues:

In the context of a recent PR

https://bugs.openjdk.org/browse/JDK-8237505
https://github.com/openjdk/jfx/pull/1002
https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem

where a number of RadioMenuItems belonging to a toggle group are added to the menu, we might want to add a new property to the ToggleGroup which controls whether all items in a group can be deselected.

If this property is set, a selected radio menu item can be deselected via either keyboard accelerator or a mouse click.  If not, then not only this operation cannot be performed, but also the first item added to said ToggleGroup gets automatically selected.

This should allow for more flexibility in creating menus with RadioMenuItems, but eliminate some boilerplate code required in such cases.

The new logic would also affect any Toggle, such as ToggleButton.

What do you think?  Thank you.

-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230120/047d851d/attachment-0001.htm>

From kevin.rushforth at oracle.com  Fri Jan 20 20:27:28 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 20 Jan 2023 12:27:28 -0800
Subject: RFC: new property in ToggleGroup
In-Reply-To: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>

How common a UI feature is being able to deselect the selected item in a 
ToggleGroup via the UI such that no item is selected? I don't normally 
see that in various apps or toolkits that I am familiar with. What I do 
see is that either a default item is selected or no item is selected 
initially (which is the one and only time that there will be no item 
selected), but in both case, once you make a selection, there is no way 
via the UI to deselect the current item. Absent a compelling need, I 
think the current behavior (once the fix for JDK-8237505 is integrated) 
is sufficient.

What do other developers think?

-- Kevin


On 1/20/2023 11:31 AM, Andy Goryachev wrote:
>
> Dear colleagues:
>
> In the context of a recent PR
>
> https://bugs.openjdk.org/browse/JDK-8237505
>
> https://github.com/openjdk/jfx/pull/1002
>
> https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
>
> where a number of RadioMenuItems belonging to a toggle group are added 
> to the menu, we might want to add a new property to the ToggleGroup 
> which controls whether all items in a group can be deselected.
>
> If this property is set, a selected radio menu item can be deselected 
> via either keyboard accelerator or a mouse click.? If not, then not 
> only this operation cannot be performed, but also the first item added 
> to said ToggleGroup gets automatically selected.
>
> This should allow for more flexibility in creating menus with 
> RadioMenuItems, but eliminate some boilerplate code required in such 
> cases.
>
> The new logic would also affect any Toggle, such as ToggleButton.
>
> What do you think?? Thank you.
>
> -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230120/433dbfff/attachment.htm>

From angorya at openjdk.org  Fri Jan 20 20:40:52 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 20 Jan 2023 20:40:52 GMT
Subject: RFR: 8275033: Drag and drop a file produces NullPointerException
 Cannot read field "dragboard"
In-Reply-To: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
References: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
Message-ID: <eaR74iK4XOKETzKpHdKOnxsVAUCHcQ2TAYHSgZhWRFM=.91f6fd1f-f55c-4007-b443-31fb96811d6f@github.com>

On Thu, 19 Jan 2023 16:16:18 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> When running on Wayland the `GDK_DRAG_LEAVE` is sent just after `GDK_DROP_START`. The leave event causes java to set `dragGesture` to `null`. On Xorg this event is not sent. 
> 
> The fix just ignores the leave event if a drop occurred.

Tested with FxDock on Xorg - no ill effects.

modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 141:

> 139:     jobjectArray mimes;
> 140:     gint dx, dy;
> 141: } enter_ctx = {NULL, FALSE, FALSE, NULL, 0, 0};

it's funny how it's initialized here and also in reset_enter_ctx(), and just by coincidence both produce the same result.  This will break if initial values are other than NULL, 0, FALSE.

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

Marked as reviewed by angorya (Committer).

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

From tsayao at openjdk.org  Fri Jan 20 22:18:13 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 20 Jan 2023 22:18:13 GMT
Subject: Integrated: 8275033: Drag and drop a file produces
 NullPointerException Cannot read field "dragboard"
In-Reply-To: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
References: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
Message-ID: <FZPqPVSvJARaq2OqMziMQs1C6SYrV2lwmVCWUvKzqnY=.81d28119-d4c6-4282-acbe-97c6002219c9@github.com>

On Thu, 19 Jan 2023 16:16:18 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> When running on Wayland the `GDK_DRAG_LEAVE` is sent just after `GDK_DROP_START`. The leave event causes java to set `dragGesture` to `null`. On Xorg this event is not sent. 
> 
> The fix just ignores the leave event if a drop occurred.

This pull request has now been integrated.

Changeset: 294e82e6
Author:    Thiago Milczarek Sayao <tsayao at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/294e82e636a74aab73491c4dea9a31a97c389353
Stats:     9 lines in 1 file changed: 5 ins; 0 del; 4 mod

8275033: Drag and drop a file produces NullPointerException Cannot read field "dragboard"

Reviewed-by: kcr, angorya

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

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

From andy.goryachev at oracle.com  Fri Jan 20 22:57:00 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 20 Jan 2023 22:57:00 +0000
Subject: RFC: new property in ToggleGroup
In-Reply-To: <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>
Message-ID: <DM5PR1001MB2172BD47F71192422D4BC3EAE5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>

I just want to add one thing - the initial state of RadioMenuItems added to a menu is unselected, even if they belong to a ToggleGroup.

One can say that having all unselected radio buttons in a toggle group makes no sense, or perhaps it depends on the application requirements - though I cannot find an example where it might be needed.

So either we allow two different policies by adding a property to the ToggleGroup, or we proclaim that adding a radio button to a toggle group must have a side effect of one (first) button to be automatically selected, otherwise the whole group is in inconsistent state (or the app developer must write some code to select one).

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Friday, 2023/01/20 at 12:27
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFC: new property in ToggleGroup
How common a UI feature is being able to deselect the selected item in a ToggleGroup via the UI such that no item is selected? I don't normally see that in various apps or toolkits that I am familiar with. What I do see is that either a default item is selected or no item is selected initially (which is the one and only time that there will be no item selected), but in both case, once you make a selection, there is no way via the UI to deselect the current item. Absent a compelling need, I think the current behavior (once the fix for JDK-8237505 is integrated) is sufficient.

What do other developers think?

-- Kevin

On 1/20/2023 11:31 AM, Andy Goryachev wrote:
Dear colleagues:

In the context of a recent PR

https://bugs.openjdk.org/browse/JDK-8237505
https://github.com/openjdk/jfx/pull/1002
https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem

where a number of RadioMenuItems belonging to a toggle group are added to the menu, we might want to add a new property to the ToggleGroup which controls whether all items in a group can be deselected.

If this property is set, a selected radio menu item can be deselected via either keyboard accelerator or a mouse click.  If not, then not only this operation cannot be performed, but also the first item added to said ToggleGroup gets automatically selected.

This should allow for more flexibility in creating menus with RadioMenuItems, but eliminate some boilerplate code required in such cases.

The new logic would also affect any Toggle, such as ToggleButton.

What do you think?  Thank you.

-andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230120/863e1311/attachment.htm>

From kcr at openjdk.org  Fri Jan 20 23:19:16 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 20 Jan 2023 23:19:16 GMT
Subject: RFR: 8275033: Drag and drop a file produces NullPointerException
 Cannot read field "dragboard"
In-Reply-To: <eaR74iK4XOKETzKpHdKOnxsVAUCHcQ2TAYHSgZhWRFM=.91f6fd1f-f55c-4007-b443-31fb96811d6f@github.com>
References: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
 <eaR74iK4XOKETzKpHdKOnxsVAUCHcQ2TAYHSgZhWRFM=.91f6fd1f-f55c-4007-b443-31fb96811d6f@github.com>
Message-ID: <ONSxE8HjcazZIDw34O5q54RpMhmbrAnBQJia1x7dkcA=.6ae54e67-5e56-4d8f-8115-0fb0e1d7eb28@github.com>

On Fri, 20 Jan 2023 20:35:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> When running on Wayland the `GDK_DRAG_LEAVE` is sent just after `GDK_DROP_START`. The leave event causes java to set `dragGesture` to `null`. On Xorg this event is not sent. 
>> 
>> The fix just ignores the leave event if a drop occurred.
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 141:
> 
>> 139:     jobjectArray mimes;
>> 140:     gint dx, dy;
>> 141: } enter_ctx = {NULL, FALSE, FALSE, NULL, 0, 0};
> 
> it's funny how it's initialized here and also in reset_enter_ctx(), and just by coincidence both produce the same result.  This will break if initial values are other than NULL, 0, FALSE.

Indeed. During my review, before I looked more closely, I was all ready to post a comment to the effect that it was never set back to FALSE. Then I saw the `memset` in `reset_enter_ctx` that you referred to. Not the way I would have initially designed it -- relying on '0' being the desired default value for all fields (including pointers) -- but given that it is that way, this doesn't make the problem any worse.

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

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

From kevin.rushforth at oracle.com  Fri Jan 20 23:29:58 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 20 Jan 2023 15:29:58 -0800
Subject: Small changes to Gradle build scripts
In-Reply-To: <CAL3e5iGTV56yssHbEq4xToVLYjqnhAjV7FzE_ao2AxFEHZrivA@mail.gmail.com>
References: <CAL3e5iGTV56yssHbEq4xToVLYjqnhAjV7FzE_ao2AxFEHZrivA@mail.gmail.com>
Message-ID: <947b920d-ae2e-ded5-67b4-18f2a3dcb5a8@oracle.com>

It does look cleaner, and I guess every little bit helps. If you want to 
file a cleanup enhancement, we can take a look, but it won't be a very 
high priority.

-- Kevin


On 1/20/2023 6:51 AM, Scott Palmer wrote:
> Are small simplifying changes to the gradle scripts welcome?
>
> E.g. instead of:
> def inStream = new java.io.BufferedReader(new 
> java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, 
> "-fullversion").start().getErrorStream()));
> try {
> String v = inStream.readLine().trim();
> if (v != null) {
> int ib = v.indexOf("full version \"");
> if (ib != -1) {
> String str = v.substring(ib);
> String ver = str.substring(str.indexOf("\"") + 1, str.size() - 1);
> defineProperty("jdkRuntimeVersion", ver)
> def jdkVersionInfo = parseJavaVersion(ver)
> defineProperty("jdkVersion", jdkVersionInfo[0])
> defineProperty("jdkBuildNumber", jdkVersionInfo[1])
> // Define global properties based on the version of Java
> // For example, we could define a "jdk18OrLater" property as
> // follows that could then be used to implement conditional build
> // logic based on whether we were running on JDK 18 or later,
> // should the need arise.
> // def status = compareJdkVersion(jdkVersion, "18")
> // ext.jdk18OrLater = (status >= 0)
> }
> }
> } finally {
> inStream.close();
> }
>
> this:
> def verMatch = [JAVA, "-fullversion"].execute().err.text =~ /full 
> version "([^"]+)/
> if (verMatch.find()) {
> String ver = verMatch.group(1);
> defineProperty("jdkRuntimeVersion", ver)
> def jdkVersionInfo = parseJavaVersion(ver)
> defineProperty("jdkVersion", jdkVersionInfo[0])
> defineProperty("jdkBuildNumber", jdkVersionInfo[1])
> // Define global properties based on the version of Java
> // For example, we could define a "jdk18OrLater" property as
> // follows that could then be used to implement conditional build
> // logic based on whether we were running on JDK 18 or later,
> // should the need arise.
> // def status = compareJdkVersion(jdkVersion, "18")
> // ext.jdk18OrLater = (status >= 0)
> }
>
> or instead of:
> ext.HAS_JAVAFX_MODULES = false;
> def inStream2 = new java.io.BufferedReader(new 
> java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, 
> "--list-modules").start().getInputStream()));
> try {
> String v;
> while ((v = inStream2.readLine()) != null) {
> v = v.trim();
> if (v.startsWith("javafx.base")) ext.HAS_JAVAFX_MODULES = true;
> }
> } finally {
> inStream2.close();
> }
>
> this:
> ext.HAS_JAVAFX_MODULES = [JAVA, 
> '--list-modules'].execute().text.contains('javafx.base')
>
> ... much simpler and seems to work just?as well.
>
> They don't do much more than improve readability and reduce the line 
> count though, so I'm not sure if anyone cares.
>
> Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230120/c4a59898/attachment-0001.htm>

From kevin.rushforth at oracle.com  Fri Jan 20 23:41:20 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 20 Jan 2023 15:41:20 -0800
Subject: RFC: new property in ToggleGroup
In-Reply-To: <DM5PR1001MB2172BD47F71192422D4BC3EAE5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>
 <DM5PR1001MB2172BD47F71192422D4BC3EAE5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <44f16a41-479c-8b51-b221-95006e51c2e6@oracle.com>



On 1/20/2023 2:57 PM, Andy Goryachev wrote:
>
> I just want to add one thing - the initial state of RadioMenuItems 
> added to a menu is unselected, even if they belong to a ToggleGroup.
>
> One can say that having all unselected radio buttons in a toggle group 
> makes no sense, or perhaps it depends on the application requirements 
> - though I cannot find an example where it might be needed.
>

Yes, it's initially unselected unless the app makes an explicit 
selection. HTML radio buttons work the same way [1]. Some apps use that 
to indicate that nothing was selected, but then once you select it there 
will always be something selected.


> So either we allow two different policies by adding a property to the 
> ToggleGroup, or we proclaim that adding a radio button to a toggle 
> group must have a side effect of one (first) button to be 
> automatically selected, otherwise the whole group is in inconsistent 
> state (or the app developer must write some code to select one).
>

I wouldn't want to change the default behavior, since I can imagine some 
apps relying on being able to tell if the user has ever selected any of 
the choices.

Having two properties would be one solution, presuming we think that we 
need to provide a way for the app to indicate that it wants us to 
enforce the invariant of ensuring that the app can't ever get the 
control in a state where nothing is selected. Although, since it would 
be an opt-in, the app could just as easily set the default itself as 
opposed to setting this new? property.

-- Kevin

[1] 
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio

> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Friday, 2023/01/20 at 12:27
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFC: new property in ToggleGroup
>
> How common a UI feature is being able to deselect the selected item in 
> a ToggleGroup via the UI such that no item is selected? I don't 
> normally see that in various apps or toolkits that I am familiar with. 
> What I do see is that either a default item is selected or no item is 
> selected initially (which is the one and only time that there will be 
> no item selected), but in both case, once you make a selection, there 
> is no way via the UI to deselect the current item. Absent a compelling 
> need, I think the current behavior (once the fix for JDK-8237505 is 
> integrated) is sufficient.
>
> What do other developers think?
>
> -- Kevin
>
> On 1/20/2023 11:31 AM, Andy Goryachev wrote:
>
>     Dear colleagues:
>
>     In the context of a recent PR
>
>     https://bugs.openjdk.org/browse/JDK-8237505
>
>     https://github.com/openjdk/jfx/pull/1002
>
>     https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
>
>     where a number of RadioMenuItems belonging to a toggle group are
>     added to the menu, we might want to add a new property to the
>     ToggleGroup which controls whether all items in a group can be
>     deselected.
>
>     If this property is set, a selected radio menu item can be
>     deselected via either keyboard accelerator or a mouse click.? If
>     not, then not only this operation cannot be performed, but also
>     the first item added to said ToggleGroup gets automatically selected.
>
>     This should allow for more flexibility in creating menus with
>     RadioMenuItems, but eliminate some boilerplate code required in
>     such cases.
>
>     The new logic would also affect any Toggle, such as ToggleButton.
>
>     What do you think?? Thank you.
>
>     -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230120/f27bfedd/attachment.htm>

From tsayao at openjdk.org  Sat Jan 21 14:12:12 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 21 Jan 2023 14:12:12 GMT
Subject: RFR: 8275033: Drag and drop a file produces NullPointerException
 Cannot read field "dragboard"
In-Reply-To: <ONSxE8HjcazZIDw34O5q54RpMhmbrAnBQJia1x7dkcA=.6ae54e67-5e56-4d8f-8115-0fb0e1d7eb28@github.com>
References: <phNWKS_4BxgWpv-0P5xnEfjl3lpK0txvibug_Ic9Dn0=.9c4a2e1a-ee74-44fc-a7fc-51217bba365c@github.com>
 <eaR74iK4XOKETzKpHdKOnxsVAUCHcQ2TAYHSgZhWRFM=.91f6fd1f-f55c-4007-b443-31fb96811d6f@github.com>
 <ONSxE8HjcazZIDw34O5q54RpMhmbrAnBQJia1x7dkcA=.6ae54e67-5e56-4d8f-8115-0fb0e1d7eb28@github.com>
Message-ID: <w7kkLOFXrOK8-5OanLxq1Vj3X2l9ufb4spZhaBR9r7A=.ad5007d5-9f45-41ce-a157-23583cfaf16e@github.com>

On Fri, 20 Jan 2023 23:17:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 141:
>> 
>>> 139:     jobjectArray mimes;
>>> 140:     gint dx, dy;
>>> 141: } enter_ctx = {NULL, FALSE, FALSE, NULL, 0, 0};
>> 
>> it's funny how it's initialized here and also in reset_enter_ctx(), and just by coincidence both produce the same result.  This will break if initial values are other than NULL, 0, FALSE.
>
> Indeed. During my review, before I looked more closely, I was all ready to post a comment to the effect that it was never set back to FALSE. Then I saw the `memset` in `reset_enter_ctx` that you referred to. Not the way I would have initially designed it -- relying on '0' being the desired default value for all fields (including pointers) -- but given that it is that way, this doesn't make the problem any worse.

I plan to gradually improve it.

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

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

From tsayao at openjdk.org  Sat Jan 21 15:07:23 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 21 Jan 2023 15:07:23 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v44]
In-Reply-To: <Qp5t6EHZ3eurEl5vglrH35zGF0X6Ig8Hh7fo4ilhi-I=.e0a779e9-c7dc-490e-9d12-86116839b1d5@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <Qp5t6EHZ3eurEl5vglrH35zGF0X6Ig8Hh7fo4ilhi-I=.e0a779e9-c7dc-490e-9d12-86116839b1d5@github.com>
Message-ID: <Q6HzZr4M7zXFBAQs0j2QiePfCeOd-MtWfutwOd05P5o=.743828cb-d963-4ad7-8c0c-be55ea9d60bd@github.com>

On Tue, 17 Jan 2023 18:52:33 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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 one additional commit since the last revision:
> 
>   Revert "Remove duplicated set_events"
>   
>   This reverts commit 077b8df9238679e05b491f015b89670c9ca332a4.

I installed a new Ubuntu 20.04 VM.

This is the result with the print statements.


// this is the Java call to set the size based on Window (not content)
set_bounds -> w = 500, h = 300, cw = -1, ch = -1
// those are the values notified to java (frame extents not received yet)
notify window size -> w = 500, h = 300
notify view size -> cw = 500, ch = 300
// frame extents received, this is the call to set bounds to adjust decoration sizes
set_bounds -> w = 500, h = 300, cw = 500, ch = 263
// those are the values reported to java (note that h is now 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
// this is the paint received from java - values are correct
paint -> 500, 263
paint -> 500, 263


The addition of the print statements made the glitch disappear.

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

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

From tsayao at openjdk.org  Sat Jan 21 15:10:21 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 21 Jan 2023 15:10:21 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v38]
In-Reply-To: <dASvbACYsiXp2S70H4hBr7-rAhdvK7yuO7tijqI_de4=.24815446-177c-457f-bc5a-73bb93618812@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <8OF6z89i4Ib9CwNG2LKxNHNP7uZdReh9NmBqzW1WnPE=.27984f93-cf0a-4be8-806b-eedfbd22349d@github.com>
 <dASvbACYsiXp2S70H4hBr7-rAhdvK7yuO7tijqI_de4=.24815446-177c-457f-bc5a-73bb93618812@github.com>
Message-ID: <tUzoBeb39v93TWL9ISoAQbWYgznvgaLERx0du45JmMI=.76d99912-b44b-4a74-af1c-3847eb6c4553@github.com>

On Thu, 22 Dec 2022 22:08:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix redraw bug (black header)
>
> On my system, the latest change you made didn't make any difference. Not sure why.
> 
> One other observation, which may or may not be related. The system test `InitialSizeTest` fails now 100% of the time on Ubuntu 16.04. The requested Stage size is 200 and the actual size is 228.

@kevinrushforth If you have some time to look at it again I would appreciate. I am interested in getting this PR merged so I can improve it further.

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

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

From tsayao at openjdk.org  Sat Jan 21 15:16:03 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 21 Jan 2023 15:16:03 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v45]
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: <920LNgBg5QjPm6w9WO3nC_-Ow8CZtUPci8VgTRDm9Tg=.f5a05f4c-83b5-4800-bf91-28b5056aa76e@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 54 commits:

 - Merge branch 'master' into clean_glass_gtk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Revert "Remove duplicated set_events"
   
   This reverts commit 077b8df9238679e05b491f015b89670c9ca332a4.
 - Added (temporary) print statements to check size reporting
 - Remove duplicated set_events
 - Merge branch 'master' into clean_glass_gtk
 - Merge branch 'openjdk:master' into master
 - Clarify TITLED / non TITLED
 - ... and 44 more: https://git.openjdk.org/jfx/compare/294e82e6...b8e6b2b8

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

Changes: https://git.openjdk.org/jfx/pull/915/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=44
  Stats: 731 lines in 4 files changed: 225 ins; 387 del; 119 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 jhendrikx at openjdk.org  Sat Jan 21 15:51:48 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 21 Jan 2023 15:51:48 GMT
Subject: [jfx20] RFR: 8300664 Missing copyright header in
 ConditionalBinding.java file
Message-ID: <hk6OIniUfXqMqsuhzqhFPyGgiSCvgMzU1R6ntI8ofaI=.e953a5ca-b4c2-4076-bc13-a9b1adbb97d4@github.com>

Added a copyright header.

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

Commit messages:
 - Add copyright header

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

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

From pedro.duquevieira at gmail.com  Sat Jan 21 15:53:40 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sat, 21 Jan 2023 15:53:40 +0000
Subject: RFC: new property in ToggleGroup
Message-ID: <CAAEud6aRawoBbNS77oZ5Z+prGD6z+wFyToFk__A0XnQbz8ih2Q@mail.gmail.com>

My 2 cents,

I agree with Kevin, I don't see this as a common feature in User Interfaces.

UX wise, like Kevin says, you usually start off with no radio button
selected and then after one is selected the user can't usually deselect the
radio buttons, he can only select another option in the group.

How common a UI feature is being able to deselect the selected item in a
> ToggleGroup via the UI such that no item is selected? I don't normally
> see that in various apps or toolkits that I am familiar with. What I do
> see is that either a default item is selected or no item is selected
> initially (which is the one and only time that there will be no item
> selected), but in both case, once you make a selection, there is no way
> via the UI to deselect the current item. Absent a compelling need, I
> think the current behavior (once the fix for JDK-8237505 is integrated)
> is sufficient.


What do other developers think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230121/2e9d5421/attachment.htm>

From pedro.duquevieira at gmail.com  Sat Jan 21 16:19:33 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sat, 21 Jan 2023 16:19:33 +0000
Subject: Style themes API
In-Reply-To: <CAJEpuXR6XMLByDPGTnZfa+7vuFaeVaZsL8BsOFj6vGYNr2_ong@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
 <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
 <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>
 <CAJEpuXR6XMLByDPGTnZfa+7vuFaeVaZsL8BsOFj6vGYNr2_ong@mail.gmail.com>
Message-ID: <CAAEud6b-Pa9pnFqFHG=12dy70XtKcUOGodCoJHNJ8uwk6QkeQw@mail.gmail.com>

Hi again Michael,

2-

> Currently, the order of precedence is as follows (from highest to lowest):
> 1. Node.style
> 2. Parent.stylesheets
> 3. Scene.stylesheets
> 4. StyleableProperty values set from code
> 5. Application.styleTheme
> 6. Application.userAgentStylesheet


I understand you're suggesting that a style theme could effectively be
> inserted between 3 and 4, such that it overrides local values set from
> code, but not values set in Scene stylesheets.
> I'm not sure that the added complexity is worth the marginal benefits.
> As far as JavaFX has always had the concept of built-in "themes",
> users could reliably override any StyleableProperty value from code.
> Developers might be surprised to find out that they can't set the
> value of a StyleableProperty from code because an application-wide
> style theme overrides any local changes.
> The migration story from Scene stylesheets to a StyleTheme might be a
> little bit easier, but it complicates the mental model of how themes
> interact with the CSS cascade.


I've been building javafx themes for years now. Started creating JMetro in
JavaFX version 2. During this time I've been following how other themes are
being built and I can say that about 90% of the themes (rough estimate)
that are out there, are composed of author stylesheets, i.e they override
values set from code (including JMetro).
I agree that themes that are to be provided to other developers would
probably be better off if they are user agent stylesheets. My point is that
migrating those 90% of themes to use this API would be easier if this flag
exists otherwise migration would likely introduce UI regressions for
developers using those themes.

To be clear, what I'm proposing is a flag, or enum, or whatever, in
StyleTheme that defines whether the stylesheets in the StyleTheme should be
a user agent stylesheet or author stylesheet.

Another point is in making themes that are only to be used locally in a
specific app that the developer is creating. It might be of interest that
he can toggle this flag and make all settings defined in the theme override
any styling set from code (or in FXML) so that he can have a centralized
point where all styling is done.


3 -

> I agree that it would be nice to have a way to programmatically
> control the appearance of system-provided window decorations.
> It's not entirely related to style themes: a style theme is an
> application-wide concept, while window decorations are specific to
> each individual window.
> Maybe we could do this similarly to the Stage.initStyle method, which
> serves a similar purpose of setting up window decorations.


Style themes are generally either defined as dark or light. i.e. you'll
very rarely have a theme that has some Windows with dark decorations and
others with light decorations. So I think it makes sense to have this as a
theme property.
The ability to toggle decorations (light or dark) on an individual Window
is a good point you're making. Perhaps we should have a global definition
in the StyleTheme (whether the theme is light or dark) and a definition
that can be set per Window.
If you set it on the StyleTheme then all Windows will respect it, but you
can override that value on each Window. If you override it on a specific
Window, that definition would take precedence over the global StyleTheme
one.

4-

> If we wanted to expose this front-and-center, we could add these

properties to the Platform.Properties interface:


    public interface Preferences extends ObservableMap<String, Object> {
>         ReadOnlyBooleanProperty darkModeProperty();
>         ReadOnlyObjectProperty<Color> accentColorProperty();
>         ...
>     }


Yes, I think that would be great.

Thanks again!


On Mon, Jan 16, 2023 at 11:28 PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> Hi Pedro,
> see my comments below.
>
>
> On Mon, Jan 16, 2023 at 1:10 PM Pedro Duque Vieira
> <pedro.duquevieira at gmail.com> wrote:
> >
> > No problem, I mentioned those in my first comment but probably got lost
> in this conversation.
> > 2 ? I think the ability to specify in the StyleTheme whether it is a
> user agent stylesheet, or an author stylesheet could be of interest. Most
> of the themes I know are composed of author stylesheets (they use the
> getStylesheets() API in Scene) so migration to using the StyleTheme API
> would be easier if one could specify this. Conversely specifying that the
> StyleTheme is a user agent stylesheet will also be very useful in the cases
> where we?re creating a theme but don?t want it to override styles specified
> through code, etc.
> >
> > I'll now also add that you might want to create a theme, from the get
> go, that doesn't get trumped by any rule set through code, either code
> itself on in FXML files (which will be code anyway). So that the theme css
> is what always drives the presentation of your app (it has priority).
> > This is already possible by choosing to add your stylesheets to the
> Scene getStylesheets() method or by using the setUserAgentStylesheet()
> method.
>
> Currently, the order of precedence is as follows (from highest to lowest):
> 1. Node.style
> 2. Parent.stylesheets
> 3. Scene.stylesheets
> 4. StyleableProperty values set from code
> 5. Application.styleTheme
> 6. Application.userAgentStylesheet
>
> I understand you're suggesting that a style theme could effectively be
> inserted between 3 and 4, such that it overrides local values set from
> code, but not values set in Scene stylesheets.
> I'm not sure that the added complexity is worth the marginal benefits.
> As far as JavaFX has always had the concept of built-in "themes",
> users could reliably override any StyleableProperty value from code.
> Developers might be surprised to find out that they can't set the
> value of a StyleableProperty from code because an application-wide
> style theme overrides any local changes.
> The migration story from Scene stylesheets to a StyleTheme might be a
> little bit easier, but it complicates the mental model of how themes
> interact with the CSS cascade.
>
>
>
> > Ok thanks for clarifying what happens on Mac. Yes on the Windows OS,
> JavaFX won't honor your system wide settings. If your system is in dark
> mode the frames will still be shown in light mode.
> > But anyways, I think, the programmer should be able to toggle the
> dark/light mode setting irrespective of what is defined in the system.
> There are many apps where you, as a user, can choose dark or light mode in
> the app itself and it will honor it regardless of what you have defined in
> the system (e.g. Intellij, Slack, etc, etc). Some will allow you to set
> whether you want to use the system setting for light/dark mode or your own
> setting in the app.
> > This can be of value in cases where you, as a user, prefer to use an app
> in dark mode and others in some other mode, so you can choose themes on an
> app by app basis.
> > Or perhaps the developer wants to design an app that's just dark. In
> that case you'd want the ability to toggle the frame decorations to being
> dark (all the time).
>
> I agree that it would be nice to have a way to programmatically
> control the appearance of system-provided window decorations.
> It's not entirely related to style themes: a style theme is an
> application-wide concept, while window decorations are specific to
> each individual window.
> Maybe we could do this similarly to the Stage.initStyle method, which
> serves a similar purpose of setting up window decorations.
>
>
>
> > Just to be clear I was just talking about how we would present this API
> (platform preferences). This property would be a way to more easily know if
> the system is in dark/light mode, the accent color, without needing to know
> the specific "key".
>
> If we wanted to expose this front-and-center, we could add these
> properties to the Platform.Properties interface:
>
>     public interface Preferences extends ObservableMap<String, Object> {
>         ReadOnlyBooleanProperty darkModeProperty();
>         ReadOnlyObjectProperty<Color> accentColorProperty();
>         ...
>     }
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230121/d39846be/attachment-0001.htm>

From tsayao at openjdk.org  Sat Jan 21 16:21:53 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 21 Jan 2023 16:21:53 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v27]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <zNwWNXgYpZZGYwTrwVgeEnx_w9F3bPhu4-ejDYpMj8s=.66a11a97-c79d-4a35-998e-173072bf6200@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;
> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent.

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:

 - Better end drag
 - Merge branch 'master' into 8273379-dnd-keys
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp
 - Merge branch 'openjdk:master' into master
 - Do not rely on gdk_threads_add_idle_full to end drag as it might lead to inconsistent behaviour.
 - Revert unnecessary changes
 - Add test scenario
 - Merge branch 'master' into 8273379-dnd-keys
 - Merge branch 'openjdk:master' into master
 - Fix DragView below cursor
 - Minor adjustments
 - ... and 55 more: https://git.openjdk.org/jfx/compare/294e82e6...127677c1

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

Changes: https://git.openjdk.org/jfx/pull/986/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=26
  Stats: 959 lines in 9 files changed: 621 ins; 167 del; 171 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

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

From kcr at openjdk.org  Sat Jan 21 16:22:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 21 Jan 2023 16:22:14 GMT
Subject: [jfx20] RFR: 8300664 Missing copyright header in
 ConditionalBinding.java file
In-Reply-To: <hk6OIniUfXqMqsuhzqhFPyGgiSCvgMzU1R6ntI8ofaI=.e953a5ca-b4c2-4076-bc13-a9b1adbb97d4@github.com>
References: <hk6OIniUfXqMqsuhzqhFPyGgiSCvgMzU1R6ntI8ofaI=.e953a5ca-b4c2-4076-bc13-a9b1adbb97d4@github.com>
Message-ID: <Qp1uynVpXH4cwLEGkld9RjOvLDk5W5_3aQbrVr44zho=.b61ad421-1597-4308-88ea-0404feb11bea@github.com>

On Sat, 21 Jan 2023 15:25:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Added a copyright header.

Marked as reviewed by kcr (Lead).

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

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

From nlisker at gmail.com  Sat Jan 21 16:21:58 2023
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 21 Jan 2023 18:21:58 +0200
Subject: RFC: new property in ToggleGroup
In-Reply-To: <44f16a41-479c-8b51-b221-95006e51c2e6@oracle.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>
 <DM5PR1001MB2172BD47F71192422D4BC3EAE5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <44f16a41-479c-8b51-b221-95006e51c2e6@oracle.com>
Message-ID: <CA+0ynh9q3w_30GXhyChs14z5mXeHx0tG-e5T=DPTfJWV93ss-g@mail.gmail.com>

I don't see it being especially useful. GUI's tend to work this way. I
remember it was the same in Swing.

On Sat, Jan 21, 2023 at 1:41 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

>
>
> On 1/20/2023 2:57 PM, Andy Goryachev wrote:
>
> I just want to add one thing - the initial state of RadioMenuItems added
> to a menu is unselected, even if they belong to a ToggleGroup.
>
>
>
> One can say that having all unselected radio buttons in a toggle group
> makes no sense, or perhaps it depends on the application requirements -
> though I cannot find an example where it might be needed.
>
>
> Yes, it's initially unselected unless the app makes an explicit selection.
> HTML radio buttons work the same way [1]. Some apps use that to indicate
> that nothing was selected, but then once you select it there will always be
> something selected.
>
>
>
>
> So either we allow two different policies by adding a property to the
> ToggleGroup, or we proclaim that adding a radio button to a toggle group
> must have a side effect of one (first) button to be automatically selected,
> otherwise the whole group is in inconsistent state (or the app developer
> must write some code to select one).
>
>
> I wouldn't want to change the default behavior, since I can imagine some
> apps relying on being able to tell if the user has ever selected any of the
> choices.
>
> Having two properties would be one solution, presuming we think that we
> need to provide a way for the app to indicate that it wants us to enforce
> the invariant of ensuring that the app can't ever get the control in a
> state where nothing is selected. Although, since it would be an opt-in, the
> app could just as easily set the default itself as opposed to setting this
> new  property.
>
> -- Kevin
>
> [1]
> https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio
>
>
>
> -andy
>
>
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
> <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth
> <kevin.rushforth at oracle.com> <kevin.rushforth at oracle.com>
> *Date: *Friday, 2023/01/20 at 12:27
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> <openjfx-dev at openjdk.org>
> *Subject: *Re: RFC: new property in ToggleGroup
>
> How common a UI feature is being able to deselect the selected item in a
> ToggleGroup via the UI such that no item is selected? I don't normally see
> that in various apps or toolkits that I am familiar with. What I do see is
> that either a default item is selected or no item is selected initially
> (which is the one and only time that there will be no item selected), but
> in both case, once you make a selection, there is no way via the UI to
> deselect the current item. Absent a compelling need, I think the current
> behavior (once the fix for JDK-8237505 is integrated) is sufficient.
>
> What do other developers think?
>
> -- Kevin
>
> On 1/20/2023 11:31 AM, Andy Goryachev wrote:
>
> Dear colleagues:
>
>
>
> In the context of a recent PR
>
>
>
> https://bugs.openjdk.org/browse/JDK-8237505
>
> https://github.com/openjdk/jfx/pull/1002
>
>
> https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
>
>
>
> where a number of RadioMenuItems belonging to a toggle group are added to
> the menu, we might want to add a new property to the ToggleGroup which
> controls whether all items in a group can be deselected.
>
>
>
> If this property is set, a selected radio menu item can be deselected via
> either keyboard accelerator or a mouse click.  If not, then not only this
> operation cannot be performed, but also the first item added to said
> ToggleGroup gets automatically selected.
>
>
>
> This should allow for more flexibility in creating menus with
> RadioMenuItems, but eliminate some boilerplate code required in such cases.
>
>
>
> The new logic would also affect any Toggle, such as ToggleButton.
>
>
>
> What do you think?  Thank you.
>
>
>
> -andy
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230121/f5b07ecb/attachment-0001.htm>

From tsayao at openjdk.org  Sat Jan 21 16:28:15 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 21 Jan 2023 16:28:15 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v27]
In-Reply-To: <zNwWNXgYpZZGYwTrwVgeEnx_w9F3bPhu4-ejDYpMj8s=.66a11a97-c79d-4a35-998e-173072bf6200@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
 <zNwWNXgYpZZGYwTrwVgeEnx_w9F3bPhu4-ejDYpMj8s=.66a11a97-c79d-4a35-998e-173072bf6200@github.com>
Message-ID: <YPeaUcdTI7sZNy9a6tDxKVvmHjYQpWH4r7W4gE3E-N8=.4400a305-0947-470c-8a4f-abcdd7c95315@github.com>

On Sat, 21 Jan 2023 16:21:53 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR fixes 8273379.
>> 
>> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
>> 
>> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
>> 
>> There's also some cleaup.
>> 
>> To do general testing (two tests were added):
>> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
>> 
>> Information for reviewing:
>> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
>> * There's a new `DragSourceContext` instead of global variables;
>> * DragView were simplified;
>> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
>> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
>> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
>> * The Scenario were the drag source window closes during the drag is now covered;
>> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent.
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
> 
>  - Better end drag
>  - Merge branch 'master' into 8273379-dnd-keys
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp
>  - Merge branch 'openjdk:master' into master
>  - Do not rely on gdk_threads_add_idle_full to end drag as it might lead to inconsistent behaviour.
>  - Revert unnecessary changes
>  - Add test scenario
>  - Merge branch 'master' into 8273379-dnd-keys
>  - Merge branch 'openjdk:master' into master
>  - Fix DragView below cursor
>  - Minor adjustments
>  - ... and 55 more: https://git.openjdk.org/jfx/compare/294e82e6...127677c1

It seems to be working as expected with Ubuntu 20.04 .

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

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

From michaelstrau2 at gmail.com  Sat Jan 21 16:32:53 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 21 Jan 2023 17:32:53 +0100
Subject: RFC: new property in ToggleGroup
In-Reply-To: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXQ1terifjvqxX9PzS73jMSj7OUJ9qcKVm_QbSGhV0O7DQ@mail.gmail.com>

My expectation with radio groups is that they may start out initially
unselected, but once a selection has been made, no user interaction
can unselect all toggles again.
I don't see any compelling reason to change that. If the group needs
to be reset to its initial state, that's as easy as calling
`toggleGroup.selectToggle(null)`.

However, what you're describing sounds to me like a group of
checkboxes. I've seen this type of grouping many times in various
applications, and checkboxes are generally understood to be
deselectable.
So my question is: why don't we instead have CheckBox implement
Toggle, allowing it to be used with ToggleGroup? That would make it
possible to create a deselectable group of toggles.

On Fri, Jan 20, 2023 at 8:31 PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> Dear colleagues:
>
>
>
> In the context of a recent PR
>
>
>
> https://bugs.openjdk.org/browse/JDK-8237505
>
> https://github.com/openjdk/jfx/pull/1002
>
> https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
>
>
>
> where a number of RadioMenuItems belonging to a toggle group are added to the menu, we might want to add a new property to the ToggleGroup which controls whether all items in a group can be deselected.
>
>
>
> If this property is set, a selected radio menu item can be deselected via either keyboard accelerator or a mouse click.  If not, then not only this operation cannot be performed, but also the first item added to said ToggleGroup gets automatically selected.
>
>
>
> This should allow for more flexibility in creating menus with RadioMenuItems, but eliminate some boilerplate code required in such cases.
>
>
>
> The new logic would also affect any Toggle, such as ToggleButton.
>
>
>
> What do you think?  Thank you.
>
>
>
> -andy

From nlisker at gmail.com  Sat Jan 21 18:19:07 2023
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 21 Jan 2023 20:19:07 +0200
Subject: RFC: new property in ToggleGroup
In-Reply-To: <CAJEpuXQ1terifjvqxX9PzS73jMSj7OUJ9qcKVm_QbSGhV0O7DQ@mail.gmail.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXQ1terifjvqxX9PzS73jMSj7OUJ9qcKVm_QbSGhV0O7DQ@mail.gmail.com>
Message-ID: <CA+0ynh8Qo8KYb+_pT6JLZ7VHGvQwY2jszJQh-xaLsmD1ydr3+A@mail.gmail.com>

We already have ToggleButton:

Unlike RadioButtons, ToggleButtons in a ToggleGroup do not attempt to force
> at least one selected ToggleButton in the group.

That is, if a ToggleButton is selected, clicking on it will cause it to
> become unselected.

With RadioButton, clicking on the selected button in the group will have no
> effect.


Checkboxes tend to allow multiple selection ("select all items that apply
to you"), which means they don't need to toggle each other, they are
independent. They also have indeterminate states, which I don't know how to
address regarding ToggleGroup selection policies.

On Sat, Jan 21, 2023 at 6:33 PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> My expectation with radio groups is that they may start out initially
> unselected, but once a selection has been made, no user interaction
> can unselect all toggles again.
> I don't see any compelling reason to change that. If the group needs
> to be reset to its initial state, that's as easy as calling
> `toggleGroup.selectToggle(null)`.
>
> However, what you're describing sounds to me like a group of
> checkboxes. I've seen this type of grouping many times in various
> applications, and checkboxes are generally understood to be
> deselectable.
> So my question is: why don't we instead have CheckBox implement
> Toggle, allowing it to be used with ToggleGroup? That would make it
> possible to create a deselectable group of toggles.
>
> On Fri, Jan 20, 2023 at 8:31 PM Andy Goryachev
> <andy.goryachev at oracle.com> wrote:
> >
> > Dear colleagues:
> >
> >
> >
> > In the context of a recent PR
> >
> >
> >
> > https://bugs.openjdk.org/browse/JDK-8237505
> >
> > https://github.com/openjdk/jfx/pull/1002
> >
> >
> https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
> >
> >
> >
> > where a number of RadioMenuItems belonging to a toggle group are added
> to the menu, we might want to add a new property to the ToggleGroup which
> controls whether all items in a group can be deselected.
> >
> >
> >
> > If this property is set, a selected radio menu item can be deselected
> via either keyboard accelerator or a mouse click.  If not, then not only
> this operation cannot be performed, but also the first item added to said
> ToggleGroup gets automatically selected.
> >
> >
> >
> > This should allow for more flexibility in creating menus with
> RadioMenuItems, but eliminate some boilerplate code required in such cases.
> >
> >
> >
> > The new logic would also affect any Toggle, such as ToggleButton.
> >
> >
> >
> > What do you think?  Thank you.
> >
> >
> >
> > -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230121/ac3efa17/attachment-0001.htm>

From duke at openjdk.org  Sat Jan 21 19:14:12 2023
From: duke at openjdk.org (JoachimSchriek)
Date: Sat, 21 Jan 2023 19:14:12 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport
In-Reply-To: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
References: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
Message-ID: <f9BCFqwQBNTP3XcHsOMwdoLkceOKZ9fjEM01jhRUva0=.824b2772-0a6c-4095-9903-173eeda0ca89@github.com>

On Mon, 26 Dec 2022 19:08:55 GMT, JoachimSchriek <duke at openjdk.org> 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.

Hi Kevin, should I push a commit with a test class to my repository in package test.robot.javafx.scene.tableview?

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

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

From michaelstrau2 at gmail.com  Sat Jan 21 19:26:36 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 21 Jan 2023 20:26:36 +0100
Subject: RFC: new property in ToggleGroup
In-Reply-To: <CA+0ynh8Qo8KYb+_pT6JLZ7VHGvQwY2jszJQh-xaLsmD1ydr3+A@mail.gmail.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXQ1terifjvqxX9PzS73jMSj7OUJ9qcKVm_QbSGhV0O7DQ@mail.gmail.com>
 <CA+0ynh8Qo8KYb+_pT6JLZ7VHGvQwY2jszJQh-xaLsmD1ydr3+A@mail.gmail.com>
Message-ID: <CAJEpuXQ4s_kXpjn-erErBk2h8ff9nsSLM_EYccP7fEeRwJ4+7Q@mail.gmail.com>

Sure, checkboxes allow multiple selection in general, but as I've
said, I've come across lots of examples where applications use
radio-like checkboxes to do precisely what Andy proposed: create a
group of toggles where either one toggle or no toggle can be selected
at any given time. I'm not saying that this is a great UX, I'm saying
that this is a common thing in many applications. That's in stark
contrast to a deselectable group of RadioButtons, which I haven't come
across in any application that I know.

While one could use ToggleButtons for that, ToggleButtons are not
CheckBoxes. They look different out of the box, and require
unintuitive re-styling to make them look like CheckBoxes.
My point is this: if it looks like a CheckBox, it should also _be_ a
CheckBox. In this case, that's as easy as acknowledging that a
CheckBox is, indeed, a Toggle.

I don't think that the indeterminate state is a problem here. For the
"group of one or zero toggles" scenario, one would simply disallow the
indeterminate state.
If the indeterminate state is allowed, no conflict occurs: upon
automatic deselection, the ToggleGroup would set
CheckBox.selected=false, while CheckBox.indeterminate would remain
true.
That doesn't make a lot of sense from a UI perspective, but it's not
something that would happen by accident. After all,
CheckBox.allowIndeterminate is false by default.

On Sat, Jan 21, 2023 at 7:19 PM Nir Lisker <nlisker at gmail.com> wrote:
>
> We already have ToggleButton:
>
>> Unlike RadioButtons, ToggleButtons in a ToggleGroup do not attempt to force at least one selected ToggleButton in the group.
>>
>> That is, if a ToggleButton is selected, clicking on it will cause it to become unselected.
>>
>> With RadioButton, clicking on the selected button in the group will have no effect.
>
>
> Checkboxes tend to allow multiple selection ("select all items that apply to you"), which means they don't need to toggle each other, they are independent. They also have indeterminate states, which I don't know how to address regarding ToggleGroup selection policies.
>
> On Sat, Jan 21, 2023 at 6:33 PM Michael Strau? <michaelstrau2 at gmail.com> wrote:
>>
>> My expectation with radio groups is that they may start out initially
>> unselected, but once a selection has been made, no user interaction
>> can unselect all toggles again.
>> I don't see any compelling reason to change that. If the group needs
>> to be reset to its initial state, that's as easy as calling
>> `toggleGroup.selectToggle(null)`.
>>
>> However, what you're describing sounds to me like a group of
>> checkboxes. I've seen this type of grouping many times in various
>> applications, and checkboxes are generally understood to be
>> deselectable.
>> So my question is: why don't we instead have CheckBox implement
>> Toggle, allowing it to be used with ToggleGroup? That would make it
>> possible to create a deselectable group of toggles.
>>
>> On Fri, Jan 20, 2023 at 8:31 PM Andy Goryachev
>> <andy.goryachev at oracle.com> wrote:
>> >
>> > Dear colleagues:
>> >
>> >
>> >
>> > In the context of a recent PR
>> >
>> >
>> >
>> > https://bugs.openjdk.org/browse/JDK-8237505
>> >
>> > https://github.com/openjdk/jfx/pull/1002
>> >
>> > https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
>> >
>> >
>> >
>> > where a number of RadioMenuItems belonging to a toggle group are added to the menu, we might want to add a new property to the ToggleGroup which controls whether all items in a group can be deselected.
>> >
>> >
>> >
>> > If this property is set, a selected radio menu item can be deselected via either keyboard accelerator or a mouse click.  If not, then not only this operation cannot be performed, but also the first item added to said ToggleGroup gets automatically selected.
>> >
>> >
>> >
>> > This should allow for more flexibility in creating menus with RadioMenuItems, but eliminate some boilerplate code required in such cases.
>> >
>> >
>> >
>> > The new logic would also affect any Toggle, such as ToggleButton.
>> >
>> >
>> >
>> > What do you think?  Thank you.
>> >
>> >
>> >
>> > -andy

From jhendrikx at openjdk.org  Sat Jan 21 21:59:12 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 21 Jan 2023 21:59:12 GMT
Subject: [jfx20] Integrated: 8300664 Missing copyright header in
 ConditionalBinding.java file
In-Reply-To: <hk6OIniUfXqMqsuhzqhFPyGgiSCvgMzU1R6ntI8ofaI=.e953a5ca-b4c2-4076-bc13-a9b1adbb97d4@github.com>
References: <hk6OIniUfXqMqsuhzqhFPyGgiSCvgMzU1R6ntI8ofaI=.e953a5ca-b4c2-4076-bc13-a9b1adbb97d4@github.com>
Message-ID: <BXGDZfprKYl3TZ4KbWcbUD1F-RMuuagTV50QI2vqsdU=.7773183c-90de-471a-9ffa-d351fb9c5a50@github.com>

On Sat, 21 Jan 2023 15:25:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Added a copyright header.

This pull request has now been integrated.

Changeset: 05a67df6
Author:    John Hendrikx <jhendrikx at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/05a67df666bbcfc48299346005aa07b1e9d48ab5
Stats:     25 lines in 1 file changed: 25 ins; 0 del; 0 mod

8300664: Missing copyright header in ConditionalBinding.java file

Reviewed-by: kcr

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

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

From kcr at openjdk.org  Sat Jan 21 22:01:12 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 21 Jan 2023 22:01:12 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport
In-Reply-To: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
References: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
Message-ID: <t9Sq4vARLZ__ysC-pCg_GjUZfwHM5jOq-XrCwqk6fdI=.0143a66a-83e0-4d9c-a469-96850aa17577@github.com>

On Mon, 26 Dec 2022 19:08:55 GMT, JoachimSchriek <duke at openjdk.org> 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.

Sure, that sounds good.

I should add that this presumes you can't test this with a unit test in the `javafx.controls` module (testing it without using robot is better if feasible).

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

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

From mstrauss at openjdk.org  Sat Jan 21 23:02:13 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 21 Jan 2023 23:02:13 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator
In-Reply-To: <GzI3sSkm1rPQWe_u9Q3kdVN35X6KOMntuK0KJzYttXo=.0b8e55c8-54c2-4094-bd7e-b25279b308e0@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
 <GzI3sSkm1rPQWe_u9Q3kdVN35X6KOMntuK0KJzYttXo=.0b8e55c8-54c2-4094-bd7e-b25279b308e0@github.com>
Message-ID: <goM7uUCcKWLQ7tzg2ubbBoKIVI7_OaZrWqFLlZKkpqY=.8debe29e-f209-41aa-b4ff-76f076e85511@github.com>

On Fri, 20 Jan 2023 19:06:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.
>> 
>> Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.
>> 
>> Added test to validate the change.
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 178:
> 
>> 176:                         if (!menuitem.isDisable()) {
>> 177:                             if (menuitem instanceof RadioMenuItem) {
>> 178:                                 if(((RadioMenuItem)menuitem).getToggleGroup() == null){
> 
> minor: this group insists on adding spaces after "if" and before "{"

You can use a pattern variable here to get rid of all the casts.

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

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

From mstrauss at openjdk.org  Sat Jan 21 23:49:24 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 21 Jan 2023 23:49:24 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v19]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <jjYQJPm5-AQDwBNJLWePlLgxKyRYvWkxWjw_ri32TEc=.d4b93097-a1e6-42ae-b43c-e6a120c22080@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the user-agent stylesheet of the application.
>      * <p>
>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>      * It can be used to provide default styling for UI controls and other nodes.
>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>      * <p>
>      * Before JavaFX 21, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>      * scene graph.
>      * <p>
>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. Preferences
> `javafx.application.Platform.Preferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `ObservableMap` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code Preferences} extends {@link ObservableMap} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface Preferences extends ObservableMap<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> }
> 
> An instance of `Preferences` can be retrieved via `Platform.getPreferences()`.
> 
> Here's a list of the preferences available for Windows, as reported by the [SystemParametersInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow), [GetSysColor](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor) and [Windows.UI.ViewManagement.UISettings.GetColorValue](https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.getcolorvalue) APIs. Deprecated colors are not included.
> | Windows preferences                                  | Type    |
> |--------------------------------------|---------|
> | Windows.SPI.HighContrast             | Boolean |
> | Windows.SPI.HighContrastColorScheme  | String  |
> | Windows.SysColor.COLOR_3DFACE        | Color   |
> | Windows.SysColor.COLOR_BTNTEXT       | Color   |
> | Windows.SysColor.COLOR_GRAYTEXT      | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHT     | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHTTEXT | Color   |
> | Windows.SysColor.COLOR_HOTLIGHT      | Color   |
> | Windows.SysColor.COLOR_WINDOW        | Color   |
> | Windows.SysColor.COLOR_WINDOWTEXT    | Color   |
> | Windows.UIColor.Background           | Color   |
> | Windows.UIColor.Foreground           | Color   |
> | Windows.UIColor.AccentDark3          | Color   |
> | Windows.UIColor.AccentDark2          | Color   |
> | Windows.UIColor.AccentDark1          | Color   |
> | Windows.UIColor.Accent               | Color   |
> | Windows.UIColor.AccentLight1         | Color   |
> | Windows.UIColor.AccentLight2         | Color   |
> | Windows.UIColor.AccentLight3         | Color   |
> 
> Here is a list of macOS preferences as reported by `NSColor`'s [UI Element Colors](https://developer.apple.com/documentation/appkit/nscolor/ui_element_colors) and [Adaptable System Colors](https://developer.apple.com/documentation/appkit/nscolor/standard_colors). Deprecated colors are not included.
> | macOS preferences                                                      | Type    |
> |----------------------------------------------------------|---------|
> | macOS.NSColor.labelColor                                 | Color   |
> | macOS.NSColor.secondaryLabelColor                        | Color   |
> | macOS.NSColor.tertiaryLabelColor                         | Color   |
> | macOS.NSColor.quaternaryLabelColor                       | Color   |
> | macOS.NSColor.textColor                                  | Color   |
> | macOS.NSColor.placeholderTextColor                       | Color   |
> | macOS.NSColor.selectedTextColor                          | Color   |
> | macOS.NSColor.textBackgroundColor                        | Color   |
> | macOS.NSColor.selectedTextBackgroundColor                | Color   |
> | macOS.NSColor.keyboardFocusIndicatorColor                | Color   |
> | macOS.NSColor.unemphasizedSelectedTextColor              | Color   |
> | macOS.NSColor.unemphasizedSelectedTextBackgroundColor    | Color   |
> | macOS.NSColor.linkColor                                  | Color   |
> | macOS.NSColor.separatorColor                             | Color   |
> | macOS.NSColor.selectedContentBackgroundColor             | Color   |
> | macOS.NSColor.unemphasizedSelectedContentBackgroundColor | Color   |
> | macOS.NSColor.selectedMenuItemTextColor                  | Color   |
> | macOS.NSColor.gridColor                                  | Color   |
> | macOS.NSColor.headerTextColor                            | Color   |
> | macOS.NSColor.alternatingContentBackgroundColors         | Color[] |
> | macOS.NSColor.controlAccentColor                         | Color   |
> | macOS.NSColor.controlColor                               | Color   |
> | macOS.NSColor.controlBackgroundColor                     | Color   |
> | macOS.NSColor.controlTextColor                           | Color   |
> | macOS.NSColor.disabledControlTextColor                   | Color   |
> | macOS.NSColor.selectedControlColor                       | Color   |
> | macOS.NSColor.selectedControlTextColor                   | Color   |
> | macOS.NSColor.alternateSelectedControlTextColor          | Color   |
> | macOS.NSColor.currentControlTint                         | String  |
> | macOS.NSColor.windowBackgroundColor                      | Color   |
> | macOS.NSColor.windowFrameTextColor                       | Color   |
> | macOS.NSColor.underPageBackgroundColor                   | Color   |
> | macOS.NSColor.findHighlightColor                         | Color   |
> | macOS.NSColor.highlightColor                             | Color   |
> | macOS.NSColor.shadowColor                                | Color   |
> | macOS.NSColor.systemBlueColor                            | Color   |
> | macOS.NSColor.systemBrownColor                           | Color   |
> | macOS.NSColor.systemGrayColor                            | Color   |
> | macOS.NSColor.systemGreenColor                           | Color   |
> | macOS.NSColor.systemIndigoColor                          | Color   |
> | macOS.NSColor.systemOrangeColor                          | Color   |
> | macOS.NSColor.systemPinkColor                            | Color   |
> | macOS.NSColor.systemPurpleColor                          | Color   |
> | macOS.NSColor.systemRedColor                             | Color   |
> | macOS.NSColor.systemTealColor                            | Color   |
> | macOS.NSColor.systemYellowColor                          | Color   |
> 
> On Linux, GTK's theme name and [public CSS colors](https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-22/gtk/theme/Adwaita/_colors-public.scss) are reported:
> | Linux preferences                                                | Type    |
> |----------------------------------------------------|---------|
> | GTK.theme_name                                | String  |
> | GTK.theme_fg_color                    | Color   |
> | GTK.theme_bg_color                    | Color   |
> | GTK.theme_base_color                  | Color   |
> | GTK.theme_selected_bg_color           | Color   |
> | GTK.theme_selected_fg_color           | Color   |
> | GTK.insensitive_bg_color              | Color   |
> | GTK.insensitive_fg_color              | Color   |
> | GTK.insensitive_base_color            | Color   |
> | GTK.theme_unfocused_fg_color          | Color   |
> | GTK.theme_unfocused_bg_color          | Color   |
> | GTK.theme_unfocused_base_color        | Color   |
> | GTK.theme_unfocused_selected_bg_color | Color   |
> | GTK.theme_unfocused_selected_fg_color | Color   |
> | GTK.borders                           | Color   |
> | GTK.unfocused_borders                 | Color   |
> | GTK.warning_color                     | Color   |
> | GTK.error_color                       | Color   |
> | GTK.success_color                     | Color   |
> 
> ### Built-in themes
> The two built-in themes `CaspianTheme` and `ModenaTheme` are exposed as public API in the `javafx.scene.control.theme` package. Both classes extend `ThemeBase`, which is a simple `StyleTheme` implementation that allows developers to easily extend the built-in themes.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  Rename Application.styleTheme to userAgentStyleTheme

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/757f7ff5..12882080

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=18
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=17-18

  Stats: 240 lines in 7 files changed: 111 ins; 33 del; 96 mod
  Patch: https://git.openjdk.org/jfx/pull/511.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511

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

From mstrauss at openjdk.org  Sat Jan 21 23:54:34 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 21 Jan 2023 23:54:34 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v20]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <3Xllc1HYswoNx8ZJn8XzqNIMYsdfBC165MVR8zu9dfM=.c4491e62-d50e-473c-8dce-2bd5af3e3f1a@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the user-agent stylesheet of the application.
>      * <p>
>      * A user-agent stylesheet is a global stylesheet that can be specified in addition to a
>      * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph.
>      * It can be used to provide default styling for UI controls and other nodes.
>      * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>      * <p>
>      * Before JavaFX 21, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #styleThemeProperty() styleTheme}.
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application.
>      * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the
>      * scene graph.
>      * <p>
>      * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a
>      * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. Preferences
> `javafx.application.Platform.Preferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `ObservableMap` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code Preferences} extends {@link ObservableMap} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface Preferences extends ObservableMap<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> }
> 
> An instance of `Preferences` can be retrieved via `Platform.getPreferences()`.
> 
> Here's a list of the preferences available for Windows, as reported by the [SystemParametersInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow), [GetSysColor](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor) and [Windows.UI.ViewManagement.UISettings.GetColorValue](https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.getcolorvalue) APIs. Deprecated colors are not included.
> | Windows preferences                                  | Type    |
> |--------------------------------------|---------|
> | Windows.SPI.HighContrast             | Boolean |
> | Windows.SPI.HighContrastColorScheme  | String  |
> | Windows.SysColor.COLOR_3DFACE        | Color   |
> | Windows.SysColor.COLOR_BTNTEXT       | Color   |
> | Windows.SysColor.COLOR_GRAYTEXT      | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHT     | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHTTEXT | Color   |
> | Windows.SysColor.COLOR_HOTLIGHT      | Color   |
> | Windows.SysColor.COLOR_WINDOW        | Color   |
> | Windows.SysColor.COLOR_WINDOWTEXT    | Color   |
> | Windows.UIColor.Background           | Color   |
> | Windows.UIColor.Foreground           | Color   |
> | Windows.UIColor.AccentDark3          | Color   |
> | Windows.UIColor.AccentDark2          | Color   |
> | Windows.UIColor.AccentDark1          | Color   |
> | Windows.UIColor.Accent               | Color   |
> | Windows.UIColor.AccentLight1         | Color   |
> | Windows.UIColor.AccentLight2         | Color   |
> | Windows.UIColor.AccentLight3         | Color   |
> 
> Here is a list of macOS preferences as reported by `NSColor`'s [UI Element Colors](https://developer.apple.com/documentation/appkit/nscolor/ui_element_colors) and [Adaptable System Colors](https://developer.apple.com/documentation/appkit/nscolor/standard_colors). Deprecated colors are not included.
> | macOS preferences                                                      | Type    |
> |----------------------------------------------------------|---------|
> | macOS.NSColor.labelColor                                 | Color   |
> | macOS.NSColor.secondaryLabelColor                        | Color   |
> | macOS.NSColor.tertiaryLabelColor                         | Color   |
> | macOS.NSColor.quaternaryLabelColor                       | Color   |
> | macOS.NSColor.textColor                                  | Color   |
> | macOS.NSColor.placeholderTextColor                       | Color   |
> | macOS.NSColor.selectedTextColor                          | Color   |
> | macOS.NSColor.textBackgroundColor                        | Color   |
> | macOS.NSColor.selectedTextBackgroundColor                | Color   |
> | macOS.NSColor.keyboardFocusIndicatorColor                | Color   |
> | macOS.NSColor.unemphasizedSelectedTextColor              | Color   |
> | macOS.NSColor.unemphasizedSelectedTextBackgroundColor    | Color   |
> | macOS.NSColor.linkColor                                  | Color   |
> | macOS.NSColor.separatorColor                             | Color   |
> | macOS.NSColor.selectedContentBackgroundColor             | Color   |
> | macOS.NSColor.unemphasizedSelectedContentBackgroundColor | Color   |
> | macOS.NSColor.selectedMenuItemTextColor                  | Color   |
> | macOS.NSColor.gridColor                                  | Color   |
> | macOS.NSColor.headerTextColor                            | Color   |
> | macOS.NSColor.alternatingContentBackgroundColors         | Color[] |
> | macOS.NSColor.controlAccentColor                         | Color   |
> | macOS.NSColor.controlColor                               | Color   |
> | macOS.NSColor.controlBackgroundColor                     | Color   |
> | macOS.NSColor.controlTextColor                           | Color   |
> | macOS.NSColor.disabledControlTextColor                   | Color   |
> | macOS.NSColor.selectedControlColor                       | Color   |
> | macOS.NSColor.selectedControlTextColor                   | Color   |
> | macOS.NSColor.alternateSelectedControlTextColor          | Color   |
> | macOS.NSColor.currentControlTint                         | String  |
> | macOS.NSColor.windowBackgroundColor                      | Color   |
> | macOS.NSColor.windowFrameTextColor                       | Color   |
> | macOS.NSColor.underPageBackgroundColor                   | Color   |
> | macOS.NSColor.findHighlightColor                         | Color   |
> | macOS.NSColor.highlightColor                             | Color   |
> | macOS.NSColor.shadowColor                                | Color   |
> | macOS.NSColor.systemBlueColor                            | Color   |
> | macOS.NSColor.systemBrownColor                           | Color   |
> | macOS.NSColor.systemGrayColor                            | Color   |
> | macOS.NSColor.systemGreenColor                           | Color   |
> | macOS.NSColor.systemIndigoColor                          | Color   |
> | macOS.NSColor.systemOrangeColor                          | Color   |
> | macOS.NSColor.systemPinkColor                            | Color   |
> | macOS.NSColor.systemPurpleColor                          | Color   |
> | macOS.NSColor.systemRedColor                             | Color   |
> | macOS.NSColor.systemTealColor                            | Color   |
> | macOS.NSColor.systemYellowColor                          | Color   |
> 
> On Linux, GTK's theme name and [public CSS colors](https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-22/gtk/theme/Adwaita/_colors-public.scss) are reported:
> | Linux preferences                                                | Type    |
> |----------------------------------------------------|---------|
> | GTK.theme_name                                | String  |
> | GTK.theme_fg_color                    | Color   |
> | GTK.theme_bg_color                    | Color   |
> | GTK.theme_base_color                  | Color   |
> | GTK.theme_selected_bg_color           | Color   |
> | GTK.theme_selected_fg_color           | Color   |
> | GTK.insensitive_bg_color              | Color   |
> | GTK.insensitive_fg_color              | Color   |
> | GTK.insensitive_base_color            | Color   |
> | GTK.theme_unfocused_fg_color          | Color   |
> | GTK.theme_unfocused_bg_color          | Color   |
> | GTK.theme_unfocused_base_color        | Color   |
> | GTK.theme_unfocused_selected_bg_color | Color   |
> | GTK.theme_unfocused_selected_fg_color | Color   |
> | GTK.borders                           | Color   |
> | GTK.unfocused_borders                 | Color   |
> | GTK.warning_color                     | Color   |
> | GTK.error_color                       | Color   |
> | GTK.success_color                     | Color   |
> 
> ### Built-in themes
> The two built-in themes `CaspianTheme` and `ModenaTheme` are exposed as public API in the `javafx.scene.control.theme` package. Both classes extend `ThemeBase`, which is a simple `StyleTheme` implementation that allows developers to easily extend the built-in themes.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/12882080..27ead34f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=18-19

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

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

From mstrauss at openjdk.org  Sat Jan 21 23:58:24 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 21 Jan 2023 23:58:24 GMT
Subject: RFR: 8267546: Add CSS themes as a first-class concept [v21]
In-Reply-To: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
References: <pZpZifSx9jiOs6qXjGo2fkR5aWZ7oQXruPI1HHGLrew=.94973aaf-648c-4bdf-9fbc-1dcee95df049@github.com>
Message-ID: <f93ahi3SRg_RARYsKBfUix0bHdPvPT7_vTohy51A0JM=.e8533b2f-98db-4913-9e1a-0253a104699b@github.com>

> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes.
> 
> ### New APIs in `javafx.graphics`
> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features.
> #### 1. StyleTheme
> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
> 
> /**
>  * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other
>  * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all
>  * JavaFX nodes in the scene graph.
>  * <p>
>  * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running,
>  * enabling applications to create dynamic themes that respond to changing user preferences.
>  * <p>
>  * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as
>  * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade
>  * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}.
>  */
> public interface StyleTheme {
>     /**
>      * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}.
>      * <p>
>      * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this
>      * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list
>      * change notifications.
>      * 
>      * @implSpec Implementations of this method that return an {@link ObservableList} must emit all
>      *           change notifications on the JavaFX application thread.
>      *
>      * @implNote Implementations of this method that return an {@link ObservableList} are encouraged
>      *           to minimize the number of subsequent list change notifications that are fired by the
>      *           list, as each change notification causes the CSS subsystem to re-apply the referenced
>      *           stylesheets.
>      */
>     List<String> getStylesheets();
> }
> 
> 
> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair):
> 
> public class Application {
>     ...
>     /**
>      * Specifies the single user-agent stylesheet of the application.
>      * <p>
>      * The user-agent stylesheet is a global stylesheet that defines the appearance of the application.
>      * It has the second-lowest precedence in the CSS cascade, and can be overridden in the scene graph
>      * by setting the {@link Scene#userAgentStylesheetProperty() Scene.userAgentStylesheet} or
>      * {@link SubScene#userAgentStylesheetProperty() SubScene.userAgentStylesheet} property.
>      * <p>
>      * Before JavaFX 21, built-in themes were selectable using the special user-agent stylesheet constants
>      * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning
>      * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN}
>      * or {@code STYLESHEET_MODENA} will also set the value of the {@link #userAgentStyleThemeProperty() userAgentStyleTheme}
>      * property to a new instance of the corresponding theme class.
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must
>      *       not be concurrently modified with {@link #userAgentStyleThemeProperty() userAgentStyleTheme}.
>      *
>      * @since 21
>      */
>     public static StringProperty userAgentStylesheetProperty();
>     public static String getUserAgentStylesheet();
>     public static void setUserAgentStylesheet(String url);
> 
>     /**
>      * Specifies the user-agent {@link StyleTheme} of the application.
>      * <p>
>      * {@code StyleTheme} is a collection of user-agent stylesheets that define the appearance of the application.
>      * {@code StyleTheme} has the lowest precedence in the CSS cascade, and can be overridden in the scene graph
>      * by setting any of the following properties:
>      * <ul>
>      *     <li>{@link #userAgentStylesheetProperty() Application.userAgentStylesheet}
>      *     <li>{@link Scene#userAgentStylesheetProperty() Scene.userAgentStylesheet}
>      *     <li>{@link SubScene#userAgentStylesheetProperty() SubScene.userAgentStylesheet}
>      * </ul>
>      * <p>
>      * Note: this property can be modified on any thread, but it is not thread-safe and must not be
>      *       concurrently modified with {@link #userAgentStylesheetProperty() userAgentStylesheet}.
>      *
>      * @since 21
>      */
>     public static ObjectProperty<StyleTheme> styleThemeProperty();
>     public static StyleTheme getStyleTheme();
>     public static void setStyleTheme(StyleTheme theme);
>     ...
> }
> 
> 
> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`.
> 
> #### 2. Preferences
> `javafx.application.Platform.Preferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `ObservableMap` and adds several useful methods, as well as the option to register a listener for change notifications:
> 
> /**
>  * Contains UI preferences of the current platform.
>  * <p>
>  * {@code Preferences} extends {@link ObservableMap} to expose platform preferences as key-value pairs.
>  * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed
>  * alternatives to the untyped {@link #get} method.
>  * <p>
>  * The preferences that are reported by the platform may be dependent on the operating system version.
>  * Applications should always test whether a preference is available, or use the {@link #getString(String, String)},
>  * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback
>  * value if the preference is not available.
>  */
> public interface Preferences extends ObservableMap<String, Object> {
>     String getString(String key);
>     String getString(String key, String fallbackValue);
> 
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
> 
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> }
> 
> An instance of `Preferences` can be retrieved via `Platform.getPreferences()`.
> 
> Here's a list of the preferences available for Windows, as reported by the [SystemParametersInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow), [GetSysColor](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor) and [Windows.UI.ViewManagement.UISettings.GetColorValue](https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.getcolorvalue) APIs. Deprecated colors are not included.
> | Windows preferences                                  | Type    |
> |--------------------------------------|---------|
> | Windows.SPI.HighContrast             | Boolean |
> | Windows.SPI.HighContrastColorScheme  | String  |
> | Windows.SysColor.COLOR_3DFACE        | Color   |
> | Windows.SysColor.COLOR_BTNTEXT       | Color   |
> | Windows.SysColor.COLOR_GRAYTEXT      | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHT     | Color   |
> | Windows.SysColor.COLOR_HIGHLIGHTTEXT | Color   |
> | Windows.SysColor.COLOR_HOTLIGHT      | Color   |
> | Windows.SysColor.COLOR_WINDOW        | Color   |
> | Windows.SysColor.COLOR_WINDOWTEXT    | Color   |
> | Windows.UIColor.Background           | Color   |
> | Windows.UIColor.Foreground           | Color   |
> | Windows.UIColor.AccentDark3          | Color   |
> | Windows.UIColor.AccentDark2          | Color   |
> | Windows.UIColor.AccentDark1          | Color   |
> | Windows.UIColor.Accent               | Color   |
> | Windows.UIColor.AccentLight1         | Color   |
> | Windows.UIColor.AccentLight2         | Color   |
> | Windows.UIColor.AccentLight3         | Color   |
> 
> Here is a list of macOS preferences as reported by `NSColor`'s [UI Element Colors](https://developer.apple.com/documentation/appkit/nscolor/ui_element_colors) and [Adaptable System Colors](https://developer.apple.com/documentation/appkit/nscolor/standard_colors). Deprecated colors are not included.
> | macOS preferences                                                      | Type    |
> |----------------------------------------------------------|---------|
> | macOS.NSColor.labelColor                                 | Color   |
> | macOS.NSColor.secondaryLabelColor                        | Color   |
> | macOS.NSColor.tertiaryLabelColor                         | Color   |
> | macOS.NSColor.quaternaryLabelColor                       | Color   |
> | macOS.NSColor.textColor                                  | Color   |
> | macOS.NSColor.placeholderTextColor                       | Color   |
> | macOS.NSColor.selectedTextColor                          | Color   |
> | macOS.NSColor.textBackgroundColor                        | Color   |
> | macOS.NSColor.selectedTextBackgroundColor                | Color   |
> | macOS.NSColor.keyboardFocusIndicatorColor                | Color   |
> | macOS.NSColor.unemphasizedSelectedTextColor              | Color   |
> | macOS.NSColor.unemphasizedSelectedTextBackgroundColor    | Color   |
> | macOS.NSColor.linkColor                                  | Color   |
> | macOS.NSColor.separatorColor                             | Color   |
> | macOS.NSColor.selectedContentBackgroundColor             | Color   |
> | macOS.NSColor.unemphasizedSelectedContentBackgroundColor | Color   |
> | macOS.NSColor.selectedMenuItemTextColor                  | Color   |
> | macOS.NSColor.gridColor                                  | Color   |
> | macOS.NSColor.headerTextColor                            | Color   |
> | macOS.NSColor.alternatingContentBackgroundColors         | Color[] |
> | macOS.NSColor.controlAccentColor                         | Color   |
> | macOS.NSColor.controlColor                               | Color   |
> | macOS.NSColor.controlBackgroundColor                     | Color   |
> | macOS.NSColor.controlTextColor                           | Color   |
> | macOS.NSColor.disabledControlTextColor                   | Color   |
> | macOS.NSColor.selectedControlColor                       | Color   |
> | macOS.NSColor.selectedControlTextColor                   | Color   |
> | macOS.NSColor.alternateSelectedControlTextColor          | Color   |
> | macOS.NSColor.currentControlTint                         | String  |
> | macOS.NSColor.windowBackgroundColor                      | Color   |
> | macOS.NSColor.windowFrameTextColor                       | Color   |
> | macOS.NSColor.underPageBackgroundColor                   | Color   |
> | macOS.NSColor.findHighlightColor                         | Color   |
> | macOS.NSColor.highlightColor                             | Color   |
> | macOS.NSColor.shadowColor                                | Color   |
> | macOS.NSColor.systemBlueColor                            | Color   |
> | macOS.NSColor.systemBrownColor                           | Color   |
> | macOS.NSColor.systemGrayColor                            | Color   |
> | macOS.NSColor.systemGreenColor                           | Color   |
> | macOS.NSColor.systemIndigoColor                          | Color   |
> | macOS.NSColor.systemOrangeColor                          | Color   |
> | macOS.NSColor.systemPinkColor                            | Color   |
> | macOS.NSColor.systemPurpleColor                          | Color   |
> | macOS.NSColor.systemRedColor                             | Color   |
> | macOS.NSColor.systemTealColor                            | Color   |
> | macOS.NSColor.systemYellowColor                          | Color   |
> 
> On Linux, GTK's theme name and [public CSS colors](https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-22/gtk/theme/Adwaita/_colors-public.scss) are reported:
> | Linux preferences                                                | Type    |
> |----------------------------------------------------|---------|
> | GTK.theme_name                                | String  |
> | GTK.theme_fg_color                    | Color   |
> | GTK.theme_bg_color                    | Color   |
> | GTK.theme_base_color                  | Color   |
> | GTK.theme_selected_bg_color           | Color   |
> | GTK.theme_selected_fg_color           | Color   |
> | GTK.insensitive_bg_color              | Color   |
> | GTK.insensitive_fg_color              | Color   |
> | GTK.insensitive_base_color            | Color   |
> | GTK.theme_unfocused_fg_color          | Color   |
> | GTK.theme_unfocused_bg_color          | Color   |
> | GTK.theme_unfocused_base_color        | Color   |
> | GTK.theme_unfocused_selected_bg_color | Color   |
> | GTK.theme_unfocused_selected_fg_color | Color   |
> | GTK.borders                           | Color   |
> | GTK.unfocused_borders                 | Color   |
> | GTK.warning_color                     | Color   |
> | GTK.error_color                       | Color   |
> | GTK.success_color                     | Color   |
> 
> ### Built-in themes
> The two built-in themes `CaspianTheme` and `ModenaTheme` are exposed as public API in the `javafx.scene.control.theme` package. Both classes extend `ThemeBase`, which is a simple `StyleTheme` implementation that allows developers to easily extend the built-in themes.
> 
> ### Usage
> In its simplest form, a style theme is just a static collection of stylesheets:
> 
> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css");
> 
> A dynamic theme can be created by returning an instance of `ObservableList`:
> 
> public class MyCustomTheme implements StyleTheme {
>     private final ObservableList<String> stylesheets =
>         FXCollections.observableArrayList("colors-light.css", "controls.css");
> 
>     @Override
>     public List<String> getStylesheets() {
>         return stylesheets;
>     }
> 
>     public void setDarkMode(boolean enabled) {
>         stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css");
>     }
> }
> 
> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets:
> 
> Application.setStyleTheme(new ModenaTheme() {
>     {
>         addFirst("stylesheet1.css");
>         addLast("stylesheet2.css");
>     }
> });

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/511/files
  - new: https://git.openjdk.org/jfx/pull/511/files/27ead34f..2757610c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=20
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=19-20

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

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

From thiago.sayao at gmail.com  Sun Jan 22 00:08:02 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 21 Jan 2023 21:08:02 -0300
Subject: TableViewBuilder idea
Message-ID: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>

Hi,

TableView data usually comes from a database and is mapped to java objects
(I don't have actual statistics on this but it's probably a true assertion).
It Would be very useful if we could just copy database mapped objects to
javafx observables and say: Display it on a tableview.
Configuration of each column would be done as an annotation, like this:

public class EmployeeObservable {
    @Column(label = "Registration", style = "-fx-alignment: right")
    private IntegerProperty registration = new SimpleIntegerProperty();

    @Column(label = "Name")
    private StringProperty name = new SimpleStringProperty();

    @Column(label = "Salary", converter = BigDecimalCurrencyConverter.class)
    private ObjectProperty<BigDecimal> salary = new SimpleObjectProperty<>();

    //boilerplate here
}


Other annotation options:

@Column(ignore = true)

@Column(graphicsConverter = CheckBoxGraphicsConverter.class)

And to apply it:

TableViewBuilder<EmployeeObservable> builder = new
TableViewBuilder<>(tableView, EmployeeObservable.class);
builder.build();


I actually have implemented this and it's very useful. I can't share it
because I've done it for a private company, but it's easy to re-do it.

I'm not sure if it would go in a general purpose toolkit, but I thought it
would be nice to share (the idea).

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230121/4261ae2a/attachment-0001.htm>

From michaelstrau2 at gmail.com  Sun Jan 22 00:51:13 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sun, 22 Jan 2023 01:51:13 +0100
Subject: Style themes API
In-Reply-To: <CAAEud6b-Pa9pnFqFHG=12dy70XtKcUOGodCoJHNJ8uwk6QkeQw@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
 <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
 <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>
 <CAJEpuXR6XMLByDPGTnZfa+7vuFaeVaZsL8BsOFj6vGYNr2_ong@mail.gmail.com>
 <CAAEud6b-Pa9pnFqFHG=12dy70XtKcUOGodCoJHNJ8uwk6QkeQw@mail.gmail.com>
Message-ID: <CAJEpuXQ+wbJZtEaV4pcY65=XEXo7mTTWcs3VCYjGp2oe-=uJ_w@mail.gmail.com>

Hi Pedro,

see my comments below.


On Sat, Jan 21, 2023 at 5:19 PM Pedro Duque Vieira
<pedro.duquevieira at gmail.com> wrote:
> I've been building javafx themes for years now. Started creating JMetro in JavaFX version 2. During this time I've been following how other themes are being built and I can say that about 90% of the themes (rough estimate) that are out there, are composed of author stylesheets, i.e they override values set from code (including JMetro).
> I agree that themes that are to be provided to other developers would probably be better off if they are user agent stylesheets. My point is that migrating those 90% of themes to use this API would be easier if this flag exists otherwise migration would likely introduce UI regressions for developers using those themes.
>
> To be clear, what I'm proposing is a flag, or enum, or whatever, in StyleTheme that defines whether the stylesheets in the StyleTheme should be a user agent stylesheet or author stylesheet.
>
> Another point is in making themes that are only to be used locally in a specific app that the developer is creating. It might be of interest that he can toggle this flag and make all settings defined in the theme override any styling set from code (or in FXML) so that he can have a centralized point where all styling is done.

I think that the likelihood of this feature making it into the 21
release dramatically increases if we keep changes to the CSS subsystem
to an absolute minimum. I understand your point, but I want to deliver
this feature in the smallest useful package and add more features
later with follow-on PRs.

That's why I've renamed `Application.styleTheme` to
`Application.userAgentStyleTheme`. This makes it unmistakably clear
that we're only talking about user-agent stylesheets.
Also, it leaves open the possibility to add the
`Application.styleTheme` property later, which would cause the theme
to be interpreted as comprised of author stylesheets.
Classifying author/UA themes at the property level is also more
consistent with the way author/UA stylesheets are currently classified
in JavaFX.
What do you think about the styleTheme/userAgentStyleTheme API,
instead of having a flag in the implementation of StyleTheme itself?

Since one of the objectives of the PR is to promote Caspian and Modena
to first-class theme implementations, it makes sense to focus on UA
themes first (since built-in themes are comprised of UA stylesheets).



> 3 -
> Style themes are generally either defined as dark or light. i.e. you'll very rarely have a theme that has some Windows with dark decorations and others with light decorations. So I think it makes sense to have this as a theme property.
> The ability to toggle decorations (light or dark) on an individual Window is a good point you're making. Perhaps we should have a global definition in the StyleTheme (whether the theme is light or dark) and a definition that can be set per Window.
> If you set it on the StyleTheme then all Windows will respect it, but you can override that value on each Window. If you override it on a specific Window, that definition would take precedence over the global StyleTheme one.

In general, StyleTheme is a very simple concept: it's a dynamic
collection of stylesheets.
I don't think the interface should force implementers to deal with
anything other than stylesheets. If we did that, the following code
wouldn't work any more:

    Application.setUserAgentStyleTheme(
        () -> List.of("stylesheet1.css", "stylesheet2.css");

Maybe we can add a new interface, for example DarkModeAware, and if an
application theme is marked with this interface, JavaFX will try to
respect dark/light mode for platform decorations:

    public class MyCustomTheme implements StyleTheme, DarkModeAware {
        @Override
        public List<String> getStylesheets() {
            return List.of("stylesheet1.css", "stylesheet2.css");
        }
    }

    // Setting a DarkModeAware theme causes JavaFX to draw light or
    // dark platform decorations by default, depending on the current
    // platform preference. If the theme is not DarkModeAware, JavaFX
    // defaults to light decorations.
    //
    Application.setUserAgentStyleTheme(new MyCustomTheme());

In any case, I think we can deliver this feature in a follow-on PR.


> 4-
>>
>> If we wanted to expose this front-and-center, we could add these
>>
>> properties to the Platform.Properties interface:
>
>
>>     public interface Preferences extends ObservableMap<String, Object> {
>>         ReadOnlyBooleanProperty darkModeProperty();
>>         ReadOnlyObjectProperty<Color> accentColorProperty();
>>         ...
>>     }
>
>
> Yes, I think that would be great.

Let's see what other people think.

From mstrauss at openjdk.org  Sun Jan 22 01:31:15 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 22 Jan 2023 01:31:15 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v8]
In-Reply-To: <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
Message-ID: <mLpaZqFxnDSyKsM7Kkic09j5ewX0eIdjuWg8n6hKnkQ=.922a831f-c9cc-42b7-82be-13f6964c4e17@github.com>

On Thu, 12 Jan 2023 08:53:14 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> 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:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>    
>    # Conflicts:
>    #	modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java
>    #	modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java
>    #	modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>  - JDK-8277848
>    Added tests to ensure no premature garbage collection is happening.
>  - JDK-8277848
>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>  - JDK-8277848
>    Added the 3 requests whitespaces
>  - JDK-8277848
>    Further optimization based code review.
>    This Bugfix should now event improve the performance
>  - JDK-8277848
>    Added missing change
>  - JDK-8277848
>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

modules/javafx.base/src/test/java/test/javafx/beans/property/ListPropertyBaseTest.java line 824:

> 822:         JMemoryBuddy.memoryTest(checker -> {
> 823:             // given
> 824:             System.out.println("Start collection: " + FXCollections.observableArrayList());

By the way, can these `println` statements in various tests be removed?

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

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

From duke at openjdk.org  Sun Jan 22 15:19:20 2023
From: duke at openjdk.org (JoachimSchriek)
Date: Sun, 22 Jan 2023 15:19:20 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport [v2]
In-Reply-To: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
References: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
Message-ID: <hvTabNOz-_3BMr8C0qZoVKOU2Uc6LxDjP36JD0Qqczk=.491c4401-792c-4054-9c90-cccb75f3dfb7@github.com>

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

  Committed Test Case for [openjdk/jfx] 8173321: Click on trough has no
  effect when cell height > viewport (PR #985):

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/985/files
  - new: https://git.openjdk.org/jfx/pull/985/files/ec9828ab..3360e186

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

  Stats: 202 lines in 1 file changed: 202 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  Sun Jan 22 15:22:12 2023
From: duke at openjdk.org (JoachimSchriek)
Date: Sun, 22 Jan 2023 15:22:12 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport [v2]
In-Reply-To: <hvTabNOz-_3BMr8C0qZoVKOU2Uc6LxDjP36JD0Qqczk=.491c4401-792c-4054-9c90-cccb75f3dfb7@github.com>
References: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
 <hvTabNOz-_3BMr8C0qZoVKOU2Uc6LxDjP36JD0Qqczk=.491c4401-792c-4054-9c90-cccb75f3dfb7@github.com>
Message-ID: <G1L9tpZC_X5eSNTmW24h2dwNLDQSPr4afPTlJvBsT5k=.251ae1ec-f3d9-4be8-ac76-90b49a36d796@github.com>

On Sun, 22 Jan 2023 15:19:20 GMT, JoachimSchriek <duke at openjdk.org> 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:
> 
>   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.

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

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

From duke at openjdk.org  Sun Jan 22 15:34:25 2023
From: duke at openjdk.org (JoachimSchriek)
Date: Sun, 22 Jan 2023 15:34:25 GMT
Subject: RFR: 8173321: Click on trough has no effect when cell height >
 viewport [v3]
In-Reply-To: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
References: <LHBiNph8b1SLGZnGSZlDCTO2LIKhJXKqlbce1qYDtK8=.e50096cc-8597-4038-b393-a00570866ed6@github.com>
Message-ID: <XfHC9jpK2fpSOSxop9Vc6MgP2rW9gTz_Cn4MHgLI4Cw=.e366cef5-2242-4a94-bf11-d4afa8708985@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/985/files
  - new: https://git.openjdk.org/jfx/pull/985/files/3360e186..7ad99bde

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 gmail.com  Sun Jan 22 15:45:59 2023
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 22 Jan 2023 17:45:59 +0200
Subject: TableViewBuilder idea
In-Reply-To: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
References: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
Message-ID: <CA+0ynh9x2hV9gXBkw2PoxDWCgwiE5HuxsaN78T4hxfDBr9LhtA@mail.gmail.com>

Isn't this something that an external library can do? I would think that
writing an adapter that can read JPA annotations is the way to go. After
all, most entities are not written with JavaFX properties.

On Sun, Jan 22, 2023 at 2:08 AM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> Hi,
>
> TableView data usually comes from a database and is mapped to java objects
> (I don't have actual statistics on this but it's probably a true assertion).
> It Would be very useful if we could just copy database mapped objects to
> javafx observables and say: Display it on a tableview.
> Configuration of each column would be done as an annotation, like this:
>
> public class EmployeeObservable {
>     @Column(label = "Registration", style = "-fx-alignment: right")
>     private IntegerProperty registration = new SimpleIntegerProperty();
>
>     @Column(label = "Name")
>     private StringProperty name = new SimpleStringProperty();
>
>     @Column(label = "Salary", converter = BigDecimalCurrencyConverter.class)
>     private ObjectProperty<BigDecimal> salary = new SimpleObjectProperty<>();
>
>     //boilerplate here
> }
>
>
> Other annotation options:
>
> @Column(ignore = true)
>
> @Column(graphicsConverter = CheckBoxGraphicsConverter.class)
>
> And to apply it:
>
> TableViewBuilder<EmployeeObservable> builder = new TableViewBuilder<>(tableView, EmployeeObservable.class);
> builder.build();
>
>
> I actually have implemented this and it's very useful. I can't share it
> because I've done it for a private company, but it's easy to re-do it.
>
> I'm not sure if it would go in a general purpose toolkit, but I thought it
> would be nice to share (the idea).
>
> -- Thiago.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230122/9023ee97/attachment.htm>

From thiago.sayao at gmail.com  Sun Jan 22 15:54:03 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 22 Jan 2023 12:54:03 -0300
Subject: TableViewBuilder idea
In-Reply-To: <CA+0ynh9x2hV9gXBkw2PoxDWCgwiE5HuxsaN78T4hxfDBr9LhtA@mail.gmail.com>
References: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
 <CA+0ynh9x2hV9gXBkw2PoxDWCgwiE5HuxsaN78T4hxfDBr9LhtA@mail.gmail.com>
Message-ID: <CAAP_wunAV_zq513VuEqC2bU2pRYbQ-aCLMkbAbMD8hP02frL3w@mail.gmail.com>

Probably goes on a library. But it would also be nice to have to boost
productivity on enterprise applications, boosting JavaFX adoption.

The idea is not to map directly to JavaFX observables because it would
imply importing it on the "backend logic". But just copy from a DTO to an
observable class and the UI would auto-update.

It can come from a database or a web-service.


-- Thiago



Em dom., 22 de jan. de 2023 12:46, Nir Lisker <nlisker at gmail.com> escreveu:

> Isn't this something that an external library can do? I would think that
> writing an adapter that can read JPA annotations is the way to go. After
> all, most entities are not written with JavaFX properties.
>
> On Sun, Jan 22, 2023 at 2:08 AM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>> Hi,
>>
>> TableView data usually comes from a database and is mapped to java
>> objects (I don't have actual statistics on this but it's probably a true
>> assertion).
>> It Would be very useful if we could just copy database mapped objects to
>> javafx observables and say: Display it on a tableview.
>> Configuration of each column would be done as an annotation, like this:
>>
>> public class EmployeeObservable {
>>     @Column(label = "Registration", style = "-fx-alignment: right")
>>     private IntegerProperty registration = new SimpleIntegerProperty();
>>
>>     @Column(label = "Name")
>>     private StringProperty name = new SimpleStringProperty();
>>
>>     @Column(label = "Salary", converter = BigDecimalCurrencyConverter.class)
>>     private ObjectProperty<BigDecimal> salary = new SimpleObjectProperty<>();
>>
>>     //boilerplate here
>> }
>>
>>
>> Other annotation options:
>>
>> @Column(ignore = true)
>>
>> @Column(graphicsConverter = CheckBoxGraphicsConverter.class)
>>
>> And to apply it:
>>
>> TableViewBuilder<EmployeeObservable> builder = new TableViewBuilder<>(tableView, EmployeeObservable.class);
>> builder.build();
>>
>>
>> I actually have implemented this and it's very useful. I can't share it
>> because I've done it for a private company, but it's easy to re-do it.
>>
>> I'm not sure if it would go in a general purpose toolkit, but I thought
>> it would be nice to share (the idea).
>>
>> -- Thiago.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230122/34492092/attachment-0001.htm>

From michaelstrau2 at gmail.com  Sun Jan 22 16:24:24 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sun, 22 Jan 2023 17:24:24 +0100
Subject: TableViewBuilder idea
In-Reply-To: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
References: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
Message-ID: <CAJEpuXTGBhuHLp+fbE=BtyX4kXOnVAxBzvEnm6tccV1vbY6zpw@mail.gmail.com>

This looks interesting, but I'd rather have this as a library.
One question: how does this approach work with language localization,
given that "label" is a constant?

On Sun, Jan 22, 2023 at 1:08 AM Thiago Milczarek Say?o
<thiago.sayao at gmail.com> wrote:
>
> Hi,
>
> TableView data usually comes from a database and is mapped to java objects (I don't have actual statistics on this but it's probably a true assertion).
> It Would be very useful if we could just copy database mapped objects to javafx observables and say: Display it on a tableview.
> Configuration of each column would be done as an annotation, like this:
>
> public class EmployeeObservable {
>     @Column(label = "Registration", style = "-fx-alignment: right")
>     private IntegerProperty registration = new SimpleIntegerProperty();
>
>     @Column(label = "Name")
>     private StringProperty name = new SimpleStringProperty();
>
>     @Column(label = "Salary", converter = BigDecimalCurrencyConverter.class)
>     private ObjectProperty<BigDecimal> salary = new SimpleObjectProperty<>();
>
>     //boilerplate here
> }
>
>
> Other annotation options:
>
> @Column(ignore = true)
>
> @Column(graphicsConverter = CheckBoxGraphicsConverter.class)
>
> And to apply it:
>
> TableViewBuilder<EmployeeObservable> builder = new TableViewBuilder<>(tableView, EmployeeObservable.class);
> builder.build();
>
>
> I actually have implemented this and it's very useful. I can't share it because I've done it for a private company, but it's easy to re-do it.
>
> I'm not sure if it would go in a general purpose toolkit, but I thought it would be nice to share (the idea).
>
> -- Thiago.
>

From thiago.sayao at gmail.com  Sun Jan 22 16:35:52 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 22 Jan 2023 13:35:52 -0300
Subject: TableViewBuilder idea
In-Reply-To: <CAJEpuXTGBhuHLp+fbE=BtyX4kXOnVAxBzvEnm6tccV1vbY6zpw@mail.gmail.com>
References: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
 <CAJEpuXTGBhuHLp+fbE=BtyX4kXOnVAxBzvEnm6tccV1vbY6zpw@mail.gmail.com>
Message-ID: <CAAP_wu=x2cxsLTs=NoVXQ-cvGXeVAJCvX=dMLXQf6g-sku2Edg@mail.gmail.com>

label = "%key"

tableViewBuilder.enableI18n(true).build();

It's just an idea. It also can be done setting a i18n transformer class on
the builder.


Em dom., 22 de jan. de 2023 13:24, Michael Strau? <michaelstrau2 at gmail.com>
escreveu:

> This looks interesting, but I'd rather have this as a library.
> One question: how does this approach work with language localization,
> given that "label" is a constant?
>
> On Sun, Jan 22, 2023 at 1:08 AM Thiago Milczarek Say?o
> <thiago.sayao at gmail.com> wrote:
> >
> > Hi,
> >
> > TableView data usually comes from a database and is mapped to java
> objects (I don't have actual statistics on this but it's probably a true
> assertion).
> > It Would be very useful if we could just copy database mapped objects to
> javafx observables and say: Display it on a tableview.
> > Configuration of each column would be done as an annotation, like this:
> >
> > public class EmployeeObservable {
> >     @Column(label = "Registration", style = "-fx-alignment: right")
> >     private IntegerProperty registration = new SimpleIntegerProperty();
> >
> >     @Column(label = "Name")
> >     private StringProperty name = new SimpleStringProperty();
> >
> >     @Column(label = "Salary", converter =
> BigDecimalCurrencyConverter.class)
> >     private ObjectProperty<BigDecimal> salary = new
> SimpleObjectProperty<>();
> >
> >     //boilerplate here
> > }
> >
> >
> > Other annotation options:
> >
> > @Column(ignore = true)
> >
> > @Column(graphicsConverter = CheckBoxGraphicsConverter.class)
> >
> > And to apply it:
> >
> > TableViewBuilder<EmployeeObservable> builder = new
> TableViewBuilder<>(tableView, EmployeeObservable.class);
> > builder.build();
> >
> >
> > I actually have implemented this and it's very useful. I can't share it
> because I've done it for a private company, but it's easy to re-do it.
> >
> > I'm not sure if it would go in a general purpose toolkit, but I thought
> it would be nice to share (the idea).
> >
> > -- Thiago.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230122/94fcbb25/attachment.htm>

From tsayao at openjdk.org  Sun Jan 22 23:31:15 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 22 Jan 2023 23:31:15 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v45]
In-Reply-To: <920LNgBg5QjPm6w9WO3nC_-Ow8CZtUPci8VgTRDm9Tg=.f5a05f4c-83b5-4800-bf91-28b5056aa76e@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <920LNgBg5QjPm6w9WO3nC_-Ow8CZtUPci8VgTRDm9Tg=.f5a05f4c-83b5-4800-bf91-28b5056aa76e@github.com>
Message-ID: <RQx9sFZNIvd_4uSDaz9W39tF581LftEfKyteHboP2jc=.4b57fbfd-75bd-4731-904d-5a40fd891875@github.com>

On Sat, 21 Jan 2023 15:16:03 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 54 commits:
> 
>  - Merge branch 'master' into clean_glass_gtk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Revert "Remove duplicated set_events"
>    
>    This reverts commit 077b8df9238679e05b491f015b89670c9ca332a4.
>  - Added (temporary) print statements to check size reporting
>  - Remove duplicated set_events
>  - Merge branch 'master' into clean_glass_gtk
>  - Merge branch 'openjdk:master' into master
>  - Clarify TITLED / non TITLED
>  - ... and 44 more: https://git.openjdk.org/jfx/compare/294e82e6...b8e6b2b8

Found two regressions:
https://bugs.openjdk.org/browse/JDK-8130182
https://bugs.openjdk.org/browse/JDK-8089923

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

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

From tsayao at openjdk.org  Mon Jan 23 03:51:33 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 23 Jan 2023 03:51:33 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v46]
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: <iHkEYaWbWbLGCu1CbCKcmbxVbDothovBu10AI3WPn-o=.d9f9538d-130f-4839-ad79-b4205e8a1c48@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/915/files
  - new: https://git.openjdk.org/jfx/pull/915/files/b8e6b2b8..ccd84d72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=45
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=44-45

  Stats: 99 lines in 2 files changed: 16 ins; 59 del; 24 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 kpk at openjdk.org  Mon Jan 23 08:24:23 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 23 Jan 2023 08:24:23 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator [v2]
In-Reply-To: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
Message-ID: <Chz7EgtR-KU5uYAtVNTNXE6aFq-DdQpsXB4zO9i0-mU=.50478b54-98c5-477f-bf00-3d94f806dcd0@github.com>

> No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.
> 
> Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.
> 
> Added test to validate the change.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1002/files
  - new: https://git.openjdk.org/jfx/pull/1002/files/b124c24e..42e8c397

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

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

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

From kpk at openjdk.org  Mon Jan 23 08:24:23 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 23 Jan 2023 08:24:23 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator [v2]
In-Reply-To: <goM7uUCcKWLQ7tzg2ubbBoKIVI7_OaZrWqFLlZKkpqY=.8debe29e-f209-41aa-b4ff-76f076e85511@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
 <GzI3sSkm1rPQWe_u9Q3kdVN35X6KOMntuK0KJzYttXo=.0b8e55c8-54c2-4094-bd7e-b25279b308e0@github.com>
 <goM7uUCcKWLQ7tzg2ubbBoKIVI7_OaZrWqFLlZKkpqY=.8debe29e-f209-41aa-b4ff-76f076e85511@github.com>
Message-ID: <1owH1WMpnIDtS2bMmroxJwgt5uFpUswKRSbXITAmnEs=.2da13bfc-f113-4550-8b66-22a4df9832a6@github.com>

On Sat, 21 Jan 2023 22:58:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 178:
>> 
>>> 176:                         if (!menuitem.isDisable()) {
>>> 177:                             if (menuitem instanceof RadioMenuItem) {
>>> 178:                                 if(((RadioMenuItem)menuitem).getToggleGroup() == null){
>> 
>> minor: this group insists on adding spaces after "if" and before "{"
>
> You can use a pattern variable here to get rid of all the casts.

Updated the code to address above comments

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

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

From kpk at openjdk.org  Mon Jan 23 08:30:16 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 23 Jan 2023 08:30:16 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator [v2]
In-Reply-To: <GzI3sSkm1rPQWe_u9Q3kdVN35X6KOMntuK0KJzYttXo=.0b8e55c8-54c2-4094-bd7e-b25279b308e0@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
 <GzI3sSkm1rPQWe_u9Q3kdVN35X6KOMntuK0KJzYttXo=.0b8e55c8-54c2-4094-bd7e-b25279b308e0@github.com>
Message-ID: <6IZIDtoinfuuguQ63MIpGo6U_2oyr3pcpfVtvVBeSGg=.50b3ac94-763a-4b55-bbba-0984d5ec6cbb@github.com>

On Fri, 20 Jan 2023 19:13:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Tested with the MonkeyTester app.
> 
> I'd like to have a discussion on a new ToggleGroup's property (i'll send an email to the mailing list).

I saw the mail chain sent out for this discussion. I agree that  if any changes required as a result of this discussion can be taken as separate enhancement as you mentioned in the previous comment.

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

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

From mike at hydraulic.software  Mon Jan 23 14:34:21 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Mon, 23 Jan 2023 15:34:21 +0100
Subject: TableViewBuilder idea
In-Reply-To: <CAAP_wu=x2cxsLTs=NoVXQ-cvGXeVAJCvX=dMLXQf6g-sku2Edg@mail.gmail.com>
References: <CAAP_wu=jeq5ssy3gM5u2hJ_TF0Ti2VLJBW2pN-jtt5-=cbjvmQ@mail.gmail.com>
 <CAJEpuXTGBhuHLp+fbE=BtyX4kXOnVAxBzvEnm6tccV1vbY6zpw@mail.gmail.com>
 <CAAP_wu=x2cxsLTs=NoVXQ-cvGXeVAJCvX=dMLXQf6g-sku2Edg@mail.gmail.com>
Message-ID: <CAGv+2bPWFWPQvdjvoyyvVvA8UGeAR1uXQLWF5hp2o9yFdzsFeg@mail.gmail.com>

One thing worth considering is that the approach of putting everything in a
third party library makes it much harder to find things. JavaFX has a lot
of capabilities that you can't find out about unless you spend time
maintaining an encyclopedic knowledge of hundreds of GitHub repositories.
This isn't unique to JavaFX obviously, lots of frameworks and ecosystems
have the same issue. But there is tremendous value in standard libraries,
in having things be in one place where browsing the docs or using
autocomplete is sufficient to discover them.

Consider if there was no javafx.controls module! Instead for every widget
you had to find them on GitHub and they all came from different authors,
had different levels of documentation, might conflict with each other and
so on. Some toolkits do work that way (e.g. reactjs, compose) but I didn't
enjoy it much.


On Sun, 22 Jan 2023 at 17:38, Thiago Milczarek Say?o <thiago.sayao at gmail.com>
wrote:

> label = "%key"
>
> tableViewBuilder.enableI18n(true).build();
>
> It's just an idea. It also can be done setting a i18n transformer class on
> the builder.
>
>
> Em dom., 22 de jan. de 2023 13:24, Michael Strau? <michaelstrau2 at gmail.com>
> escreveu:
>
>> This looks interesting, but I'd rather have this as a library.
>> One question: how does this approach work with language localization,
>> given that "label" is a constant?
>>
>> On Sun, Jan 22, 2023 at 1:08 AM Thiago Milczarek Say?o
>> <thiago.sayao at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > TableView data usually comes from a database and is mapped to java
>> objects (I don't have actual statistics on this but it's probably a true
>> assertion).
>> > It Would be very useful if we could just copy database mapped objects
>> to javafx observables and say: Display it on a tableview.
>> > Configuration of each column would be done as an annotation, like this:
>> >
>> > public class EmployeeObservable {
>> >     @Column(label = "Registration", style = "-fx-alignment: right")
>> >     private IntegerProperty registration = new SimpleIntegerProperty();
>> >
>> >     @Column(label = "Name")
>> >     private StringProperty name = new SimpleStringProperty();
>> >
>> >     @Column(label = "Salary", converter =
>> BigDecimalCurrencyConverter.class)
>> >     private ObjectProperty<BigDecimal> salary = new
>> SimpleObjectProperty<>();
>> >
>> >     //boilerplate here
>> > }
>> >
>> >
>> > Other annotation options:
>> >
>> > @Column(ignore = true)
>> >
>> > @Column(graphicsConverter = CheckBoxGraphicsConverter.class)
>> >
>> > And to apply it:
>> >
>> > TableViewBuilder<EmployeeObservable> builder = new
>> TableViewBuilder<>(tableView, EmployeeObservable.class);
>> > builder.build();
>> >
>> >
>> > I actually have implemented this and it's very useful. I can't share it
>> because I've done it for a private company, but it's easy to re-do it.
>> >
>> > I'm not sure if it would go in a general purpose toolkit, but I thought
>> it would be nice to share (the idea).
>> >
>> > -- Thiago.
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230123/2246feb4/attachment-0001.htm>

From angorya at openjdk.org  Mon Jan 23 16:00:59 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 23 Jan 2023 16:00:59 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator [v2]
In-Reply-To: <Chz7EgtR-KU5uYAtVNTNXE6aFq-DdQpsXB4zO9i0-mU=.50478b54-98c5-477f-bf00-3d94f806dcd0@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
 <Chz7EgtR-KU5uYAtVNTNXE6aFq-DdQpsXB4zO9i0-mU=.50478b54-98c5-477f-bf00-3d94f806dcd0@github.com>
Message-ID: <LiA3nsTAiNxbjxVLd2mJXDQTF4VfiOd40NaWHNOJwyk=.7479b7f1-1183-4457-ba75-f91cc82e4453@github.com>

On Mon, 23 Jan 2023 08:24:23 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.
>> 
>> Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.
>> 
>> Added test to validate the change.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

lgtm

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

Marked as reviewed by angorya (Committer).

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

From tsayao at openjdk.org  Mon Jan 23 16:27:59 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 23 Jan 2023 16:27:59 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v46]
In-Reply-To: <iHkEYaWbWbLGCu1CbCKcmbxVbDothovBu10AI3WPn-o=.d9f9538d-130f-4839-ad79-b4205e8a1c48@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <iHkEYaWbWbLGCu1CbCKcmbxVbDothovBu10AI3WPn-o=.d9f9538d-130f-4839-ad79-b4205e8a1c48@github.com>
Message-ID: <9yldzgVG1CEWj1gAePEAjjdbMHQbHEkxQhdMk3klrxI=.27974819-42d3-4948-9aec-06b7d12cfa96@github.com>

On Mon, 23 Jan 2023 03:51:33 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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 change the positioning code to just apply gravity when decorations are received. I based the login on `setBounds` gravity docs:


     * Gravity values specify how to correct window location if only its size
     * changes (for example when stage decorations are added). User initiated
     * resizing should be ignored and must not influence window location through
     * this mechanism.
     *
     * The corresponding correction formulas are:
     *
     * {@code x -= xGravity * deltaW}
     * {@code y -= yGravity * deltaH}

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

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

From tsayao at openjdk.org  Mon Jan 23 16:55:05 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 23 Jan 2023 16:55:05 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v2]
In-Reply-To: <xSbYcg4oe97Rx0rsFNP0bLlWrIV71b52cI0aZSWP0oY=.5b545e42-2a7d-41ef-9f06-798a90088eef@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <xSbYcg4oe97Rx0rsFNP0bLlWrIV71b52cI0aZSWP0oY=.5b545e42-2a7d-41ef-9f06-798a90088eef@github.com>
Message-ID: <8HrXaHvbcGNbpeqTdh6IBQ3IGAg06s7eHHbKb2RQBl4=.5be7f7aa-8806-4cf1-89e5-2a9ba83db481@github.com>

On Wed, 18 Jan 2023 00:04:22 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pre-review adjustments

This is with SWT 3.8.2 (uses gtk2):

![image](https://user-images.githubusercontent.com/30704286/214099291-01afcbe0-5bf3-4ca6-b428-c8d8d5f76a2e.png)

With SWT 4.26:

![image](https://user-images.githubusercontent.com/30704286/214100052-f5891a3c-86b7-4cbd-8490-2166100cc0ec.png)

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

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

From andy.goryachev at oracle.com  Mon Jan 23 18:04:29 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 23 Jan 2023 18:04:29 +0000
Subject: [External] : Re: RFC: new property in ToggleGroup
In-Reply-To: <CA+0ynh9q3w_30GXhyChs14z5mXeHx0tG-e5T=DPTfJWV93ss-g@mail.gmail.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>
 <DM5PR1001MB2172BD47F71192422D4BC3EAE5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <44f16a41-479c-8b51-b221-95006e51c2e6@oracle.com>
 <CA+0ynh9q3w_30GXhyChs14z5mXeHx0tG-e5T=DPTfJWV93ss-g@mail.gmail.com>
Message-ID: <DM5PR1001MB21725A3169C9AF92B5111B08E5C89@DM5PR1001MB2172.namprd10.prod.outlook.com>

It is indeed the same in Swing: the initial state for a ButtonGroup is all deselected.  Kevin brought up a good example with HTML radio buttons - in effect saying that this initial state indicates that the user needs to make a choice, which is the most frequent case in an HTML page.

However, it may or may not be the case in FX.  Consider, for example, a case where a file viewer presents a number of modes - (text | hex | image) to present a file.  These modes are mutually exclusive (thus requiring RadioMenuItems or ToggleButtons), but one *must* be selected initially, since it does not make sense to ask the user to make a choice, instead a default choice must be made by the application.

Yes, it can be simply solved by making a default one selected in the code, and that is what is usually done.  I just thought that having a property would eliminate extra code.  One can also extend ToggleGroup to provide that functionality, and that is what I have done in the past.

Thank you all for the discussion and insightful comments.  Given the negative feedback and availability of easy workaround I withdraw this RFC.

Cheers,
-andy



From: Nir Lisker <nlisker at gmail.com>
Date: Saturday, 2023/01/21 at 08:22
To: Kevin Rushforth <kevin.rushforth at oracle.com>
Cc: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: RFC: new property in ToggleGroup
I don't see it being especially useful. GUI's tend to work this way. I remember it was the same in Swing.

On Sat, Jan 21, 2023 at 1:41 AM Kevin Rushforth <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>> wrote:

On 1/20/2023 2:57 PM, Andy Goryachev wrote:
I just want to add one thing - the initial state of RadioMenuItems added to a menu is unselected, even if they belong to a ToggleGroup.

One can say that having all unselected radio buttons in a toggle group makes no sense, or perhaps it depends on the application requirements - though I cannot find an example where it might be needed.

Yes, it's initially unselected unless the app makes an explicit selection. HTML radio buttons work the same way [1]. Some apps use that to indicate that nothing was selected, but then once you select it there will always be something selected.




So either we allow two different policies by adding a property to the ToggleGroup, or we proclaim that adding a radio button to a toggle group must have a side effect of one (first) button to be automatically selected, otherwise the whole group is in inconsistent state (or the app developer must write some code to select one).

I wouldn't want to change the default behavior, since I can imagine some apps relying on being able to tell if the user has ever selected any of the choices.

Having two properties would be one solution, presuming we think that we need to provide a way for the app to indicate that it wants us to enforce the invariant of ensuring that the app can't ever get the control in a state where nothing is selected. Although, since it would be an opt-in, the app could just as easily set the default itself as opposed to setting this new  property.

-- Kevin

[1] https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio<https://urldefense.com/v3/__https:/www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzk6Vz7Whx$>



-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>
Date: Friday, 2023/01/20 at 12:27
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFC: new property in ToggleGroup
How common a UI feature is being able to deselect the selected item in a ToggleGroup via the UI such that no item is selected? I don't normally see that in various apps or toolkits that I am familiar with. What I do see is that either a default item is selected or no item is selected initially (which is the one and only time that there will be no item selected), but in both case, once you make a selection, there is no way via the UI to deselect the current item. Absent a compelling need, I think the current behavior (once the fix for JDK-8237505 is integrated) is sufficient.

What do other developers think?

-- Kevin
On 1/20/2023 11:31 AM, Andy Goryachev wrote:
Dear colleagues:

In the context of a recent PR

https://bugs.openjdk.org/browse/JDK-8237505
https://github.com/openjdk/jfx/pull/1002<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1002__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzkyU-UIVq$>
https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem<https://urldefense.com/v3/__https:/stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzk5wy-flH$>

where a number of RadioMenuItems belonging to a toggle group are added to the menu, we might want to add a new property to the ToggleGroup which controls whether all items in a group can be deselected.

If this property is set, a selected radio menu item can be deselected via either keyboard accelerator or a mouse click.  If not, then not only this operation cannot be performed, but also the first item added to said ToggleGroup gets automatically selected.

This should allow for more flexibility in creating menus with RadioMenuItems, but eliminate some boilerplate code required in such cases.

The new logic would also affect any Toggle, such as ToggleButton.

What do you think?  Thank you.

-andy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230123/c856c28f/attachment-0001.htm>

From tsayao at openjdk.org  Mon Jan 23 19:24:37 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 23 Jan 2023 19:24:37 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v3]
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <_jLVssndQD6iNne-yv_WFOX8TNiUOxRDaYWBO6P5s3A=.49bb0aad-cc51-44dd-b32c-81dfe505e58c@github.com>

> Simple PR to remove gtk2 library compilation and loading.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Improve SWT detection

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/999/files
  - new: https://git.openjdk.org/jfx/pull/999/files/82eedc55..a1ae52d8

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

  Stats: 42 lines in 1 file changed: 2 ins; 34 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/999/head:pull/999

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

From jpereda at openjdk.org  Mon Jan 23 20:55:01 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 23 Jan 2023 20:55:01 GMT
Subject: RFR: 8300893: Wrong state after deselecting two or more cells of a
 TableView selection
Message-ID: <qH8gBJk_h20hbB8xQUFTyu-072fxJIJ3MMs6jilPBS4=.f81e069b-d560-4ab3-a985-d02b21bd1bfc@github.com>

Given a TableView with multiple and cell selection modes enabled, three different but closely related issues are tackled with this PR:

- Selection history, that is used to backtrack deselection of cells, removes deselected cells, so the "second to last" cell is always up to date for second and further deselection

- Selection history is also used for horizontal backtracking: deselection can go from right to left or left to right (in which case the second to last cell from the selected cells list is not correct, since these are always sorted from left to right, and top to bottom)
- Selection history, can be reset after the selection gets replaced with a new one (meaning that there is a new anchor)

Tests have been added for this three issues (in same order), for both TableView and TreeTableView
- testSelectionPathDeviationWorks1 was already there, but ignored, and with a small bug. Tests vertical backtrack 
- testSelectionPathDeviationWorks2 tests horizontal backtrack
- testSelectionPathDeviationWorks3 tests vertical backtrack, change of anchor, and tests vertical backtrack again

The three (six) of them fail without the proposed fix, pass with it.

Minor:  the selection history now has a bigger size (there is no real reason to limit it to 10 cells).

-------------

Commit messages:
 - Add more tests
 - Fix and include ignored tests that are now passing
 - Reset selection history, increase its size, use it also for horizontal selection, and remove deselected cells
 - Allow clearing and removing elements from SizeLimitedList

Changes: https://git.openjdk.org/jfx/pull/1008/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300893
  Stats: 274 lines in 4 files changed: 247 ins; 5 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1008.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1008/head:pull/1008

PR: https://git.openjdk.org/jfx/pull/1008

From john.hendrikx at gmail.com  Mon Jan 23 21:29:36 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 23 Jan 2023 22:29:36 +0100
Subject: [External] : Re: RFC: new property in ToggleGroup
In-Reply-To: <DM5PR1001MB21725A3169C9AF92B5111B08E5C89@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172A0FAFBF7373C402FAC85E5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <72572d6a-0a21-d9d3-5749-484430d4987c@oracle.com>
 <DM5PR1001MB2172BD47F71192422D4BC3EAE5C59@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <44f16a41-479c-8b51-b221-95006e51c2e6@oracle.com>
 <CA+0ynh9q3w_30GXhyChs14z5mXeHx0tG-e5T=DPTfJWV93ss-g@mail.gmail.com>
 <DM5PR1001MB21725A3169C9AF92B5111B08E5C89@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <71ef3e8c-dfe4-3831-7f7b-268e0ad64f5c@gmail.com>

Radio buttons are a very common UI control that are well understood by 
users familair with UI's of the past decades, and also for programmers 
reading the resulting state of the radio buttons. Allowing deselection 
would be something users have not seen before, and I'm sure every UI 
styleguide out there will advocate against allowing this even if it were 
possible in the UI toolkit of choice. Allowing deselection is also 
something programmers have not seen before (did the user really select 
nothing, or is it still in its default state?) Therefore, having JavaFX 
support such a feature would be supporting something that will probably 
be avoided by everyone making UI's that are easy to understand by users.

I think we'd need to see more use cases, and also requests from other 
users before considering such a feature. Even then it would go against 
years of UI design and user familiarity with UI's on practically every 
platform (it's amazing to be honest that almost all platforms use the 
same concept for a group of choice of which only one can be selected).

If a radio button group really needs a way to express "none of the 
above", then another option can be added that does exactly that.

--John

On 23/01/2023 19:04, Andy Goryachev wrote:
>
> It is indeed the same in Swing: the initial state for a ButtonGroup is 
> all deselected.? Kevin brought up a good example with HTML radio 
> buttons - in effect saying that this initial state indicates that the 
> user needs to make a choice, which is the most frequent case in an 
> HTML page.
>
> However, it may or may not be the case in FX.? Consider, for example, 
> a case where a file viewer presents a number of modes - (text | hex | 
> image) to present a file.? These modes are mutually exclusive (thus 
> requiring RadioMenuItems or ToggleButtons), but one *must* be selected 
> initially, since it does not make sense to ask the user to make a 
> choice, instead a default choice must be made by the application.
>
> Yes, it can be simply solved by making a default one selected in the 
> code, and that is what is usually done.? I just thought that having a 
> property would eliminate extra code.? One can also extend ToggleGroup 
> to provide that functionality, and that is what I have done in the past.
>
> Thank you all for the discussion and insightful comments.? Given the 
> negative feedback and availability of easy workaround I withdraw this RFC.
>
> Cheers,
>
> -andy
>
> *From: *Nir Lisker <nlisker at gmail.com>
> *Date: *Saturday, 2023/01/21 at 08:22
> *To: *Kevin Rushforth <kevin.rushforth at oracle.com>
> *Cc: *Andy Goryachev <andy.goryachev at oracle.com>, 
> openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: RFC: new property in ToggleGroup
>
> I don't see it being especially useful. GUI's tend to work this way. I 
> remember it was the same in Swing.
>
> On Sat, Jan 21, 2023 at 1:41 AM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     On 1/20/2023 2:57 PM, Andy Goryachev wrote:
>
>         I just want to add one thing - the initial state of
>         RadioMenuItems added to a menu is unselected, even if they
>         belong to a ToggleGroup.
>
>         One can say that having all unselected radio buttons in a
>         toggle group makes no sense, or perhaps it depends on the
>         application requirements - though I cannot find an example
>         where it might be needed.
>
>
>     Yes, it's initially unselected unless the app makes an explicit
>     selection. HTML radio buttons work the same way [1]. Some apps use
>     that to indicate that nothing was selected, but then once you
>     select it there will always be something selected.
>
>
>
>         So either we allow two different policies by adding a property
>         to the ToggleGroup, or we proclaim that adding a radio button
>         to a toggle group must have a side effect of one (first)
>         button to be automatically selected, otherwise the whole group
>         is in inconsistent state (or the app developer must write some
>         code to select one).
>
>
>     I wouldn't want to change the default behavior, since I can
>     imagine some apps relying on being able to tell if the user has
>     ever selected any of the choices.
>
>     Having two properties would be one solution, presuming we think
>     that we need to provide a way for the app to indicate that it
>     wants us to enforce the invariant of ensuring that the app can't
>     ever get the control in a state where nothing is selected.
>     Although, since it would be an opt-in, the app could just as
>     easily set the default itself as opposed to setting this new property.
>
>     -- Kevin
>
>     [1]
>     https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio
>     <https://urldefense.com/v3/__https:/www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzk6Vz7Whx$>
>
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>         <mailto:openjfx-dev-retn at openjdk.org> on behalf of Kevin
>         Rushforth <kevin.rushforth at oracle.com>
>         <mailto:kevin.rushforth at oracle.com>
>         *Date: *Friday, 2023/01/20 at 12:27
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>         <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: RFC: new property in ToggleGroup
>
>         How common a UI feature is being able to deselect the selected
>         item in a ToggleGroup via the UI such that no item is
>         selected? I don't normally see that in various apps or
>         toolkits that I am familiar with. What I do see is that either
>         a default item is selected or no item is selected initially
>         (which is the one and only time that there will be no item
>         selected), but in both case, once you make a selection, there
>         is no way via the UI to deselect the current item. Absent a
>         compelling need, I think the current behavior (once the fix
>         for JDK-8237505 is integrated) is sufficient.
>
>         What do other developers think?
>
>         -- Kevin
>
>         On 1/20/2023 11:31 AM, Andy Goryachev wrote:
>
>             Dear colleagues:
>
>             In the context of a recent PR
>
>             https://bugs.openjdk.org/browse/JDK-8237505
>
>             https://github.com/openjdk/jfx/pull/1002
>             <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1002__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzkyU-UIVq$>
>
>             https://stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem
>             <https://urldefense.com/v3/__https:/stackoverflow.com/questions/57911107/javafx-togglegroup-not-functioning-properly-with-accelerators-radiomenuitem__;!!ACWV5N9M2RV99hQ!IHUhh-zd22k26dpWxaIMIQPWkUKslHglTRC3u7NgvYYyYi4ZLWiijdogZwo2f9iRPTRGkKW9kGAzk5wy-flH$>
>
>             where a number of RadioMenuItems belonging to a toggle
>             group are added to the menu, we might want to add a new
>             property to the ToggleGroup which controls whether all
>             items in a group can be deselected.
>
>             If this property is set, a selected radio menu item can be
>             deselected via either keyboard accelerator or a mouse
>             click.? If not, then not only this operation cannot be
>             performed, but also the first item added to said
>             ToggleGroup gets automatically selected.
>
>             This should allow for more flexibility in creating menus
>             with RadioMenuItems, but eliminate some boilerplate code
>             required in such cases.
>
>             The new logic would also affect any Toggle, such as
>             ToggleButton.
>
>             What do you think? Thank you.
>
>             -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230123/8d25e81f/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon Jan 23 21:32:59 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 23 Jan 2023 21:32:59 +0000
Subject: [External] : Re: Style themes API
In-Reply-To: <CAJEpuXSW4pt72LmpGgWMQgHDNt=us+RbU0_BnjOjaKdSDz4HhQ@mail.gmail.com>
References: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
 <DM5PR1001MB2172B6157DB71975064A2A04E5C29@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXSW4pt72LmpGgWMQgHDNt=us+RbU0_BnjOjaKdSDz4HhQ@mail.gmail.com>
Message-ID: <DM5PR1001MB2172A3D8D4AA30C45236DF7AE5C89@DM5PR1001MB2172.namprd10.prod.outlook.com>

Michael:

Thank you for clarifications.

Let me backtrack a bit and ask a very specific question: what is the problem (or problems) you are trying to solve?

I would like to understand if the problem exists (more on that below), does a workaround exists or it is currently impossible to solve the problem using the existing APIs, and relative importance of the problem.

For example, when speaking about themes and missing APIs, I would say that

1. Large scale stylesheet change at run time (i.e. going from Modena to Caspian), or listing available stylesheets is probably not high on the list of desired features.

2. What is high on the list of desired features is ability to select color theme (light/dark/hiContrast) at run time, possibly automatically by picking up the OS preference is it exists.  Ideally, the color scheme would also pick up other, user-defined colors from the OS and integrate this into the current stylesheet (Modena).  Right now there is no public API to support that, as far as I know, and no support in Modena.css

3. Another feature high on my wish list is ability to generate and apply CSS changes at run time.  For example, reacting to the user selecting larger or smaller font, more spacious or compact style, and so on.  Theoretically, this is possible by generating a new stylesheet (it has to be a heavily modified standard stylesheet) and feeding that to the Application using data: URL protocol.

4. Since you do mention javafx.application.Platform.Preferences in your PR, I fully agree that it is a good idea to expose platform and preferences, especially since there are no public APIs for that.  This probably deserves its own PR instead of being a part of #2.  But the main value, as I see it (and I could be wrong) is that the platform preferences are incorporated into the main stylesheet.

Perhaps I totally misunderstand the goal of your PR #511, so could you please describe the problem this PR is trying to solve?

Thank you
-andy


From: Michael Strau? <michaelstrau2 at gmail.com>
Date: Friday, 2023/01/13 at 16:14
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: Style themes API
Hi Andy!

please see my comments below:


On Fri, Jan 13, 2023 at 6:31 PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> #1 Theme
> I wonder if we need to clarify what we mean by the word "theme" in the context of a javaFX application.  Are we talking about colors, fonts, spacing, graphics, or all of the above?  Would a completely different stylesheet like Caspian or Modena be considered a separate theme, or would we rather have a way to modify the standard stylesheet by adding ability to redefine the different aspects such as colors and spacing without making structural changes to the stylesheet itself?


The proposed documentation defines it as: "StyleTheme is a collection
of stylesheets that specify the appearance of UI controls and other
nodes in the application."
So we're talking about everything that can be set via CSS. Caspian and
Modena are two separate themes, but they can be extended by prepending
or appending custom stylesheets.
One way to achieve this is by subclassing the
`javafx.scene.control.theme.CaspianTheme` or
`javafx.scene.control.theme.ModenaTheme` class and using the
`addFirst` and `addLast` methods to add custom stylesheets:

    public class MyTheme extends ModenaTheme {
        public MyTheme() {
            addLast("myColors.css");
        }
    }

Note that `addFirst` and `addLast` are two methods that are specific
to the implementation of Caspian and Modena, these are not
general-purpose methods available for all `StyleTheme`
implementations.
Since both themes are implemented using a single CSS file, there is no
way to fundamentally change the structure of the theme.

However, other theme implementations may offer a different API that
may allow changing the stylesheets that comprise the theme in a
structural way.
For example, a theme implementation might use one stylesheet per
control instead of a single stylesheet for the entire theme, and offer
a way to override or modify individual control stylesheets.



> #2 Colors
> When talking about colors specifically, the main requirements might be:
> change the base colors used by the standard stylesheets, or just Modena
> derived colors might use different logic for light and dark themes
> have ability to select a group of colors, or "color themes" - such as Light, Dark, Solarized, High Contrast, etc.
> pick up the user-defined color preferences from the platform
> track the user-defined color preferences at run time
>
> I think most of these (except for platform colors) can be implemented currently at the application level (that is, without introducing new APIs) simply by loading a stylesheet that redefines base colors (e.g. -fx-base), however, it gets complicated when we start deriving colors.  For example, the use of derive() will need to change in order to obtain an esthetically pleasing colors in the dark theme.


All of these things (except as you say, querying and tracking changes
of platform colors) can be currently implemented by programmatically
composing a monolithic user-agent stylesheet. The advantage of this
approach is that you can use any kind of logic, not just what's
supported by JavaFX CSS functions like derive().



> #3 Platform Colors
> Thank you for researching the preferences provided by the three different platforms.  I wonder if it would make sense to extract that into a separate PR, perhaps as an implementation detail, to be further refined as a part of Desktop replacement for JavaFX?  And, if we are talking about exposing platform colors via APIs, do we want to make it as a part of one giant facility like java.swt.Desktop equivalent, or via individual methods in Platform, or perhaps some other lookup scheme that allows for future extension?
> Do you think it could be possible to describe the individual platform properties (what is Windows.UIColor.AccentDark3?), and possibly attempt to map platform-specific properties to a platform-independent set of properties which represent a union of the three major platforms?
> There is one more complication - constant changes in the platform design language.  Ideally, any new APIs would support gradual evolution of the platform by, for example, providing methods to query whether particular item is available or not.


The platform preferences API is an integral part of the value
proposition of style themes. JavaFX has long included a very limited
form of this (not as public API), built specifically to support
Windows high contrast themes.
I don't think that it makes sense to separate the platform preferences
API from style themes, because
a) the existing support for Windows high contrast themes must continue
to work with the new first-class theme implementations, which requires
new code that will instantly be rendered irrelevant when the platform
preferences API arrives. Not a good investment of our time.
b) leveraging the platform preferences API to support platform
dark/light modes will probably be the first thing that theme
implementers will want to do anyway.

Note that the proposed platform preferences API exposes all kinds of
properties as mappings of key-value pairs. The API reports properties
that are available on the current platform, which might depend on any
number of factors, including the operating system version.
For example, all of the Windows.UIColor properties are not available
on Windows systems running earlier versions than Windows 10 Build
10240. Similarly, properties might be deprecated or removed in future
OS versions.
That's why the documentation of `Platform.Preferences` explains:

    * The preferences that are reported by the platform may be
dependent on the operating system version.
    * Applications should always test whether a preference is
available, or use the {@link #getString(String, String)},
    * {@link #getBoolean(String, boolean)} or {@link #getColor(String,
Color)} overloads that accept a fallback
    * value if the preference is not available.

Another approach to expose platform preferences would be to have Java
classes that mirror platform APIs (for example, something like a
javafx.application.windows.UIColor class).
But I don't see any clear advantage of that, and it's probably not a
good idea to promote platform implementation details to
front-and-center APIs.

One might ask why we should expose platform preferences in JavaFX at
all. Applications could just query the relevant properties themselves.
But that's easier said than done: many platform preferences can only
be queried from native code, and tracking changes of these properties
often requires a level of integration into windowing toolkits (for
example, event loops) that is hard or impossible to achieve in
application code.

Regarding documentation: "Windows.UIColor.AccentDark3" is whatever
Microsoft says it is. I don't think we should interpret what this
means, but we could point users to a relevant Microsoft documentation.
What is the policy of linking to external resources in Javadoc
comments?

Regarding platform-independent properties: Yes, that would be very
useful, but I don't think it should be a core part of JavaFX. As you
already noted, platforms constantly evolve and design trends come and
go. We shouldn't aim for this moving target. Third-party libraries can
build on top of the platform preferences API to provide developers
with platform-independent APIs for common OS features. The question
"what is a meaningful set of common properties" might also have
different answers depending on what theme implementers want to
achieve.



> #4 Spacing and Font Size
> A lot of modern UIs introduced the concept of density (for example, in MS Outlook, Preferences -> General -> Density preference), by making spacing between UI elements larger or smaller (at run time).  Similarly, the font size can be made larger or smaller (Ctrl-+ / Ctrl-- in Firefox).  The font size change affects "em" units, perhaps we need a parallel construct like "space-em" units that is applied to spacing?  Even then, we might need special logic to switch from pixels to fractions of "space-em" for large scales.
>
> How can we enable this functionality, ideally without making drastic changes to the base stylesheet?  Is it even possible?


Some platforms have a text scale preference that can be different from
general UI scale. For example, in Windows this is the
UISettings.TextScaleFactor preference, which is currently not reported
in the style themes PR. I think this should be added to the list of
reported preferences.
That being said, I don't plan on making any changes at all to the
existing themes (Caspian and Modena). These themes are implemented as
monoliths, and it would be a lot of work to refactor them into
reusable, composable parts.

Of course, new theme implementations might support multiple densities,
for example by programmatically composing the stylesheets.



> #5 Programmatic Stylesheet Generation
> Somewhere in this discussion we might also consider adding a possibility of generating a stylesheet programmatically, ideally in a type-safe manner, compatible with auto-completion.  jfx17 (I think) added a way to load a stylesheet data url, so it is much easier now, but I think a better way would be to skip the encoding/decoding step and just generate the stylesheet object directly.
> Perhaps the ideal scenario, one that makes it possible to adjust every aspect of the application styling, is to generate the complete stylesheet at run time, and possibly passing it to JavaFx in a binary form that does not require parsing.
> I understand this is totally separate issue which will no doubt require its own discussion.


That's an interesting option, but it's not a good fit with the
existing stylesheet API, which generally expects a String with either
an inline data-URI or a link to a CSS file.
There's a bit of design space with the new StyleTheme interface, which
is currently defined as:

    interface StyleTheme {
        List<String> getStylesheets();
    }

If the getStylesheets() method returned a List<Object>, we could also
accept user-provided Stylesheet objects (in addition to Strings). What
do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230123/fdf0a03a/attachment-0001.htm>

From tsayao at openjdk.org  Tue Jan 24 00:02:17 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 24 Jan 2023 00:02:17 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v3]
In-Reply-To: <_jLVssndQD6iNne-yv_WFOX8TNiUOxRDaYWBO6P5s3A=.49bb0aad-cc51-44dd-b32c-81dfe505e58c@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <_jLVssndQD6iNne-yv_WFOX8TNiUOxRDaYWBO6P5s3A=.49bb0aad-cc51-44dd-b32c-81dfe505e58c@github.com>
Message-ID: <zlS58irXTfM6my_2EisCH1a955G_GNspvnMz8krtPrI=.2a139672-b40a-46a3-8ee7-3944b040b47d@github.com>

On Mon, 23 Jan 2023 19:24:37 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve SWT detection

I noticed that the version query function used in SWT gtk detection is not present in recent versions, so I replaced it.

-------------

PR: https://git.openjdk.org/jfx/pull/999

From michaelstrau2 at gmail.com  Tue Jan 24 09:44:51 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 24 Jan 2023 10:44:51 +0100
Subject: [External] : Re: Style themes API
In-Reply-To: <DM5PR1001MB2172A3D8D4AA30C45236DF7AE5C89@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <CAJEpuXSkLpv4Qdx6p+PVPrttB1mU_hshXu0pPa67MgcwFjLK6A@mail.gmail.com>
 <DM5PR1001MB2172B6157DB71975064A2A04E5C29@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXSW4pt72LmpGgWMQgHDNt=us+RbU0_BnjOjaKdSDz4HhQ@mail.gmail.com>
 <DM5PR1001MB2172A3D8D4AA30C45236DF7AE5C89@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXT7ofy747pujKbsWhvNNxsmSunwCRh+aJ8yY=Dvb5rOaA@mail.gmail.com>

Hi Andy,

see my comments below:


On Mon, Jan 23, 2023 at 10:33 PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> Let me backtrack a bit and ask a very specific question: what is the problem (or problems) you are trying to solve?
> I would like to understand if the problem exists (more on that below), does a workaround exists or it is currently impossible to solve the problem using the existing APIs, and relative importance of the problem.

While JavaFX knows about themes (after all, it ships with two
hard-wired themes), it doesn't offer a public API for custom themes.
That's a bit of a problem, especially since the built-in themes look
quite dated.
Now, what's a theme? It's a dynamic collection of user-agent
stylesheets with a bit of logic determining when and how individual
stylesheets are included in the CSS cascade.
In the CSS subsystem, JavaFX already supports application-wide
user-agent stylesheet collections (that's how the built-in themes are
implemented).
The public API seems like an afterthought: you set
Application.userAgentStylesheet to some magic string to select a
built-theme.

But of course, developers want custom themes. There are two basic workarounds:
1) Add author stylesheets to the Scene
2) Replace the built-in theme with a single new user-agent stylesheet

The first option can be used to extend or modify the built-in theme,
but it does so by changing the semantics of the new styles: author
stylesheets override user code, while user-agent stylesheets don't.
The second option retains the semantics of themes (allow user code to
override properties), but comes at the price of being incredibly
clunky:
* You can only specify a single stylesheet, which means there's no way
to create a custom theme comprised of many individual stylesheets.
* You can't modify existing themes. Once you set a non-magic
Application.userAgentStylesheet, you lose all stylesheets that came
with the built-in themes.
* You can't even copy the built-in theme stylesheets and modify the
files to your liking, because that way you'll lose all of the dynamic
features (for example, reacting to the high contrast scheme setting).

If JavaFX is to stay relevant, it must give developers the tools they
need to create visually pleasing applications. Dynamic themes are
absolutely required for that (can you imagine a modern application
that doesn't support dark mode?).



> For example, when speaking about themes and missing APIs, I would say that
>
> 1. Large scale stylesheet change at run time (i.e. going from Modena to Caspian), or listing available stylesheets is probably not high on the list of desired features.

Going from Modena to Caspian and back is an existing feature, so
that's already there. What do you mean by "listing available
stylesheets", and how is it relevant to this PR?



> 2. What is high on the list of desired features is ability to select color theme (light/dark/hiContrast) at run time, possibly automatically by picking up the OS preference is it exists.  Ideally, the color scheme would also pick up other, user-defined colors from the OS and integrate this into the current stylesheet (Modena).  Right now there is no public API to support that, as far as I know, and no support in Modena.css

Since themes are an implementation detail right now, there's no public
API for anything of that sort.
The main premise of this PR is to promote themes to actual Java
classes. If you want to extend Modena, you simply extend the
javafx.scene.control.theme.ModenaTheme class and add your custom
stylesheets.
However, since modena.css is not designed to be extensible, the
ModenaTheme class also has very few extension points (basically just
an addFirst(String) and addLast(String) method to prepend or append
custom stylesheets).

If you wanted to make a version of Modena that supports dynamic
colors, you could do so by programmatically generating a small
stylesheet that only contains color definitions, and then simply swap
out this stylesheet in the ModenaTheme implementation whenever the
colors have changed. Of course, that also requires a bit of
refactoring of modena.css to remove the hard-coded colors. Note: it is
not a goal of this PR to refactor the built-in themes.



> 3. Another feature high on my wish list is ability to generate and apply CSS changes at run time.  For example, reacting to the user selecting larger or smaller font, more spacious or compact style, and so on.  Theoretically, this is possible by generating a new stylesheet (it has to be a heavily modified standard stylesheet) and feeding that to the Application using data: URL protocol.

Sure, that's theoretically possible. But it's probably not a good
developer story to dump the entirety of an application's theme
stylesheets into a single data URI.

With this PR, you could support a compact mode by creating a custom
theme and exposing an API for that:

    public class MyCustomTheme implements StyleTheme {
        private final ObservableList<String> stylesheets =
            FXCollections.observableArrayList("controls.css");

        @Override
        public List<String> getStylesheets() {
             return stylesheets;
        }

        public void setCompactMode(boolean enabled) {
            if (enabled && stylesheets.size() == 1) {
                stylesheets.add("compact.css");
            } else if (!enabled && stylesheets.size() == 2) {
                stylesheets.remove(1);
            }
        }
    }



> 4. Since you do mention javafx.application.Platform.Preferences in your PR, I fully agree that it is a good idea to expose platform and preferences, especially since there are no public APIs for that.  This probably deserves its own PR instead of being a part of #2.  But the main value, as I see it (and I could be wrong) is that the platform preferences are incorporated into the main stylesheet.

The Platform.Preferences API is required to promote Caspian and Modena
to first-class themes, since both themes support high-contrast colors
on Windows and need to continue doing so. This means they need a way
of knowing when to switch to high-contrast colors without hard-coding
that into JavaFX. Custom themes want to be able to support
high-contrast colors, too. :-)

I'm not sure if much is gained by separating those two things
(preferences and themes) into different PRs, as themes are probably
the main consumer of platform preferences. Designing platform
preferences in a vacuum might be harder than co-evolving it with
themes.

From aghaisas at openjdk.org  Tue Jan 24 10:40:36 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 24 Jan 2023 10:40:36 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v5]
In-Reply-To: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
Message-ID: <GjoaYZ4rVbSpfZZDmvbEyaS1U_EI86cjwqlVG0kZnMA=.39d8207b-81f7-41bf-8279-e4e80e8386fa@github.com>

> 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.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/995/files
  - new: https://git.openjdk.org/jfx/pull/995/files/7b441fbf..84423f5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=995&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=995&range=03-04

  Stats: 24 lines in 5 files changed: 3 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jfx/pull/995.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/995/head:pull/995

PR: https://git.openjdk.org/jfx/pull/995

From aghaisas at openjdk.org  Tue Jan 24 10:40:36 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 24 Jan 2023 10:40:36 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
Message-ID: <qVrR7YONhBTnXdh6Qhm88nFgXmrrkj0XvquaiOA_DT0=.8b5e21ee-a59b-4f45-ad76-9c70b5071f22@github.com>

On Fri, 20 Jan 2023 11:16:04 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional review fixes

> 

@nlisker, Can you please file an issue explaining how exactly you would like `ListView` documentation to be restructured?

-------------

PR: https://git.openjdk.org/jfx/pull/995

From aghaisas at openjdk.org  Tue Jan 24 10:40:37 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 24 Jan 2023 10:40:37 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <v8DA8mEXLD8nmC6kWo3WAWAu4kfe8XZCK_vRaQ4ygjg=.86745814-34fe-4c0b-b031-fa7f2d0e82fb@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
 <v8DA8mEXLD8nmC6kWo3WAWAu4kfe8XZCK_vRaQ4ygjg=.86745814-34fe-4c0b-b031-fa7f2d0e82fb@github.com>
Message-ID: <Yc4T-s0BjCoShbhHHVudMfg29pYmUdQakqBsYK7SyfU=.d5103c12-4763-49bc-a512-b7ad5eefb5d1@github.com>

On Fri, 20 Jan 2023 12:39:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional review fixes
>
> modules/javafx.controls/src/main/java/javafx/scene/control/ComboBox.java line 147:
> 
>> 145:  * a custom {@link #cellFactoryProperty() cell factory}.</li>
>> 146:  * </ul>
>> 147:  * <p>The following minimal example shows how to create a custom cell factory for {@code ComboBox} containing {@link Node}s:
> 
> Can you also add the final note, after the example, about creating the Rectangle in the instance init block or constructor?

Done!

-------------

PR: https://git.openjdk.org/jfx/pull/995

From aghaisas at openjdk.org  Tue Jan 24 10:40:37 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 24 Jan 2023 10:40:37 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <8fVW43vR9cC1IfM2CsJGHjRmCG7ax36XQ-lGoMo2VtQ=.01fd7983-927b-419d-9801-60d33a9d1678@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
 <8fVW43vR9cC1IfM2CsJGHjRmCG7ax36XQ-lGoMo2VtQ=.01fd7983-927b-419d-9801-60d33a9d1678@github.com>
Message-ID: <e8cdJlNn1269wciSZUPmx6RYXORzoX5ycbcNuYEuglw=.7afe1b62-cd94-497d-869d-8475bc3055d8@github.com>

On Thu, 19 Jan 2023 05:24:06 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra spaces
>
> modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 152:
> 
>> 150:  * <h3>Warning: Nodes should not be inserted directly into the items list</h3>
>> 151:  * ListView allows for the items list to contain elements of any type, including
>> 152:  * {@link Node} instances. Putting nodes into
> 
> `Node` is already linked above so there's no need for it, but it's fine to leave as is.

The first occurrence of `{@link Node}` is on line 152. I have kept the first occurrence and replaced others with `{@code Node}`

-------------

PR: https://git.openjdk.org/jfx/pull/995

From kcr at openjdk.org  Tue Jan 24 13:52:22 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 24 Jan 2023 13:52:22 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v5]
In-Reply-To: <GjoaYZ4rVbSpfZZDmvbEyaS1U_EI86cjwqlVG0kZnMA=.39d8207b-81f7-41bf-8279-e4e80e8386fa@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <GjoaYZ4rVbSpfZZDmvbEyaS1U_EI86cjwqlVG0kZnMA=.39d8207b-81f7-41bf-8279-e4e80e8386fa@github.com>
Message-ID: <yYJO2gJU3JSsK9BkmrCgOlecRZRW0kRHsKyX3kums_w=.ccd19169-5ae4-49e7-8f63-0c78f57af5d1@github.com>

On Tue, 24 Jan 2023 10:40:36 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/995

From kcr at openjdk.org  Tue Jan 24 15:09:26 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 24 Jan 2023 15:09:26 GMT
Subject: RFR: Merge jfx20
Message-ID: <T2Zv1GDq1fCOdhgcAphk-UbMRlXebdQnn3XFTvgdX6A=.910ff4c4-9412-4e24-a205-4d947c8558fb@github.com>

Merge `jfx20` branch into `master`.

-------------

Commit messages:
 - Merge jfx20
 - 8300664: Missing copyright header in ConditionalBinding.java file

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx/pull/1010/files
  Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1010.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1010/head:pull/1010

PR: https://git.openjdk.org/jfx/pull/1010

From kcr at openjdk.org  Tue Jan 24 15:14:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 24 Jan 2023 15:14:33 GMT
Subject: RFR: Merge jfx20 [v2]
In-Reply-To: <T2Zv1GDq1fCOdhgcAphk-UbMRlXebdQnn3XFTvgdX6A=.910ff4c4-9412-4e24-a205-4d947c8558fb@github.com>
References: <T2Zv1GDq1fCOdhgcAphk-UbMRlXebdQnn3XFTvgdX6A=.910ff4c4-9412-4e24-a205-4d947c8558fb@github.com>
Message-ID: <IEAgNHYiShoh2BuP2OC_UCjNnB5CdHcqNhqW2mzdwus=.3928d815-7f85-4b31-8bfa-6af5ce5e637e@github.com>

> Merge `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 five additional commits since the last revision:

 - Merge jfx20
 - 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/1010/files
  - new: https://git.openjdk.org/jfx/pull/1010/files/077c1e53..077c1e53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1010&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1010&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1010.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1010/head:pull/1010

PR: https://git.openjdk.org/jfx/pull/1010

From kcr at openjdk.org  Tue Jan 24 15:14:36 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 24 Jan 2023 15:14:36 GMT
Subject: Integrated: Merge jfx20
In-Reply-To: <T2Zv1GDq1fCOdhgcAphk-UbMRlXebdQnn3XFTvgdX6A=.910ff4c4-9412-4e24-a205-4d947c8558fb@github.com>
References: <T2Zv1GDq1fCOdhgcAphk-UbMRlXebdQnn3XFTvgdX6A=.910ff4c4-9412-4e24-a205-4d947c8558fb@github.com>
Message-ID: <YIzulOxXQzw5FhMdVDrBwOuTAaMO-MJzlLHy6LB_1Hs=.4413e94d-046d-43c1-a67d-703a2c899fa8@github.com>

On Tue, 24 Jan 2023 15:01:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Merge `jfx20` branch into `master`.

This pull request has now been integrated.

Changeset: e710b558
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e710b55812fbddf45e3e8069e91dd646ae397da8
Stats:     25 lines in 1 file changed: 25 ins; 0 del; 0 mod

Merge

-------------

PR: https://git.openjdk.org/jfx/pull/1010

From angorya at openjdk.org  Tue Jan 24 16:06:24 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 24 Jan 2023 16:06:24 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v5]
In-Reply-To: <GjoaYZ4rVbSpfZZDmvbEyaS1U_EI86cjwqlVG0kZnMA=.39d8207b-81f7-41bf-8279-e4e80e8386fa@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <GjoaYZ4rVbSpfZZDmvbEyaS1U_EI86cjwqlVG0kZnMA=.39d8207b-81f7-41bf-8279-e4e80e8386fa@github.com>
Message-ID: <zO8fFlsKAdzJbgph6dMagjAslSjSVSwivPQDzJ8dxuo=.b92e0bd2-102b-439d-a876-e8fc381e8c97@github.com>

On Tue, 24 Jan 2023 10:40:36 GMT, Ajit Ghaisas <aghaisas at openjdk.org> 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.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

LG

-------------

Marked as reviewed by angorya (Committer).

PR: https://git.openjdk.org/jfx/pull/995

From nlisker at openjdk.org  Tue Jan 24 16:11:26 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 24 Jan 2023 16:11:26 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v4]
In-Reply-To: <qVrR7YONhBTnXdh6Qhm88nFgXmrrkj0XvquaiOA_DT0=.8b5e21ee-a59b-4f45-ad76-9c70b5071f22@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <BI6g2b68WowDWXtAEt0DV0buYYeJxcl3gzCFBaRK9bM=.41cea6a6-a951-4e6d-8a61-ca819075cba2@github.com>
 <qVrR7YONhBTnXdh6Qhm88nFgXmrrkj0XvquaiOA_DT0=.8b5e21ee-a59b-4f45-ad76-9c70b5071f22@github.com>
Message-ID: <NP5iu1DNObdViAN1rlhmPgjyXbYVx_60Zg7JEq29fjc=.e2c00bf4-cfff-49f6-86c4-630810f9c887@github.com>

On Tue, 24 Jan 2023 10:35:36 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> > 
> 
> @nlisker, Can you please file an issue explaining how exactly you would like `ListView` documentation to be restructured?

Yes, I'll probably work on it during RDP 2. It's not the only control I want to go over.

-------------

PR: https://git.openjdk.org/jfx/pull/995

From nlisker at openjdk.org  Tue Jan 24 16:11:29 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 24 Jan 2023 16:11:29 GMT
Subject: [jfx20] RFR: 8290863: Update the documentation of Virtualized
 controls to include the best practice of not using Nodes directly in the item
 list [v3]
In-Reply-To: <e8cdJlNn1269wciSZUPmx6RYXORzoX5ycbcNuYEuglw=.7afe1b62-cd94-497d-869d-8475bc3055d8@github.com>
References: <Oat6H1vSgaLLDOFCoB5oee8CGkzZCRaCDtdJhoNJNg8=.78f9d051-0487-47d5-9977-2934e3d8cbb7@github.com>
 <PITDG_unimUSQtwITgdfguvBVOcg7J8IUFd2ewoNbWg=.709d25e7-8ecb-44b3-869e-6725d58845f4@github.com>
 <8fVW43vR9cC1IfM2CsJGHjRmCG7ax36XQ-lGoMo2VtQ=.01fd7983-927b-419d-9801-60d33a9d1678@github.com>
 <e8cdJlNn1269wciSZUPmx6RYXORzoX5ycbcNuYEuglw=.7afe1b62-cd94-497d-869d-8475bc3055d8@github.com>
Message-ID: <t4iuN5Jaay5QBsLiRv1yM-s6QaSdsqCp5MaLVQgddtU=.70ec745e-b091-40e1-9cf8-ddc619a79daa@github.com>

On Tue, 24 Jan 2023 09:59:48 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 152:
>> 
>>> 150:  * <h3>Warning: Nodes should not be inserted directly into the items list</h3>
>>> 151:  * ListView allows for the items list to contain elements of any type, including
>>> 152:  * {@link Node} instances. Putting nodes into
>> 
>> `Node` is already linked above so there's no need for it, but it's fine to leave as is.
>
> The first occurrence of `{@link Node}` is on line 152. I have kept the first occurrence and replaced others with `{@code Node}`

It's linked in the type hierarchy, but I'm fine with keeping an inline link.

-------------

PR: https://git.openjdk.org/jfx/pull/995

From swpalmer at gmail.com  Tue Jan 24 18:43:44 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 24 Jan 2023 13:43:44 -0500
Subject: BaselineOffset of StackPane is inconsistent
Message-ID: <CAL3e5iEp0XszncXK8FdgzK3fy15JfT_5METgntNfDCBvu7RuGw@mail.gmail.com>

I'm seeing something odd with the alignment of content in a TextFlow and
I'm not sure if I'm doing something wrong, or if there is a bug there.
The getBaselineOffset() method of the StackPane is returning inconsistent
values.  If I sub-class it to force a constant offset, everything works.
Since the StackPane content is always the same, I would expect
getBaselineOffset to always return the same value, but in my sample program
(below) sometimes it returns 6.5 and other times it returns 14.0. (Tested
on macOS 13.2 w. OpenJDK 19/OpenJFX19)
Parent.getBaselineOffset() is documented as: "Calculates the baseline
offset based on the first managed child." - which should always be the same
in my example. Sure enough, I checked and
getChildren().get(0).getBaselineOffset() is always returning the same value
(13.0) - so where is the discrepancy coming from?

Possibly related to https://bugs.openjdk.org/browse/JDK-8091236

The following program demonstrates the issue.  While selecting things in
the TreeView the TextFlows are repainted with different alignment between
the StackPane node and the Text nodes.

package bugs;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.ContentDisplay;
import javafx.scene.control.Label;
import javafx.scene.control.TreeCell;
import javafx.scene.control.TreeItem;
import javafx.scene.control.TreeView;
import javafx.scene.layout.StackPane;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.shape.Circle;
import javafx.scene.shape.Polygon;
import javafx.scene.text.Text;
import javafx.scene.text.TextFlow;
import javafx.stage.Stage;

public class TextFlowWithIcons extends Application {
    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        TreeItem<String> node1 = new TreeItem<>("item");
        TreeItem<String> node2 = new TreeItem<>("text");
        TreeItem<String> node3 = new TreeItem<>("tree");
        TreeItem<String> root = new TreeItem<>("ROOT");
        root.setExpanded(true);
        root.getChildren().addAll(node1, node2, node3);
        var treeView = new TreeView<String>(root);
        treeView.setCellFactory(this::cellFactory);
        VBox box = new VBox(8, new Label("Fiddle with the
TreeView...\nWatch the alignment bounce around."), treeView);
        var scene = new Scene(box);
        primaryStage.setScene(scene);
        primaryStage.setTitle("Graphic Alignment Issue");
        primaryStage.show();
    }

    private TreeCell<String> cellFactory(TreeView<String> tv) {
        return new CustomCell();
    }

    private static class CustomCell extends TreeCell<String> {

        public CustomCell() {
            setContentDisplay(ContentDisplay.GRAPHIC_ONLY);
        }

        @Override
        protected void updateItem(String item, boolean empty) {
            super.updateItem(item, empty);
            if (item != null && !empty) {
                var text1 = new Text("Some ");
                var text2 = new Text("colored ");
                var text3 = new Text(item);
                text2.setFill(Color.GREEN);
                var circle = new Circle(6);
                circle.setStroke(Color.BLACK);
                circle.setFill(Color.RED);
                var triangle = new Polygon(-6, 6, 6, 6, 0, -6);
                triangle.setFill(Color.YELLOW);
                triangle.setStroke(Color.BLACK);
                triangle.setScaleX(0.5);
                triangle.setScaleY(0.5);
                triangle.setTranslateX(4);
                triangle.setTranslateY(4);
                var icon = new StackPane(circle, triangle)
// uncomment to fix
//                {
//                    @Override
//                    public double getBaselineOffset() {
//                        return 12;
//                    }
//                }
                ;
                var textFlow = new TextFlow(icon, text1, text2, text3);
                setGraphic(textFlow);
            } else {
                setGraphic(null);
            }
            setText(null);
        }

    }
}

Regards,

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230124/8cfe873b/attachment-0001.htm>

From aghaisas at openjdk.org  Wed Jan 25 11:21:18 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 25 Jan 2023 11:21:18 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator [v2]
In-Reply-To: <Chz7EgtR-KU5uYAtVNTNXE6aFq-DdQpsXB4zO9i0-mU=.50478b54-98c5-477f-bf00-3d94f806dcd0@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
 <Chz7EgtR-KU5uYAtVNTNXE6aFq-DdQpsXB4zO9i0-mU=.50478b54-98c5-477f-bf00-3d94f806dcd0@github.com>
Message-ID: <WGfyB99Rr8Y25mlUHk6DgDW7i3wutqQFW7DMdVGLku4=.5a0559d5-eeb0-4466-941b-35d19be60183@github.com>

On Mon, 23 Jan 2023 08:24:23 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.
>> 
>> Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.
>> 
>> Added test to validate the change.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

The fix looks good to me!

-------------

Marked as reviewed by aghaisas (Reviewer).

PR: https://git.openjdk.org/jfx/pull/1002

From kpk at openjdk.org  Wed Jan 25 11:55:22 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 25 Jan 2023 11:55:22 GMT
Subject: RFR: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator [v2]
In-Reply-To: <WGfyB99Rr8Y25mlUHk6DgDW7i3wutqQFW7DMdVGLku4=.5a0559d5-eeb0-4466-941b-35d19be60183@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
 <Chz7EgtR-KU5uYAtVNTNXE6aFq-DdQpsXB4zO9i0-mU=.50478b54-98c5-477f-bf00-3d94f806dcd0@github.com>
 <WGfyB99Rr8Y25mlUHk6DgDW7i3wutqQFW7DMdVGLku4=.5a0559d5-eeb0-4466-941b-35d19be60183@github.com>
Message-ID: <xdL16FTob7THKkw9YKuw0iz0vfpdT_SZvRS58Yv62vg=.a041519e-cd09-4616-82ab-13077e7063c2@github.com>

On Wed, 25 Jan 2023 11:19:06 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> The fix looks good to me!

@aghaisas please sponsor the PR.

-------------

PR: https://git.openjdk.org/jfx/pull/1002

From kpk at openjdk.org  Wed Jan 25 12:01:25 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 25 Jan 2023 12:01:25 GMT
Subject: Integrated: 8237505: RadioMenuItem in ToggleGroup: deselected on
 accelerator
In-Reply-To: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
References: <OhdoKkKifaONetIhg8yC5M7CD8AurG2UzbpgLAm_hDs=.37b6566c-e43d-4cba-a52a-b2df9b48537f@github.com>
Message-ID: <C2EaTKnFy-JV9VS_Ss-V3LGavsBaAHCjp_PMKASXelE=.468f46b3-fbe8-4d4b-9d74-445d5a79bac4@github.com>

On Thu, 19 Jan 2023 12:54:55 GMT, Karthik P K <kpk at openjdk.org> wrote:

> No check was present in `RadioMenuItem` accelerator to see if it is in a `ToggleGroup` or not.
> 
> Made changes to check if `RadioMenuItem` is part of `ToggleGroup` or not. If it is part of a `ToggleGroup`, then it can not be cleared using accelerator.
> 
> Added test to validate the change.

This pull request has now been integrated.

Changeset: e234c89a
Author:    Karthik P K <kpk at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e234c89a253ece4962803a05d6ef77f0a7a80a82
Stats:     37 lines in 2 files changed: 35 ins; 0 del; 2 mod

8237505: RadioMenuItem in ToggleGroup: deselected on accelerator

Reviewed-by: angorya, aghaisas

-------------

PR: https://git.openjdk.org/jfx/pull/1002

From hmeda at openjdk.org  Wed Jan 25 20:04:09 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 25 Jan 2023 20:04:09 GMT
Subject: RFR: JDK-8299977 : Update WebKit to 615.1
Message-ID: <dVUwGgkTPDsJkV2zT40nNXiIf6fE33b-SDsCvyqmHAc=.586a17a1-f595-4c47-9bf3-d2166bd51c30@github.com>

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)

-------------

Commit messages:
 - Update Webkit to v615.1

Changes: https://git.openjdk.org/jfx/pull/1011/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1011&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/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 andy.goryachev at oracle.com  Wed Jan 25 22:38:32 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 25 Jan 2023 22:38:32 +0000
Subject: Q: missing APIs needed for implementation of a rich text control
Message-ID: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>

Dear colleagues:

I am trying to identify missing public APIs needed to support a rich text control.  There is a number of tickets created already against various parts of JavaFX, collected in https://bugs.openjdk.org/browse/JDK-8300569 , though I suspect this list may not be complete.

If anyone has any suggestions or requests related to the new APIs, I would be very interested to learn the context, the reason these APIs are needed, and whether a workaround exists.

Thank you in advance.

Cheers,
-andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230125/637abdf9/attachment-0001.htm>

From fkirmaier at openjdk.org  Thu Jan 26 08:54:44 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 26 Jan 2023 08:54:44 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v9]
In-Reply-To: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
Message-ID: <8RUj3XOzNWoEW-dlrHtUBIdMD7HgjH_6J3WrPW1kAoE=.b94ab007-8e17-4412-b19e-cf9f60d0e033@github.com>

> Making the initial listener of the ListProperty weak fixes the problem.
> The same is fixed for Set and Map.
> Due to a smart implementation, this is done without any performance drawback.
> (The trick is to have an object, which is both the WeakReference and the Changelistener)
> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8277848
  Removed print statements

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/689/files
  - new: https://git.openjdk.org/jfx/pull/689/files/8c69689a..d9fccd22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=07-08

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/689.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/689/head:pull/689

PR: https://git.openjdk.org/jfx/pull/689

From fkirmaier at openjdk.org  Thu Jan 26 08:54:48 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 26 Jan 2023 08:54:48 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v8]
In-Reply-To: <mLpaZqFxnDSyKsM7Kkic09j5ewX0eIdjuWg8n6hKnkQ=.922a831f-c9cc-42b7-82be-13f6964c4e17@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <r_bBMxgYY9vnq5XrQHrOE1zQGzsMOjZCTTtNWP4SZhY=.1a21e6d5-fe6a-448f-87a9-4d23efc4894e@github.com>
 <mLpaZqFxnDSyKsM7Kkic09j5ewX0eIdjuWg8n6hKnkQ=.922a831f-c9cc-42b7-82be-13f6964c4e17@github.com>
Message-ID: <lBS-oaN8i38_Bw_iXb2Z7OU9q-_q4YsFECm52xJHyTA=.afb565c8-409a-4859-b51d-8bd1eb207538@github.com>

On Sun, 22 Jan 2023 01:28:46 GMT, Michael Strau? <mstrauss at openjdk.org> 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:
>> 
>>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>>    
>>    # Conflicts:
>>    #	modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java
>>    #	modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java
>>    #	modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java
>>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>>  - JDK-8277848
>>    Added tests to ensure no premature garbage collection is happening.
>>  - JDK-8277848
>>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>>  - JDK-8277848
>>    Added the 3 requests whitespaces
>>  - JDK-8277848
>>    Further optimization based code review.
>>    This Bugfix should now event improve the performance
>>  - JDK-8277848
>>    Added missing change
>>  - JDK-8277848
>>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.
>
> modules/javafx.base/src/test/java/test/javafx/beans/property/ListPropertyBaseTest.java line 824:
> 
>> 822:         JMemoryBuddy.memoryTest(checker -> {
>> 823:             // given
>> 824:             System.out.println("Start collection: " + FXCollections.observableArrayList());
> 
> By the way, can these `println` statements in various tests be removed?

Done! I've removed the 3 print statements!

-------------

PR: https://git.openjdk.org/jfx/pull/689

From fkirmaier at openjdk.org  Thu Jan 26 09:54:25 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 26 Jan 2023 09:54:25 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
Message-ID: <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@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 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.

-------------

Changes: https://git.openjdk.org/jfx/pull/584/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=06
  Stats: 130 lines in 3 files changed: 124 ins; 2 del; 4 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  Thu Jan 26 10:05:32 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 26 Jan 2023 10:05:32 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
Message-ID: <TITAUPpat-mUJ9bMx7pVxBAPob4tocRRqIaCHZ1GZq8=.afb5b4c2-e6f7-4272-9a88-c03013f4798e@github.com>

On Thu, 26 Jan 2023 09:54:25 GMT, Florian Kirmaier <fkirmaier at openjdk.org> 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 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've just merged with master again.
It would be great if this could be reviewed at some time.

-------------

PR: https://git.openjdk.org/jfx/pull/584

From jvos at openjdk.org  Thu Jan 26 15:31:20 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 26 Jan 2023 15:31:20 GMT
Subject: [jfx17u] RFR: 8301011: Change JavaFX release version to 17.0.7 in
 jfx17u
Message-ID: <MScmIXh9k6Ukkx9VmQQq96Z9UYeK4Bf8XxTwAiErqjQ=.df642db4-b106-4214-bf68-09b4d2c7b9ab@github.com>

increase release version in build.properties and jcheck configuration
Fix for JDK-8301011

-------------

Commit messages:
 - Bump release version to 17.0.7

Changes: https://git.openjdk.org/jfx17u/pull/104/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301011
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx17u/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/104/head:pull/104

PR: https://git.openjdk.org/jfx17u/pull/104

From jvos at openjdk.org  Thu Jan 26 15:38:29 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 26 Jan 2023 15:38:29 GMT
Subject: [jfx11u] RFR: 8301010: Change JavaFX release version to 11.0.19 in
 jfx11u
Message-ID: <d78OJLBvq_nbMmGrt0BC5kOWknfRi4VW_x4-q06mtMw=.8f7479ae-0690-4b97-84e9-826d73f7a6ef@github.com>

Bump release version to 11.0.19 in build.properties and .jcheck/conf
Fix for JDK-8301010

-------------

Commit messages:
 - Increase release version for JavaFX 11.0.19

Changes: https://git.openjdk.org/jfx11u/pull/125/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301010
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx11u/pull/125.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/125/head:pull/125

PR: https://git.openjdk.org/jfx11u/pull/125

From angorya at openjdk.org  Thu Jan 26 16:05:38 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 26 Jan 2023 16:05:38 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v9]
In-Reply-To: <8RUj3XOzNWoEW-dlrHtUBIdMD7HgjH_6J3WrPW1kAoE=.b94ab007-8e17-4412-b19e-cf9f60d0e033@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <8RUj3XOzNWoEW-dlrHtUBIdMD7HgjH_6J3WrPW1kAoE=.b94ab007-8e17-4412-b19e-cf9f60d0e033@github.com>
Message-ID: <tU2JntVS095XP_KR4_rLQ1PbGHolOk7seBcu2-pv6W8=.67c32338-ca09-455d-b8ac-b7dbd8439e05@github.com>

On Thu, 26 Jan 2023 08:54:44 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8277848
>   Removed print statements

I wonder if this issue might be caused by [JDK-8299986](https://bugs.openjdk.org/browse/JDK-8299986) ?

-------------

PR: https://git.openjdk.org/jfx/pull/689

From mstrauss at openjdk.org  Thu Jan 26 17:12:37 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 26 Jan 2023 17:12:37 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v9]
In-Reply-To: <8RUj3XOzNWoEW-dlrHtUBIdMD7HgjH_6J3WrPW1kAoE=.b94ab007-8e17-4412-b19e-cf9f60d0e033@github.com>
References: <tZ0VRDI3NSmv3_4VbLdazCZ2bMIfMdsyiBmv52Uhdl4=.6f21cb92-0737-48ee-8e9f-e64e8aecfed3@github.com>
 <8RUj3XOzNWoEW-dlrHtUBIdMD7HgjH_6J3WrPW1kAoE=.b94ab007-8e17-4412-b19e-cf9f60d0e033@github.com>
Message-ID: <NYgthrH5RMOOYd6o3cidJ91cnLQZVHJO56gZMW5lzUU=.6ace9539-c33a-4a0b-8d77-16a8a0c4d634@github.com>

On Thu, 26 Jan 2023 08:54:44 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8277848
>   Removed print statements

Marked as reviewed by mstrauss (Committer).

-------------

PR: https://git.openjdk.org/jfx/pull/689

From mstrauss at openjdk.org  Thu Jan 26 18:28:41 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 26 Jan 2023 18:28:41 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
Message-ID: <ZQHgrxmlzTNdXS1dteFlH6_n6_NfaoO_q7YnLac_Myw=.35d026a9-1efd-47c6-9d72-413ff97d88d7@github.com>

On Thu, 26 Jan 2023 09:54:25 GMT, Florian Kirmaier <fkirmaier at openjdk.org> 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 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've left some comments.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 420:

> 418:                 new WeakHashMap<>();
> 419:         final Map<TKPulseListener,AccessControlContext> cleanupList =
> 420:                 new WeakHashMap<>();

I wonder why we need `WeakHashMap` here. These maps are short-lived anyway, since they're local variables.

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.

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.

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.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2129:

> 2127:     }
> 2128: 
> 2129:     private final ChangeListener<Boolean> sceneWindowShowingListener = (p, o, n) -> {checkCleanDirtyNodes(); } ;

Minor: should be no space before `;`.
You could also remove 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.

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`?

-------------

PR: https://git.openjdk.org/jfx/pull/584

From mstrauss at openjdk.org  Thu Jan 26 18:40:28 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 26 Jan 2023 18:40:28 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes
In-Reply-To: <_SIN_AunxcHmrOBU0RLpxdEhuPO9qUarLWRGu_xD5YE=.a851150a-acec-482c-901a-0988db2401b7@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <ww_TVGm37cLMSjdbESAnEOvrh8Xtmzt7Jxd7a7kcAqE=.dbe35689-99f7-47c2-a66f-da0850c79fbd@github.com>
 <_SIN_AunxcHmrOBU0RLpxdEhuPO9qUarLWRGu_xD5YE=.a851150a-acec-482c-901a-0988db2401b7@github.com>
Message-ID: <-W1vparBbLbHlDpGMRRXGHVsSr04XDQt5BsUycLQBY8=.8681086c-76e5-4210-899b-6038c70d4ce9@github.com>

On Thu, 12 Jan 2023 12:38:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think this should go into JavaFX 20.
>
>> I think this should go into JavaFX 20.
> 
> I agree. In the (very likely) case it doesn't get reviewed before the fork, I'll ask you to retarget it to the `jfx20` branch.

@kevinrushforth @arapte With RDP1 ending soon, would you be willing to review this fix?

-------------

PR: https://git.openjdk.org/jfx/pull/993

From mstrauss at openjdk.org  Thu Jan 26 19:09:17 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 26 Jan 2023 19:09:17 GMT
Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v3]
In-Reply-To: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
References: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
Message-ID: <d71MuKGohI1rq2BQxCBOd5tTKLoQpmDYqfeaIqwmABQ=.357b6d7d-3904-4f79-95c0-b0baf2bd4caf@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 with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - added javadoc
 - Merge branch 'master' into fixes/node-listener-cleanup
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/java/javafx/scene/Node.java
 - Replace null check by explicit underConstruction flag
 - Merge branch 'master' into fixes/node-listener-cleanup
 - Merge
 - added tests
 - Remove Node.disabled and Node.treeVisible listeners

-------------

Changes: https://git.openjdk.org/jfx/pull/841/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=841&range=02
  Stats: 88 lines in 3 files changed: 62 ins; 10 del; 16 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  Thu Jan 26 19:09:22 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 26 Jan 2023 19:09:22 GMT
Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v2]
In-Reply-To: <VLTHJPcIbyUbOO8v1oOgnq6rCDO369RzrAVbItfhHC0=.f4b0afd0-e743-443e-a719-a103698794af@github.com>
References: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
 <VLTHJPcIbyUbOO8v1oOgnq6rCDO369RzrAVbItfhHC0=.f4b0afd0-e743-443e-a719-a103698794af@github.com>
Message-ID: <NtedjW98cpOYsxRaSQWb9zc-Qjq6OtOOmhE6xDrpuoE=.f97aaa66-7694-4a9f-b672-2801ed13325f@github.com>

On Thu, 25 Aug 2022 22:18:44 GMT, Michael Strau? <mstrauss at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Replace null check by explicit underConstruction flag
>  - Merge branch 'master' into fixes/node-listener-cleanup
>  - Merge
>  - added tests
>  - Remove Node.disabled and Node.treeVisible listeners

I've resolved some merge conflicts with the latest `master` branch.
@arapte can you re-review?

-------------

PR: https://git.openjdk.org/jfx/pull/841

From swpalmer at gmail.com  Thu Jan 26 20:33:10 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 26 Jan 2023 15:33:10 -0500
Subject: Q: missing APIs needed for implementation of a rich text control
In-Reply-To: <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
Message-ID: <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>

[dupe of private message, now including the mailing list]

I've been using RichTextFX to make my own code editor/IDE.  I see that you
have asked that project specifically on GitHub, excellent.
One thing that I wanted to do was to use a font like Fira Code that
combines characters such as != or >= into a single glyph, but there are no
APIs to request that JavaFX render those optional ligatures. Swing APIs
automatically do.  In fact just implementing some basic font selection has
been tedious.  Getting the font family from a Font object and trying to use
it in CSS to specify -fx-font-family simply doesn't work sometimes.  Trying
to filter the list of available fonts to show only those that are
fixed-width is tedious.  I tried to hack something by measuring a couple
different characters from the font that would normally be different widths,
but this is an unreliable hack. Allowing the user to choose a preferred
font and then configuring components to use it via a CSS stylesheet is
simply more difficult than it should be.
A few years ago I contributed the changes to make the tab-width
configurable, which helped with my project a little bit.  Other APIs are
needed to better control line spacing and measure font baseline offsets and
that sort of thing.  I see there is an issue for caretBlinkRate, what about
changing the caret shape? E.g. block, underscore, vertical bar, etc.
Should the block be solid or an outline? Why is caretShape read-only? Why
does it return an array of PathElements instead of simply a Shape which by
default would be a Path?  More control of kerning and general spacing might
be nice. I've wanted that in the past, not for a rich text control, but for
doing video titles.  I can see how the two needs overlap though.  I
recently asked here about rendering emojis.  That's currently very
unreliable and broken.  Getting something to work consistently
cross-platform is not easy.  Sometimes emojis are rendered in color, other
times not.  Mac renders color emojis in gray and at the wrong size (since
 the sub-pixel rendering was turned off to match macOS).  On Windows the
emojis are never in color.

Regards,

Scott

On Wed, Jan 25, 2023 at 10:41 PM Scott Palmer <swpalmer at gmail.com> wrote:

> I've been using RichTextFX to make my own code editor/IDE.  I see that you
> have asked that project specifically on GitHub, excellent.
> One thing that I wanted to do was to use a font like Fira Code that
> combines characters such as != or >= into a single glyph, but there are no
> APIs to request that JavaFX render those optional ligatures. Swing APIs
> automatically do.  In fact just implementing some basic font selection has
> been tedious.  Getting the font family from a Font object and trying to use
> it in CSS to specify -fx-font-family simply doesn't work sometimes.  Trying
> to filter the list of available fonts to show only those that are
> fixed-width is tedious.  I tried to hack something by measuring a couple
> different characters from the font that would normally be different widths,
> but this is an unreliable hack. Allowing the user to choose a preferred
> font and then configuring components to use it via a CSS stylesheet is
> simply more difficult than it should be.
> A few years ago I contributed the changes to make the tab-width
> configurable, which helped with my project a little bit.  Other APIs are
> needed to better control line spacing and measure font baseline offsets and
> that sort of thing.  I see there is an issue for caretBlinkRate, what about
> changing the caret shape? E.g. block, underscore, vertical bar, etc.
> Should the block be solid or an outline? Why is caretShape read-only? Why
> does it return an array of PathElements instead of simply a Shape which by
> default would be a Path?  More control of kerning and general spacing might
> be nice. I've wanted that in the past, not for a rich text control, but for
> doing video title.  I can see how the two needs overlap though.  I recently
> asked here about rendering emojis.  That's currently very unreliable and
> broken.  Getting something to work consistently cross-platform is not
> easy.  Sometimes emojis are rendered in color, other times not.  Mac
> renders color emojis in gray and at the wrong size (since  the sub-pixel
> rendering was turned off to match macOS).  On Windows the emojis are never
> in color.
>
> Regards,
>
> Scott
>
> On Wed, Jan 25, 2023 at 5:38 PM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
>> Dear colleagues:
>>
>>
>>
>> I am trying to identify missing public APIs needed to support a rich text
>> control.  There is a number of tickets created already against various
>> parts of JavaFX, collected in https://bugs.openjdk.org/browse/JDK-8300569
>> , though I suspect this list may not be complete.
>>
>>
>>
>> If anyone has any suggestions or requests related to the new APIs, I
>> would be very interested to learn the context, the reason these APIs are
>> needed, and whether a workaround exists.
>>
>>
>>
>> Thank you in advance.
>>
>>
>>
>> Cheers,
>>
>> -andy
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230126/43f1bbad/attachment-0001.htm>

From philip.race at oracle.com  Thu Jan 26 20:45:04 2023
From: philip.race at oracle.com (Philip Race)
Date: Thu, 26 Jan 2023 12:45:04 -0800
Subject: Q: missing APIs needed for implementation of a rich text control
In-Reply-To: <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
 <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
Message-ID: <0a7a681c-04f0-5e1a-605a-50e4ea6938e8@oracle.com>

Many of the items below (meaning excluding the caret features and app 
control of line spacing) are on my list of
things to work on.

phil

On 1/26/23 12:33 PM, Scott Palmer wrote:
> [dupe of private message, now including the mailing list]
>
> I've been using RichTextFX to make my own code editor/IDE.? I see that 
> you have asked that project specifically on GitHub,?excellent.
> One thing that I wanted to do was to use a font like Fira Code that 
> combines characters such as != or >= into a single glyph, but there 
> are no APIs to request that JavaFX render those optional ligatures. 
> Swing APIs automatically do. In fact just?implementing some basic font 
> selection has been tedious.? Getting the font family from a Font 
> object?and trying to use it in CSS to specify -fx-font-family simply 
> doesn't work sometimes.? Trying to filter the list of available?fonts 
> to show only those that are fixed-width is tedious.? I tried to hack 
> something by measuring a couple different characters from the font 
> that would?normally be different widths, but this is an unreliable 
> hack. Allowing the user to choose a?preferred font and then 
> configuring?components to use it via a CSS stylesheet is simply more 
> difficult than it should be.
> A few years ago I contributed the changes to make the tab-width 
> configurable, which helped with my project a little bit.? Other APIs 
> are needed to better control line spacing and measure font baseline 
> offsets and that sort of thing.? I see there is an issue for 
> caretBlinkRate, what about changing the caret shape? E.g. block, 
> underscore, vertical?bar, etc. ? Should the block be solid or an 
> outline? Why is caretShape read-only? Why does it return an array of 
> PathElements instead of simply a Shape which by default?would be a 
> Path?? More control of kerning and general spacing might be nice. I've 
> wanted that in the past, not for a rich text control, but for doing 
> video titles.? I can see how the two needs overlap though.? I recently 
> asked here about rendering emojis.? That's currently very unreliable 
> and broken.? Getting something to work consistently cross-platform is 
> not easy.? Sometimes emojis are rendered in color, other times not.? 
> Mac renders color emojis in gray and at the wrong size (since ?the 
> sub-pixel rendering was turned off to match macOS).? On Windows the 
> emojis are never in color.
>
> Regards,
>
> Scott
>
> On Wed, Jan 25, 2023 at 10:41 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
>     I've been using RichTextFX to make my own code editor/IDE.? I see
>     that you have asked that project specifically on GitHub,?excellent.
>     One thing that I wanted to do was to use a font like Fira Code
>     that combines characters such as != or >= into a single glyph, but
>     there are no APIs to request that JavaFX render those optional
>     ligatures. Swing APIs automatically do.? In fact just?implementing
>     some basic font selection has been tedious.? Getting the font
>     family from a Font object?and trying to use it in CSS to specify
>     -fx-font-family simply doesn't work sometimes.? Trying to filter
>     the list of available?fonts to show only those that are
>     fixed-width is tedious.? I tried to hack something by measuring a
>     couple different characters from the font that would?normally be
>     different widths, but this is an unreliable hack. Allowing the
>     user to choose a?preferred font and then configuring?components to
>     use it via a CSS stylesheet is simply more difficult than it
>     should be.
>     A few years ago I contributed the changes to make the tab-width
>     configurable, which helped with my project a little bit.? Other
>     APIs are needed to better control line spacing and measure font
>     baseline offsets and that sort of thing.? I see there is an issue
>     for caretBlinkRate, what about changing the caret shape? E.g.
>     block, underscore, vertical?bar, etc. ? Should the block be solid
>     or an outline? Why is caretShape read-only? Why does it return an
>     array of PathElements instead of simply a Shape which by
>     default?would be a Path?? More control of kerning and general
>     spacing might be nice. I've wanted that in the past, not for a
>     rich text control, but for doing video title.? I can see how the
>     two needs overlap though.? I recently asked here about rendering
>     emojis.? That's currently very unreliable and broken.? Getting
>     something to work consistently cross-platform is not easy.?
>     Sometimes emojis are rendered in color, other times not.? Mac
>     renders color emojis in gray and at the wrong size (since ?the
>     sub-pixel rendering was turned off to match macOS).? On Windows
>     the emojis are never in color.
>
>     Regards,
>
>     Scott
>
>     On Wed, Jan 25, 2023 at 5:38 PM Andy Goryachev
>     <andy.goryachev at oracle.com> wrote:
>
>         Dear colleagues:
>
>         I am trying to identify missing public APIs needed to support
>         a rich text control.? There is a number of tickets created
>         already against various parts of JavaFX, collected in
>         https://bugs.openjdk.org/browse/JDK-8300569 , though I suspect
>         this list may not be complete.
>
>         If anyone has any suggestions or requests related to the new
>         APIs, I would be very interested to learn the context, the
>         reason these APIs are needed, and whether a workaround exists.
>
>         Thank you in advance.
>
>         Cheers,
>
>         -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230126/08389827/attachment.htm>

From thiago.sayao at gmail.com  Fri Jan 27 00:08:31 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 26 Jan 2023 21:08:31 -0300
Subject: StageStyle.TOOLKIT_DECORATED
Message-ID: <CAAP_wu=R9rqKE3Eb+c-GTvshKc=L3KJR8FRM_zUbyPqHsRw5sA@mail.gmail.com>

I have begun to implement a StageStyle variation called TOOLKIT_DECORATED
(better naming welcome).

It would be JavaFX's version of:
https://docs.gtk.org/gtk4/class.HeaderBar.html

The goal is to allow a Toolkit decorated window that accepts controls
inside the decoration such as a "hamburger menu", tabs (like firefox) or
anything else.

On Linux it would depend on:
https://docs.gtk.org/gdk3/method.Window.begin_move_drag.html

That's because the Window Manager would block moving it within desktop
constraints, unless using this function.

It would auto-style (as modena does) buttons and other controls inside it.

I don't promise I will ever finish this, because I do it for fun and I have
no time for fun :)

I know I have to do a feature proposal and discussion and It might not be
accepted.

Cheers
-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230126/2e532347/attachment-0001.htm>

From swpalmer at gmail.com  Fri Jan 27 02:33:33 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 26 Jan 2023 21:33:33 -0500
Subject: BaselineOffset of StackPane is inconsistent
In-Reply-To: <CAL3e5iEp0XszncXK8FdgzK3fy15JfT_5METgntNfDCBvu7RuGw@mail.gmail.com>
References: <CAL3e5iEp0XszncXK8FdgzK3fy15JfT_5METgntNfDCBvu7RuGw@mail.gmail.com>
Message-ID: <CAL3e5iG-YJ7fU5iz+c4UOA8MyN+xnYdiEgOAxgaW4qzOzD+3LA@mail.gmail.com>

I determined this is caused by the StackPane's child node's layoutY value
sometimes being 0.0 and sometimes being 7.5.  Which is strange, since
layout should always be complete on the TreeCells by the time they are
painted.

Which got me thinking.. sure maybe on one pass it wasn't initialized or
something, but why would it keep changing?

Then I learned that updateItem is being called much more often than I had
thought.  I had previously thought it was only called when the TreeCell was
meant to render a new or different TreeItem.  Apparently it is called when
the TreeItem selection changes.  I'm not sure why, as no parameters to
updateItem include the selection state, so a TreeCell doesn't know that is
why it is being called, and the documentation and sample code doesn't
mention it.
In fact the documentation for Cell isItemChanged specifically states:

     * This method is called by Cell subclasses so that certain
CPU-intensive
     * actions (specifically, calling {@link #updateItem(Object, boolean)})
are
     * only performed when necessary

*(that is, they are only performed     * when the currently set {@link
#itemProperty() item} is considered to be     * different than the proposed
new item that could be set).*

Which implies to me (along with the method name "updateItem") that
assigning a different item to the Cell is the only reason for updateItem to
be called.
This is clearly not the case.

Another observation is that, while changing the selected item such that I
observe the misalignment, the last time getBaselineOffset is called for any
particular cell while processing that event, it always returns the same
value of 7.5, but it seems it doesn't always use this value for when it
paints.
E.g. if I toggle the selection of a cell, updateItem is called once,
creating new Nodes for the Cell's graphic, and getBaselineOffset for the
StackPane is called 4 times.  The first 3 times the first managed child of
the StackPane has layoutY = 0.0, the last time it is 7.5.

There's a bug here somewhere...

Scott


On Tue, Jan 24, 2023 at 1:43 PM Scott Palmer <swpalmer at gmail.com> wrote:

> I'm seeing something odd with the alignment of content in a TextFlow and
> I'm not sure if I'm doing something wrong, or if there is a bug there.
> The getBaselineOffset() method of the StackPane is returning inconsistent
> values.  If I sub-class it to force a constant offset, everything works.
> Since the StackPane content is always the same, I would expect
> getBaselineOffset to always return the same value, but in my sample program
> (below) sometimes it returns 6.5 and other times it returns 14.0. (Tested
> on macOS 13.2 w. OpenJDK 19/OpenJFX19)
> Parent.getBaselineOffset() is documented as: "Calculates the baseline
> offset based on the first managed child." - which should always be the same
> in my example. Sure enough, I checked and
> getChildren().get(0).getBaselineOffset() is always returning the same value
> (13.0) - so where is the discrepancy coming from?
>
> Possibly related to https://bugs.openjdk.org/browse/JDK-8091236
>
> The following program demonstrates the issue.  While selecting things in
> the TreeView the TextFlows are repainted with different alignment between
> the StackPane node and the Text nodes.
>
> package bugs;
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.ContentDisplay;
> import javafx.scene.control.Label;
> import javafx.scene.control.TreeCell;
> import javafx.scene.control.TreeItem;
> import javafx.scene.control.TreeView;
> import javafx.scene.layout.StackPane;
> import javafx.scene.layout.VBox;
> import javafx.scene.paint.Color;
> import javafx.scene.shape.Circle;
> import javafx.scene.shape.Polygon;
> import javafx.scene.text.Text;
> import javafx.scene.text.TextFlow;
> import javafx.stage.Stage;
>
> public class TextFlowWithIcons extends Application {
>     public static void main(String[] args) {
>         launch(args);
>     }
>
>     @Override
>     public void start(Stage primaryStage) {
>         TreeItem<String> node1 = new TreeItem<>("item");
>         TreeItem<String> node2 = new TreeItem<>("text");
>         TreeItem<String> node3 = new TreeItem<>("tree");
>         TreeItem<String> root = new TreeItem<>("ROOT");
>         root.setExpanded(true);
>         root.getChildren().addAll(node1, node2, node3);
>         var treeView = new TreeView<String>(root);
>         treeView.setCellFactory(this::cellFactory);
>         VBox box = new VBox(8, new Label("Fiddle with the
> TreeView...\nWatch the alignment bounce around."), treeView);
>         var scene = new Scene(box);
>         primaryStage.setScene(scene);
>         primaryStage.setTitle("Graphic Alignment Issue");
>         primaryStage.show();
>     }
>
>     private TreeCell<String> cellFactory(TreeView<String> tv) {
>         return new CustomCell();
>     }
>
>     private static class CustomCell extends TreeCell<String> {
>
>         public CustomCell() {
>             setContentDisplay(ContentDisplay.GRAPHIC_ONLY);
>         }
>
>         @Override
>         protected void updateItem(String item, boolean empty) {
>             super.updateItem(item, empty);
>             if (item != null && !empty) {
>                 var text1 = new Text("Some ");
>                 var text2 = new Text("colored ");
>                 var text3 = new Text(item);
>                 text2.setFill(Color.GREEN);
>                 var circle = new Circle(6);
>                 circle.setStroke(Color.BLACK);
>                 circle.setFill(Color.RED);
>                 var triangle = new Polygon(-6, 6, 6, 6, 0, -6);
>                 triangle.setFill(Color.YELLOW);
>                 triangle.setStroke(Color.BLACK);
>                 triangle.setScaleX(0.5);
>                 triangle.setScaleY(0.5);
>                 triangle.setTranslateX(4);
>                 triangle.setTranslateY(4);
>                 var icon = new StackPane(circle, triangle)
> // uncomment to fix
> //                {
> //                    @Override
> //                    public double getBaselineOffset() {
> //                        return 12;
> //                    }
> //                }
>                 ;
>                 var textFlow = new TextFlow(icon, text1, text2, text3);
>                 setGraphic(textFlow);
>             } else {
>                 setGraphic(null);
>             }
>             setText(null);
>         }
>
>     }
> }
>
> Regards,
>
> Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230126/3f0c29d7/attachment.htm>

From jhendrikx at openjdk.org  Fri Jan 27 11:25:36 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 27 Jan 2023 11:25:36 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
Message-ID: <dEjxpZu0m3rPPSsf-Tc1zZbjsDh4ioZDf2bVdQwm9pc=.405f45de-0719-4c38-af78-5fb7103446fe@github.com>

On Thu, 26 Jan 2023 09:54:25 GMT, Florian Kirmaier <fkirmaier at openjdk.org> 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 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 think this can be fixed differently and with far less changes required.

See the comment I added on the test case.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 743:

> 741:         synchronizeSceneNodesWithLock();
> 742:     };
> 743:     private void checkCleanDirtyNodes() {

minor: empty line to separate methods and field declarations

tests/system/src/test/java/test/javafx/scene/DirtyNodesLeakTest.java line 74:

> 72:                         showingLatch.countDown();
> 73:                     });
> 74:                 });

I've been looking at this solution, and from what I see, we're doing our best to add a clean up listener which (as far as I can tell without any comments being added) is called when the stage is no longer shown.

The test above creates a stage, adds a label to it in a stack pane, then clears the children.  I think that should be enough to make the label collectable.

I get the impression that you also have to close the stage to make it collectable, which should not be needed at all.

If I'm correct, then this solution introduces quite some new code but doesn't properly address the issue. The dirty nodes list is clearly holding on to nodes that may not be part of the scene any more. 

Looking at the code, I see that `dirtyNodes` is a poor copy of what `ArrayList` does.  It doesn't clear the array with `null`s when it is resizing the array or when it removes elements from the array (or clears it).

The code that I think is the culprit is this part:

                // This is not the first time this scene has been synchronized,
                // so we will only synchronize those nodes that need it
                for (int i = 0 ; i < dirtyNodesSize; ++i) {
                    Node node = dirtyNodes[i];
                    dirtyNodes[i] = null;
                    if (node.getScene() == Scene.this) {
                            node.syncPeer();
                    }
                }
                dirtyNodesSize = 0;

The problem here is that it sets `dirtyNodesSize` to 0, but doesn't clear the array, leaving references to all kinds of nodes in there.

My recommendation to solve this would be to change this code to use `ArrayList` instead of a hand rolled solution. `ArrayList` will properly `null` out slots in its array when they become unused.

-------------

Changes requested by jhendrikx (Committer).

PR: https://git.openjdk.org/jfx/pull/584

From jhendrikx at openjdk.org  Fri Jan 27 11:25:40 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 27 Jan 2023 11:25:40 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <ZQHgrxmlzTNdXS1dteFlH6_n6_NfaoO_q7YnLac_Myw=.35d026a9-1efd-47c6-9d72-413ff97d88d7@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
 <ZQHgrxmlzTNdXS1dteFlH6_n6_NfaoO_q7YnLac_Myw=.35d026a9-1efd-47c6-9d72-413ff97d88d7@github.com>
Message-ID: <bION_eaklL7aGsTJ1PJ01JDni85vNIldz2-1tnaWMY4=.6cf083e2-52b3-45e5-9246-543c6f328c1a@github.com>

On Thu, 26 Jan 2023 18:04:41 GMT, Michael Strau? <mstrauss at openjdk.org> 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/com/sun/javafx/tk/Toolkit.java line 420:
> 
>> 418:                 new WeakHashMap<>();
>> 419:         final Map<TKPulseListener,AccessControlContext> 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.

> 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.

-------------

PR: https://git.openjdk.org/jfx/pull/584

From mike at hydraulic.software  Fri Jan 27 14:05:01 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Fri, 27 Jan 2023 15:05:01 +0100
Subject: Q: missing APIs needed for implementation of a rich text control
In-Reply-To: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAGv+2bNX7BPD1sTP0fH61tjDAgO22cvbf7C=cYWcgEMNtLJ76g@mail.gmail.com>

I'm sure you're aware already, but there is this:

https://github.com/gluonhq/rich-text-area

It's missing from your list of open source projects in the ticket. It is
the most recent, I think, so Gluon would have the most insight into what's
required.


On Wed, 25 Jan 2023 at 23:40, Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Dear colleagues:
>
>
>
> I am trying to identify missing public APIs needed to support a rich text
> control.  There is a number of tickets created already against various
> parts of JavaFX, collected in https://bugs.openjdk.org/browse/JDK-8300569
> , though I suspect this list may not be complete.
>
>
>
> If anyone has any suggestions or requests related to the new APIs, I would
> be very interested to learn the context, the reason these APIs are needed,
> and whether a workaround exists.
>
>
>
> Thank you in advance.
>
>
>
> Cheers,
>
> -andy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/52fc9d70/attachment.htm>

From jhendrikx at openjdk.org  Fri Jan 27 14:23:37 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 27 Jan 2023 14:23:37 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
Message-ID: <j-O7RTVqt2rsN0bJQOToDfOpXQ6xn24oLJYnD_yw-Hs=.e7cfc1bd-6723-4271-933e-f9ae3229dd2a@github.com>

On Thu, 26 Jan 2023 09:54:25 GMT, Florian Kirmaier <fkirmaier at openjdk.org> 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 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/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.

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`).

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1304:

> 1302:     }
> 1303: 
> 1304:     private void synchronizeSceneNodesWithLock() {

The name is confusing, it seems to indicate that you shouldn't call this if you don't have the lock, but instead it does the locking itself. The `WithLock` part should just be dropped as it can be called at any time, anywhere AFAICS, and that this may involving locking does not need to expressed in the name.

-------------

PR: https://git.openjdk.org/jfx/pull/584

From jhendrikx at openjdk.org  Fri Jan 27 14:57:34 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 27 Jan 2023 14:57:34 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v7]
In-Reply-To: <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <MS88LYDz7TcmkuUx9YMyh3iU_6Hztc6etqMgLXsvajo=.b0aab9d0-b64c-48e7-8b04-757b118ec99e@github.com>
Message-ID: <Ix4gapb0G-rx50ECJWnyxXgiICsLDtOO9BqDZHaOdfE=.b640f66a-0679-43bc-8074-703b315cc2d1@github.com>

On Thu, 26 Jan 2023 09:54:25 GMT, Florian Kirmaier <fkirmaier at openjdk.org> 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 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`.

-------------

PR: https://git.openjdk.org/jfx/pull/584

From kcr at openjdk.org  Fri Jan 27 15:05:40 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 27 Jan 2023 15:05:40 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes
In-Reply-To: <_SIN_AunxcHmrOBU0RLpxdEhuPO9qUarLWRGu_xD5YE=.a851150a-acec-482c-901a-0988db2401b7@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <ww_TVGm37cLMSjdbESAnEOvrh8Xtmzt7Jxd7a7kcAqE=.dbe35689-99f7-47c2-a66f-da0850c79fbd@github.com>
 <_SIN_AunxcHmrOBU0RLpxdEhuPO9qUarLWRGu_xD5YE=.a851150a-acec-482c-901a-0988db2401b7@github.com>
Message-ID: <5bwpUx2h9fZOgErHuTkJRJzQhrvuMyA8NKF8YEsEmjA=.cd0fa03f-07bc-4ed0-a180-0e5000ab7b7a@github.com>

On Thu, 12 Jan 2023 12:38:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think this should go into JavaFX 20.
>
>> I think this should go into JavaFX 20.
> 
> I agree. In the (very likely) case it doesn't get reviewed before the fork, I'll ask you to retarget it to the `jfx20` branch.

> @kevinrushforth @arapte With RDP1 ending soon, would you be willing to review this fix?

One of us will review it next week.

-------------

PR: https://git.openjdk.org/jfx/pull/993

From andy.goryachev at oracle.com  Fri Jan 27 17:00:00 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 27 Jan 2023 17:00:00 +0000
Subject: [External] : Re: Q: missing APIs needed for implementation of a
 rich text control
In-Reply-To: <CAGv+2bNX7BPD1sTP0fH61tjDAgO22cvbf7C=cYWcgEMNtLJ76g@mail.gmail.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAGv+2bNX7BPD1sTP0fH61tjDAgO22cvbf7C=cYWcgEMNtLJ76g@mail.gmail.com>
Message-ID: <DM5PR1001MB2172518CA56F74E403DA4C1AE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>

Thank you.  Added the project to the list.

-andy

From: Mike Hearn <mike at hydraulic.software>
Date: Friday, January 27, 2023 at 06:05
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Q: missing APIs needed for implementation of a rich text control
I'm sure you're aware already, but there is this:

https://github.com/gluonhq/rich-text-area<https://urldefense.com/v3/__https:/github.com/gluonhq/rich-text-area__;!!ACWV5N9M2RV99hQ!N6IKQLCBLcNU-DH6Bi2x8YNyGskWXpMOT5TsX_15I3QIXevhQ3CO5GbSvIEBTJ_9LULfEmGG_oowDe3D0bOAvrFdhA$>

It's missing from your list of open source projects in the ticket. It is the most recent, I think, so Gluon would have the most insight into what's required.


On Wed, 25 Jan 2023 at 23:40, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
Dear colleagues:

I am trying to identify missing public APIs needed to support a rich text control.  There is a number of tickets created already against various parts of JavaFX, collected in https://bugs.openjdk.org/browse/JDK-8300569 , though I suspect this list may not be complete.

If anyone has any suggestions or requests related to the new APIs, I would be very interested to learn the context, the reason these APIs are needed, and whether a workaround exists.

Thank you in advance.

Cheers,
-andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/1b69867b/attachment.htm>

From thiago.sayao at gmail.com  Fri Jan 27 17:21:26 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 27 Jan 2023 14:21:26 -0300
Subject: StageStyle.TOOLKIT_DECORATED
In-Reply-To: <CAAP_wu=R9rqKE3Eb+c-GTvshKc=L3KJR8FRM_zUbyPqHsRw5sA@mail.gmail.com>
References: <CAAP_wu=R9rqKE3Eb+c-GTvshKc=L3KJR8FRM_zUbyPqHsRw5sA@mail.gmail.com>
Message-ID: <CAAP_wunh8F3kdUFRixRtJevbMyLw-2YE01T=1ritBsQA9VTu2w@mail.gmail.com>

Looking further into it, seems this is the way to go:
https://github.com/openjdk/jfx/pull/594


Em qui., 26 de jan. de 2023 ?s 21:08, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> I have begun to implement a StageStyle variation called TOOLKIT_DECORATED
> (better naming welcome).
>
> It would be JavaFX's version of:
> https://docs.gtk.org/gtk4/class.HeaderBar.html
>
> The goal is to allow a Toolkit decorated window that accepts controls
> inside the decoration such as a "hamburger menu", tabs (like firefox) or
> anything else.
>
> On Linux it would depend on:
> https://docs.gtk.org/gdk3/method.Window.begin_move_drag.html
>
> That's because the Window Manager would block moving it within desktop
> constraints, unless using this function.
>
> It would auto-style (as modena does) buttons and other controls inside it.
>
> I don't promise I will ever finish this, because I do it for fun and I
> have no time for fun :)
>
> I know I have to do a feature proposal and discussion and It might not be
> accepted.
>
> Cheers
> -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/7c17d939/attachment-0001.htm>

From andy.goryachev at oracle.com  Fri Jan 27 17:30:57 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 27 Jan 2023 17:30:57 +0000
Subject: Q: missing APIs needed for implementation of a rich text control
In-Reply-To: <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
 <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
Message-ID: <DM5PR1001MB217297D94A7F98312ABB81BEE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>

>  More control of kerning and general spacing might be nice.

What properties, besides kerning, are you referring to?

Also, a question for the wider audience: is there a need to have caretBlinkRate property for each control, or a single global one would suffice?  In other words, are there use cases when two or more controls might need a different blink rate?

Thank you.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Scott Palmer <swpalmer at gmail.com>
Date: Thursday, January 26, 2023 at 12:33
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Q: missing APIs needed for implementation of a rich text control
[dupe of private message, now including the mailing list]

I've been using RichTextFX to make my own code editor/IDE.  I see that you have asked that project specifically on GitHub, excellent.
One thing that I wanted to do was to use a font like Fira Code that combines characters such as != or >= into a single glyph, but there are no APIs to request that JavaFX render those optional ligatures. Swing APIs automatically do.  In fact just implementing some basic font selection has been tedious.  Getting the font family from a Font object and trying to use it in CSS to specify -fx-font-family simply doesn't work sometimes.  Trying to filter the list of available fonts to show only those that are fixed-width is tedious.  I tried to hack something by measuring a couple different characters from the font that would normally be different widths, but this is an unreliable hack. Allowing the user to choose a preferred font and then configuring components to use it via a CSS stylesheet is simply more difficult than it should be.
A few years ago I contributed the changes to make the tab-width configurable, which helped with my project a little bit.  Other APIs are needed to better control line spacing and measure font baseline offsets and that sort of thing.  I see there is an issue for caretBlinkRate, what about changing the caret shape? E.g. block, underscore, vertical bar, etc.   Should the block be solid or an outline? Why is caretShape read-only? Why does it return an array of PathElements instead of simply a Shape which by default would be a Path?  More control of kerning and general spacing might be nice. I've wanted that in the past, not for a rich text control, but for doing video titles.  I can see how the two needs overlap though.  I recently asked here about rendering emojis.  That's currently very unreliable and broken.  Getting something to work consistently cross-platform is not easy.  Sometimes emojis are rendered in color, other times not.  Mac renders color emojis in gray and at the wrong size (since  the sub-pixel rendering was turned off to match macOS).  On Windows the emojis are never in color.

Regards,

Scott

On Wed, Jan 25, 2023 at 10:41 PM Scott Palmer <swpalmer at gmail.com<mailto:swpalmer at gmail.com>> wrote:
I've been using RichTextFX to make my own code editor/IDE.  I see that you have asked that project specifically on GitHub, excellent.
One thing that I wanted to do was to use a font like Fira Code that combines characters such as != or >= into a single glyph, but there are no APIs to request that JavaFX render those optional ligatures. Swing APIs automatically do.  In fact just implementing some basic font selection has been tedious.  Getting the font family from a Font object and trying to use it in CSS to specify -fx-font-family simply doesn't work sometimes.  Trying to filter the list of available fonts to show only those that are fixed-width is tedious.  I tried to hack something by measuring a couple different characters from the font that would normally be different widths, but this is an unreliable hack. Allowing the user to choose a preferred font and then configuring components to use it via a CSS stylesheet is simply more difficult than it should be.
A few years ago I contributed the changes to make the tab-width configurable, which helped with my project a little bit.  Other APIs are needed to better control line spacing and measure font baseline offsets and that sort of thing.  I see there is an issue for caretBlinkRate, what about changing the caret shape? E.g. block, underscore, vertical bar, etc.   Should the block be solid or an outline? Why is caretShape read-only? Why does it return an array of PathElements instead of simply a Shape which by default would be a Path?  More control of kerning and general spacing might be nice. I've wanted that in the past, not for a rich text control, but for doing video title.  I can see how the two needs overlap though.  I recently asked here about rendering emojis.  That's currently very unreliable and broken.  Getting something to work consistently cross-platform is not easy.  Sometimes emojis are rendered in color, other times not.  Mac renders color emojis in gray and at the wrong size (since  the sub-pixel rendering was turned off to match macOS).  On Windows the emojis are never in color.

Regards,

Scott

On Wed, Jan 25, 2023 at 5:38 PM Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
Dear colleagues:

I am trying to identify missing public APIs needed to support a rich text control.  There is a number of tickets created already against various parts of JavaFX, collected in https://bugs.openjdk.org/browse/JDK-8300569 , though I suspect this list may not be complete.

If anyone has any suggestions or requests related to the new APIs, I would be very interested to learn the context, the reason these APIs are needed, and whether a workaround exists.

Thank you in advance.

Cheers,
-andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/71e76479/attachment-0001.htm>

From swpalmer at gmail.com  Fri Jan 27 20:55:23 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 27 Jan 2023 15:55:23 -0500
Subject: Q: missing APIs needed for implementation of a rich text control
In-Reply-To: <DM5PR1001MB217297D94A7F98312ABB81BEE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
 <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
 <DM5PR1001MB217297D94A7F98312ABB81BEE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAL3e5iGt07tc0OEUorzeGdo=ep87VPyd=KxS91_cDea_zT5Emw@mail.gmail.com>

When I was experimenting with a program to generate titles for videos the
ability to control the spacing between letters (not kerning, but tracking)
would have been helpful.
E.g. animating something like this:
Title
T i t l e
T  i  t  l  e
T   i   t   l   e
I don't recall everything I encountered in that project, but I believe all
the basic font metrics about baseline and ascenders/descenders would help.

A FontChooser would be useful.  Applications can always code their own, but
the same can be said for ColorPicker.  It doesn't look like there is one
available even from 3rd-party libraries like ControlsFX.
Going from a Font object to CSS -fx-font-size, -fx-font-family, -fx-
font-weight, -fx-font-style doesn't always work as I've already mentioned.
The Font object doesn't have a method to get the font weight and there is
no -fx-font-name style.  Setting -fx-font-family doesn't always result in
CSS that successfully selects the desired font if used in combination with
-fx-font-style and/or -fx-font-weight.  Sometimes adding CSS for weight or
style will cause a completely different family to be used which can look
quite drastic when a variable width font is substituted for a fixed-width
font just because you tried to make something bold.
Also FontPosture only has ITALIC and NORMAL, but CSS -fx-font-style has
'normal',  'italic' and 'oblique' - There is no way to ask for 'oblique'
from code and the FontStyleConverter will convert "oblique" to REGULAR,
even though "oblique" works in CSS to get a slanted font.

Asking about caretBlinkRate, I'm not sure. I imagine only one caret
should ever be visible, with the exception of a rich text control that
supports multiple simultaneous insertion points, like many code editors.
In that case there would still only be one rate at a time even though there
are multiple carets.  My point being there should never be a need for
multiple rates to be active at the same time, so maybe you could get away
with a global rate.  I can't think of a need for multiple rates, but maybe
someone else can.

Regards,

Scott

On Fri, Jan 27, 2023 at 12:31 PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> >  More control of kerning and general spacing might be nice.
>
>
>
> What properties, besides kerning, are you referring to?
>
>
>
> Also, a question for the wider audience: is there a need to have
> caretBlinkRate property for each control, or a single global one would
> suffice?  In other words, are there use cases when two or more controls
> might need a different blink rate?
>
>
>
> Thank you.
>
>
>
> -andy
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Scott
> Palmer <swpalmer at gmail.com>
> *Date: *Thursday, January 26, 2023 at 12:33
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Re: Q: missing APIs needed for implementation of a rich text
> control
>
> [dupe of private message, now including the mailing list]
>
>
>
> I've been using RichTextFX to make my own code editor/IDE.  I see that you
> have asked that project specifically on GitHub, excellent.
>
> One thing that I wanted to do was to use a font like Fira Code that
> combines characters such as != or >= into a single glyph, but there are no
> APIs to request that JavaFX render those optional ligatures. Swing APIs
> automatically do.  In fact just implementing some basic font selection has
> been tedious.  Getting the font family from a Font object and trying to use
> it in CSS to specify -fx-font-family simply doesn't work sometimes.  Trying
> to filter the list of available fonts to show only those that are
> fixed-width is tedious.  I tried to hack something by measuring a couple
> different characters from the font that would normally be different widths,
> but this is an unreliable hack. Allowing the user to choose a preferred
> font and then configuring components to use it via a CSS stylesheet is
> simply more difficult than it should be.
>
> A few years ago I contributed the changes to make the tab-width
> configurable, which helped with my project a little bit.  Other APIs are
> needed to better control line spacing and measure font baseline offsets and
> that sort of thing.  I see there is an issue for caretBlinkRate, what about
> changing the caret shape? E.g. block, underscore, vertical bar, etc.
> Should the block be solid or an outline? Why is caretShape read-only? Why
> does it return an array of PathElements instead of simply a Shape which by
> default would be a Path?  More control of kerning and general spacing might
> be nice. I've wanted that in the past, not for a rich text control, but for
> doing video titles.  I can see how the two needs overlap though.  I
> recently asked here about rendering emojis.  That's currently very
> unreliable and broken.  Getting something to work consistently
> cross-platform is not easy.  Sometimes emojis are rendered in color, other
> times not.  Mac renders color emojis in gray and at the wrong size (since
>  the sub-pixel rendering was turned off to match macOS).  On Windows the
> emojis are never in color.
>
>
>
> Regards,
>
>
>
> Scott
>
>
>
> On Wed, Jan 25, 2023 at 10:41 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
> I've been using RichTextFX to make my own code editor/IDE.  I see that you
> have asked that project specifically on GitHub, excellent.
>
> One thing that I wanted to do was to use a font like Fira Code that
> combines characters such as != or >= into a single glyph, but there are no
> APIs to request that JavaFX render those optional ligatures. Swing APIs
> automatically do.  In fact just implementing some basic font selection has
> been tedious.  Getting the font family from a Font object and trying to use
> it in CSS to specify -fx-font-family simply doesn't work sometimes.  Trying
> to filter the list of available fonts to show only those that are
> fixed-width is tedious.  I tried to hack something by measuring a couple
> different characters from the font that would normally be different widths,
> but this is an unreliable hack. Allowing the user to choose a preferred
> font and then configuring components to use it via a CSS stylesheet is
> simply more difficult than it should be.
>
> A few years ago I contributed the changes to make the tab-width
> configurable, which helped with my project a little bit.  Other APIs are
> needed to better control line spacing and measure font baseline offsets and
> that sort of thing.  I see there is an issue for caretBlinkRate, what about
> changing the caret shape? E.g. block, underscore, vertical bar, etc.
> Should the block be solid or an outline? Why is caretShape read-only? Why
> does it return an array of PathElements instead of simply a Shape which by
> default would be a Path?  More control of kerning and general spacing might
> be nice. I've wanted that in the past, not for a rich text control, but for
> doing video title.  I can see how the two needs overlap though.  I recently
> asked here about rendering emojis.  That's currently very unreliable and
> broken.  Getting something to work consistently cross-platform is not
> easy.  Sometimes emojis are rendered in color, other times not.  Mac
> renders color emojis in gray and at the wrong size (since  the sub-pixel
> rendering was turned off to match macOS).  On Windows the emojis are never
> in color.
>
>
>
> Regards,
>
>
>
> Scott
>
>
>
> On Wed, Jan 25, 2023 at 5:38 PM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
> Dear colleagues:
>
>
>
> I am trying to identify missing public APIs needed to support a rich text
> control.  There is a number of tickets created already against various
> parts of JavaFX, collected in https://bugs.openjdk.org/browse/JDK-8300569
> , though I suspect this list may not be complete.
>
>
>
> If anyone has any suggestions or requests related to the new APIs, I would
> be very interested to learn the context, the reason these APIs are needed,
> and whether a workaround exists.
>
>
>
> Thank you in advance.
>
>
>
> Cheers,
>
> -andy
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/11689d87/attachment-0001.htm>

From martin at martinfox.com  Fri Jan 27 21:55:05 2023
From: martin at martinfox.com (Martin Fox)
Date: Fri, 27 Jan 2023 13:55:05 -0800
Subject: Q: missing APIs needed for implementation of a rich text control
In-Reply-To: <DM5PR1001MB217297D94A7F98312ABB81BEE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
 <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
 <DM5PR1001MB217297D94A7F98312ABB81BEE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <5601317F-873D-4D00-8D47-8557B10CDC68@martinfox.com>

Andy,

Could you elaborate on why you want to see KeyEvents for dead keys on Linux? https://bugs.openjdk.org/browse/JDK-8172867

On Windows dead keys are delivered as KeyEvents. The dead keys generate KEY_PRESSED events and the final composed character is delivered in a KEY_TYPED event. This reflects how the OS handles dead keys.

On Mac dead keys are handled using InputMethodEvents. The dead keys generated composed events and the final character is presented as committed text. This also reflects how the OS handles dead keys.

X11 follows the Mac model but JavaFX does not implement this completely (it only sends the final commit event). I haven?t delved into the code in detail but I suspect fleshing out the InputMethodEvent path to match the Mac would be much easier than trying to force Linux to deliver the same event stream as Windows.

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/3351e97f/attachment.htm>

From jhendrikx at openjdk.org  Fri Jan 27 22:04:29 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 27 Jan 2023 22:04:29 GMT
Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v2]
In-Reply-To: <YagYm2WtKRVtyjdQ_UGujA-WAgCGlbQUWWZ48jf5bbI=.6e9efbaa-b7c2-43a5-af27-85b84e416f2f@github.com>
References: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
 <VLTHJPcIbyUbOO8v1oOgnq6rCDO369RzrAVbItfhHC0=.f4b0afd0-e743-443e-a719-a103698794af@github.com>
 <YagYm2WtKRVtyjdQ_UGujA-WAgCGlbQUWWZ48jf5bbI=.6e9efbaa-b7c2-43a5-af27-85b84e416f2f@github.com>
Message-ID: <yTr91SaNivUXPURo57N_ooLVnrN-JmaoW6gUD8Iihpk=.b2fca2ce-89b1-4258-9fdb-abd214e22972@github.com>

On Fri, 26 Aug 2022 00:22:54 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> It's true that `Parent.getChildren()` must not return `null`, and that we shouldn't add null checks to protect against bugs.
> 
> However, in this specific instance, `Node.setTreeVisible` is called from the constructor of `Node`. At that point in time, the `Parent` constructor has not yet run, so its final fields are still unassigned (and therefore `null`).
> 
> The same problem exists for `SubScene.getRoot()` a few lines earlier, which is specified to never return `null`, but will indeed return `null` if called when the `SubScene` is under construction.
> 
> But there's a serious problem with the null checking approach: it's calling a protected method at an unexpected time, before the constructor of a derived class has run. Since that's not what derived classes would expect, I have instead opted for a different solution, which includes a `underInitialization` flag that is passed to `Node.setTreeVisible`. When the flag is set, the calls to `SubScene.getRoot()` and `Parent.getChildren()` are elided (they'd return `null` anyway, so there's no point in calling these methods).

Can this not be done in a way that doesn't require this `underInitialization` flag?  The call in the constructor to `updateTreeVisible` looks misplaced, or at least, won't do much; visible is going to be `true`, parent is gonna be `null`, sub scene is going to be `null`... all that it is going to do is set `treeVisible` to `true`, so why not just initialize the field that way?

Result of this code for an uninitialized `Node` is going to be a call to `setTreeVisible(true)`, it won't do anything else:

    private void updateTreeVisible(boolean parentChanged) {
        boolean isTreeVisible = isVisible();  // is going to be true
        final Node parentNode = getParent() != null ? getParent() :    // parentNode is going to be null
                    clipParent != null ? clipParent :
                    getSubScene() != null ? getSubScene() : null;
        if (isTreeVisible) {
            isTreeVisible = parentNode == null || parentNode.isTreeVisible();   // is going to be true
        }
        // When the parent has changed to visible and we have unsynchronized visibility,
        // we have to synchronize, because the rendering will now pass through the newly-visible parent
        // Otherwise an invisible Node might get rendered
        if (parentChanged && parentNode != null && parentNode.isTreeVisible()
                && isDirty(DirtyBits.NODE_VISIBLE)) {  // won't enter this if
            addToSceneDirtyList();
        }
        setTreeVisible(isTreeVisible);  // called with true
    }

Then `setTreeVisible`:

    final void setTreeVisible(boolean value) {
        if (treeVisible != value) {    // always enters if (as initial value of treeVisible is false, and called with true)
            treeVisible = value;
            updateCanReceiveFocus();  // doesn't do anything, canReceiveFocus was false initially and will be false again
            focusSetDirty(getScene());  // doesn't do anything, scene == null
            if (getClip() != null) {  // doesn't do anything, clip == null
                getClip().updateTreeVisible(true);
            }
            if (treeVisible && !isDirtyEmpty()) {  // doesn't do anything, dirty is empty
                addToSceneDirtyList();
            }
            ((TreeVisiblePropertyReadOnly) treeVisibleProperty()).invalidate();  // doesn't do anything, there are no listeners yet
            if (Node.this instanceof SubScene) {  
                Node subSceneRoot = ((SubScene)Node.this).getRoot();
                if (subSceneRoot != null) {  // will always be null, we're still initializing
                    // SubScene.getRoot() is only null if it's constructor
                    // has not finished.
                    subSceneRoot.setTreeVisible(value && subSceneRoot.isVisible());
                }
            }
        }
    }

End result of running all that code... `treeVisible` goes from `false` to `true`.

-------------

PR: https://git.openjdk.org/jfx/pull/841

From andy.goryachev at oracle.com  Fri Jan 27 22:11:50 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 27 Jan 2023 22:11:50 +0000
Subject: [External] : Re: Q: missing APIs needed for implementation of a
 rich text control
In-Reply-To: <5601317F-873D-4D00-8D47-8557B10CDC68@martinfox.com>
References: <DM5PR1001MB2172C37FA2B672E50C207BE3E5CE9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAL3e5iEHsNXeGky1ex1ipAjpj0uGs2dGWSaVk1jnzckSFNRcXw@mail.gmail.com>
 <CAL3e5iFgVEETvsFb-PGzsNDFfNyO4bz_LsgB+sTwKqbm40tcaQ@mail.gmail.com>
 <DM5PR1001MB217297D94A7F98312ABB81BEE5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <5601317F-873D-4D00-8D47-8557B10CDC68@martinfox.com>
Message-ID: <DM5PR1001MB2172E2359790B168B4C99504E5CC9@DM5PR1001MB2172.namprd10.prod.outlook.com>

Martin:

I am trying to collect the JBS tickets that might impact a rich text control.


I am not sure why Windows does not go through InputMethodEvents, but it looks like there is enough inconsistency in the behavior on Linux to warrant a defect.  Looks like someone was working on a fix and then it got dropped.

-andy



From: Martin Fox <martin at martinfox.com>
Date: Friday, January 27, 2023 at 13:55
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: Q: missing APIs needed for implementation of a rich text control
Andy,

Could you elaborate on why you want to see KeyEvents for dead keys on Linux? https://bugs.openjdk.org/browse/JDK-8172867

On Windows dead keys are delivered as KeyEvents. The dead keys generate KEY_PRESSED events and the final composed character is delivered in a KEY_TYPED event. This reflects how the OS handles dead keys.

On Mac dead keys are handled using InputMethodEvents. The dead keys generated composed events and the final character is presented as committed text. This also reflects how the OS handles dead keys.

X11 follows the Mac model but JavaFX does not implement this completely (it only sends the final commit event). I haven?t delved into the code in detail but I suspect fleshing out the InputMethodEvent path to match the Mac would be much easier than trying to force Linux to deliver the same event stream as Windows.

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230127/1c73a21a/attachment-0001.htm>

From kcr at openjdk.org  Sat Jan 28 14:22:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 28 Jan 2023 14:22:30 GMT
Subject: RFR: JDK-8299977 : Update WebKit to 615.1
In-Reply-To: <dVUwGgkTPDsJkV2zT40nNXiIf6fE33b-SDsCvyqmHAc=.586a17a1-f595-4c47-9bf3-d2166bd51c30@github.com>
References: <dVUwGgkTPDsJkV2zT40nNXiIf6fE33b-SDsCvyqmHAc=.586a17a1-f595-4c47-9bf3-d2166bd51c30@github.com>
Message-ID: <C_u9m_1caI8xAlZbuVI0ZAj9Qg8Hp8MIf4FHyNhClTw=.985e0e6e-5a40-4670-b77e-3342b3670ff4@github.com>

On Wed, 25 Jan 2023 19:51:02 GMT, Hima Bindu Meda <hmeda at openjdk.org> 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)

Looks good. I'll re-approve once you remove the comment and print statement from `ImageBufferBackend.h` that you mentioned in the description.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1011

From dlemmermann at gmail.com  Sat Jan 28 14:25:36 2023
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Sat, 28 Jan 2023 15:25:36 +0100
Subject: Virtual Flow enhancements
In-Reply-To: <CABxFH2GKaSDpsghpBin_05yUV-Fh49aji3CaFQAL7gVVsuAXTg@mail.gmail.com>
References: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
 <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>
 <3845162C-7988-45A2-A474-177286C3B343@gmail.com>
 <CABxFH2ECP6Zxwb1NEX7C6mFhD-wJ4WTPqPQqE5aXwo9-h_MMZQ@mail.gmail.com>
 <4E285C52-C692-4C03-992A-CC76B0E91A04@gmail.com>
 <192C1D96-AFBA-4F6D-ACD3-81F6EEDEA060@gmail.com>
 <CABxFH2GKaSDpsghpBin_05yUV-Fh49aji3CaFQAL7gVVsuAXTg@mail.gmail.com>
Message-ID: <48F14931-D88B-4847-BF52-3866C282C3AF@gmail.com>

My customer PSI has now also created their own fork and implemented a mechanism to specify row heights explicitly:

"https://github.com/PSI-Polska/jfx17u/tree/jfx-17-PSI - look at 3 commits with "8277380", workaround for JDK-8277380. FlexGantt provides the row sizes, so it wasn't hard to adopt it to use row size/height supplier.?

? Dirk


> On 22 Nov 2022, at 12:13, Johan Vos <johan.vos at gluonhq.com> wrote:
> 
> That is good food indeed. It would be sort of a circumvention of what is often leading to major issues of different kinds: the Cell.updateItem is used for a number of differen goals. The javadoc for this one [1] is already an indication that this is something dangerous:"It is very important that subclasses of Cell override the updateItem method properly".
> 
> Even when doing it properly (and granted, there is no clear definition of "properly" here), there are still different usecases. In case the method is called because the specific item is about to be rendered in that specific cell, it makes sense that there is often additional processing needed. 
> However, that same method is also called when the VirtualFlow needs to get the boundaries of the specified item when it would be rendered in a cell. Often, these two cases come down to the same: if we want the know the dimensions of something, we can populate the cell and then return its dimensions. 
> This can lead to significant overhead:
> 1. you know ahead of time what the size of a specific cell is (in which case the suggestion from Dirk is valid), so no need for any computation
> 2. you need to do additional processing in case the cell is really rendered. 
> 
> This can sort of being bypassed by checking if the current cell is the accumCell, but this is not a documented API. I personally think we can do a bit more with the accumCell, which is used internally by the VirtualFlow when we need to do operations on a cell that is not (inteded to be) visible. If the invocation of `Cell.updateItem` makes it crystal clear if we are invoking this method either to (really draw the item in the cell and render it) or (to do dimension calculations) developers have an easier way to pass dimension information.
> 
> - Johan 
>  
> [1] https://openjfx.io/javadoc/19/javafx.controls/javafx/scene/control/Cell.html#updateItem(T,boolean)
> 
> On Tue, Nov 22, 2022 at 11:44 AM Dirk Lemmermann <dlemmermann at gmail.com <mailto:dlemmermann at gmail.com>> wrote:
>> Food for thought: something that might be nice to have could be a separate model that tells the VirtualFlows what the row heights are. In FlexGanttFX the height of each row is explicitly controlled by a heightProperty() of a ?row" class and not by calculation. E.g. VirtualFlow.setHeightProvider(...) or (to support vertical and horizontal flows) VirtualFlow.setSizeProvider(?). This could then be used to pre-populate the size cache. If your application stays the in the range of hundreds of rows this could work pretty fast. 
>> 
>>> On 28 Oct 2022, at 14:43, Dirk Lemmermann <dlemmermann at gmail.com <mailto:dlemmermann at gmail.com>> wrote:
>>> 
>>> Looks like I missed this last replay from Johan. In my last email I was referring to a work-around where one VirtualFlow gets repositioned via scrollTo() method calls in response to changes in the other VirtualFlow. Not only are the rows alignments way off but updates are lagging behind.
>>> 
>>> But let?s leave that behind for now and let?s try to find an existing property that would make our use-case work again.
>>> 
>>> For the ?FlexGanttFX? use-case where I need to syncronize  the scrolling of a TreeTableView and a ListView I would love to be able to simply bind the ?position? properties of those two controls with each other. That feels very intuitive to me. If both controls have the same number of rows and each row?s height matches the row?s height in the other control then this should work, but currently it does not. 
>>> 
>>> The ?position? property gets updated by the VirtualFlow. When the flow sets this property to a certain value then I would hope setting the same value from outside would place the virtual flow at the exact same position. Basically I am hoping that this is a bijective mapping but it is not ?. unless ? the user scrolled all the way down in both views. Then it becomes a bijective mapping. So I guess after having made all rows visible the calculations are based on hard facts (as in ?actual row height?) and not on estimates.
>>> 
>>> To summarise the requirement: there should be a way to bind a property of VirtualFlow so that two instances with the same content can be scrolled in sync (content = same rows with same heights resulting in same total virtual height).
>>> 
>>> Dirk
>>> 
>>>> On 15 Sep 2022, at 21:20, Johan Vos <johan.vos at gluonhq.com <mailto:johan.vos at gluonhq.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, Sep 14, 2022 at 12:19 PM Dirk Lemmermann <dlemmermann at gmail.com <mailto:dlemmermann at gmail.com>> wrote:
>>>>> Hi,
>>>>> 
>>>>> 
>>>>> FlexGanttFX used to make this work via bidirectional bindings of the properties of the vertical scrollbars of both VirtualFlows. With the latest fixes to the VirtualFlow the assumption that two identically populated VirtualFlows would provide identical values to the ScrollBar properties is no longer true. The attempt to bind the ?position? property also failed and a work-around that Johan provided also has not been successful, yet (a customer of mine is still evaluating it).
>>>> 
>>>> I don't know what work-around you refer to, but I often point to public methods in VirtualFlow that, when properly combined, allow many usecases. I sometimes see code where the information about the positioning of elements in the VirtualFlow is obtained via the position of the scrollbar thumb, which seems a really odd way to get this info (and especially unreliable as the relation with the real positioning of cells is unspecified). There are other methods on VirtualFlow that imho are better suited for getting/setting information. 
>>>> What I want to avoid is that we have 2 API's that almost achieve the same. Hence, before considering a new method or property, I think we should make sure that there is currently no existing (documented) way to achieve it. I am pretty sure there are cases that can not be solved with the existing set of API's, and those cases are exactly what I'm looking for.
>>>> 
>>>> - Johan
>>>> 
>>>> 
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230128/07ca5026/attachment-0001.htm>

From mstrauss at openjdk.org  Sat Jan 28 16:24:30 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 28 Jan 2023 16:24:30 GMT
Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4]
In-Reply-To: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
References: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
Message-ID: <DNjGxtjFlfyKDqutmjPNce9joFfTWbPZ7EWo-mFPVc4=.887d389a-0b8c-4953-93bc-53828db978b3@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:

  Initialize treeVisible field directly

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/841/files
  - new: https://git.openjdk.org/jfx/pull/841/files/fe803883..02577bba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=841&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=841&range=02-03

  Stats: 50 lines in 3 files changed: 1 ins; 26 del; 23 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  Sat Jan 28 16:27:25 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 28 Jan 2023 16:27:25 GMT
Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v2]
In-Reply-To: <yTr91SaNivUXPURo57N_ooLVnrN-JmaoW6gUD8Iihpk=.b2fca2ce-89b1-4258-9fdb-abd214e22972@github.com>
References: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
 <VLTHJPcIbyUbOO8v1oOgnq6rCDO369RzrAVbItfhHC0=.f4b0afd0-e743-443e-a719-a103698794af@github.com>
 <YagYm2WtKRVtyjdQ_UGujA-WAgCGlbQUWWZ48jf5bbI=.6e9efbaa-b7c2-43a5-af27-85b84e416f2f@github.com>
 <yTr91SaNivUXPURo57N_ooLVnrN-JmaoW6gUD8Iihpk=.b2fca2ce-89b1-4258-9fdb-abd214e22972@github.com>
Message-ID: <fBlxJV5mQsLngUXu8fBJ7hKt6oQrcoF7--pt0zRmpC4=.8c2603d4-e296-48f3-bbf0-382859742096@github.com>

On Fri, 27 Jan 2023 22:01:46 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Can this not be done in a way that doesn't require this `underInitialization` flag?

That's a good idea, and a also a good observation that the constructor only really sets `treeVisible` to `true`.
I've updated the PR accordingly, which removes some of the complexity. There's no need for additional unit tests, as the expected behavior is already covered by `NodeTest.testIsTreeVisible`.

-------------

PR: https://git.openjdk.org/jfx/pull/841

From jhendrikx at openjdk.org  Sat Jan 28 17:02:28 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 28 Jan 2023 17:02:28 GMT
Subject: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4]
In-Reply-To: <DNjGxtjFlfyKDqutmjPNce9joFfTWbPZ7EWo-mFPVc4=.887d389a-0b8c-4953-93bc-53828db978b3@github.com>
References: <AGQKY9SGJaOb2lgcy4vJF9huhqQ_fYq67EQY8joYUBA=.67ffa04d-cfae-465f-8d9a-56a75d24fb71@github.com>
 <DNjGxtjFlfyKDqutmjPNce9joFfTWbPZ7EWo-mFPVc4=.887d389a-0b8c-4953-93bc-53828db978b3@github.com>
Message-ID: <FswMF_keB8rckMp73bd9UCcBJsCwnTTfgVXKquli99I=.cdcf2fc2-94a3-4414-84a8-fc74820a4f6b@github.com>

On Sat, 28 Jan 2023 16:24:30 GMT, Michael Strau? <mstrauss at openjdk.org> 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

Marked as reviewed by jhendrikx (Committer).

-------------

PR: https://git.openjdk.org/jfx/pull/841

From michaelstrau2 at gmail.com  Sat Jan 28 20:07:21 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 28 Jan 2023 21:07:21 +0100
Subject: Style themes update
Message-ID: <CAJEpuXTG-ASsYr+46-MYAO-9BsCYbFrGyWZZtLSoQO93Uvkmkg@mail.gmail.com>

The following document describes the current state of the proposed
theming feature for JavaFX.
I've tweaked the feature stacking and APIs to accomodate some of the
insights gained by previous discussions on this mailing list. For
example, controlling the platform window apperance and potentially
using progammatically generated Stylesheet objects is now possible.
I'm now looking to gather another round of feedback to further refine
the proposed feature.

Since the feature is quite large, it will be delivered in three installments:

PR 1: Add a platform preferences API to expose UI settings of the
operating system
PR 2: Add a Stage.appearance property to make the appearance of
platform window decorations customizable
PR 3: Add StyleTheme, which promotes themes to first-class citizens in JavaFX



Summary
-------
Enhance JavaFX with style themes, which are collections of CSS
stylesheets with custom logic to dynamically change or swap
stylesheets at runtime. This allows developers to create visually
pleasing themes that, due to their dynamic nature, can integrate well
with the look&feel of modern operating systems (e.g. dark mode and
accent colors).



Goals
-----
* Expose UI settings of the operating system (color preferences, dark
mode, etc.) as "platform preferences" in JavaFX.
* Allow the light/dark appearance of window decorations be controlled by JavaFX.
* Promote CSS user-agent themes from an implementation detail to a
first-class concept.
* Implement Caspian and Modena as first-class themes.



Non-goals
---------
It is not a goal to
* Provide a rich/opinionated framework that developers can use to
create custom theme classes;
* Add any new features to Caspian or Modena (e.g. dark mode).



Motivation
----------
While JavaFX knows about themes (it ships with two of them: Caspian
and Modena), it doesn't offer a public API to create custom themes.
What's a theme? It's a dynamic collection of user-agent stylesheets
with some logic to determine when and how individual stylesheets are
included in the CSS cascade. For example, a stylesheet with
high-contrast theme colors may be dynamically included in the cascade
depending on whether the operating system was set to a high contrast
mode.

In the CSS subsystem, JavaFX already supports application-wide
user-agent stylesheet collections (that's how the built-in themes are
implemented). The public API seems like an afterthought: the
Application.userAgentStylesheet property, which specifies a stylesheet
URI, also accepts two magic constants ("CASPIAN" and "MODENA") to
select one of the built-in themes.

There are two workarounds to create a custom theme for a JavaFX application:
1) Add author stylesheets to the Scene
2) Replace the built-in theme with a single new user-agent stylesheet

The first option can be used to extend or modify the built-in theme,
but it does so by changing the semantics of the new styles: author
stylesheets override user code, while user-agent stylesheets don't. It
also makes it harder to create entirely new themes for JavaFX, since
the built-in styles are always present in the CSS cascade.

The second option retains the semantics of themes (allow user code to
override properties), but comes at the price of being quite clunky:
* Only a single stylesheet can be specified. As such, there's no way
to create a custom theme that is comprised of many individual
stylesheets (like the built-in themes are).
* Existing themes can't be modified. Once the
Application.userAgentStylesheet property is set to any stylesheet, all
stylesheets that came with the built-in theme are discarded.
* Even if developers choose to copy and modify a built-in stylesheet
in its entirety, they will lose all dynamic features (for example,
reacting to changes of the high contrast platform preference), because
the logic that conditionally adds to or removes stylesheets from the
CSS cascade is only available for the two built-in themes and cannot
be added to custom stylesheets.

Ultimately, JavaFX needs to enable developers to easily create
visually pleasing themes that keep up with the changing trends of user
interface design. This includes the ability to integrate well with the
platforms that JavaFX applications run on, for example by supporting
dark mode and accent coloring.



Platform preferences
--------------------
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 application 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<String, Object> {
        // Platform-independent API
        ReadOnlyObjectProperty<Appearance> appearanceProperty();
        ReadOnlyObjectProperty<Color> backgroundColorProperty();
        ReadOnlyObjectProperty<Color> foregroundColorProperty();
        ReadOnlyObjectProperty<Color> accentColorProperty();

        // Convenience methods to retrieve platform-specific values from the map
        String getString(String key);
        String getString(String key, String fallbackValue);
        Boolean getBoolean(String key);
        boolean getBoolean(String key, boolean fallbackValue);
        Color getColor(String key);
        Color getColor(String key, Color fallbackValue);
    }

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().



Stage appearance
----------------
The Preferences.appearance property indicates whether the operating
system uses a light or dark color scheme. A well-designed dark mode
integration requires a JavaFX application to not only provide a set of
suitable dark stylesheets, but also configure the platform window
decorations to reflect the dark theme. This requires a new API to
control the appearance of window decorations:

    public class Stage {
        ...
        public ObjectProperty<Appearance> appearanceProperty();
        public Appearance getAppearance();
        public void setAppearance(Appearance appearance);
        ...
    }

By default, a JavaFX stage uses a light appearance. Developers can set
the stage appearance to either light or dark independently from the
operating system's dark mode setting. This can be useful for
applications that only offer either a light or a dark theme.
Applications that support both appearances and want to reflect the OS
preference can do so by simply binding the stage appearance to the
platform appearance:

    var stage = new Stage();
    stage.appearanceProperty().bind(
        Platform.getPreferences().appearanceProperty());

    stage.setScene(...);
    stage.show();



Style themes
------------
The new javafx.css.StyleTheme interface promotes themes to first-class
citizens in JavaFX:

    public interface StyleTheme {
        List<Stylesheet> getStylesheets();
    }

Note that the getStylesheets() method returns a list of
javafx.css.Stylesheet instances, not a list of URIs. Applications can
load stylesheets from CSS files with a set of new method on the
Stylesheet class:

    public Stylesheet {
        ...
        public static Stylesheet load(String url);
        public static Stylesheet load(InputStream stream);
        ...
    }

A future enhancement of the javafx.css APIs might allow applications
to programmatically create Stylesheet instances from scratch, without
parsing external CSS files or data URIs.

If a StyleTheme implementation returns an ObservableList<Stylesheet>
from its getStylesheets() method, the CSS subsystem observes the list
for changes and automatically reapplies the stylesheets when the list
has changed. This allows themes to dynamically respond to changing
platform or user preferences by adding or removing stylesheets at
runtime.

The two built-in themes CaspianTheme and ModenaTheme are exposed as
public API in the javafx.scene.control.theme package. Both classes
extend ThemeBase, which is a simple StyleTheme implementation that
allows developers to easily extend the built-in themes by prepending
or appending additional stylesheets:

    Application.setUserAgentStyleTheme(new ModenaTheme() {
        {
            addFirst(Stylesheet.load("stylesheet1.css"));
            addLast(Stylesheet.load("stylesheet2.css"));
        }
    });

ThemeBase has no other extension points aside from addFirst and
addLast, since the built-in theme stylesheets are not designed to
support further extension. A future enhancement may refactor the
built-in themes to make color definitions swappable, and automatically
pick up preferred platform colors and accent colors.



Applying a theme
----------------
A new userAgentStyleTheme property is added to
javafx.application.Application, and userAgentStylesheet is promoted to
a JavaFX property (currently, this is just a getter/setter pair):

    public abstract class Application
        ...
        public static StringProperty userAgentStylesheetProperty();
        public static String getUserAgentStylesheet();
        public static void setUserAgentStylesheet(String url);
        ...
        public static ObjectProperty<StyleTheme> userAgentStyleThemeProperty();
        public static StyleTheme getUserAgentStyleTheme();
        public static void setUserAgentStyleTheme(StyleTheme theme);
    }

userAgentStyleTheme and userAgentStylesheet are correlated to preserve
backwards compatibility: setting userAgentStylesheet to the magic
values "CASPIAN" or "MODENA" will implicitly set userAgentStyleTheme
to a new instance of the CaspianTheme or ModenaTheme class. In the CSS
cascade, userAgentStylesheet has a higher precedence than
userAgentStyleTheme. Setting userAgentStylesheet to a value other than
"CASPIAN" or "MODENA" will override the style theme of the application
in its entirety, preserving backwards compatibility with applications
that were created before the style theme API was added.

A future enhancement may add a userAgentStyleTheme property to other
scene graph classes like Scene, Region or Parent. This would allow
applications to use different style themes across the application.

From tsayao at openjdk.org  Sat Jan 28 23:24:46 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 28 Jan 2023 23:24:46 GMT
Subject: RFR: 8273379 - GTK3 stops sending key events during drag and drop
 [v28]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <lc8TDuA7vnX8rCUEFnxI2Ov73T-9TqIfV0WQmexeLKQ=.d809a155-0601-479e-8cbc-dbded0437e0f@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;
> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent.
> 
> 
> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png)
> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Use standard cursors

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/127677c1..c0eb6531

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=27
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=26-27

  Stats: 20 lines in 1 file changed: 0 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

PR: https://git.openjdk.org/jfx/pull/986

From thiago.sayao at gmail.com  Sun Jan 29 00:44:50 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 28 Jan 2023 21:44:50 -0300
Subject: Move/Resize undecorated windows
Message-ID: <CAAP_wumJcfuVG2Ew2g7E5f1904EB3590xv+NFCDfzN42KZiHsQ@mail.gmail.com>

Hi,

I did a PR (Draft) with move/resize for Linux:
https://github.com/openjdk/jfx/pull/1013

To move forward I would need help for other platforms, like Windows and Mac.

I am aware of this other PR:
https://github.com/openjdk/jfx/pull/594

But it would not work on Linux, because the window manager blocks moving
windows outside of the screen bounds accounting panels, unless telling it
"please, move the window for me".  But that's only possible on the native
side.

This PR (#1030) does this and it's not bound to any Stage Style - the drag
and resize can start from anywhere. I'm sure it can be done on other
platforms too, because GTK does (the PR contains links for its
implementation).

For resizing I am thinking of doing a SceneEgdeDetector (better naming
welcome) that would be a helper for detecting when the cursor is on the
edge. Of course it would need to work with non-rectangle shapes, for
transparent stages with rounded edges. Suggestions on how to implement this
are welcome.

This functionality will allow for custom decorators (A nice feature to have
for modern-looking apps) as it would have to move the window when dragged.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230128/a9b1d96f/attachment.htm>

From mstrauss at openjdk.org  Sun Jan 29 01:38:08 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 29 Jan 2023 01:38:08 GMT
Subject: RFR: 8301302: Platform preferences API
Message-ID: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>

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<String, Object> {
    // Platform-independent API
    ReadOnlyObjectProperty<Appearance> appearanceProperty();
    ReadOnlyObjectProperty<Color> backgroundColorProperty();
    ReadOnlyObjectProperty<Color> foregroundColorProperty();
    ReadOnlyObjectProperty<Color> accentColorProperty();

    // Convenience methods to retrieve platform-specific values from the map
    String getString(String key);
    String getString(String key, String fallbackValue);
    Boolean getBoolean(String key);
    boolean getBoolean(String key, boolean fallbackValue);
    Color getColor(String key);
    Color getColor(String key, Color fallbackValue);
}


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()`.

-------------

Commit messages:
 - 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
 - Platform.Preferences implements ObservableMap
 - Added missing newline at end of file
 - ... and 19 more: https://git.openjdk.org/jfx/compare/48f6f5ba...776dabf3

Changes: https://git.openjdk.org/jfx/pull/1014/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301302
  Stats: 2430 lines in 28 files changed: 2330 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 jhendrikx at openjdk.org  Sun Jan 29 14:34:23 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 29 Jan 2023 14:34:23 GMT
Subject: RFR: 8301302: Platform preferences API
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: <1cX2L8yzuFaLAUUfQ2TRFXWzJwKAlp1OcpSjoinJfqQ=.3a69ea6b-7eca-4898-beb5-aecbda77e092@github.com>

On Sun, 29 Jan 2023 01:33:48 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 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<String, Object> {
>     // Platform-independent API
>     ReadOnlyObjectProperty<Appearance> appearanceProperty();
>     ReadOnlyObjectProperty<Color> backgroundColorProperty();
>     ReadOnlyObjectProperty<Color> foregroundColorProperty();
>     ReadOnlyObjectProperty<Color> accentColorProperty();
> 
>     // Convenience methods to retrieve platform-specific values from the map
>     String getString(String key);
>     String getString(String key, String fallbackValue);
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> }
> 
> 
> 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()`.

Just commenting on the convenience API part.  I think in modern Java you'd use `Optional` to avoid creating multiple methods for each type (`Optional` supports far more options as "fallback") and to avoid having to return `null` as a special value.

     /**
      * Gets an optional value associated with the given key. If the key is not present or not of the correct type
      * this optional will be empty.
      */
     Optional<String> getString(String key);

In this way you could get a certain key that may be platform specific like this (names made up):

     int mousePointerWidth = prefs.getInteger("windows-cursor-size")
           .or(() -> prefs.getInteger("linux-mouse-pointer-width"))
           .or(() -> prefs.getInteger("mac-pointer-radius").map(x -> x * 2))  // multiply radius by 2 to get width
           .orElse(16);

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From mstrauss at openjdk.org  Sun Jan 29 17:10:26 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 29 Jan 2023 17:10:26 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
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: <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>

> 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<String, Object> {
>     // Platform-independent API
>     ReadOnlyObjectProperty<Appearance> appearanceProperty();
>     ReadOnlyObjectProperty<Color> backgroundColorProperty();
>     ReadOnlyObjectProperty<Color> foregroundColorProperty();
>     ReadOnlyObjectProperty<Color> accentColorProperty();
> 
>     // Convenience methods to retrieve platform-specific values from the map
>     String getString(String key);
>     String getString(String key, String fallbackValue);
>     Boolean getBoolean(String key);
>     boolean getBoolean(String key, boolean fallbackValue);
>     Color getColor(String key);
>     Color getColor(String key, Color fallbackValue);
> }
> 
> 
> 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 incrementally with one additional commit since the last revision:

  Use Optional for convenience methods in Preferences

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1014/files
  - new: https://git.openjdk.org/jfx/pull/1014/files/776dabf3..59dfb2b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=00-01

  Stats: 106 lines in 3 files changed: 18 ins; 36 del; 52 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 mstrauss at openjdk.org  Sun Jan 29 17:10:27 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 29 Jan 2023 17:10:27 GMT
Subject: RFR: 8301302: Platform preferences API
In-Reply-To: <1cX2L8yzuFaLAUUfQ2TRFXWzJwKAlp1OcpSjoinJfqQ=.3a69ea6b-7eca-4898-beb5-aecbda77e092@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <1cX2L8yzuFaLAUUfQ2TRFXWzJwKAlp1OcpSjoinJfqQ=.3a69ea6b-7eca-4898-beb5-aecbda77e092@github.com>
Message-ID: <BMLMhnqNxyq95HsPQt9eQhX-Grq2DmJA4pw5gzp2wsQ=.a1acccb3-8718-4028-a57d-92402624566d@github.com>

On Sun, 29 Jan 2023 14:31:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Just commenting on the convenience API part. I think in modern Java you'd use `Optional` to avoid creating multiple methods for each type (`Optional` supports far more options as "fallback") and to avoid having to return `null` as a special value.

That's a good suggestion, I've updated the API accordingly.

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From thiago.sayao at gmail.com  Sun Jan 29 18:45:23 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 29 Jan 2023 15:45:23 -0300
Subject: How to calculate distance from Stage to Root accounting possible CSS
 transformations?
Message-ID: <CAAP_wukPkAW01TNatiEQQhnkusHq7oWyqU_eNM+zVfLS31hfEg@mail.gmail.com>

Hi,

I want to calculate where to display resize cursors when resizing an
TRANSPARENT Stage + Scene with rounded borders.

- Stage
--- Scene
---- Root

I don't think we would have to be pixel-exact, the resize cursors could be
displayed between Stage and begin of Root actual content.
The actual content could be distant from its "layout box", because of a
border or a padding, for example.

https://github.com/tsayao/jfx/blob/begin_window_move/tests/manual/graphics/StageBeginMoveDragTest.java

Any ideas?

Thanks.
-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230129/2f4e660f/attachment.htm>

From tsayao at openjdk.org  Sun Jan 29 19:41:03 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 29 Jan 2023 19:41:03 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the source
 code repository
Message-ID: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>

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.

-------------

Commit messages:
 - Allow 20 parameters and _methods()
 - Add UI folder
 - Add manual tests
 - Remove Compile_with_MEDIA___WEBKIT.xml
 - Add hs_err*.log, .DS_Store to .gitignore
 - Add Run configuration to build MEDIA and WEBKIT
 - Checkstyle: Allow parameters with same name as fields
 - Add run configuration for robot tests
 - Be more realistic on checking javadoc
 - checkstyle.xml: allow 120 chars line
 - ... and 33 more: https://git.openjdk.org/jfx/compare/294e82e6...31e59b26

Changes: https://git.openjdk.org/jfx/pull/1009/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1009&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8223373
  Stats: 966 lines in 42 files changed: 448 ins; 511 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1009.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1009/head:pull/1009

PR: https://git.openjdk.org/jfx/pull/1009

From tsayao at openjdk.org  Sun Jan 29 19:41:04 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 29 Jan 2023 19:41:04 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository
In-Reply-To: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
Message-ID: <NWPo3C6kH6MDVVr80HRB0TD6sh0X_10505DkFmGbdBo=.fec23898-5ccb-4a19-aade-f36b4a64b6c9@github.com>

On Mon, 23 Jan 2023 23:55:51 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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.

I would appreciate feedback from intellij idea users.

CheckStyle plugin is also available for [Eclipse](https://checkstyle.org/eclipse-cs/#!/) if anyone is willing to set it up.

It caught many simple mistakes on the code.

@andy-goryachev-oracle You might like it :)

I would like to add manual tests to gradle so it would be imported by the IDE in a way it doesn't build (most are single java files that can be run directly) but code completion works. Does anyone know how to do that?

I still cannot run manual tests directly from the IDE. I think it's close to working, but something is missing and I'm not a gradle ninja.

Eclipse outputs the same error when running manual tests, so I think it's not possible to fix without restructuring the folder. 

Ready for review.

-------------

PR: https://git.openjdk.org/jfx/pull/1009

From angorya at openjdk.org  Sun Jan 29 19:41:05 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Sun, 29 Jan 2023 19:41:05 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository
In-Reply-To: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
Message-ID: <Q8PNeizvtSFtWpQWRXdSOlZLLRVUkIzkIA895RKDbVQ=.6e725d6f-5968-4510-9ede-ff3770a66310@github.com>

On Mon, 23 Jan 2023 23:55:51 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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.

will take a look at the CheckStyle plug-in, thanks!

Since you are touching /.gitignore, could you also

- Add hs_err*.log, .DS_Store to .gitignore

from JDK-8296810 ?

-------------

PR: https://git.openjdk.org/jfx/pull/1009

From mhanl at openjdk.org  Sun Jan 29 19:41:06 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 29 Jan 2023 19:41:06 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository
In-Reply-To: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
Message-ID: <reiWdJaVStNbM5o_OCFnc32__wcq3zp_Br-1ELUeaNo=.063ac826-33f2-4870-bfe8-6d586fda4179@github.com>

On Mon, 23 Jan 2023 23:55:51 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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.

Since I also use IntelliJ, I will review the PR in the next few days. :)

-------------

PR: https://git.openjdk.org/jfx/pull/1009

From kpk at openjdk.org  Mon Jan 30 12:28:18 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 30 Jan 2023 12:28:18 GMT
Subject: RFR: 8088998: LineChart: duplicate child added exception when remove &
 add a series
Message-ID: <F6dRBNVcmUf-pL3RM4QnWhCYbZTpJbjk2BqqS7ocBhA=.3176c352-88a1-43c8-8a26-d12941f60c6e@github.com>

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.

-------------

Commit messages:
 - Fix linechart exception issue on adding removed series

Changes: https://git.openjdk.org/jfx/pull/1015/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1015&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8088998
  Stats: 138 lines in 2 files changed: 135 ins; 2 del; 1 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 hmeda at openjdk.org  Mon Jan 30 15:11:20 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 30 Jan 2023 15:11:20 GMT
Subject: RFR: JDK-8299977 : Update WebKit to 615.1 [v2]
In-Reply-To: <dVUwGgkTPDsJkV2zT40nNXiIf6fE33b-SDsCvyqmHAc=.586a17a1-f595-4c47-9bf3-d2166bd51c30@github.com>
References: <dVUwGgkTPDsJkV2zT40nNXiIf6fE33b-SDsCvyqmHAc=.586a17a1-f595-4c47-9bf3-d2166bd51c30@github.com>
Message-ID: <F5CTDXFX-944wWhXNaxZf-Jdt2oKf-YIn9w2H_Ns7Bg=.c9c99b61-6a48-4aca-87e0-0f4a832cc7ae@github.com>

> 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:

  Add blank lines

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1011/files
  - new: https://git.openjdk.org/jfx/pull/1011/files/3247ba09..66237d46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1011&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1011&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 kcr at openjdk.org  Mon Jan 30 17:24:36 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 30 Jan 2023 17:24:36 GMT
Subject: RFR: 8251862: Wrong position of Popup windows at the intersection
 of 2 screens [v3]
In-Reply-To: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
References: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
Message-ID: <1UubA5Tu0h7tC-ggHHINe0zUdT-fsAdJs6xVPECHcrA=.357d2ec3-78eb-4444-9490-377514eb1d47@github.com>

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into 8251862-multi-screen-popup
 - Merge remote-tracking branch 'origin/master' into 8251862-multi-screen-popup
 - 8251862: Wrong position of Popup windows at the intersection of 2 screens

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/971/files
  - new: https://git.openjdk.org/jfx/pull/971/files/b693b871..4d08c853

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=971&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=971&range=01-02

  Stats: 4802 lines in 96 files changed: 3794 ins; 619 del; 389 mod
  Patch: https://git.openjdk.org/jfx/pull/971.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/971/head:pull/971

PR: https://git.openjdk.org/jfx/pull/971

From kcr at openjdk.org  Mon Jan 30 18:57:53 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 30 Jan 2023 18:57:53 GMT
Subject: RFR: 8251862: Wrong position of Popup windows at the intersection
 of 2 screens [v3]
In-Reply-To: <1UubA5Tu0h7tC-ggHHINe0zUdT-fsAdJs6xVPECHcrA=.357d2ec3-78eb-4444-9490-377514eb1d47@github.com>
References: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
 <1UubA5Tu0h7tC-ggHHINe0zUdT-fsAdJs6xVPECHcrA=.357d2ec3-78eb-4444-9490-377514eb1d47@github.com>
Message-ID: <s2G7RkKLp-WzGAW-aEn_E3dxWplRm-M3pmZny5W3ErM=.e0abf14b-4da4-4a57-becb-1fa5b17850d8@github.com>

On Mon, 30 Jan 2023 17:24:36 GMT, Kevin Rushforth <kcr at openjdk.org> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8251862-multi-screen-popup
>  - Merge remote-tracking branch 'origin/master' into 8251862-multi-screen-popup
>  - 8251862: Wrong position of Popup windows at the intersection of 2 screens

I filed [JDK-8301386](https://bugs.openjdk.org/browse/JDK-8301386) to track the additional problem in the code that adjusts the position of the popup to keep it on the same screen as the anchor.

-------------

PR: https://git.openjdk.org/jfx/pull/971

From kizune at openjdk.org  Mon Jan 30 22:50:47 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 30 Jan 2023 22:50:47 GMT
Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader
Message-ID: <YoT9AvHykiwbYH-Vg2flUBX_6N4KLvreaaegMfYIhOs=.8f8fcf90-6538-44fb-ba87-ba2d26d990da@github.com>

Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized.

-------------

Commit messages:
 - Fixed the properties file copyright year
 - Merge branch 'master' into JDK-8298382
 - 8298382: JavaFX ChartArea Accessibility Reader

Changes: https://git.openjdk.org/jfx/pull/1016/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298382
  Stats: 100 lines in 3 files changed: 93 ins; 0 del; 7 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 jpereda at openjdk.org  Tue Jan 31 10:37:02 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 31 Jan 2023 10:37:02 GMT
Subject: RFR: 8281327: JavaFX does not support fonts installed per-user on
 Windows 10/11
Message-ID: <JLA7-CjKg2RAltYbebl-vXEJo2TW2ywG4qmlFGJd67U=.11e61a7d-07de-4a65-80a7-436be63e1439@github.com>

This PR simply applies the patch from [JDK-8218914](https://bugs.openjdk.org/browse/JDK-8218914) that solved the same issue for the JDK.

I've tested it on Windows 11 (Version 22H2 Build 22621.1105). 

I have the Roboto font installed under C:\Users%user\AppData\Local\Microsoft\Windows\Fonts
and with this PR, -Dprism.debugfonts shows:


...
font=segoe ui historic file=seguihis.ttf
font=roboto file=C:\Users%user\AppData\Local\Microsoft\Windows\Fonts\Roboto-Regular.ttf
font=yu mincho file=yumin.ttf
...


Also, I can see that the font is picked in a simple JavaFX application.
Without this PR, the font is not used, and defaults to a system one. 

I don't think I can add this as a system/manual test to the PR, though.

-------------

Commit messages:
 - Apply patch from JDK-8218914

Changes: https://git.openjdk.org/jfx/pull/1017/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8281327
  Stats: 113 lines in 1 file changed: 63 ins; 43 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1017.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1017/head:pull/1017

PR: https://git.openjdk.org/jfx/pull/1017

From duke at openjdk.org  Tue Jan 31 11:21:16 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 31 Jan 2023 11:21:16 GMT
Subject: RFR: 8281327: JavaFX does not support fonts installed per-user on
 Windows 10/11
In-Reply-To: <JLA7-CjKg2RAltYbebl-vXEJo2TW2ywG4qmlFGJd67U=.11e61a7d-07de-4a65-80a7-436be63e1439@github.com>
References: <JLA7-CjKg2RAltYbebl-vXEJo2TW2ywG4qmlFGJd67U=.11e61a7d-07de-4a65-80a7-436be63e1439@github.com>
Message-ID: <UslFpNkTGv-ohi06FmVIy8Tg07zpoWuPGIT037witn4=.db4b9de7-156a-4319-9f88-453bc75f95eb@github.com>

On Tue, 31 Jan 2023 10:30:22 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR simply applies the patch from [JDK-8218914](https://bugs.openjdk.org/browse/JDK-8218914) that solved the same issue for the JDK.
> 
> I've tested it on Windows 11 (Version 22H2 Build 22621.1105). 
> 
> I have the Roboto font installed under C:\Users%user\AppData\Local\Microsoft\Windows\Fonts
> and with this PR, -Dprism.debugfonts shows:
> 
> 
> ...
> font=segoe ui historic file=seguihis.ttf
> font=roboto file=C:\Users%user\AppData\Local\Microsoft\Windows\Fonts\Roboto-Regular.ttf
> font=yu mincho file=yumin.ttf
> ...
> 
> 
> Also, I can see that the font is picked in a simple JavaFX application.
> Without this PR, the font is not used, and defaults to a system one. 
> 
> I don't think I can add this as a system/manual test to the PR, though.

That is great! We have been looking forward to this patch for two years.

-------------

PR: https://git.openjdk.org/jfx/pull/1017

From kcr at openjdk.org  Tue Jan 31 13:07:15 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 13:07:15 GMT
Subject: [jfx17u] RFR: 8301011: Change JavaFX release version to 17.0.7 in
 jfx17u
In-Reply-To: <MScmIXh9k6Ukkx9VmQQq96Z9UYeK4Bf8XxTwAiErqjQ=.df642db4-b106-4214-bf68-09b4d2c7b9ab@github.com>
References: <MScmIXh9k6Ukkx9VmQQq96Z9UYeK4Bf8XxTwAiErqjQ=.df642db4-b106-4214-bf68-09b4d2c7b9ab@github.com>
Message-ID: <JiPWOvRY7_4ru_gIbE-qQYGsKzpGEZ1nW3lWbu71RII=.3f358576-89a0-4a93-a809-3af9d964ffb3@github.com>

On Thu, 26 Jan 2023 15:25:32 GMT, Johan Vos <jvos at openjdk.org> wrote:

> increase release version in build.properties and jcheck configuration
> Fix for JDK-8301011

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx17u/pull/104

From kcr at openjdk.org  Tue Jan 31 13:10:20 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 13:10:20 GMT
Subject: [jfx11u] RFR: 8301010: Change JavaFX release version to 11.0.19 in
 jfx11u
In-Reply-To: <d78OJLBvq_nbMmGrt0BC5kOWknfRi4VW_x4-q06mtMw=.8f7479ae-0690-4b97-84e9-826d73f7a6ef@github.com>
References: <d78OJLBvq_nbMmGrt0BC5kOWknfRi4VW_x4-q06mtMw=.8f7479ae-0690-4b97-84e9-826d73f7a6ef@github.com>
Message-ID: <JgGzVQm3DbpHgGFNPpdG_ZWDIOqXzOqMPN5JbPHa1Vw=.f42f04b7-d195-4329-a0aa-2419a785851f@github.com>

On Thu, 26 Jan 2023 15:31:52 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump release version to 11.0.19 in build.properties and .jcheck/conf
> Fix for JDK-8301010

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx11u/pull/125

From aoqi at openjdk.org  Tue Jan 31 13:26:54 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Tue, 31 Jan 2023 13:26:54 GMT
Subject: [jfx17u] RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
Message-ID: <cHn29BEI04IGDuRQxI4ghYpuiFWbEsCI-JUqcpzFHyg=.140fd1db-adf4-4fcd-b28c-931ff9766bd4@github.com>

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`)

-------------

Commit messages:
 - 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON

Changes: https://git.openjdk.org/jfx17u/pull/103/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=103&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/jfx17u/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/103/head:pull/103

PR: https://git.openjdk.org/jfx17u/pull/103

From aoqi at openjdk.org  Tue Jan 31 13:26:55 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Tue, 31 Jan 2023 13:26:55 GMT
Subject: [jfx17u] RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <cHn29BEI04IGDuRQxI4ghYpuiFWbEsCI-JUqcpzFHyg=.140fd1db-adf4-4fcd-b28c-931ff9766bd4@github.com>
References: <cHn29BEI04IGDuRQxI4ghYpuiFWbEsCI-JUqcpzFHyg=.140fd1db-adf4-4fcd-b28c-931ff9766bd4@github.com>
Message-ID: <a2BYEn9I91OwCcoVZusBENp61bt5Y3PG3zsVASneVQM=.c3754f1a-f2bd-42c7-842d-38fb133af29b@github.com>

On Mon, 9 Jan 2023 13:29:27 GMT, Ao Qi <aoqi at openjdk.org> 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`)

RFC and RFR. Thanks.

-------------

PR: https://git.openjdk.org/jfx17u/pull/103

From kcr at openjdk.org  Tue Jan 31 13:31:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 13:31:17 GMT
Subject: [jfx17u] RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <cHn29BEI04IGDuRQxI4ghYpuiFWbEsCI-JUqcpzFHyg=.140fd1db-adf4-4fcd-b28c-931ff9766bd4@github.com>
References: <cHn29BEI04IGDuRQxI4ghYpuiFWbEsCI-JUqcpzFHyg=.140fd1db-adf4-4fcd-b28c-931ff9766bd4@github.com>
Message-ID: <DO3L8p2F6GWxPprDyybex6US0o7rwxZtWot2MGKrU68=.e3fa0ce7-3cbd-4935-9df8-096e8e9a18e0@github.com>

On Mon, 9 Jan 2023 13:29:27 GMT, Ao Qi <aoqi at openjdk.org> 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 needs to wait until PR #104 is integrated (else the fix version will be wrong).

@johanvos can then comment on this. I will note that this backport is on my list of things that should be done to keep the native WebKit in sync with mainline.

-------------

PR: https://git.openjdk.org/jfx17u/pull/103

From thiago.sayao at gmail.com  Tue Jan 31 14:15:02 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 31 Jan 2023 11:15:02 -0300
Subject: Toolkit decorations experiment
Message-ID: <CAAP_wukxe+7o7Z1q5hkBq2-tAvGxgMett8K=NtnLw00Ek8Ky3g@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230131/938c2c7a/attachment.htm>

From kpk at openjdk.org  Tue Jan 31 14:46:05 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 31 Jan 2023 14:46:05 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not select
 index 0
Message-ID: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>

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

-------------

Commit messages:
 - TableView row selection issue fix

Changes: https://git.openjdk.org/jfx/pull/1018/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1018&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8138842
  Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 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 jvos at openjdk.org  Tue Jan 31 14:58:29 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 31 Jan 2023 14:58:29 GMT
Subject: [jfx17u] Integrated: 8301011: Change JavaFX release version to 17.0.7
 in jfx17u
In-Reply-To: <MScmIXh9k6Ukkx9VmQQq96Z9UYeK4Bf8XxTwAiErqjQ=.df642db4-b106-4214-bf68-09b4d2c7b9ab@github.com>
References: <MScmIXh9k6Ukkx9VmQQq96Z9UYeK4Bf8XxTwAiErqjQ=.df642db4-b106-4214-bf68-09b4d2c7b9ab@github.com>
Message-ID: <6VmpW5d6HupB_P0UNoSvZ8lwh2O-n6OOOC2rvCV-jJ4=.6af66000-482f-4f95-a62d-5dde7ae9998e@github.com>

On Thu, 26 Jan 2023 15:25:32 GMT, Johan Vos <jvos at openjdk.org> wrote:

> increase release version in build.properties and jcheck configuration
> Fix for JDK-8301011

This pull request has now been integrated.

Changeset: 27fac395
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/27fac39560bd146cce90fbe3f83b50066698bc7e
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8301011: Change JavaFX release version to 17.0.7 in jfx17u

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx17u/pull/104

From jvos at openjdk.org  Tue Jan 31 15:01:41 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 31 Jan 2023 15:01:41 GMT
Subject: [jfx11u] Integrated: 8301010: Change JavaFX release version to 11.0.19
 in jfx11u
In-Reply-To: <d78OJLBvq_nbMmGrt0BC5kOWknfRi4VW_x4-q06mtMw=.8f7479ae-0690-4b97-84e9-826d73f7a6ef@github.com>
References: <d78OJLBvq_nbMmGrt0BC5kOWknfRi4VW_x4-q06mtMw=.8f7479ae-0690-4b97-84e9-826d73f7a6ef@github.com>
Message-ID: <zjtr5-cHfnE6i89T6k9Bj4KZnNlo5V_NM5vDoOv_B4U=.d74fa81a-3559-4d3a-98fe-c86cadd01ba5@github.com>

On Thu, 26 Jan 2023 15:31:52 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump release version to 11.0.19 in build.properties and .jcheck/conf
> Fix for JDK-8301010

This pull request has now been integrated.

Changeset: 6a31ceba
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/6a31ceba4a95bcc7766e396a6509a43e35c59392
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8301010: Change JavaFX release version to 11.0.19 in jfx11u

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx11u/pull/125

From dlemmermann at gmail.com  Tue Jan 31 15:12:54 2023
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Tue, 31 Jan 2023 16:12:54 +0100
Subject: Toolkit decorations experiment
In-Reply-To: <CAAP_wukxe+7o7Z1q5hkBq2-tAvGxgMett8K=NtnLw00Ek8Ky3g@mail.gmail.com>
References: <CAAP_wukxe+7o7Z1q5hkBq2-tAvGxgMett8K=NtnLw00Ek8Ky3g@mail.gmail.com>
Message-ID: <758B484D-8530-403D-919A-2395AD38C35F@gmail.com>

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.

> On 31 Jan 2023, at 15:15, Thiago Milczarek Say?o <thiago.sayao at gmail.com> wrote:
> 
> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230131/a7fd16a8/attachment.htm>

From angorya at openjdk.org  Tue Jan 31 16:00:37 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 16:00:37 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
Message-ID: <MZVH-CB0WEtwm08S4TbpW-Jr85y50EqJyrrZlLujLyQ=.a2fb18ce-6d17-499b-9e60-315d4db5f162@github.com>

On Tue, 31 Jan 2023 14:40:00 GMT, Karthik P K <kpk at openjdk.org> 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

I wonder if there are other places like this elsewhere in the code.
This change looks good.

-------------

Marked as reviewed by angorya (Committer).

PR: https://git.openjdk.org/jfx/pull/1018

From mstrauss at openjdk.org  Tue Jan 31 16:49:20 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 31 Jan 2023 16:49:20 GMT
Subject: RFR: 8281327: JavaFX does not support fonts installed per-user on
 Windows 10/11
In-Reply-To: <JLA7-CjKg2RAltYbebl-vXEJo2TW2ywG4qmlFGJd67U=.11e61a7d-07de-4a65-80a7-436be63e1439@github.com>
References: <JLA7-CjKg2RAltYbebl-vXEJo2TW2ywG4qmlFGJd67U=.11e61a7d-07de-4a65-80a7-436be63e1439@github.com>
Message-ID: <iHk6FHXsYDEk7GTSfIbsGOrHUFsTQ-vAn-0dGG9ujBc=.cd0096a6-7989-417c-8e39-23a9c49a9dc9@github.com>

On Tue, 31 Jan 2023 10:30:22 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR simply applies the patch from [JDK-8218914](https://bugs.openjdk.org/browse/JDK-8218914) that solved the same issue for the JDK.
> 
> I've tested it on Windows 11 (Version 22H2 Build 22621.1105). 
> 
> I have the Roboto font installed under C:\Users%user\AppData\Local\Microsoft\Windows\Fonts
> and with this PR, -Dprism.debugfonts shows:
> 
> 
> ...
> font=segoe ui historic file=seguihis.ttf
> font=roboto file=C:\Users%user\AppData\Local\Microsoft\Windows\Fonts\Roboto-Regular.ttf
> font=yu mincho file=yumin.ttf
> ...
> 
> 
> Also, I can see that the font is picked in a simple JavaFX application.
> Without this PR, the font is not used, and defaults to a system one. 
> 
> I don't think I can add this as a system/manual test to the PR, though.

modules/javafx.graphics/src/main/native-font/fontpath.c line 572:

> 570:     if (ret != ERROR_SUCCESS ||
> 571:         dwMaxValueNameLen >= MAX_BUFFER ||
> 572:         dwMaxValueDataLen >= MAX_BUFFER) {

This implementation instantly fails if _any_ value or data exceeds `MAX_BUFFER`. Wouldn't it be better to only skip the values that are too large, instead of ignoring all values entirely?

Instead of using `RegQueryInfoKeyW`, the [documentation](https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regenumvaluew) suggests the following approach:

> To enumerate values, an application should initially call the RegEnumValue function with the dwIndex parameter set to zero. The application should then increment dwIndex and call the RegEnumValue function until there are no more values (until the function returns ERROR_NO_MORE_ITEMS).

-------------

PR: https://git.openjdk.org/jfx/pull/1017

From kcr at openjdk.org  Tue Jan 31 17:02:42 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 17:02:42 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes [v2]
In-Reply-To: <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>
Message-ID: <CsQCSiWjyPI0ZTlXT5zvW8UV7gIbAzq31GqIkq29qmY=.8d233752-ab88-4ea0-b183-d8982f1abd22@github.com>

On Fri, 13 Jan 2023 04:04:54 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When a scene graph contains multiple nested focused nodes (this can happen with `TableView` and other controls), the `focusWithin` bits that are cleared when a focused node is de-focused must only be cleared when there is no other nested node in the scene graph that would also cause `focusWithin` to be set.
>> 
>> For example, consider a scene graph of nested nodes:
>> A -> B -> C -> D
>> 
>> When B and D are both focused, the scene graph looks like this:
>> A(`focusWithin`)
>> -> B(`focused`, `focusWithin`)
>> -> C(`focusWithin`)
>> -> D(`focused`, `focusWithin`)
>> 
>> When B is de-focused, the `focusWithin` flags must still be preserved because D remains focused.
>> 
>> This PR fixes the issue by counting the number of times `focusWithin` has been "set", and only clears it when it has been "un-set" an equal number of times.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactoring

Looks good. Approved for `jfx20`.

I left a couple questions, one of which might warrant a follow-up issue depending on your answer.

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8321:

> 8319:             count += change;
> 8320: 
> 8321:             if (count == 1) {

This presumes that you never call this with `change > 1`. You don't, so it seems fine.

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8325:

> 8323:             } else if (count == 0) {
> 8324:                 set(false);
> 8325:             }

Is it worth adding a check for `count < 0` and logging a warning (possibly treating it as if it were 0)? In theory, it shouldn't happen, but if it ever did, `focusWithin` would be wrong after that. This could be done as a P4 follow-up for 21, unless you are certain that it cannot ever happen.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/993

From nlisker at openjdk.org  Tue Jan 31 17:07:41 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 31 Jan 2023 17:07:41 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
Message-ID: <Z6ln5i3pVY-W9uH40Y6-IKggmIVUtfJOGi51itK0Pd0=.50d11b1d-f167-456c-86f2-baa6c3f74754@github.com>

On Tue, 31 Jan 2023 14:40:00 GMT, Karthik P K <kpk at openjdk.org> 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

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.

-------------

PR: https://git.openjdk.org/jfx/pull/1018

From mstrauss at openjdk.org  Tue Jan 31 17:14:20 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 31 Jan 2023 17:14:20 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes [v2]
In-Reply-To: <CsQCSiWjyPI0ZTlXT5zvW8UV7gIbAzq31GqIkq29qmY=.8d233752-ab88-4ea0-b183-d8982f1abd22@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>
 <CsQCSiWjyPI0ZTlXT5zvW8UV7gIbAzq31GqIkq29qmY=.8d233752-ab88-4ea0-b183-d8982f1abd22@github.com>
Message-ID: <37QKL1XGwMVLDFhzQ7AWBbKeI1QI9QES071sK1hI3ks=.d72150f5-8fa7-4667-914c-c363c358c99b@github.com>

On Tue, 31 Jan 2023 16:42:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactoring
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8325:
> 
>> 8323:             } else if (count == 0) {
>> 8324:                 set(false);
>> 8325:             }
> 
> Is it worth adding a check for `count < 0` and logging a warning (possibly treating it as if it were 0)? In theory, it shouldn't happen, but if it ever did, `focusWithin` would be wrong after that. This could be done as a P4 follow-up for 21, unless you are certain that it cannot ever happen.

On the one hand, this might make the code a little bit more robust, but on the other hand, it might hide a bug elsewhere. Surely `count` should never be negative. I lean slightly towards not protecting code against bugs in this way, mostly because it might expose potential bugs sooner.

If we want to validate that this method is not called with an incorrect argument, maybe just throwing an exception would be better.

-------------

PR: https://git.openjdk.org/jfx/pull/993

From mstrauss at openjdk.org  Tue Jan 31 17:14:22 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 31 Jan 2023 17:14:22 GMT
Subject: [jfx20] Integrated: 8300013: Node.focusWithin doesn't account for
 nested focused nodes
In-Reply-To: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
Message-ID: <nq7zXoIrgcsuTEVycae6OhbguVjp4Y4yhzu9Ec2SS24=.9141cea9-7074-4aab-b1b3-11ad09454fde@github.com>

On Thu, 12 Jan 2023 03:08:30 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a scene graph contains multiple nested focused nodes (this can happen with `TableView` and other controls), the `focusWithin` bits that are cleared when a focused node is de-focused must only be cleared when there is no other nested node in the scene graph that would also cause `focusWithin` to be set.
> 
> For example, consider a scene graph of nested nodes:
> A -> B -> C -> D
> 
> When B and D are both focused, the scene graph looks like this:
> A(`focusWithin`)
> -> B(`focused`, `focusWithin`)
> -> C(`focusWithin`)
> -> D(`focused`, `focusWithin`)
> 
> When B is de-focused, the `focusWithin` flags must still be preserved because D remains focused.
> 
> This PR fixes the issue by counting the number of times `focusWithin` has been "set", and only clears it when it has been "un-set" an equal number of times.

This pull request has now been integrated.

Changeset: a4bc9d1a
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a4bc9d1a69e56cab92d3dc34cfff49c5cb524443
Stats:     89 lines in 2 files changed: 73 ins; 0 del; 16 mod

8300013: Node.focusWithin doesn't account for nested focused nodes

Reviewed-by: aghaisas, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/993

From pedro.duquevieira at gmail.com  Tue Jan 31 17:14:28 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 31 Jan 2023 17:14:28 +0000
Subject: Style themes API
In-Reply-To: <CAJEpuXQ+wbJZtEaV4pcY65=XEXo7mTTWcs3VCYjGp2oe-=uJ_w@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
 <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
 <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>
 <CAJEpuXR6XMLByDPGTnZfa+7vuFaeVaZsL8BsOFj6vGYNr2_ong@mail.gmail.com>
 <CAAEud6b-Pa9pnFqFHG=12dy70XtKcUOGodCoJHNJ8uwk6QkeQw@mail.gmail.com>
 <CAJEpuXQ+wbJZtEaV4pcY65=XEXo7mTTWcs3VCYjGp2oe-=uJ_w@mail.gmail.com>
Message-ID: <CAAEud6ZLCDmR_KHijAMDJKSuPsinikTnt2tZFu8OK=kADVZi6w@mail.gmail.com>

Hi Michael,

Truly sorry for the late reply but haven't had time to reply sooner,
unfortunately..

2 -

> > I've been building javafx themes for years now. Started creating JMetro
> in JavaFX version 2. During this time I've been following how other themes
> are being built and I can say that about 90% of the themes (rough estimate)
> that are out there, are composed of author stylesheets, i.e they override
> values set from code (including JMetro).
> > I agree that themes that are to be provided to other developers would
> probably be better off if they are user agent stylesheets. My point is that
> migrating those 90% of themes to use this API would be easier if this flag
> exists otherwise migration would likely introduce UI regressions for
> developers using those themes.
> >
> > To be clear, what I'm proposing is a flag, or enum, or whatever, in
> StyleTheme that defines whether the stylesheets in the StyleTheme should be
> a user agent stylesheet or author stylesheet.
> >
> > Another point is in making themes that are only to be used locally in a
> specific app that the developer is creating. It might be of interest that
> he can toggle this flag and make all settings defined in the theme override
> any styling set from code (or in FXML) so that he can have a centralized
> point where all styling is done.


I think that the likelihood of this feature making it into the 21
> release dramatically increases if we keep changes to the CSS subsystem
> to an absolute minimum. I understand your point, but I want to deliver
> this feature in the smallest useful package and add more features
> later with follow-on PRs.


That's why I've renamed `Application.styleTheme` to
> `Application.userAgentStyleTheme`. This makes it unmistakably clear
> that we're only talking about user-agent stylesheets.
> Also, it leaves open the possibility to add the
> `Application.styleTheme` property later, which would cause the theme
> to be interpreted as comprised of author stylesheets.
> Classifying author/UA themes at the property level is also more
> consistent with the way author/UA stylesheets are currently classified
> in JavaFX.
> What do you think about the styleTheme/userAgentStyleTheme API,
> instead of having a flag in the implementation of StyleTheme itself?


Since one of the objectives of the PR is to promote Caspian and Modena
> to first-class theme implementations, it makes sense to focus on UA
> themes first (since built-in themes are comprised of UA stylesheets).


OK.
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.


3 -
> Style themes are generally either defined as dark or light. i.e. you'll
very rarely have a theme that has some Windows with dark decorations and
others with light decorations. So I think it makes sense to have this as a
theme property.
> The ability to toggle decorations (light or dark) on an individual Window
is a good point you're making. Perhaps we should have a global definition
in the StyleTheme (whether the theme is light or dark) and a definition
that can be set per Window.
> If you set it on the StyleTheme then all Windows will respect it, but you
can override that value on each Window. If you override it on a specific
Window, that definition would take precedence over the global StyleTheme
one.

In general, StyleTheme is a very simple concept: it's a dynamic
> collection of stylesheets.
> I don't think the interface should force implementers to deal with
> anything other than stylesheets. If we did that, the following code
> wouldn't work any more:


    Application.setUserAgentStyleTheme(
>         () -> List.of("stylesheet1.css", "stylesheet2.css");


Maybe we can add a new interface, for example DarkModeAware, and if an
> application theme is marked with this interface, JavaFX will try to
> respect dark/light mode for platform decorations:


    public class MyCustomTheme implements StyleTheme, DarkModeAware {
>         @Override
>         public List<String> getStylesheets() {
>             return List.of("stylesheet1.css", "stylesheet2.css");
>         }
>     }


    // Setting a DarkModeAware theme causes JavaFX to draw light or
>     // dark platform decorations by default, depending on the current
>     // platform preference. If the theme is not DarkModeAware, JavaFX
>     // defaults to light decorations.
>     //
>     Application.setUserAgentStyleTheme(new MyCustomTheme());


In any case, I think we can deliver this feature in a follow-on PR.


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.

Thanks again,









On Sun, Jan 22, 2023 at 12:51 AM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> Hi Pedro,
>
> see my comments below.
>
>
> On Sat, Jan 21, 2023 at 5:19 PM Pedro Duque Vieira
> <pedro.duquevieira at gmail.com> wrote:
> > I've been building javafx themes for years now. Started creating JMetro
> in JavaFX version 2. During this time I've been following how other themes
> are being built and I can say that about 90% of the themes (rough estimate)
> that are out there, are composed of author stylesheets, i.e they override
> values set from code (including JMetro).
> > I agree that themes that are to be provided to other developers would
> probably be better off if they are user agent stylesheets. My point is that
> migrating those 90% of themes to use this API would be easier if this flag
> exists otherwise migration would likely introduce UI regressions for
> developers using those themes.
> >
> > To be clear, what I'm proposing is a flag, or enum, or whatever, in
> StyleTheme that defines whether the stylesheets in the StyleTheme should be
> a user agent stylesheet or author stylesheet.
> >
> > Another point is in making themes that are only to be used locally in a
> specific app that the developer is creating. It might be of interest that
> he can toggle this flag and make all settings defined in the theme override
> any styling set from code (or in FXML) so that he can have a centralized
> point where all styling is done.
>
> I think that the likelihood of this feature making it into the 21
> release dramatically increases if we keep changes to the CSS subsystem
> to an absolute minimum. I understand your point, but I want to deliver
> this feature in the smallest useful package and add more features
> later with follow-on PRs.
>
> That's why I've renamed `Application.styleTheme` to
> `Application.userAgentStyleTheme`. This makes it unmistakably clear
> that we're only talking about user-agent stylesheets.
> Also, it leaves open the possibility to add the
> `Application.styleTheme` property later, which would cause the theme
> to be interpreted as comprised of author stylesheets.
> Classifying author/UA themes at the property level is also more
> consistent with the way author/UA stylesheets are currently classified
> in JavaFX.
> What do you think about the styleTheme/userAgentStyleTheme API,
> instead of having a flag in the implementation of StyleTheme itself?
>
> Since one of the objectives of the PR is to promote Caspian and Modena
> to first-class theme implementations, it makes sense to focus on UA
> themes first (since built-in themes are comprised of UA stylesheets).
>
>
>
> > 3 -
> > Style themes are generally either defined as dark or light. i.e. you'll
> very rarely have a theme that has some Windows with dark decorations and
> others with light decorations. So I think it makes sense to have this as a
> theme property.
> > The ability to toggle decorations (light or dark) on an individual
> Window is a good point you're making. Perhaps we should have a global
> definition in the StyleTheme (whether the theme is light or dark) and a
> definition that can be set per Window.
> > If you set it on the StyleTheme then all Windows will respect it, but
> you can override that value on each Window. If you override it on a
> specific Window, that definition would take precedence over the global
> StyleTheme one.
>
> In general, StyleTheme is a very simple concept: it's a dynamic
> collection of stylesheets.
> I don't think the interface should force implementers to deal with
> anything other than stylesheets. If we did that, the following code
> wouldn't work any more:
>
>     Application.setUserAgentStyleTheme(
>         () -> List.of("stylesheet1.css", "stylesheet2.css");
>
> Maybe we can add a new interface, for example DarkModeAware, and if an
> application theme is marked with this interface, JavaFX will try to
> respect dark/light mode for platform decorations:
>
>     public class MyCustomTheme implements StyleTheme, DarkModeAware {
>         @Override
>         public List<String> getStylesheets() {
>             return List.of("stylesheet1.css", "stylesheet2.css");
>         }
>     }
>
>     // Setting a DarkModeAware theme causes JavaFX to draw light or
>     // dark platform decorations by default, depending on the current
>     // platform preference. If the theme is not DarkModeAware, JavaFX
>     // defaults to light decorations.
>     //
>     Application.setUserAgentStyleTheme(new MyCustomTheme());
>
> In any case, I think we can deliver this feature in a follow-on PR.
>
>
> > 4-
> >>
> >> If we wanted to expose this front-and-center, we could add these
> >>
> >> properties to the Platform.Properties interface:
> >
> >
> >>     public interface Preferences extends ObservableMap<String, Object> {
> >>         ReadOnlyBooleanProperty darkModeProperty();
> >>         ReadOnlyObjectProperty<Color> accentColorProperty();
> >>         ...
> >>     }
> >
> >
> > Yes, I think that would be great.
>
> Let's see what other people think.
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230131/1dc08b84/attachment-0001.htm>

From mstrauss at openjdk.org  Tue Jan 31 17:35:25 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 31 Jan 2023 17:35:25 GMT
Subject: [jfx20] RFR: 8300013: Node.focusWithin doesn't account for nested
 focused nodes [v2]
In-Reply-To: <37QKL1XGwMVLDFhzQ7AWBbKeI1QI9QES071sK1hI3ks=.d72150f5-8fa7-4667-914c-c363c358c99b@github.com>
References: <2RwzafQlugICtRa4iDEJH3aqigWQ11Ce6tKP8dpRTYk=.a8581604-fb8b-44d9-ada0-28814d6c2c05@github.com>
 <NXDtArPGcPTevtVz97bjNuCrzcXDhg1k2m_kajNULho=.54e0ff1d-a99d-4b03-b074-ecc16457e426@github.com>
 <CsQCSiWjyPI0ZTlXT5zvW8UV7gIbAzq31GqIkq29qmY=.8d233752-ab88-4ea0-b183-d8982f1abd22@github.com>
 <37QKL1XGwMVLDFhzQ7AWBbKeI1QI9QES071sK1hI3ks=.d72150f5-8fa7-4667-914c-c363c358c99b@github.com>
Message-ID: <0c5S8Bbh2lc0drm3HSs-7sXzKM01N_AiPcHdGqiaPUw=.a3d06bbd-165f-43c4-a5a7-12497087aa96@github.com>

On Tue, 31 Jan 2023 17:08:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8325:
>> 
>>> 8323:             } else if (count == 0) {
>>> 8324:                 set(false);
>>> 8325:             }
>> 
>> Is it worth adding a check for `count < 0` and logging a warning (possibly treating it as if it were 0)? In theory, it shouldn't happen, but if it ever did, `focusWithin` would be wrong after that. This could be done as a P4 follow-up for 21, unless you are certain that it cannot ever happen.
>
> On the one hand, this might make the code a little bit more robust, but on the other hand, it might hide a bug elsewhere. Surely `count` should never be negative. I lean slightly towards not protecting code against bugs in this way, mostly because it might expose potential bugs sooner.
> 
> If we want to validate that this method is not called with an incorrect argument, maybe just throwing an exception would be better.

I've created a ticket to investigate this: https://bugs.openjdk.org/browse/JDK-8301556

-------------

PR: https://git.openjdk.org/jfx/pull/993

From jpereda at openjdk.org  Tue Jan 31 17:40:50 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 31 Jan 2023 17:40:50 GMT
Subject: RFR: 8281327: JavaFX does not support fonts installed per-user on
 Windows 10/11
In-Reply-To: <iHk6FHXsYDEk7GTSfIbsGOrHUFsTQ-vAn-0dGG9ujBc=.cd0096a6-7989-417c-8e39-23a9c49a9dc9@github.com>
References: <JLA7-CjKg2RAltYbebl-vXEJo2TW2ywG4qmlFGJd67U=.11e61a7d-07de-4a65-80a7-436be63e1439@github.com>
 <iHk6FHXsYDEk7GTSfIbsGOrHUFsTQ-vAn-0dGG9ujBc=.cd0096a6-7989-417c-8e39-23a9c49a9dc9@github.com>
Message-ID: <xkQHsJD_Cg0jrAbRojlIyq4SaRlAaxDzayOT8eH6iqQ=.4f0538d5-986d-4e47-86bb-759565c5f999@github.com>

On Tue, 31 Jan 2023 16:47:01 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR simply applies the patch from [JDK-8218914](https://bugs.openjdk.org/browse/JDK-8218914) that solved the same issue for the JDK.
>> 
>> I've tested it on Windows 11 (Version 22H2 Build 22621.1105). 
>> 
>> I have the Roboto font installed under C:\Users%user\AppData\Local\Microsoft\Windows\Fonts
>> and with this PR, -Dprism.debugfonts shows:
>> 
>> 
>> ...
>> font=segoe ui historic file=seguihis.ttf
>> font=roboto file=C:\Users%user\AppData\Local\Microsoft\Windows\Fonts\Roboto-Regular.ttf
>> font=yu mincho file=yumin.ttf
>> ...
>> 
>> 
>> Also, I can see that the font is picked in a simple JavaFX application.
>> Without this PR, the font is not used, and defaults to a system one. 
>> 
>> I don't think I can add this as a system/manual test to the PR, though.
>
> modules/javafx.graphics/src/main/native-font/fontpath.c line 572:
> 
>> 570:     if (ret != ERROR_SUCCESS ||
>> 571:         dwMaxValueNameLen >= MAX_BUFFER ||
>> 572:         dwMaxValueDataLen >= MAX_BUFFER) {
> 
> This implementation instantly fails if _any_ value or data exceeds `MAX_BUFFER`. Wouldn't it be better to only skip the values that are too large, instead of ignoring all values entirely?
> 
> Instead of using `RegQueryInfoKeyW`, the [documentation](https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regenumvaluew) suggests the following approach:
> 
>> To enumerate values, an application should initially call the RegEnumValue function with the dwIndex parameter set to zero. The application should then increment dwIndex and call the RegEnumValue function until there are no more values (until the function returns ERROR_NO_MORE_ITEMS).

Please note that this is just a refactoring of the existing code, extracting a method so that it can be called twice, and it is also what the JDK is doing. 
If the affected code needs changes, maybe that is for a follow up.

-------------

PR: https://git.openjdk.org/jfx/pull/1017

From kcr at openjdk.org  Tue Jan 31 18:20:28 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 18:20:28 GMT
Subject: RFR: 8088998: LineChart: duplicate child added exception when
 remove & add a series
In-Reply-To: <F6dRBNVcmUf-pL3RM4QnWhCYbZTpJbjk2BqqS7ocBhA=.3176c352-88a1-43c8-8a26-d12941f60c6e@github.com>
References: <F6dRBNVcmUf-pL3RM4QnWhCYbZTpJbjk2BqqS7ocBhA=.3176c352-88a1-43c8-8a26-d12941f60c6e@github.com>
Message-ID: <_U2wBpOMTI794iIyHSWtU3RVyqIb473rMGorWAXyUCo=.30763b0e-c8a7-4e14-bff1-63c867e180ee@github.com>

On Mon, 30 Jan 2023 12:21:38 GMT, Karthik P K <kpk at openjdk.org> 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.

Reviewers: @aghaisas @andy-goryachev-oracle

-------------

PR: https://git.openjdk.org/jfx/pull/1015

From kcr at openjdk.org  Tue Jan 31 18:22:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 18:22:58 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository
In-Reply-To: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
Message-ID: <1Zuhx1POpw-Litlg8LjiyoghThmnsznMc-1n2m31wqQ=.6af58850-bd6e-4409-9acb-ef2a928c5e8e@github.com>

On Mon, 23 Jan 2023 23:55:51 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> 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.

This touches `build.gradle` and `settings.gradle` in addition to IDE-specific files. Those changes will need additional review, so I'm requesting two reviewers.

-------------

PR: https://git.openjdk.org/jfx/pull/1009

From kcr at openjdk.org  Tue Jan 31 18:27:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 18:27:11 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
Message-ID: <756L5GE5W5ks0V1wJ674SJRXha0Y16UxMfltgAtzP4w=.17efaa77-599f-4e1e-8e4d-690f7dfa273b@github.com>

On Sun, 29 Jan 2023 17:10:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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<String, Object> {
>>     // Platform-independent API
>>     ReadOnlyObjectProperty<Appearance> appearanceProperty();
>>     ReadOnlyObjectProperty<Color> backgroundColorProperty();
>>     ReadOnlyObjectProperty<Color> foregroundColorProperty();
>>     ReadOnlyObjectProperty<Color> accentColorProperty();
>> 
>>     // Convenience methods to retrieve platform-specific values from the map
>>     Optional<Integer> getInteger(String key);
>>     Optional<Double> getDouble(String key);
>>     Optional<String> getString(String key);
>>     Optional<Boolean> getBoolean(String key);
>>     Optional<Color> 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 incrementally with one additional commit since the last revision:
> 
>   Use Optional for convenience methods in Preferences

It is premature to review this, since we have not had a discussion of whether we want such an API in the core of JavaFX. I am moving it back to Draft.

When/if it is ready to be reviewed it will need a CSR.

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From kcr at openjdk.org  Tue Jan 31 18:51:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 18:51:06 GMT
Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader
In-Reply-To: <YoT9AvHykiwbYH-Vg2flUBX_6N4KLvreaaegMfYIhOs=.8f8fcf90-6538-44fb-ba87-ba2d26d990da@github.com>
References: <YoT9AvHykiwbYH-Vg2flUBX_6N4KLvreaaegMfYIhOs=.8f8fcf90-6538-44fb-ba87-ba2d26d990da@github.com>
Message-ID: <IGiyFf1HxbqNHMZAE2ANr7vLYrqhCaO66iqDXf-p31c=.0b9380b0-6789-48a9-bca0-0973a02ef480@github.com>

On Mon, 30 Jan 2023 21:56:45 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Change the underlying class XYChart to take into account labels for axes. Make label patterns and default axes labels localized.

Can you provide an evaluation of the bug and a description of the fix?

-------------

PR: https://git.openjdk.org/jfx/pull/1016

From sykora at openjdk.org  Tue Jan 31 18:52:01 2023
From: sykora at openjdk.org (Joeri Sykora)
Date: Tue, 31 Jan 2023 18:52:01 GMT
Subject: RFR: JDK-8299977 : Update WebKit to 615.1 [v2]
In-Reply-To: <F5CTDXFX-944wWhXNaxZf-Jdt2oKf-YIn9w2H_Ns7Bg=.c9c99b61-6a48-4aca-87e0-0f4a832cc7ae@github.com>
References: <dVUwGgkTPDsJkV2zT40nNXiIf6fE33b-SDsCvyqmHAc=.586a17a1-f595-4c47-9bf3-d2166bd51c30@github.com>
 <F5CTDXFX-944wWhXNaxZf-Jdt2oKf-YIn9w2H_Ns7Bg=.c9c99b61-6a48-4aca-87e0-0f4a832cc7ae@github.com>
Message-ID: <p9QCbCJGMbTR0g2TkO3ZD32CDX2EB4kkmjf5vkSh6Eo=.f2e5b355-8662-4299-86ad-6d9e139a7afe@github.com>

On Mon, 30 Jan 2023 15:11:20 GMT, Hima Bindu Meda <hmeda at openjdk.org> 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:
> 
>   Add blank lines

Building and testing succeeded on linux, mac and windows x86_64.

-------------

Marked as reviewed by sykora (Author).

PR: https://git.openjdk.org/jfx/pull/1011

From kcr at openjdk.org  Tue Jan 31 19:01:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 31 Jan 2023 19:01:33 GMT
Subject: RFR: 8251862: Wrong position of Popup windows at the intersection
 of 2 screens [v4]
In-Reply-To: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
References: <HY7hNVkiXg0QR1pLWYAUgmhbiNn8wyF5jgjVBks0yG8=.5b175bd0-0eda-477e-a901-e40e4c8acfd1@github.com>
Message-ID: <BbReMECV2ArRAuIqa8WXC99Vtq4pU7pBM8FbQKbVgeE=.c8e87896-302a-4389-bf34-1ad86c9be15e@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/971/files
  - new: https://git.openjdk.org/jfx/pull/971/files/4d08c853..d256762b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=971&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=971&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/971.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/971/head:pull/971

PR: https://git.openjdk.org/jfx/pull/971

From jhendrikx at openjdk.org  Tue Jan 31 19:35:00 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 31 Jan 2023 19:35:00 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
Message-ID: <Oy_qT0kYYHi7InpjFapbPTGKYVHsiW-z-PMKEYncd8g=.588975f3-1ef1-4436-83c9-629eac9cc213@github.com>

On Tue, 31 Jan 2023 14:40:00 GMT, Karthik P K <kpk at openjdk.org> 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

Change looks good, I just feel we shouldn't be catering to `null` here at all.

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 2645:

> 2643: 
> 2644:         @Override public void selectIndices(int row, int... rows) {
> 2645:             if (rows == null || rows.length == 0) {

To get `rows` to be `null` you'd have to call this method as: `selectIndices(2, null)` -- IMHO that should result in an exception, and not be accepted to be the same as `selectIndices(2)` or `selectIndices(2, new int[0])`.

I checked the documentation, and it does not mention that `null` is allowed here, which means it isn't.

Also: weird method signature, but I guess if you want to enforce at least one parameter it could be done this way.

-------------

Marked as reviewed by jhendrikx (Committer).

PR: https://git.openjdk.org/jfx/pull/1018

From angorya at openjdk.org  Tue Jan 31 19:39:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 19:39:00 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <Oy_qT0kYYHi7InpjFapbPTGKYVHsiW-z-PMKEYncd8g=.588975f3-1ef1-4436-83c9-629eac9cc213@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
 <Oy_qT0kYYHi7InpjFapbPTGKYVHsiW-z-PMKEYncd8g=.588975f3-1ef1-4436-83c9-629eac9cc213@github.com>
Message-ID: <ZatsOq-ApSTWIr22AXBtwS91-pfNPsJVPou-TrclNRE=.177780a9-b89c-4b3b-a7f3-f4bb4d091c28@github.com>

On Tue, 31 Jan 2023 19:31:46 GMT, John Hendrikx <jhendrikx at openjdk.org> 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
>
> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 2645:
> 
>> 2643: 
>> 2644:         @Override public void selectIndices(int row, int... rows) {
>> 2645:             if (rows == null || rows.length == 0) {
> 
> To get `rows` to be `null` you'd have to call this method as: `selectIndices(2, null)` -- IMHO that should result in an exception, and not be accepted to be the same as `selectIndices(2)` or `selectIndices(2, new int[0])`.
> 
> I checked the documentation, and it does not mention that `null` is allowed here, which means it isn't.
> 
> Also: weird method signature, but I guess if you want to enforce at least one parameter it could be done this way.

I had the same thought here.
The signature is indeed weird, but since it is perfectly legal to invoke it with selectIndices(0, null), I think this change is absolutely correct.

-------------

PR: https://git.openjdk.org/jfx/pull/1018

From jhendrikx at openjdk.org  Tue Jan 31 19:44:01 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 31 Jan 2023 19:44:01 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <ZatsOq-ApSTWIr22AXBtwS91-pfNPsJVPou-TrclNRE=.177780a9-b89c-4b3b-a7f3-f4bb4d091c28@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
 <Oy_qT0kYYHi7InpjFapbPTGKYVHsiW-z-PMKEYncd8g=.588975f3-1ef1-4436-83c9-629eac9cc213@github.com>
 <ZatsOq-ApSTWIr22AXBtwS91-pfNPsJVPou-TrclNRE=.177780a9-b89c-4b3b-a7f3-f4bb4d091c28@github.com>
Message-ID: <Gm2s3anp_Jotj7hduWj9hZwtmFrGQfCf2zV5jId1ri4=.5c10ecb3-2f89-4d9d-b17f-9be599525b1c@github.com>

On Tue, 31 Jan 2023 19:36:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 2645:
>> 
>>> 2643: 
>>> 2644:         @Override public void selectIndices(int row, int... rows) {
>>> 2645:             if (rows == null || rows.length == 0) {
>> 
>> To get `rows` to be `null` you'd have to call this method as: `selectIndices(2, null)` -- IMHO that should result in an exception, and not be accepted to be the same as `selectIndices(2)` or `selectIndices(2, new int[0])`.
>> 
>> I checked the documentation, and it does not mention that `null` is allowed here, which means it isn't.
>> 
>> Also: weird method signature, but I guess if you want to enforce at least one parameter it could be done this way.
>
> I had the same thought here.
> The signature is indeed weird, but since it is perfectly legal to invoke it with selectIndices(0, null), I think this change is absolutely correct.

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:

    /**
     * <p>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.
     *
     * <p>If there is already one or more indices selected in this model, calling
     * this method will <b>not</b> clear these selections - to do so it is
     * necessary to first call clearSelection.
     *
     * <p>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);

-------------

PR: https://git.openjdk.org/jfx/pull/1018

From jhendrikx at openjdk.org  Tue Jan 31 19:44:02 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 31 Jan 2023 19:44:02 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <Gm2s3anp_Jotj7hduWj9hZwtmFrGQfCf2zV5jId1ri4=.5c10ecb3-2f89-4d9d-b17f-9be599525b1c@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
 <Oy_qT0kYYHi7InpjFapbPTGKYVHsiW-z-PMKEYncd8g=.588975f3-1ef1-4436-83c9-629eac9cc213@github.com>
 <ZatsOq-ApSTWIr22AXBtwS91-pfNPsJVPou-TrclNRE=.177780a9-b89c-4b3b-a7f3-f4bb4d091c28@github.com>
 <Gm2s3anp_Jotj7hduWj9hZwtmFrGQfCf2zV5jId1ri4=.5c10ecb3-2f89-4d9d-b17f-9be599525b1c@github.com>
Message-ID: <pJnNC6B0o7zrDf1kYs_cOY1DbvNISC8bqqWAQtHTv1I=.a9466156-1b4e-43c5-9e42-cbe32c7f1456@github.com>

On Tue, 31 Jan 2023 19:40:06 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I had the same thought here.
>> The signature is indeed weird, but since it is perfectly legal to invoke it with selectIndices(0, null), I think this change is absolutely correct.
>
> 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:
> 
>     /**
>      * <p>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.
>      *
>      * <p>If there is already one or more indices selected in this model, calling
>      * this method will <b>not</b> clear these selections - to do so it is
>      * necessary to first call clearSelection.
>      *
>      * <p>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.

-------------

PR: https://git.openjdk.org/jfx/pull/1018

From kizune at openjdk.org  Tue Jan 31 19:54:58 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 31 Jan 2023 19:54:58 GMT
Subject: RFR: 8298382: JavaFX ChartArea Accessibility Reader
In-Reply-To: <IGiyFf1HxbqNHMZAE2ANr7vLYrqhCaO66iqDXf-p31c=.0b9380b0-6789-48a9-bca0-0973a02ef480@github.com>
References: <YoT9AvHykiwbYH-Vg2flUBX_6N4KLvreaaegMfYIhOs=.8f8fcf90-6538-44fb-ba87-ba2d26d990da@github.com>
 <IGiyFf1HxbqNHMZAE2ANr7vLYrqhCaO66iqDXf-p31c=.0b9380b0-6789-48a9-bca0-0973a02ef480@github.com>
Message-ID: <dv0L3NuVRoH3FM5I2bBRyzSey96fJRVPPXpS5-mt3g8=.236bcd8b-1312-4994-ada6-0c7b5fc110dd@github.com>

On Tue, 31 Jan 2023 18:48:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Can you provide an evaluation of the bug and a description of the fix?

Done.

-------------

PR: https://git.openjdk.org/jfx/pull/1016

From michaelstrau2 at gmail.com  Tue Jan 31 20:02:52 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 31 Jan 2023 21:02:52 +0100
Subject: Style themes update
In-Reply-To: <CAJEpuXTG-ASsYr+46-MYAO-9BsCYbFrGyWZZtLSoQO93Uvkmkg@mail.gmail.com>
References: <CAJEpuXTG-ASsYr+46-MYAO-9BsCYbFrGyWZZtLSoQO93Uvkmkg@mail.gmail.com>
Message-ID: <CAJEpuXRchEj-U6h97XFanAH-zOkKeY-Aov6SRiK+3Q3fd2ra6w@mail.gmail.com>

I've created a Gist with the updated proposal, this seems easier than
sending around large amounts of text for every change:

https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548

From angorya at openjdk.org  Tue Jan 31 20:03:04 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 20:03:04 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
Message-ID: <VY2dNUx9cpD1BjbkBEKfJHHNO6Omzcrv9C_tJQSYwHw=.4bbb4261-d768-4ecd-b7d2-14dd0aabd28f@github.com>

On Sun, 29 Jan 2023 17:10:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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<String, Object> {
>>     // Platform-independent API
>>     ReadOnlyObjectProperty<Appearance> appearanceProperty();
>>     ReadOnlyObjectProperty<Color> backgroundColorProperty();
>>     ReadOnlyObjectProperty<Color> foregroundColorProperty();
>>     ReadOnlyObjectProperty<Color> accentColorProperty();
>> 
>>     // Convenience methods to retrieve platform-specific values from the map
>>     Optional<Integer> getInteger(String key);
>>     Optional<Double> getDouble(String key);
>>     Optional<String> getString(String key);
>>     Optional<Boolean> getBoolean(String key);
>>     Optional<Color> 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 incrementally with one additional commit since the last revision:
> 
>   Use Optional for convenience methods in Preferences

In the context of adding theme support in javafx, I think this PR is a step in the right direction.  I also like a small set of platform-independent properties like fg and bg colors.  I wonder if the same approach can be extended for other aspects of platform L&F, like fonts, spacing, and may be other aspects (like, hiding scrollbars setting on Mac?)

I agree with @kevinrushforth - we'd need more discussion on the actual implementation.  There are a few items that I feel are unnecessary, or might be done differently, and I'd like to learn what other people think.

Specifically:

1. Appearance enum seems unnecessary - there might be more choices in a specific platform (Mac Ventura has three: dark/light/auto).  Perhaps using fg/bg color intensity is sufficient to find out whether the overall theme is "dark" or "light".
2. ObservableMap.  Similarly to Node.getProperties(), I wonder if there might be a better way to observe the changes.  May be a different metaphor (subscription?), like adding a value change listener to a specific key.  We do need a set of keys (perhaps that can be an ObservableSet).  Having said that, ObservableMap is good enough solution, and forgive me for stating the obvious, it should not initialize anything if the platform properties have not been requested by the application code.

What do you think?

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From nlisker at openjdk.org  Tue Jan 31 20:06:03 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 31 Jan 2023 20:06:03 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
Message-ID: <1QDc4gjGOft_nbc2VA4-9MUCbFlZcwkIKHs1WVgD62w=.e9047fa2-8609-4db1-9fc6-58d7cec867de@github.com>

On Tue, 31 Jan 2023 14:40:00 GMT, Karthik P K <kpk at openjdk.org> 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

`TreeTableView` has the same problem.

-------------

PR: https://git.openjdk.org/jfx/pull/1018

From mstrauss at openjdk.org  Tue Jan 31 20:20:59 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 31 Jan 2023 20:20:59 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <VY2dNUx9cpD1BjbkBEKfJHHNO6Omzcrv9C_tJQSYwHw=.4bbb4261-d768-4ecd-b7d2-14dd0aabd28f@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
 <VY2dNUx9cpD1BjbkBEKfJHHNO6Omzcrv9C_tJQSYwHw=.4bbb4261-d768-4ecd-b7d2-14dd0aabd28f@github.com>
Message-ID: <BxVOgi4upJBrXlVsimpNPjpgmJTWcEYR09VobiErFxo=.7a093e75-5dd9-4133-a7fa-43dd51abb699@github.com>

On Tue, 31 Jan 2023 20:00:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> In the context of adding theme support in javafx, I think this PR is a step in the right direction. I also like a small set of platform-independent properties like fg and bg colors. I wonder if the same approach can be extended for other aspects of platform L&F, like fonts, spacing, and may be other aspects (like, hiding scrollbars setting on Mac?)

That could indeed be a useful enhancement.

> 1. Appearance enum seems unnecessary - there might be more choices in a specific platform (Mac Ventura has three: dark/light/auto).  Perhaps using fg/bg color intensity is sufficient to find out whether the overall theme is "dark" or "light".

While dark/light mode can indeed be detected just by comparing foreground and background color, the reason for the `Appearance` enumeration and the `Preferences.appearance` property is to support dark window frames. In [this gist](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) (see "Stage appearance"), I've described how the stage appearance and platform appearance APIs interact.

> 2. ObservableMap.  Similarly to Node.getProperties(), I wonder if there might be a better way to observe the changes.  May be a different metaphor (subscription?), like adding a value change listener to a specific key.  We do need a set of keys (perhaps that can be an ObservableSet).  Having said that, ObservableMap is good enough solution, and forgive me for stating the obvious, it should not initialize anything if the platform properties have not been requested by the application code.

The use of `ObservableMap` is debatable.
I think that always initializing platform properties makes it easier to reason about the code. Saving the allocation of just a single map with 20-or-so key-value pairs is not a convincing reason to complicate the implementation, especially since most of the platform preferences implementation lives in the Glass toolkit, and not in the user-facing framework.

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From angorya at openjdk.org  Tue Jan 31 20:40:01 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 20:40:01 GMT
Subject: RFR: 8138842: TableViewSelectionModel.selectIndices does not
 select index 0
In-Reply-To: <1QDc4gjGOft_nbc2VA4-9MUCbFlZcwkIKHs1WVgD62w=.e9047fa2-8609-4db1-9fc6-58d7cec867de@github.com>
References: <EKnqHgeJj-iDRhJWfi6MVFT3T8rWEgcySTgvF3uMtS8=.dc7893a7-c3f6-41cc-bd61-10e4861084dc@github.com>
 <1QDc4gjGOft_nbc2VA4-9MUCbFlZcwkIKHs1WVgD62w=.e9047fa2-8609-4db1-9fc6-58d7cec867de@github.com>
Message-ID: <C3QCuXGt40arDU_ylT853iQYfFxLCiZ1r9rKy5HpU7U=.e4a63cb3-dcb8-44b5-a387-4cee0c7c7c67@github.com>

On Tue, 31 Jan 2023 20:03:19 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> TreeTableView has the same problem.

good point!  could we apply a similar change to TreeTableView:3012?

-------------

PR: https://git.openjdk.org/jfx/pull/1018

From swpalmer at openjdk.org  Tue Jan 31 23:09:58 2023
From: swpalmer at openjdk.org (Scott Palmer)
Date: Tue, 31 Jan 2023 23:09:58 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
Message-ID: <r8w_0keOj_J56w5q2wlLG-M3e58w5JyMkZn4KjZfGnI=.841bbf78-0a01-48a0-896b-138c1f447e16@github.com>

On Sun, 29 Jan 2023 17:10:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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<String, Object> {
>>     // Platform-independent API
>>     ReadOnlyObjectProperty<Appearance> appearanceProperty();
>>     ReadOnlyObjectProperty<Color> backgroundColorProperty();
>>     ReadOnlyObjectProperty<Color> foregroundColorProperty();
>>     ReadOnlyObjectProperty<Color> accentColorProperty();
>> 
>>     // Convenience methods to retrieve platform-specific values from the map
>>     Optional<Integer> getInteger(String key);
>>     Optional<Double> getDouble(String key);
>>     Optional<String> getString(String key);
>>     Optional<Boolean> getBoolean(String key);
>>     Optional<Color> 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 incrementally with one additional commit since the last revision:
> 
>   Use Optional for convenience methods in Preferences

On Tue, Jan 31, 2023 at 3:00 PM Andy Goryachev ***@***.***>
wrote:

> In the context of adding theme support in javafx, I think this PR is a
> step in the right direction. I also like a small set of
> platform-independent properties like fg and bg colors. I wonder if the same
> approach can be extended for other aspects of platform L&F, like fonts,
> spacing, and may be other aspects (like, hiding scrollbars setting on Mac?)
>
> I agree with @kevinrushforth <https://github.com/kevinrushforth> - we'd
> need more discussion on the actual implementation. There are a few items
> that I feel are unnecessary, or might be done differently, and I'd like to
> learn what other people think.
>
> Specifically:
>
>    1. Appearance enum seems unnecessary - there might be more choices in
>    a specific platform (Mac Ventura has three: dark/light/auto).
>
>
Is it necessary for any application to know about "auto"?  Presumably when
the mode automatically changes from one to the other there would be an
event that should be handled, just as if the user changed the setting while
the application was running.

Scott

> Message ID: ***@***.***>
>

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From angorya at openjdk.org  Tue Jan 31 23:10:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 23:10:00 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <BxVOgi4upJBrXlVsimpNPjpgmJTWcEYR09VobiErFxo=.7a093e75-5dd9-4133-a7fa-43dd51abb699@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
 <VY2dNUx9cpD1BjbkBEKfJHHNO6Omzcrv9C_tJQSYwHw=.4bbb4261-d768-4ecd-b7d2-14dd0aabd28f@github.com>
 <BxVOgi4upJBrXlVsimpNPjpgmJTWcEYR09VobiErFxo=.7a093e75-5dd9-4133-a7fa-43dd51abb699@github.com>
Message-ID: <AfzOcJfWUlSPJ6PovruwhwDXyARHi-MHgeNUYoUsnpY=.2a0fb45e-60e5-4891-8f59-50574f51c214@github.com>

On Tue, 31 Jan 2023 20:18:05 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> the reason for the Appearance enumeration and the Preferences.appearance property is to support dark window frames.

I think that, by default, the FX frame decorations should pick up the platform theme (dark, light, accent color, etc.).  It should be possible to override this behavior somehow - possibly by setting the base/accent color - but using an enum for this purpose feels unnecessary.


> Saving the allocation of just a single map with 20-or-so key-value pairs is not a convincing reason to complicate the implementation

It's not just allocation, but also listening to changes at run time.  For example, the user changing the theme from light to dark should, in my opinion, update any running FX application, unless otherwise is prescribed by the application requirements.



-andy






From: mstr2 ***@***.***>
Date: Tuesday, January 31, 2023 at 12:18
To: openjdk/jfx ***@***.***>
Cc: Andy Goryachev ***@***.***>, Comment ***@***.***>
Subject: [External] : Re: [openjdk/jfx] 8301302: Platform preferences API (PR #1014)

In the context of adding theme support in javafx, I think this PR is a step in the right direction. I also like a small set of platform-independent properties like fg and bg colors. I wonder if the same approach can be extended for other aspects of platform L&F, like fonts, spacing, and may be other aspects (like, hiding scrollbars setting on Mac?)

That could indeed be a useful enhancement.

  1.  Appearance enum seems unnecessary - there might be more choices in a specific platform (Mac Ventura has three: dark/light/auto). Perhaps using fg/bg color intensity is sufficient to find out whether the overall theme is "dark" or "light".

While dark/light mode can indeed be detected just by comparing foreground and background color, the reason for the Appearance enumeration and the Preferences.appearance property is to support dark window frames. In this gist<https://urldefense.com/v3/__https:/gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548__;!!ACWV5N9M2RV99hQ!IMBktwM52wz3rGVNfcYTrwhd0QKoYAK2MpRFZkhslCqpdNN8ca8ilF8yLnMfQBywAFpIZ-OirPQAk0US0ltRtKf2sbTJfA$> (see "Stage appearance"), I've described how the stage appearance and platform appearance APIs interact.

  1.  ObservableMap. Similarly to Node.getProperties(), I wonder if there might be a better way to observe the changes. May be a different metaphor (subscription?), like adding a value change listener to a specific key. We do need a set of keys (perhaps that can be an ObservableSet). Having said that, ObservableMap is good enough solution, and forgive me for stating the obvious, it should not initialize anything if the platform properties have not been requested by the application code.

The use of ObservableMap is debatable.
I think that always initializing platform properties makes it easier to reason about the code. Saving the allocation of just a single map with 20-or-so key-value pairs is not a convincing reason to complicate the implementation, especially since most of the platform preferences implementation lives in the Glass toolkit, and not in the user-facing framework.

?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1014*issuecomment-1411006332__;Iw!!ACWV5N9M2RV99hQ!IMBktwM52wz3rGVNfcYTrwhd0QKoYAK2MpRFZkhslCqpdNN8ca8ilF8yLnMfQBywAFpIZ-OirPQAk0US0ltRtKeGSZTOsg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AZQ34ZHDAK2M2JVQWMHVXNDWVFXQPANCNFSM6AAAAAAUJ6L3R4__;!!ACWV5N9M2RV99hQ!IMBktwM52wz3rGVNfcYTrwhd0QKoYAK2MpRFZkhslCqpdNN8ca8ilF8yLnMfQBywAFpIZ-OirPQAk0US0ltRtKf_uwcosw$>.
You are receiving this because you commented.Message ID: ***@***.***>

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From angorya at openjdk.org  Tue Jan 31 23:14:59 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 23:14:59 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <r8w_0keOj_J56w5q2wlLG-M3e58w5JyMkZn4KjZfGnI=.841bbf78-0a01-48a0-896b-138c1f447e16@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
 <r8w_0keOj_J56w5q2wlLG-M3e58w5JyMkZn4KjZfGnI=.841bbf78-0a01-48a0-896b-138c1f447e16@github.com>
Message-ID: <-NPcVeRBir4f1hTPZh1jEWbuhJHmYZflBBMnJ8Xrh-g=.e3b40288-87b1-4401-9541-4ca8dcdacd2f@github.com>

On Tue, 31 Jan 2023 23:04:50 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

> Is it necessary for any application to know about "auto"?

I actually don't know how the "auto" behaves.  From the description it seems the colors might actually change gradually throughout the day, thus making an enum useless and necessitating the use of the actual colors.

***@***.***

-andy




From: Scott Palmer ***@***.***>
Date: Tuesday, January 31, 2023 at 15:05
To: openjdk/jfx ***@***.***>
Cc: Andy Goryachev ***@***.***>, Comment ***@***.***>
Subject: [External] : Re: [openjdk/jfx] 8301302: Platform preferences API (PR #1014)
On Tue, Jan 31, 2023 at 3:00 PM Andy Goryachev ***@***.***>
wrote:

> In the context of adding theme support in javafx, I think this PR is a
> step in the right direction. I also like a small set of
> platform-independent properties like fg and bg colors. I wonder if the same
> approach can be extended for other aspects of platform L&F, like fonts,
> spacing, and may be other aspects (like, hiding scrollbars setting on Mac?)
>
> I agree with @kevinrushforth <https://github.com/kevinrushforth><https://urldefense.com/v3/__https:/github.com/kevinrushforth*3E__;JQ!!ACWV5N9M2RV99hQ!KHKaL2kyeeUaTInIrS8Uhsv6ERm_8WkoL8AnRSjL0wrZHd7sAwYhgS-04iFgvIaFFG8jBOn21R4qDKP5cQK_qehehGOxHA$> - we'd
> need more discussion on the actual implementation. There are a few items
> that I feel are unnecessary, or might be done differently, and I'd like to
> learn what other people think.
>
> Specifically:
>
> 1. Appearance enum seems unnecessary - there might be more choices in
> a specific platform (Mac Ventura has three: dark/light/auto).
>
>
Is it necessary for any application to know about "auto"? Presumably when
the mode automatically changes from one to the other there would be an
event that should be handled, just as if the user changed the setting while
the application was running.

Scott

> Message ID: ***@***.***>
>


?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1014*issuecomment-1411193097__;Iw!!ACWV5N9M2RV99hQ!KHKaL2kyeeUaTInIrS8Uhsv6ERm_8WkoL8AnRSjL0wrZHd7sAwYhgS-04iFgvIaFFG8jBOn21R4qDKP5cQK_qejGo1dBdQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AZQ34ZCIPVHZMVEXMC2WO7TWVGLB7ANCNFSM6AAAAAAUJ6L3R4__;!!ACWV5N9M2RV99hQ!KHKaL2kyeeUaTInIrS8Uhsv6ERm_8WkoL8AnRSjL0wrZHd7sAwYhgS-04iFgvIaFFG8jBOn21R4qDKP5cQK_qehZTOIwSA$>.
You are receiving this because you commented.Message ID: ***@***.***>

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From angorya at openjdk.org  Tue Jan 31 23:19:57 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 31 Jan 2023 23:19:57 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
Message-ID: <e-Sm3wbPR7STkBdXnMzS2vR8cV5ZjMoj_mHXBEw3BA0=.dc7904b7-4d73-4f77-8990-7f3a1112e50f@github.com>

On Sun, 29 Jan 2023 17:10:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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<String, Object> {
>>     // Platform-independent API
>>     ReadOnlyObjectProperty<Appearance> appearanceProperty();
>>     ReadOnlyObjectProperty<Color> backgroundColorProperty();
>>     ReadOnlyObjectProperty<Color> foregroundColorProperty();
>>     ReadOnlyObjectProperty<Color> accentColorProperty();
>> 
>>     // Convenience methods to retrieve platform-specific values from the map
>>     Optional<Integer> getInteger(String key);
>>     Optional<Double> getDouble(String key);
>>     Optional<String> getString(String key);
>>     Optional<Boolean> getBoolean(String key);
>>     Optional<Color> 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 incrementally with one additional commit since the last revision:
> 
>   Use Optional for convenience methods in Preferences

mailing list ate a screenshot from the last message.  here it is:

<img width="467" alt="Screenshot 2023-01-31 at 15 10 38" src="https://user-images.githubusercontent.com/107069028/215905602-1e656e6c-620f-4437-b041-11b6ebc46834.png">

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From swpalmer at gmail.com  Tue Jan 31 23:30:58 2023
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 31 Jan 2023 18:30:58 -0500
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <-NPcVeRBir4f1hTPZh1jEWbuhJHmYZflBBMnJ8Xrh-g=.e3b40288-87b1-4401-9541-4ca8dcdacd2f@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
 <r8w_0keOj_J56w5q2wlLG-M3e58w5JyMkZn4KjZfGnI=.841bbf78-0a01-48a0-896b-138c1f447e16@github.com>
 <-NPcVeRBir4f1hTPZh1jEWbuhJHmYZflBBMnJ8Xrh-g=.e3b40288-87b1-4401-9541-4ca8dcdacd2f@github.com>
Message-ID: <CAL3e5iGAf9khrHJeJvTeeXS759C_fC3pAngfApxwo1LAaHNfkQ@mail.gmail.com>

On Tue, Jan 31, 2023 at 6:15 PM Andy Goryachev <angorya at openjdk.org> wrote:

> On Tue, 31 Jan 2023 23:04:50 GMT, Scott Palmer <swpalmer at openjdk.org>
> wrote:
>
> > Is it necessary for any application to know about "auto"?
>
> I actually don't know how the "auto" behaves.  From the description it
> seems the colors might actually change gradually throughout the day, thus
> making an enum useless and necessitating the use of the actual colors.
>

>From https://support.apple.com/en-ca/guide/mac-help/mchl52e1c2d2/mac

Auto just changes from light to dark based on the "Night Shift" setting,
which uses either a fixed schedule, or sunset.  It doesn't have any "in
between" modes. Though it does animate the transition of the colors over
1/2 second or so.

The point being that as far as making the application aware of the current
state, auto isn't needed.  As a preference for within the application
(force light or dark, or 'auto' = track the OS setting) it might be
useful.  I would only include it if the Theme proposal is also going to
dynamically track the OS preference and switch Themes for you.  It looks
like you have that covered by having the application bind to the Platform
Preferences value, in which case "auto" would be an application setting
rather than a JavaFX platform setting.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230131/20b1408b/attachment.htm>

From mstrauss at openjdk.org  Tue Jan 31 23:42:56 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 31 Jan 2023 23:42:56 GMT
Subject: RFR: 8301302: Platform preferences API [v2]
In-Reply-To: <AfzOcJfWUlSPJ6PovruwhwDXyARHi-MHgeNUYoUsnpY=.2a0fb45e-60e5-4891-8f59-50574f51c214@github.com>
References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com>
 <vP33ebbq9UueDIDD-qU07RSURWq7k8pFv2aXgVPwjw0=.d6460f69-241a-4a0c-b842-25f4d9280f89@github.com>
 <VY2dNUx9cpD1BjbkBEKfJHHNO6Omzcrv9C_tJQSYwHw=.4bbb4261-d768-4ecd-b7d2-14dd0aabd28f@github.com>
 <BxVOgi4upJBrXlVsimpNPjpgmJTWcEYR09VobiErFxo=.7a093e75-5dd9-4133-a7fa-43dd51abb699@github.com>
 <AfzOcJfWUlSPJ6PovruwhwDXyARHi-MHgeNUYoUsnpY=.2a0fb45e-60e5-4891-8f59-50574f51c214@github.com>
Message-ID: <o4M5O60SF7ob_9Pv333qXTA085DxTcnMt3Ge0faMwO0=.a5146998-25d5-42df-be42-1c26618c8d1f@github.com>

On Tue, 31 Jan 2023 23:07:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I think that, by default, the FX frame decorations should pick up the platform theme (dark, light, accent color, etc.). It should be possible to override this behavior somehow - possibly by setting the base/accent color - but using an enum for this purpose feels unnecessary.

I think it shouldn't do that automatically, because the default themes do not support a dark mode out of the box. _No_ theme will support multiple appearances without being specifically designed to do so.

If a theme supports multiple appearances, the "just use the platform appearance" behavior only requires a single line of code, which also takes care of macOS's "auto" appearance:


    var stage = new Stage();
    stage.appearanceProperty().bind(Platform.getPreferences().appearanceProperty());


By the way, `Stage.appearance` doesn't really have anything to do with `StyleTheme`. A style theme is the proposed collection of stylesheets that define the look of a JavaFX application, while the stage appearance _only_ determines the appearance of native window decorations.

On Windows, the dark appearance adds the `DWMA_USE_IMMERSIVE_DARK_MODE` flag to the native window (see [Support Dark and Light themes in Win32 apps](https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes)), on macOS it chooses the "DarkAqua" appearance instead of the "Aqua" appearance (see [Choosing a Specific Appearance for Your macOS App](https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app)). There is no middle ground, it's either dark or it's not. Therefore I think the enumeration is a useful representation of this distinction.

-------------

PR: https://git.openjdk.org/jfx/pull/1014

From pedro.duquevieira at gmail.com  Tue Jan 31 23:54:55 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 31 Jan 2023 23:54:55 +0000
Subject: Style themes API
In-Reply-To: <CAAEud6ZLCDmR_KHijAMDJKSuPsinikTnt2tZFu8OK=kADVZi6w@mail.gmail.com>
References: <CAAEud6YgWSi6bCV+0iZPSNbdYpPXVPXoen-E1Rp7nun9zitc=Q@mail.gmail.com>
 <CAJEpuXTJtm2PYGpqTbjYXqB0uZu8Y0kVd-FDnyQHRczigOLzvw@mail.gmail.com>
 <CAAEud6admXmmraASeNikQsUmo15_qJcH2+z3yq8gGD1p9aR_Nw@mail.gmail.com>
 <CAJEpuXR6XMLByDPGTnZfa+7vuFaeVaZsL8BsOFj6vGYNr2_ong@mail.gmail.com>
 <CAAEud6b-Pa9pnFqFHG=12dy70XtKcUOGodCoJHNJ8uwk6QkeQw@mail.gmail.com>
 <CAJEpuXQ+wbJZtEaV4pcY65=XEXo7mTTWcs3VCYjGp2oe-=uJ_w@mail.gmail.com>
 <CAAEud6ZLCDmR_KHijAMDJKSuPsinikTnt2tZFu8OK=kADVZi6w@mail.gmail.com>
Message-ID: <CAAEud6a6VN=i=cba6zSycX-vkk4kskuWbpR22xoXyQYrQCQDvQ@mail.gmail.com>

My previous message seems to have perhaps gotten lost in the
various messages exchanged in this mailing list.. (just doing this small
comment so that my previous message doesn't get lost..)

It's getting very late here where I live, I will be back later tomorrow (a
few hours from now).

Thanks

On Tue, Jan 31, 2023 at 5:14 PM Pedro Duque Vieira <
pedro.duquevieira at gmail.com> wrote:

> Hi Michael,
>
> Truly sorry for the late reply but haven't had time to reply sooner,
> unfortunately..
>
> 2 -
>
>> > I've been building javafx themes for years now. Started creating JMetro
>> in JavaFX version 2. During this time I've been following how other themes
>> are being built and I can say that about 90% of the themes (rough estimate)
>> that are out there, are composed of author stylesheets, i.e they override
>> values set from code (including JMetro).
>> > I agree that themes that are to be provided to other developers would
>> probably be better off if they are user agent stylesheets. My point is that
>> migrating those 90% of themes to use this API would be easier if this flag
>> exists otherwise migration would likely introduce UI regressions for
>> developers using those themes.
>> >
>> > To be clear, what I'm proposing is a flag, or enum, or whatever, in
>> StyleTheme that defines whether the stylesheets in the StyleTheme should be
>> a user agent stylesheet or author stylesheet.
>> >
>> > Another point is in making themes that are only to be used locally in a
>> specific app that the developer is creating. It might be of interest that
>> he can toggle this flag and make all settings defined in the theme override
>> any styling set from code (or in FXML) so that he can have a centralized
>> point where all styling is done.
>
>
> I think that the likelihood of this feature making it into the 21
>> release dramatically increases if we keep changes to the CSS subsystem
>> to an absolute minimum. I understand your point, but I want to deliver
>> this feature in the smallest useful package and add more features
>> later with follow-on PRs.
>
>
> That's why I've renamed `Application.styleTheme` to
>> `Application.userAgentStyleTheme`. This makes it unmistakably clear
>> that we're only talking about user-agent stylesheets.
>> Also, it leaves open the possibility to add the
>> `Application.styleTheme` property later, which would cause the theme
>> to be interpreted as comprised of author stylesheets.
>> Classifying author/UA themes at the property level is also more
>> consistent with the way author/UA stylesheets are currently classified
>> in JavaFX.
>> What do you think about the styleTheme/userAgentStyleTheme API,
>> instead of having a flag in the implementation of StyleTheme itself?
>
>
> Since one of the objectives of the PR is to promote Caspian and Modena
>> to first-class theme implementations, it makes sense to focus on UA
>> themes first (since built-in themes are comprised of UA stylesheets).
>
>
> OK.
> 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.
>
>
> 3 -
> > Style themes are generally either defined as dark or light. i.e. you'll
> very rarely have a theme that has some Windows with dark decorations and
> others with light decorations. So I think it makes sense to have this as a
> theme property.
> > The ability to toggle decorations (light or dark) on an individual
> Window is a good point you're making. Perhaps we should have a global
> definition in the StyleTheme (whether the theme is light or dark) and a
> definition that can be set per Window.
> > If you set it on the StyleTheme then all Windows will respect it, but
> you can override that value on each Window. If you override it on a
> specific Window, that definition would take precedence over the global
> StyleTheme one.
>
> In general, StyleTheme is a very simple concept: it's a dynamic
>> collection of stylesheets.
>> I don't think the interface should force implementers to deal with
>> anything other than stylesheets. If we did that, the following code
>> wouldn't work any more:
>
>
>     Application.setUserAgentStyleTheme(
>>         () -> List.of("stylesheet1.css", "stylesheet2.css");
>
>
> Maybe we can add a new interface, for example DarkModeAware, and if an
>> application theme is marked with this interface, JavaFX will try to
>> respect dark/light mode for platform decorations:
>
>
>     public class MyCustomTheme implements StyleTheme, DarkModeAware {
>>         @Override
>>         public List<String> getStylesheets() {
>>             return List.of("stylesheet1.css", "stylesheet2.css");
>>         }
>>     }
>
>
>     // Setting a DarkModeAware theme causes JavaFX to draw light or
>>     // dark platform decorations by default, depending on the current
>>     // platform preference. If the theme is not DarkModeAware, JavaFX
>>     // defaults to light decorations.
>>     //
>>     Application.setUserAgentStyleTheme(new MyCustomTheme());
>
>
> In any case, I think we can deliver this feature in a follow-on PR.
>
>
> 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.
>
> Thanks again,
>
>
>
>
>
>
>
>
>
> On Sun, Jan 22, 2023 at 12:51 AM Michael Strau? <michaelstrau2 at gmail.com>
> wrote:
>
>> Hi Pedro,
>>
>> see my comments below.
>>
>>
>> On Sat, Jan 21, 2023 at 5:19 PM Pedro Duque Vieira
>> <pedro.duquevieira at gmail.com> wrote:
>> > I've been building javafx themes for years now. Started creating JMetro
>> in JavaFX version 2. During this time I've been following how other themes
>> are being built and I can say that about 90% of the themes (rough estimate)
>> that are out there, are composed of author stylesheets, i.e they override
>> values set from code (including JMetro).
>> > I agree that themes that are to be provided to other developers would
>> probably be better off if they are user agent stylesheets. My point is that
>> migrating those 90% of themes to use this API would be easier if this flag
>> exists otherwise migration would likely introduce UI regressions for
>> developers using those themes.
>> >
>> > To be clear, what I'm proposing is a flag, or enum, or whatever, in
>> StyleTheme that defines whether the stylesheets in the StyleTheme should be
>> a user agent stylesheet or author stylesheet.
>> >
>> > Another point is in making themes that are only to be used locally in a
>> specific app that the developer is creating. It might be of interest that
>> he can toggle this flag and make all settings defined in the theme override
>> any styling set from code (or in FXML) so that he can have a centralized
>> point where all styling is done.
>>
>> I think that the likelihood of this feature making it into the 21
>> release dramatically increases if we keep changes to the CSS subsystem
>> to an absolute minimum. I understand your point, but I want to deliver
>> this feature in the smallest useful package and add more features
>> later with follow-on PRs.
>>
>> That's why I've renamed `Application.styleTheme` to
>> `Application.userAgentStyleTheme`. This makes it unmistakably clear
>> that we're only talking about user-agent stylesheets.
>> Also, it leaves open the possibility to add the
>> `Application.styleTheme` property later, which would cause the theme
>> to be interpreted as comprised of author stylesheets.
>> Classifying author/UA themes at the property level is also more
>> consistent with the way author/UA stylesheets are currently classified
>> in JavaFX.
>> What do you think about the styleTheme/userAgentStyleTheme API,
>> instead of having a flag in the implementation of StyleTheme itself?
>>
>> Since one of the objectives of the PR is to promote Caspian and Modena
>> to first-class theme implementations, it makes sense to focus on UA
>> themes first (since built-in themes are comprised of UA stylesheets).
>>
>>
>>
>> > 3 -
>> > Style themes are generally either defined as dark or light. i.e. you'll
>> very rarely have a theme that has some Windows with dark decorations and
>> others with light decorations. So I think it makes sense to have this as a
>> theme property.
>> > The ability to toggle decorations (light or dark) on an individual
>> Window is a good point you're making. Perhaps we should have a global
>> definition in the StyleTheme (whether the theme is light or dark) and a
>> definition that can be set per Window.
>> > If you set it on the StyleTheme then all Windows will respect it, but
>> you can override that value on each Window. If you override it on a
>> specific Window, that definition would take precedence over the global
>> StyleTheme one.
>>
>> In general, StyleTheme is a very simple concept: it's a dynamic
>> collection of stylesheets.
>> I don't think the interface should force implementers to deal with
>> anything other than stylesheets. If we did that, the following code
>> wouldn't work any more:
>>
>>     Application.setUserAgentStyleTheme(
>>         () -> List.of("stylesheet1.css", "stylesheet2.css");
>>
>> Maybe we can add a new interface, for example DarkModeAware, and if an
>> application theme is marked with this interface, JavaFX will try to
>> respect dark/light mode for platform decorations:
>>
>>     public class MyCustomTheme implements StyleTheme, DarkModeAware {
>>         @Override
>>         public List<String> getStylesheets() {
>>             return List.of("stylesheet1.css", "stylesheet2.css");
>>         }
>>     }
>>
>>     // Setting a DarkModeAware theme causes JavaFX to draw light or
>>     // dark platform decorations by default, depending on the current
>>     // platform preference. If the theme is not DarkModeAware, JavaFX
>>     // defaults to light decorations.
>>     //
>>     Application.setUserAgentStyleTheme(new MyCustomTheme());
>>
>> In any case, I think we can deliver this feature in a follow-on PR.
>>
>>
>> > 4-
>> >>
>> >> If we wanted to expose this front-and-center, we could add these
>> >>
>> >> properties to the Platform.Properties interface:
>> >
>> >
>> >>     public interface Preferences extends ObservableMap<String, Object>
>> {
>> >>         ReadOnlyBooleanProperty darkModeProperty();
>> >>         ReadOnlyObjectProperty<Color> accentColorProperty();
>> >>         ...
>> >>     }
>> >
>> >
>> > Yes, I think that would be great.
>>
>> Let's see what other people think.
>>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230131/a1e29b6f/attachment-0001.htm>