Integrated: 8285217: [Android] Window's screen is not updated after native screen was disposed
On Wed, 20 Apr 2022 18:26:06 GMT, Jose Pereda wrote: > This PR updates the screen for each window even for the case where the old > screen has been disposed but there is a new screen instance found for such > window. > > This is the case of Android, where the lifecycle of the application allows > destroying the native screen when the app goes to the background, and > providing a new native screen, in case it comes back to the foreground. > Before this PR, the screen for the window wasn't updated after returning from > the background, and if orientation changes happened, the dimensions were > wrong. This pull request has now been integrated. Changeset: 6c6545f7 Author:Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/6c6545f7b8b9917ef4aceb0a367864f240a2a9c5 Stats: 38 lines in 4 files changed: 25 ins; 3 del; 10 mod 8285217: [Android] Window's screen is not updated after native screen was disposed Reviewed-by: jvos - PR: https://git.openjdk.java.net/jfx/pull/778
RFR: 8286552: TextFormatter: UpdateValue/UpdateText is called, when no ValueConverter is set
A common reason for using the `TextFormatter` is the need for a `filter`.
Therefore, the following constructor is typically used:
`public TextFormatter(@NamedArg("filter") UnaryOperator filter) { ... }`
With that, no `valueConverter` is set in the `TextFormatter`.
When a `TextField` will commit his value, `TextFormatter.updateValue(...)` is
called.
Since `valueConverter` is null, an NPE is thrown and catched inside it and
`TextFormatter.updateText()` is called (which will call
`TextInputControl.updateText(...)`), which won't do anything either since
`valueConverter` is still not set (=null).
A minor improvement here is to just skip `TextFormatter.updateValue(...)` and
therefore `TextFormatter.updateText()`, since this methods won't do anything
without a `valueConverter`.
With that change, no exception is thrown and catched, and therefore also
exception breakpoints are not called.
This will also slightly increase the performance, as throwing exceptions is a
(minor) bottleneck.
-
Commit messages:
- 8286552: TextFormatter.updateValue(...) won't call updateText(), when no
valueConverter is set
Changes: https://git.openjdk.java.net/jfx/pull/794/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=794=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8286552
Stats: 79 lines in 2 files changed: 75 ins; 0 del; 4 mod
Patch: https://git.openjdk.java.net/jfx/pull/794.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/794/head:pull/794
PR: https://git.openjdk.java.net/jfx/pull/794
What can I do with the GStreamer bundled in JavaFX? Can I record the screen?
Hi all, I haven't understood what part of GStreamer is included in JavaFX. Can I record the screen with it using d3d11screencapturesrc or ximagesrc? Thanks Davide
Re: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView)
On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger wrote: > Separate test class added for TreeTableView case. > Fix is analogous to JDK-8251480. Looks good! Verified that the fix works. I can also confirm, that this fix is the same as previously done for `TableView` in PR: https://github.com/openjdk/jfx/pull/757 - Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/779
Integrated: 8283869: Update attribution in webkit.md file
On Tue, 10 May 2022 16:37:57 GMT, Kevin Rushforth wrote: > Doc-only change to update the license attribution in our `webkit.md` file. This pull request has now been integrated. Changeset: 7bb48194 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/7bb4819409dd617ba2e3658ee66f23b94dc0bec1 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod 8283869: Update attribution in webkit.md file Reviewed-by: arapte - PR: https://git.openjdk.java.net/jfx/pull/793
Re: RFR: 8283869: Update attribution in webkit.md file
On Tue, 10 May 2022 16:37:57 GMT, Kevin Rushforth wrote: > Doc-only change to update the license attribution in our `webkit.md` file. LGTM - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/793
RFR: 8283869: Update attribution in webkit.md file
Doc-only change to update the license attribution in our `webkit.md` file. - Commit messages: - 8283869: Update attribution in webkit.md file Changes: https://git.openjdk.java.net/jfx/pull/793/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=793=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283869 Stats: 5484 lines in 1 file changed: 5483 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/793.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/793/head:pull/793 PR: https://git.openjdk.java.net/jfx/pull/793
Re: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1
On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in > the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not > present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c Reviewer: @johanvos - PR: https://git.openjdk.java.net/jfx17u/pull/54
[jfx17u] Integrated: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases
On Mon, 9 May 2022 21:20:29 GMT, Kevin Rushforth wrote: > This PR is dependent on #58 so it is in Draft for now. Once #58 is > integrated, I will rebase this and submit it, at which time it will be a > clean backport, and the diffs will only show the updated test and build > changes associated with just this fix. This pull request has now been integrated. Changeset: c8eafd82 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/c8eafd827b5aff73e4fb14b2721bdf45c6f3dc0d Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Backport-of: 94807b6edfb9af55be353cab237e8e64007c61dc - PR: https://git.openjdk.java.net/jfx17u/pull/59
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v4]
On Tue, 10 May 2022 15:19:58 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Use constant value for DPI Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v4]
> This PR updates the screen for each window even for the case where the old > screen has been disposed but there is a new screen instance found for such > window. > > This is the case of Android, where the lifecycle of the application allows > destroying the native screen when the app goes to the background, and > providing a new native screen, in case it comes back to the foreground. > Before this PR, the screen for the window wasn't updated after returning from > the background, and if orientation changes happened, the dimensions were > wrong. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Use constant value for DPI - Changes: - all: https://git.openjdk.java.net/jfx/pull/778/files - new: https://git.openjdk.java.net/jfx/pull/778/files/28129038..7e5958cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=778=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=778=02-03 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778
[jfx17u] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases
This PR is dependent on #58 so it is in Draft for now. Once #58 is integrated, I will rebase this and submit it, at which time it will be a clean backport, and the diffs will only show the updated test and build changes associated with just this fix. - Commit messages: - 8280275: JUnit5 tests using Assumptions API fail to compile in some cases Changes: https://git.openjdk.java.net/jfx17u/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=59=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280275 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/59/head:pull/59 PR: https://git.openjdk.java.net/jfx17u/pull/59
Re: RFR: 8284654: Modal behavior returns to wrong stage [v3]
On Tue, 10 May 2022 12:56:53 GMT, Thiago Milczarek Sayao
wrote:
>> When there's an APPLICATION_MODAL window, all other windows are disabled and
>> re-enabled when the APPLICATION_MODAL window closes. This causes
>> `requestToFront()` to be called on every window, and it does not guarantee
>> order.
>>
>> The fix also works for:
>> https://bugs.openjdk.java.net/browse/JDK-8269429
>>
>> But this one might need another fix:
>> https://bugs.openjdk.java.net/browse/JDK-8240640
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert "Set the focus on the latest window when re-enabling them"
>
> This reverts commit b024de586c187f9000f791dab99507a4979cc027.
I reverted the last change.
After more analysis I think it's not a bug, but a side-effect of not using
native window modality in favor of enabling/disabling windows.
It works like this:
On the original step 5 ("Click anywhere in Window One") the window would get
the focus, but instead will send a FOCUS_DISABLED event, which will bring up
the MODAL window.
The problem is that the window will get the focus, to be lost in favor of the
last window (which is the MODAL one).
To prevent this, a disabled window should never be focused. But that prevents
the whole FOCUS_DISABLED logic.
Note that the APPLICATION_MODAL window on the example has no owner, so I think
it's ok to consider a side effect and not a bug.
-
PR: https://git.openjdk.java.net/jfx/pull/784
[jfx17u] Integrated: 8276142: Update gradle to version 7.3
On Mon, 9 May 2022 21:14:23 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: be207ddb Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/be207ddb7249b369a028bc6fb6985adda7841648 Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod 8276142: Update gradle to version 7.3 Backport-of: 13c24d22463436bc953ec5159beec7a78017019f - PR: https://git.openjdk.java.net/jfx17u/pull/56
[jfx17u] Integrated: 8276174: JavaFX build fails on macOS aarch64
On Mon, 9 May 2022 21:22:04 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u` so we can build on macOS / aarch64 without needing > to specify `-PCOMPILE_TARGET=arm64`. This pull request has now been integrated. Changeset: a5edae13 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/a5edae1392699e7380a0b528eb1118889377cc02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8276174: JavaFX build fails on macOS aarch64 Backport-of: d289db94d15e49ed28f797b516ffccf023fce9c9 - PR: https://git.openjdk.java.net/jfx17u/pull/60
[jfx17u] Integrated: 8273998: Clarify specification for Window properties controlled by the window manager
On Mon, 9 May 2022 21:15:34 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: bdb8d28e Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/bdb8d28ecc7bb10278a9a8385da79b5f5652bb09 Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod 8273998: Clarify specification for Window properties controlled by the window manager Backport-of: 7a1a19c098e21572077c9c3d75cc2141fadc99f6 - PR: https://git.openjdk.java.net/jfx17u/pull/57
Re: RFR: 8284654: Modal behavior returns to wrong stage [v3]
> When there's an APPLICATION_MODAL window, all other windows are disabled and > re-enabled when the APPLICATION_MODAL window closes. This causes > `requestToFront()` to be called on every window, and it does not guarantee > order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Revert "Set the focus on the latest window when re-enabling them" This reverts commit b024de586c187f9000f791dab99507a4979cc027. - Changes: - all: https://git.openjdk.java.net/jfx/pull/784/files - new: https://git.openjdk.java.net/jfx/pull/784/files/b024de58..a6cad45b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=784=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=784=01-02 Stats: 8 lines in 2 files changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784
[jfx17u] Integrated: 8274274: Update JUnit to version 5.8.1
On Mon, 9 May 2022 21:18:07 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: 2ab0e82e Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/2ab0e82ee9cf2516b32914e2df4725becf8a2664 Stats: 161 lines in 5 files changed: 151 ins; 3 del; 7 mod 8274274: Update JUnit to version 5.8.1 Backport-of: ff6e8d50badd57549811391b1380707bb94ac55b - PR: https://git.openjdk.java.net/jfx17u/pull/58
[jfx17u] Integrated: 8281564: Update cmake to 3.22.3
On Mon, 9 May 2022 21:13:07 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. Tested along with the rest of the fixes in the > `test-kcr-17.0.4` branch. This pull request has now been integrated. Changeset: 684c80fc Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/684c80fc7c7149d77509936867e7a42dc88ed9ed Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod 8281564: Update cmake to 3.22.3 Backport-of: d960d639dc6e37de0cdb69075a31a17090b83a3d - PR: https://git.openjdk.java.net/jfx17u/pull/55
Re: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again
On Wed, 17 Feb 2021 18:50:54 GMT, Kevin Rushforth wrote: >> `Tooltip` is no longer hiding upon receiving >> `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on >> overlaying tooltip also kills the tooltip, so the infinite duration tooltip >> can be closed. > > One more request: Please follow the instructions > [here](https://github.com/openjdk/jfx/pull/395/checks) to enable running > pre-submit tests. @kevinrushforth sorry for "little" delay in answering, but I thing that previously failing tests have passed as successful now. - PR: https://git.openjdk.java.net/jfx/pull/395
Re: RFR: 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again [v3]
> `Tooltip` is no longer hiding upon receiving > `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on > overlaying tooltip also kills the tooltip, so the infinite duration tooltip > can be closed. Paweł Kruszczyński 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 'openjdk:master' into 8261221_tooltip_blinks - 8261221: Tooltip bigger than screen size blinks - applying reviewed fixes - 8261221: Tooltip bigger than screen size blinks - shows and hides over and over again - Changes: - all: https://git.openjdk.java.net/jfx/pull/395/files - new: https://git.openjdk.java.net/jfx/pull/395/files/3fb62625..0a175dca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=395=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=395=01-02 Stats: 954937 lines in 11930 files changed: 523481 ins; 281758 del; 149698 mod Patch: https://git.openjdk.java.net/jfx/pull/395.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/395/head:pull/395 PR: https://git.openjdk.java.net/jfx/pull/395
Re: RFR: 8284654: Modal behavior returns to wrong stage [v2]
On Mon, 9 May 2022 14:54:55 GMT, Thiago Milczarek Sayao wrote: >> When there's an APPLICATION_MODAL window, all other windows are disabled and >> re-enabled when the APPLICATION_MODAL window closes. This causes >> `requestToFront()` to be called on every window, and it does not guarantee >> order. >> >> The fix also works for: >> https://bugs.openjdk.java.net/browse/JDK-8269429 >> >> But this one might need another fix: >> https://bugs.openjdk.java.net/browse/JDK-8240640 > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Set the focus on the latest window when re-enabling them The original fix gets affected by the new commit. Now, after closing dialog the focus always returns only to the stage that was created later. 1. Run the sample attached to [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654). 2. Click button One and Two both once in order 3. Re-arrange both the windows such that they are visible. 4. Click the button "Click here" in Window One: Error dialog will be displayed 5. Close the Error dialog => Window Two gets focused but Window One should gets focused. => This worked correctly before the latest commit. - PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3]
On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Scale screen dimensions This looks now more in line with what the other platforms are doing. We expect the native layer to deal with low-level window/screen handling, and they should notify the java layer in case of relevant events. - PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3]
On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Scale screen dimensions modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.c line 171: > 169: 0, 0, (jint) width, (jint) height, > 170: 0, 0, (jint) width, (jint) height, > 171: 100, 100, (jfloat) 1, (jfloat) 1, androidDensity, > androidDensity); might be good to replace the `100` with e.g. `dpi` and assign a constant value (100) at the top of this file to it, in case we later want to retrieve that in a more dynamic way. - PR: https://git.openjdk.java.net/jfx/pull/778
