RFR: 8301302: Platform preferences API

[Michael Strauß]

Platform preferences are the preferred UI settings of the operating system. For 
example, on Windows this includes the color values identified by the 
`Windows.UI.ViewManagement.UIColorType` enumeration; on macOS this includes the 
system color values of the `NSColor` class.

Exposing these dynamic values to JavaFX applications allows developers to 
create themes that can integrate seamlessly with the color scheme of the 
operating system.

Platform preferences are exposed as an `ObservableMap` of platform-specific 
key-value pairs, which means that the preferences available on Windows are 
different from macOS or Linux. JavaFX provides a small, curated list of 
preferences that are available on most platforms, and are therefore exposed 
with a platform-independent API:


public interface Preferences extends ObservableMap {
// Platform-independent API
ReadOnlyObjectProperty appearanceProperty();
ReadOnlyObjectProperty backgroundColorProperty();
ReadOnlyObjectProperty foregroundColorProperty();
ReadOnlyObjectProperty accentColorProperty();

// Convenience methods to retrieve platform-specific values from the map
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=1014=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

Move/Resize undecorated windows

[Thiago Milczarek Sayão]

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.

Re: RFR: 8273379 - GTK3 stops sending key events during drag and drop [v28]

[Thiago Milczarek Sayao]

> 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=986=27
 - incr: https://webrevs.openjdk.org/?repo=jfx=986=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

Style themes update

[Michael Strauß]

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

Re: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4]

[John Hendrikx]

On Sat, 28 Jan 2023 16:24:30 GMT, Michael Strauß  wrote:

>> `Node` adds InvalidationListeners to its parent's `disabled` and 
>> `treeVisible` properties and calls its own `updateDisabled()` and 
>> `updateTreeVisible(boolean)` methods when the property values change.
>> 
>> These listeners are not required, since `Node` can easily call the 
>> `updateDisabled()` and `updateTreeVisible(boolean)` methods on its children, 
>> saving the memory cost of maintaining listeners and bindings.
>
> Michael Strauß has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Initialize treeVisible field directly

Marked as reviewed by jhendrikx (Committer).

-

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

Re: RFR: 8290765: Remove parent disabled/treeVisible listeners [v2]

[Michael Strauß]

On Fri, 27 Jan 2023 22:01:46 GMT, John Hendrikx  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

Re: RFR: 8290765: Remove parent disabled/treeVisible listeners [v4]

[Michael Strauß]

> `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=841=03
 - incr: https://webrevs.openjdk.org/?repo=jfx=841=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

Re: Virtual Flow enhancements

[Dirk Lemmermann]

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  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  > 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 >> > 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 >>> > wrote:
 
 
 
 On Wed, Sep 14, 2022 at 12:19 PM Dirk Lemmermann >>> 

Re: RFR: JDK-8299977 : Update WebKit to 615.1

[Kevin Rushforth]

On Wed, 25 Jan 2023 19:51:02 GMT, Hima Bindu Meda  wrote:

> Update JavaFX WebKit to GTK WebKit 2.38 (615.1).
> 
> Verified the updated version build, sanity tests and stability.
> This does not cause any issues except one unit test failure.
> Also, there are some artifacts observed while playing youtube
> 
> The above issues are recorded and ignored using below bugs:
> [JDK-8300954](https://bugs.openjdk.org/browse/JDK-8300954)
> [JDK-8301022](https://bugs.openjdk.org/browse/JDK-8301022)

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