From mstrauss at openjdk.java.net Mon Aug 2 13:24:12 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Aug 2021 13:24:12 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v3] In-Reply-To: References: Message-ID: <3DmcSgr9W7_lZRUAT6u8ELR4xuCIPASzurt85EtJB2s=.c4eec6f6-c5df-41cd-9b1a-aa56225b9b84@github.com> > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes per discussion, added test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/cf1daa2e..9d79df63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=01-02 Stats: 167 lines in 2 files changed: 89 ins; 61 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Mon Aug 2 13:24:13 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Aug 2021 13:24:13 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: On Sat, 26 Jun 2021 00:01:20 GMT, Michael Strau? wrote: > 3. I think the way you are propagating `focusWithin` might not work if nodes are added or removed from the scene graph. I've added a test for this case: `FocusTest.testFocusStatesAreClearedFromFormerParentsOfFocusedNode`. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Mon Aug 2 13:54:45 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Aug 2021 13:54:45 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v4] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible - changes per discussion, added test - wording - Re-ordered methods - remove code comment - revert changes to line endings - added test - Merge branch 'master' into feature/focusvisible - Only fire focus change notification if value is actually different - minor naming change - ... and 6 more: https://git.openjdk.java.net/jfx/compare/8c12b454...50ec08f6 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/9d79df63..50ec08f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=02-03 Stats: 341137 lines in 6581 files changed: 184453 ins; 110765 del; 45919 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Mon Aug 2 16:53:08 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Aug 2021 16:53:08 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v5] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: restart github actions ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/50ec08f6..e0591088 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From aghaisas at openjdk.java.net Tue Aug 3 06:24:38 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 3 Aug 2021 06:24:38 GMT Subject: [jfx17] Integrated: 8250590: Classes and methods in the javafx.css package are missing documentation In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 13:55:45 GMT, Ajit Ghaisas wrote: > This PR corrects/adds missing documentation for classes in javafx.css package. This pull request has now been integrated. Changeset: 7575473c Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/7575473c657a3fbd13cc5d8cf0d07ad3a543e050 Stats: 584 lines in 33 files changed: 511 ins; 4 del; 69 mod 8250590: Classes and methods in the javafx.css package are missing documentation Reviewed-by: kcr, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/589 From fastegal at swingempire.de Wed Aug 4 09:58:13 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 04 Aug 2021 11:58:13 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> my suggestion would be the longstanding commit-edit-on-focus-lost - solved by an enhancement to the editing api on virtualized controls -- Jeanette Zitat von Kevin Rushforth : > Now that JavaFX 17 is in RDP2, we can turn more attention to bug > fixes and enhancement requests for JavaFX 18. It's the summer, so > there may be delays as some people are out at various times > (including me), but I would like to get some of the outstanding > enhancement requests moving over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the > binary incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how > to proceed) > > * Undecorated interactive stage style (still in early discussion, > but the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > > -- Kevin From github.com+31666175+jonathanvusich at openjdk.java.net Wed Aug 4 14:09:19 2021 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Wed, 4 Aug 2021 14:09:19 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v8] In-Reply-To: References: Message-ID: > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into jonathan/fix-chart-axis-labels - Updated per review comments - Add tests for vertical axis as well - Improve layout calculations for rotated text - Remove unused import - Unrotate labels if there is enough space for them - Added copyright header - Added fix and test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/342/files - new: https://git.openjdk.java.net/jfx/pull/342/files/9d2c8ac9..cc73f8dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=06-07 Stats: 442103 lines in 7940 files changed: 245930 ins; 125567 del; 70606 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From tbee at tbee.org Wed Aug 4 14:30:57 2021 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 4 Aug 2021 16:30:57 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> Message-ID: <9ebd06d3-277f-b32f-e3e3-0a5a44e12964@tbee.org> +1 On 2021-08-04 11:58, Jeanette Winzenburg wrote: > > my suggestion would be the longstanding commit-edit-on-focus-lost - solved by an enhancement to the editing api on virtualized controls > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the binary incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to proceed) >> >> * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. >> >> -- Kevin > > > From dlemmermann at gmail.com Wed Aug 4 14:40:53 2021 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Wed, 4 Aug 2021 16:40:53 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: <9ebd06d3-277f-b32f-e3e3-0a5a44e12964@tbee.org> References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> <9ebd06d3-277f-b32f-e3e3-0a5a44e12964@tbee.org> Message-ID: +1 Tom Eugelink schrieb am Mi. 4. Aug. 2021 um 16:31: > +1 > > On 2021-08-04 11:58, Jeanette Winzenburg wrote: > > > > my suggestion would be the longstanding commit-edit-on-focus-lost - > solved by an enhancement to the editing api on virtualized controls > > > > -- Jeanette > > > > Zitat von Kevin Rushforth : > > > >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I would > like to get some of the outstanding enhancement requests moving over the > next few weeks. > >> > >> Specifically, I'd like to see the following proceed: > >> > >> * Transparent backgrounds in WebView > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > >> PR: https://github.com/openjdk/jfx/pull/563 > >> > >> * Add DirectionalLight > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > >> PR: https://github.com/openjdk/jfx/pull/548 > >> > >> * CSS pseudoclasses :focus-visible and :focus-within > >> https://bugs.openjdk.java.net/browse/JDK-8268225 > >> PR: https://github.com/openjdk/jfx/pull/475 > >> > >> * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) > >> > >> And maybe the following: > >> > >> * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > >> > >> * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > >> > >> There are probably others I'm forgetting. > >> > >> Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > >> > >> -- Kevin > > > > > > > > -- Dirk Lemmermann Software & Consulting Zurich, Switzerland +41-(0)79-800-23-20 http://www.dlsc.com mailto:dlemmermann at gmail.com From swpalmer at gmail.com Wed Aug 4 14:47:02 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 4 Aug 2021 10:47:02 -0400 Subject: Enhancements for JavaFX 18 In-Reply-To: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> Message-ID: +1 to that. I would also like to see some progress with system tray support and microphone & webcam access. Scott > On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg wrote: > > ? > my suggestion would be the longstanding commit-edit-on-focus-lost - solved by an enhancement to the editing api on virtualized controls > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the binary incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to proceed) >> >> * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. >> >> -- Kevin > > > From sebastian.stenzel at gmail.com Wed Aug 4 17:03:32 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 4 Aug 2021 19:03:32 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <29D2E5F9-EAEC-493E-A6EA-D84A24F210A0@gmail.com> +1 for a proper system tray api > Am 04.08.2021 um 16:47 schrieb Scott Palmer : > > ?+1 to that. > > I would also like to see some progress with system tray support and microphone & webcam access. > > Scott > >> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg wrote: >> >> ? >> my suggestion would be the longstanding commit-edit-on-focus-lost - solved by an enhancement to the editing api on virtualized controls >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. >>> >>> Specifically, I'd like to see the following proceed: >>> >>> * Transparent backgrounds in WebView >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> PR: https://github.com/openjdk/jfx/pull/563 >>> >>> * Add DirectionalLight >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> PR: https://github.com/openjdk/jfx/pull/548 >>> >>> * CSS pseudoclasses :focus-visible and :focus-within >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> PR: https://github.com/openjdk/jfx/pull/475 >>> >>> * Improve property system to facilitate correct usage (minus the binary incompatible API change) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>> >>> And maybe the following: >>> >>> * Add CSS themes as a first-class concept (need a consensus on how to proceed) >>> >>> * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) >>> >>> There are probably others I'm forgetting. >>> >>> Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. >>> >>> -- Kevin >> >> >> > From youngty1997 at gmail.com Wed Aug 4 17:05:16 2021 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 4 Aug 2021 12:05:16 -0500 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <999a48e4-ec31-d5a5-aded-0049fbcb00c0@gmail.com> You want a list of bugs that could be fixed? Today's your lucky day! * Resizing a JavaFX window under Linux (still) causes graphical glitches, needing -Dprism.forceUploadingPainter=true or, IIRC, software rendering to "fix". * Resizing ALSO causes graphical glitching on the bottom and right sides on both Windows AND Linux. * Resizing an app with a TableView in view results in the TableView's integrated scrollbars flickering in and out of existence when there is plenty of space left. The less UI content there is, the less this is likely to happen - but it absolutely does happen with *just* a TableView as the root node, you gotta play with it. * Resizing the application from the left causes UI jitter. * JavaFX in general seems to have trouble keeping up with user resizing. Rapidly resizing an application with a DividerPane(TreeView left, content right) results in inconsistent positioning than if it was done slowly, in the very least. * Alt tabbing with a UI component being selected(Slider thumb, scrollbar) results in that component's color being stuck in whatever color is the CSS selected state. * You can middle and right click drag a slider thumb and scroll bars, which does not trigger a CSS state change, which is not consistent with MenuBar items. * JavaFX does not seem to calculate the size of a GridPane or TilePane with elements correctly. This results in content in ScrollPanes that is clearly larger in height than the viewport but ScrollPane does not show its scrollbars - only mouse wheel works without forcing the scrollbars to always show or transition state bugs when putting a GridPane/TilePane inside a TitlePane(or maybe it's TilePane -> TitlePane -> TilePane that's the issue? No clue.) * XY Chart data that is off screen (-1, -1) has lines drawn to them despite being... off screen. Bug or feature? * Setting the Y axis side to Side.RIGHT causes a white space with custom CSS: https://imgur.com/a/4P1Oj1Q. Might be missing some. A few features, while I'm here: * API property to force a TableView's height to be the exact amount needed to display its headers and all its rows. * API to disable TableView's scrollbars completely. * A late "showing" property for when the application has been shown to the user and all first viewing UI components have had their sizes calculated and are being displayed, if it doesn't exist already and I'm completely blind. On 7/30/21 7:56 AM, Kevin Rushforth wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may > be delays as some people are out at various times (including me), but > I would like to get some of the outstanding enhancement requests > moving over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the > binary incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > > -- Kevin > > From tsayao at openjdk.java.net Wed Aug 4 19:37:34 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 4 Aug 2021 19:37:34 GMT Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v3] In-Reply-To: References: Message-ID: On Sat, 10 Jul 2021 16:06:18 GMT, Thiago Milczarek Sayao wrote: >> The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. >> >> This is passed on WindowStage.java:198 as a mask. >> >> The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded test for modal This is also fixed by #581. ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From tsayao at openjdk.java.net Wed Aug 4 19:37:34 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 4 Aug 2021 19:37:34 GMT Subject: Withdrawn: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/551 From kirill.grouchnikov at gmail.com Wed Aug 4 20:10:43 2021 From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov) Date: Wed, 4 Aug 2021 16:10:43 -0400 Subject: Enhancements for JavaFX 18 In-Reply-To: <29D2E5F9-EAEC-493E-A6EA-D84A24F210A0@gmail.com> References: <29D2E5F9-EAEC-493E-A6EA-D84A24F210A0@gmail.com> Message-ID: May I humbly suggest fixing font rendering color fringe issues on macOS On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel < sebastian.stenzel at gmail.com> wrote: > +1 for a proper system tray api > > > Am 04.08.2021 um 16:47 schrieb Scott Palmer : > > > > ?+1 to that. > > > > I would also like to see some progress with system tray support and > microphone & webcam access. > > > > Scott > > > >> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg < > fastegal at swingempire.de> wrote: > >> > >> ? > >> my suggestion would be the longstanding commit-edit-on-focus-lost - > solved by an enhancement to the editing api on virtualized controls > >> > >> -- Jeanette > >> > >> Zitat von Kevin Rushforth : > >> > >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I would > like to get some of the outstanding enhancement requests moving over the > next few weeks. > >>> > >>> Specifically, I'd like to see the following proceed: > >>> > >>> * Transparent backgrounds in WebView > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > >>> PR: https://github.com/openjdk/jfx/pull/563 > >>> > >>> * Add DirectionalLight > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > >>> PR: https://github.com/openjdk/jfx/pull/548 > >>> > >>> * CSS pseudoclasses :focus-visible and :focus-within > >>> https://bugs.openjdk.java.net/browse/JDK-8268225 > >>> PR: https://github.com/openjdk/jfx/pull/475 > >>> > >>> * Improve property system to facilitate correct usage (minus the > binary incompatible API change) > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) > >>> > >>> And maybe the following: > >>> > >>> * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > >>> > >>> * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > >>> > >>> There are probably others I'm forgetting. > >>> > >>> Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > >>> > >>> -- Kevin > >> > >> > >> > > > From philip.race at oracle.com Wed Aug 4 20:23:48 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 4 Aug 2021 13:23:48 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: <29D2E5F9-EAEC-493E-A6EA-D84A24F210A0@gmail.com> Message-ID: +1. It is something I intend to get to for 18. -phil. On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: > May I humbly suggest fixing font rendering color fringe issues on macOS > > On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel < > sebastian.stenzel at gmail.com> wrote: > >> +1 for a proper system tray api >> >>> Am 04.08.2021 um 16:47 schrieb Scott Palmer : >>> >>> ?+1 to that. >>> >>> I would also like to see some progress with system tray support and >> microphone & webcam access. >>> Scott >>> >>>> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg < >> fastegal at swingempire.de> wrote: >>>> ? >>>> my suggestion would be the longstanding commit-edit-on-focus-lost - >> solved by an enhancement to the editing api on virtualized controls >>>> -- Jeanette >>>> >>>> Zitat von Kevin Rushforth : >>>> >>>>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >> and enhancement requests for JavaFX 18. It's the summer, so there may be >> delays as some people are out at various times (including me), but I would >> like to get some of the outstanding enhancement requests moving over the >> next few weeks. >>>>> Specifically, I'd like to see the following proceed: >>>>> >>>>> * Transparent backgrounds in WebView >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>>>> PR: https://github.com/openjdk/jfx/pull/563 >>>>> >>>>> * Add DirectionalLight >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>>>> PR: https://github.com/openjdk/jfx/pull/548 >>>>> >>>>> * CSS pseudoclasses :focus-visible and :focus-within >>>>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>>>> PR: https://github.com/openjdk/jfx/pull/475 >>>>> >>>>> * Improve property system to facilitate correct usage (minus the >> binary incompatible API change) >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>>>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>>>> >>>>> And maybe the following: >>>>> >>>>> * Add CSS themes as a first-class concept (need a consensus on how to >> proceed) >>>>> * Undecorated interactive stage style (still in early discussion, but >> the concept looks interesting and useful) >>>>> There are probably others I'm forgetting. >>>>> >>>>> Each of the above should be discussed in their own thread on >> openjfx-dev rather than a reply to this thread. >>>>> -- Kevin >>>> >>>> From hjohn at xs4all.nl Wed Aug 4 22:25:44 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 5 Aug 2021 00:25:44 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl> Perhaps: Fluent bindings for ObservableValue https://github.com/openjdk/jfx/pull/434 It was received well I think, and there was some interest from Nir Lisker to work on a proposal. --John On 30/07/2021 14:56, Kevin Rushforth wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > From hjohn at xs4all.nl Wed Aug 4 22:35:11 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 5 Aug 2021 00:35:11 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: <999a48e4-ec31-d5a5-aded-0049fbcb00c0@gmail.com> References: <999a48e4-ec31-d5a5-aded-0049fbcb00c0@gmail.com> Message-ID: <6a76080f-d3bb-e9bd-e914-17ca75767628@xs4all.nl> On 04/08/2021 19:05, Ty Young wrote: > * A late "showing" property for when the application has been shown to > the user and all first viewing UI components have had their sizes > calculated and are being displayed, if it doesn't exist already and I'm > completely blind. Do you mean a property that is true if the current node is visible, attached to a scene which is attached to a window which is currently showing? This can be achieved with a small util that takes a Node and returns an ObservableValue. I can dig up the code, I use this all the time to automatically unbind bindings when UI parts become invisible. --John From mantheprogrammer at gmail.com Thu Aug 5 15:38:15 2021 From: mantheprogrammer at gmail.com (Jacopo Benincasa) Date: Thu, 5 Aug 2021 10:38:15 -0500 Subject: Please remove me from your mailing list Message-ID: Please remove me from your mailing list. From yangovip at gmail.com Thu Aug 5 17:08:08 2021 From: yangovip at gmail.com (=?UTF-8?Q?Yango_Fran=C3=A7a_de_Freitas?=) Date: Thu, 5 Aug 2021 14:08:08 -0300 Subject: Please remove me from your mailing list In-Reply-To: References: Message-ID: me too Em qui., 5 de ago. de 2021 ?s 12:41, Jacopo Benincasa < mantheprogrammer at gmail.com> escreveu: > Please remove me from your mailing list. > From philip.race at oracle.com Thu Aug 5 18:31:35 2021 From: philip.race at oracle.com (Philip Race) Date: Thu, 5 Aug 2021 11:31:35 -0700 Subject: Please remove me from your mailing list In-Reply-To: References: Message-ID: <8e6f31d3-6402-3b53-8ee4-10149bb6d1e0@oracle.com> Unsubscribing is "self-service. Visit https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev and look near the bottom of the page for the section labelled "To unsubscribe from openjfx-dev, get a password reminder, or change your subscription options enter your subscription email address:" and enter your email address in the field and follow instructions on subsequent pages to unsubscribe. -phil. On 8/5/21 10:08 AM, Yango Fran?a de Freitas wrote: > me too > > > Em qui., 5 de ago. de 2021 ?s 12:41, Jacopo Benincasa < > mantheprogrammer at gmail.com> escreveu: > >> Please remove me from your mailing list. >> From tsayao at openjdk.java.net Thu Aug 5 23:43:44 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 5 Aug 2021 23:43:44 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation Message-ID: Found the problem thru this path: **WindowStage.java** final void handleFocusDisabled() { if (activeWindows.isEmpty()) { return; } WindowStage window = activeWindows.get(activeWindows.size() - 1); window.setIconified(false); window.requestToFront(); window.requestFocus(); } **glass_window.cpp** void WindowContextBase::process_focus(GdkEventFocus* event) { ... if (jwindow) { if (!event->in || isEnabled()) { mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); CHECK_JNI_EXCEPTION(mainEnv) } else { mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); CHECK_JNI_EXCEPTION(mainEnv) } } } So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). The docs states: /** * Enables or disables the window. * * A disabled window is unfocusable by definition. * Also, key or mouse events aren't generated for disabled windows. * * When a user tries to activate a disabled window, or the window gets * accidentally brought to the top of the stacking order, the window * generates the FOCUS_DISABLED window event. A Glass client should react * to this event and bring the currently active modal blocker of the * disabled window to top by calling blocker's minimize(false), toFront(), * and requestFocus() methods. It may also 'blink' the blocker window to * further attract user's attention. * ..... So I guess the C++ side is ok, java side on `handleFocusDisabled` looks fishy to me, but not sure about that. ------------- Commit messages: - Fix for JDK-8271054 - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - Merge pull request #15 from openjdk/master - Merge pull request #14 from openjdk/master - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - ... and 8 more: https://git.openjdk.java.net/jfx/compare/ba61a173...3770f101 Changes: https://git.openjdk.java.net/jfx/pull/598/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271054 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Fri Aug 6 01:11:28 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 6 Aug 2021 01:11:28 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. ![image](https://user-images.githubusercontent.com/30704286/128440714-1a1cb6c0-1c9c-45f4-a9ee-5385a48ca31d.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Fri Aug 6 02:22:43 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 6 Aug 2021 02:22:43 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels Message-ID: It seems raw images need to be converted BRGA -> RGBA. It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. It simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8). The existing path seems to be converting again. Run the issue sample with `-Djdk.gtk.version=2` to test. ------------- Commit messages: - Fix JDK-8271398 - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - Merge pull request #15 from openjdk/master - Merge pull request #14 from openjdk/master - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - ... and 8 more: https://git.openjdk.java.net/jfx/compare/ba61a173...de2d8ddc Changes: https://git.openjdk.java.net/jfx/pull/599/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271398 Stats: 24 lines in 1 file changed: 5 ins; 18 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599 From thiago.sayao at gmail.com Fri Aug 6 02:35:50 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 5 Aug 2021 23:35:50 -0300 Subject: apps compilation fails on ubuntu 20.04 Message-ID: Hi Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? I have: Apache Ant(TM) version 1.10.7 compiled on October 24 2019 openjdk version "16.0.1" 2021-04-20 I want to run the test apps. -do-compile: [javac] Compiling 143 source files to /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes [javac] error: invalid flag: @/home/tsayao/IdeaProjects/jfx/build/compile.args [javac] Usage: javac [javac] use --help for a list of possible options Thanks. From pbansal at openjdk.java.net Fri Aug 6 05:33:29 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 6 Aug 2021 05:33:29 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 02:18:38 GMT, Thiago Milczarek Sayao wrote: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > It simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8). The existing path seems to be converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test. I will look at this. Meanwhile, could you please write an automated system test for this? ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From dev.infeo at mailbox.org Fri Aug 6 08:53:17 2021 From: dev.infeo at mailbox.org (dev.infeo at mailbox.org) Date: Fri, 6 Aug 2021 10:53:17 +0200 (CEST) Subject: Enhancements for JavaFX 18 Message-ID: <1557220084.27822.1628239997209@office.mailbox.org> +1. Implementing the system tray api in JavaFX and not relying on AWT would be nice thing. On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel < sebastian.stenzel at gmail.com https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev> wrote: > +1 for a proper system tray api > > > Am 04.08.2021 um 16:47 schrieb Scott Palmer : > > > > +1 to that. > > > > I would also like to see some progress with system tray support and > microphone & webcam access. > > > > Scott > > > >> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg < > fastegal at swingempire.de https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev> wrote: > >> > >> > >> my suggestion would be the longstanding commit-edit-on-focus-lost - > solved by an enhancement to the editing api on virtualized controls > >> > >> -- Jeanette > >> > >> Zitat von Kevin Rushforth : > >> > >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I would > like to get some of the outstanding enhancement requests moving over the > next few weeks. > >>> > >>> Specifically, I'd like to see the following proceed: > >>> > >>> * Transparent backgrounds in WebView > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > >>> PR: https://github.com/openjdk/jfx/pull/563 > >>> > >>> * Add DirectionalLight > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > >>> PR: https://github.com/openjdk/jfx/pull/548 > >>> > >>> * CSS pseudoclasses :focus-visible and :focus-within > >>> https://bugs.openjdk.java.net/browse/JDK-8268225 > >>> PR: https://github.com/openjdk/jfx/pull/475 > >>> > >>> * Improve property system to facilitate correct usage (minus the > binary incompatible API change) > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) > >>> > >>> And maybe the following: > >>> > >>> * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > >>> > >>> * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > >>> > >>> There are probably others I'm forgetting. > >>> > >>> Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > >>> > >>> -- Kevin > >> > >> > >> > > > From nlisker at gmail.com Fri Aug 6 18:21:20 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 6 Aug 2021 21:21:20 +0300 Subject: Formatter of LocalDateTimeStringConverter Message-ID: I'm looking at [1]. The logic to create the formatter seems fishy. First, a formatter is created. Then, if dateStyle is null, it tries to create a new formatter that has its year digits fixed. However, this ignores the created formatter. Is this correct behavior and it's just the flow control that is off? [1] https://github.com/openjdk/jfx/blob/ba61a17307d48d373fd8faa169ed16821e81c0fd/modules/javafx.base/src/main/java/javafx/util/converter/LocalDateTimeStringConverter.java#L261 From tsayao at openjdk.java.net Fri Aug 6 20:47:33 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 6 Aug 2021 20:47:33 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 05:30:39 GMT, Pankaj Bansal wrote: > I will look at this. Meanwhile, could you please write an automated system test for this? Sure, I would provide it, but in the past drag and drop tests were not possible. Any ideas? ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From pbansal at openjdk.java.net Sat Aug 7 18:56:27 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 7 Aug 2021 18:56:27 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 20:44:23 GMT, Thiago Milczarek Sayao wrote: > > I will look at this. Meanwhile, could you please write an automated system test for this? > > Sure, I would provide it, but in the past drag and drop tests were not possible. Any ideas? I think it should be possible to write an automated testcase in this case. Find center of window, move mouse to the location and do mouse click (without release). Then move mouse out of window to some location. Afterwards, get the pixel color at mouse location and do mouse release. Looks like it should be possible. Please let me know if there is some problem, I will also try to write one on my end. ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From sproket at videotron.ca Sun Aug 8 10:59:55 2021 From: sproket at videotron.ca (Dan Howard) Date: Sun, 8 Aug 2021 06:59:55 -0400 Subject: Formatter of LocalDateTimeStringConverter In-Reply-To: References: Message-ID: That does look weird. It's the same looking back at the history. On 8/6/2021 2:21 PM, Nir Lisker wrote: > I'm looking at [1]. The logic to create the formatter seems fishy. First, a > formatter is created. Then, if dateStyle is null, it tries to create a new > formatter that has its year digits fixed. However, this ignores the > created formatter. Is this correct behavior and it's just the flow control > that is off? > > [1] > https://github.com/openjdk/jfx/blob/ba61a17307d48d373fd8faa169ed16821e81c0fd/modules/javafx.base/src/main/java/javafx/util/converter/LocalDateTimeStringConverter.java#L261 From youngty1997 at gmail.com Mon Aug 9 04:40:00 2021 From: youngty1997 at gmail.com (Ty Young) Date: Sun, 8 Aug 2021 23:40:00 -0500 Subject: Enhancements for JavaFX 18 In-Reply-To: <6a76080f-d3bb-e9bd-e914-17ca75767628@xs4all.nl> References: <999a48e4-ec31-d5a5-aded-0049fbcb00c0@gmail.com> <6a76080f-d3bb-e9bd-e914-17ca75767628@xs4all.nl> Message-ID: <713a42b7-cf04-ee0d-06eb-6d4337e41d64@gmail.com> On 8/4/21 5:35 PM, John Hendrikx wrote: > > > On 04/08/2021 19:05, Ty Young wrote: > >> * A late "showing" property for when the application has been shown to >> the user and all first viewing UI components have had their sizes >> calculated and are being displayed, if it doesn't exist already and I'm >> completely blind. > > Do you mean a property that is true if the current node is visible, > attached to a scene which is attached to a window which is currently > showing? > > This can be achieved with a small util that takes a Node and returns > an ObservableValue.? I can dig up the code, I use this all > the time to automatically unbind bindings when UI parts become invisible. Something like that, yes. > > --John From youngty1997 at gmail.com Mon Aug 9 04:43:27 2021 From: youngty1997 at gmail.com (Ty Young) Date: Sun, 8 Aug 2021 23:43:27 -0500 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <3af588e2-e263-94d5-c37c-13025addd6e6@gmail.com> Oh, and to add one more feature: ability to add context menu to specific TreeView cells without going through cell factory. On 7/30/21 7:56 AM, Kevin Rushforth wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may > be delays as some people are out at various times (including me), but > I would like to get some of the outstanding enhancement requests > moving over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the > binary incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > > -- Kevin > > From pedro.duquevieira at gmail.com Mon Aug 9 10:44:09 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 9 Aug 2021 11:44:09 +0100 Subject: Enhancements for JavaFX 18 Message-ID: Hi! @Phil Race If you're going to tackle font rendering, would it also be possible to work on Windows font rendering? I find that Windows font rendering is generally much worse than Mac's. One example is, for instance, trying to render "Segoe UI" (the Windows default font) , or "Segoe UI Light" font (or whatever variant) with a big font size. The font appears pixelated.. Thanks, > +1. It is something I intend to get to for 18. -phil. On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: > > May I humbly suggest fixing font rendering color fringe issues on macOS -- Pedro Duque Vieira - https://www.pixelduke.com From falcon.sheep at gmail.com Mon Aug 9 13:09:48 2021 From: falcon.sheep at gmail.com (Abu Abdullah) Date: Mon, 9 Aug 2021 17:09:48 +0400 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: I would really like to see opus codec support for the media playback On Fri, 30 Jul 2021, 4:59 pm Kevin Rushforth, wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > > From philip.race at oracle.com Mon Aug 9 15:06:14 2021 From: philip.race at oracle.com (Philip Race) Date: Mon, 9 Aug 2021 08:06:14 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com> That would be a separate piece of work.? I can't imagine much if any overlap. Is there a useful bug ID for what you are referring to ? The glyph images come from DirectWrite on Windows so I am not sure if there's something specific .. -phil. On 8/9/21 3:44 AM, Pedro Duque Vieira wrote: > Hi! > > @Phil Race ?If you're going to tackle > font rendering, would it also be possible to work on Windows font > rendering? I find that Windows font rendering is generally much worse > than Mac's. > > One example is, for instance, trying to render "Segoe UI" (the Windows > default font)?, or "Segoe UI Light"??font (or whatever variant) with a > big font size. The font appears pixelated.. > > Thanks, > > +1. It is something I intend to get to for 18. > > > -phil. > > > On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: > > May I humbly suggest fixing font rendering color fringe issues > on macOS > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From arapte at openjdk.java.net Tue Aug 10 05:44:34 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 10 Aug 2021 05:44:34 GMT Subject: [jfx17] RFR: 8271485: Javadoc "Method Summary" table is misaligned if overridden JDK method has {@inheritDoc} tag In-Reply-To: References: Message-ID: <3hwN_uAKZhEY_aLzBlGnLP_NvgcUGOunlkYi3Q9FCIs=.0ee501ec-795a-43f1-a55d-35f49f208cec@github.com> On Thu, 29 Jul 2021 16:18:24 GMT, Kevin Rushforth wrote: > As noted in the JBS bug report, the javadoc-generated HTML table for a class is messed up if any method is overridden from a core JDK class and has the `{@inheritDoc}` tag. For example, the following taken from the [Background](https://github.com/openjdk/jfx/blob/jfx17/modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java#L622) class provokes this bug: > > > /** > * {@inheritDoc} > */ > @Override public boolean equals(Object o) { > > > The proposed fix is to stop generating javadocs for overridden methods with no spec change. This matches how the JDK docs have been generated since JDK 10. See [JDK-8157000](https://bugs.openjdk.java.net/browse/JDK-8157000). This is done by running `javadoc` with the `--override-methods=summary` option. > > There is no useful information generated for such overridden methods regardless of whether or not they use the `{@inheritDoc}` tag, so this fix also addresses the problem of having methods with no description. > > See the attached "before" and "after" images. > > Before: > > ![javadoc-before](https://user-images.githubusercontent.com/34689748/127527754-ae5c529a-8c49-47a2-b595-5e423f5c9c49.png) > > After: > > ![javadoc-after](https://user-images.githubusercontent.com/34689748/127527789-c97c4689-154f-4ed0-a4a1-5dfdfde0d9d2.png) Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/593 From johan.vos at gluonhq.com Tue Aug 10 10:46:02 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 10 Aug 2021 12:46:02 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: I think we (everyone committing/reviewing in openjdk/jfx) did a great job with the 17-work: an impressive amount of old and annoying bugs are fixed. For 18 and beyond, I believe we have to keep working on those old issues -- at least if they are still relevant. Also, I am 100% ok with the list of issues Kevin mentioned that need to be moved forward now. Apart from that, I want to have support for Metal and Wayland in JavaFX 18. - Johan On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > > From pedro.duquevieira at gmail.com Tue Aug 10 10:56:42 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 10 Aug 2021 11:56:42 +0100 Subject: Enhancements for JavaFX 18 In-Reply-To: <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com> References: <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com> Message-ID: I've filed the bug a long time ago so I can't remember exactly the bug ID or the title I gave it. Do you want me to file a new one? Do you want me to attach sample images (I think you need to do some work around to attach images to a javafx bug report?)? Thanks Philip On Mon, Aug 9, 2021 at 4:06 PM Philip Race wrote: > That would be a separate piece of work. I can't imagine much if any > overlap. > Is there a useful bug ID for what you are referring to ? > The glyph images come from DirectWrite on Windows so I am not sure if > there's something specific .. > > -phil. > > On 8/9/21 3:44 AM, Pedro Duque Vieira wrote: > > Hi! > > @Phil Race If you're going to tackle font > rendering, would it also be possible to work on Windows font rendering? I > find that Windows font rendering is generally much worse than Mac's. > > One example is, for instance, trying to render "Segoe UI" (the Windows > default font) , or "Segoe UI Light" font (or whatever variant) with a big > font size. The font appears pixelated.. > > Thanks, > > >> +1. It is something I intend to get to for 18. > > > -phil. > > > On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: >> > May I humbly suggest fixing font rendering color fringe issues on macOS > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > > > -- Pedro Duque Vieira - https://www.pixelduke.com From kcr at openjdk.java.net Tue Aug 10 12:23:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Aug 2021 12:23:34 GMT Subject: [jfx17] Integrated: 8271485: Javadoc "Method Summary" table is misaligned if overridden JDK method has {@inheritDoc} tag In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 16:18:24 GMT, Kevin Rushforth wrote: > As noted in the JBS bug report, the javadoc-generated HTML table for a class is messed up if any method is overridden from a core JDK class and has the `{@inheritDoc}` tag. For example, the following taken from the [Background](https://github.com/openjdk/jfx/blob/jfx17/modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java#L622) class provokes this bug: > > > /** > * {@inheritDoc} > */ > @Override public boolean equals(Object o) { > > > The proposed fix is to stop generating javadocs for overridden methods with no spec change. This matches how the JDK docs have been generated since JDK 10. See [JDK-8157000](https://bugs.openjdk.java.net/browse/JDK-8157000). This is done by running `javadoc` with the `--override-methods=summary` option. > > There is no useful information generated for such overridden methods regardless of whether or not they use the `{@inheritDoc}` tag, so this fix also addresses the problem of having methods with no description. > > See the attached "before" and "after" images. > > Before: > > ![javadoc-before](https://user-images.githubusercontent.com/34689748/127527754-ae5c529a-8c49-47a2-b595-5e423f5c9c49.png) > > After: > > ![javadoc-after](https://user-images.githubusercontent.com/34689748/127527789-c97c4689-154f-4ed0-a4a1-5dfdfde0d9d2.png) This pull request has now been integrated. Changeset: fbeb0bbd Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/fbeb0bbd1cec6616b01e8376013f833a191124e8 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8271485: Javadoc "Method Summary" table is misaligned if overridden JDK method has {@inheritDoc} tag Do not generate javadocs for overridden methods with no spec change Reviewed-by: aghaisas, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/593 From kcr at openjdk.java.net Tue Aug 10 12:48:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Aug 2021 12:48:33 GMT Subject: RFR: Merge jfx17 Message-ID: Merge `jfx17` branch into `master`. ------------- Commit messages: - Merge jfx17 - 8271485: Javadoc "Method Summary" table is misaligned if overridden JDK method has {@inheritDoc} tag - 8250590: Classes and methods in the javafx.css package are missing documentation The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/600/files Stats: 588 lines in 34 files changed: 515 ins; 4 del; 69 mod Patch: https://git.openjdk.java.net/jfx/pull/600.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/600/head:pull/600 PR: https://git.openjdk.java.net/jfx/pull/600 From kcr at openjdk.java.net Tue Aug 10 13:00:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Aug 2021 13:00:43 GMT Subject: RFR: Merge jfx17 [v2] In-Reply-To: References: Message-ID: <6bTZHchaATj2XhZ7siJ29DKl6oP8_Xe4a0ggkBd5ifs=.861b5b68-3a50-4cb5-beaf-2f369ff0827a@github.com> > Merge `jfx17` 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 20 additional commits since the last revision: - Merge jfx17 - 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit Reviewed-by: kcr - Merge - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's Reviewed-by: jvos, kcr - 8240506: TextFieldSkin/Behavior: misbehavior on switching skin Reviewed-by: mhanl, arapte - Merge - 8270839: Remove deprecated implementation methods from Scene Reviewed-by: arapte, aghaisas - 8269374: Menu inoperable after setting stage to second monitor Reviewed-by: kcr, arapte - Merge - 8270838: Remove deprecated protected access members from DateTimeStringConverter Reviewed-by: kcr, aghaisas - ... and 10 more: https://git.openjdk.java.net/jfx/compare/5d3e3ad5...8ad579b6 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/600/files - new: https://git.openjdk.java.net/jfx/pull/600/files/8ad579b6..8ad579b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=600&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=600&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/600.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/600/head:pull/600 PR: https://git.openjdk.java.net/jfx/pull/600 From kcr at openjdk.java.net Tue Aug 10 13:00:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Aug 2021 13:00:44 GMT Subject: Integrated: Merge jfx17 In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 12:43:50 GMT, Kevin Rushforth wrote: > Merge `jfx17` branch into `master`. This pull request has now been integrated. Changeset: 20079b13 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/20079b1340c966779f383a60e56c962f3d5ff5e2 Stats: 588 lines in 34 files changed: 515 ins; 4 del; 69 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/600 From thiago.sayao at gmail.com Tue Aug 10 15:24:06 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 10 Aug 2021 12:24:06 -0300 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: Hi Johan, Would you prefer a pure Wayland backend or support it with gdk/GTK on top of the current glass backend? Cheers Em ter, 10 de ago de 2021 07:52, Johan Vos escreveu: > I think we (everyone committing/reviewing in openjdk/jfx) did a great job > with the 17-work: an impressive amount of old and annoying bugs are fixed. > For 18 and beyond, I believe we have to keep working on those old issues -- > at least if they are still relevant. > Also, I am 100% ok with the list of issues Kevin mentioned that need to be > moved forward now. > > Apart from that, I want to have support for Metal and Wayland in JavaFX 18. > > - Johan > > On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth < > kevin.rushforth at oracle.com> > wrote: > > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > > and enhancement requests for JavaFX 18. It's the summer, so there may be > > delays as some people are out at various times (including me), but I > > would like to get some of the outstanding enhancement requests moving > > over the next few weeks. > > > > Specifically, I'd like to see the following proceed: > > > > * Transparent backgrounds in WebView > > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > PR: https://github.com/openjdk/jfx/pull/563 > > > > * Add DirectionalLight > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > PR: https://github.com/openjdk/jfx/pull/548 > > > > * CSS pseudoclasses :focus-visible and :focus-within > > https://bugs.openjdk.java.net/browse/JDK-8268225 > > PR: https://github.com/openjdk/jfx/pull/475 > > > > * Improve property system to facilitate correct usage (minus the binary > > incompatible API change) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > > > And maybe the following: > > > > * Add CSS themes as a first-class concept (need a consensus on how to > > proceed) > > > > * Undecorated interactive stage style (still in early discussion, but > > the concept looks interesting and useful) > > > > There are probably others I'm forgetting. > > > > Each of the above should be discussed in their own thread on openjfx-dev > > rather than a reply to this thread. > > > > -- Kevin > > > > > > > From kevin.rushforth at oracle.com Tue Aug 10 15:44:18 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Aug 2021 08:44:18 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: Johan can comment on the details, but I think that is a matter of investigation. As with the AWT work which is under discussion, there are two related, but different deliverables that should be looked at: 1. Running the existing JavaFX GTK port on Wayland in X11 compatibility mode 2. A native JavaFX Wayland port For both of them, we need a solution to the same "robot" problems that AWT and other libraries face (there is no standard way to control the mouse or to read pixels from the screen). The fact that we already use GTK for most things should make #2 easier, and it might be able to share a lot of the code, but it very likely will need to be its ow backend, since it can't use X11. In thinking out loud, one thing to consider might be to have a single glass GTK platform with different native libraries for Wayland and X11, since we already have that support to handle gtk2 and gtk3. Maybe something like: gtk2 (legacy and only for X11) gtk3-x11 gtk3-wayland gtk4-x11 gtk4-wayland Not sure whether that makes sense or not. I imagine that 1 should be feasible in the JavaFX 18 time frame. A native Wayland port will be a lot of work, but since JavaFX already uses GTK for most things, it should be significantly less work than AWT will be. -- Kevin On 8/10/2021 8:24 AM, Thiago Milczarek Say?o wrote: > Hi Johan, > > Would you prefer a pure Wayland backend or support it with gdk/GTK on top > of the current glass backend? > > Cheers > > Em ter, 10 de ago de 2021 07:52, Johan Vos escreveu: > >> I think we (everyone committing/reviewing in openjdk/jfx) did a great job >> with the 17-work: an impressive amount of old and annoying bugs are fixed. >> For 18 and beyond, I believe we have to keep working on those old issues -- >> at least if they are still relevant. >> Also, I am 100% ok with the list of issues Kevin mentioned that need to be >> moved forward now. >> >> Apart from that, I want to have support for Metal and Wayland in JavaFX 18. >> >> - Johan >> >> On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> >> wrote: >> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >>> and enhancement requests for JavaFX 18. It's the summer, so there may be >>> delays as some people are out at various times (including me), but I >>> would like to get some of the outstanding enhancement requests moving >>> over the next few weeks. >>> >>> Specifically, I'd like to see the following proceed: >>> >>> * Transparent backgrounds in WebView >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> PR: https://github.com/openjdk/jfx/pull/563 >>> >>> * Add DirectionalLight >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> PR: https://github.com/openjdk/jfx/pull/548 >>> >>> * CSS pseudoclasses :focus-visible and :focus-within >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> PR: https://github.com/openjdk/jfx/pull/475 >>> >>> * Improve property system to facilitate correct usage (minus the binary >>> incompatible API change) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>> >>> And maybe the following: >>> >>> * Add CSS themes as a first-class concept (need a consensus on how to >>> proceed) >>> >>> * Undecorated interactive stage style (still in early discussion, but >>> the concept looks interesting and useful) >>> >>> There are probably others I'm forgetting. >>> >>> Each of the above should be discussed in their own thread on openjfx-dev >>> rather than a reply to this thread. >>> >>> -- Kevin >>> >>> >>> From kevin.rushforth at oracle.com Tue Aug 10 16:13:17 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Aug 2021 09:13:17 -0700 Subject: [External] : Re: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <712561db-9e83-33d5-e694-e9f37194cb98@oracle.com> I think having prototypes of both a Metal pipeline and native Wayland would be good in the JavaFX 18 time frame. We hope to have something to share on Metal in a month or so. The JavaFX Metal pipeline can leverage some of the work done for Java2D in the Lanai project. I'll let Johan comment on what he is thinking of for Wayland. As I mentioned in another thread, this will be a lot of work (although not as much as AWT / Swing / Java2D). -- Kevin On 8/10/2021 3:46 AM, Johan Vos wrote: > I think we (everyone committing/reviewing in openjdk/jfx) did a great > job with the 17-work: an impressive amount of old and annoying bugs > are fixed. > For 18 and beyond, I believe we have to keep working on those old > issues -- at least if they are still relevant. > Also, I am 100% ok with the list of issues Kevin mentioned that need > to be moved forward now. > > Apart from that, I want to have support for Metal and Wayland in > JavaFX 18. > > - Johan > > On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth > > wrote: > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug > fixes > and enhancement requests for JavaFX 18. It's the summer, so there > may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > PR: https://github.com/openjdk/jfx/pull/563 > > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > PR: https://github.com/openjdk/jfx/pull/548 > > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > > PR: https://github.com/openjdk/jfx/pull/475 > > > * Improve property system to facilitate correct usage (minus the > binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > PR: https://github.com/openjdk/jfx/pull/590 > > (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on > openjfx-dev > rather than a reply to this thread. > > -- Kevin > > From kevin.rushforth at oracle.com Tue Aug 10 16:19:46 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Aug 2021 09:19:46 -0700 Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: <88b0c76a-fcf6-602e-58ec-41844cc315da@oracle.com> On 8/7/2021 11:56 AM, Pankaj Bansal wrote: > On Fri, 6 Aug 2021 20:44:23 GMT, Thiago Milczarek Sayao wrote: > >>> I will look at this. Meanwhile, could you please write an automated system test for this? >> Sure, I would provide it, but in the past drag and drop tests were not possible. Any ideas? > I think it should be possible to write an automated testcase in this case. Find center of window, move mouse to the location and do mouse click (without release). Then move mouse out of window to some location. Afterwards, get the pixel color at mouse location and do mouse release. Looks like it should be possible. Please let me know if there is some problem, I will also try to write one on my end. If this does turn out to be too complex, we can file a new JBS issue to track adding an automated test. In which case, a manual test could be added as part of this PR. -- Kevin From philip.race at oracle.com Tue Aug 10 16:50:21 2021 From: philip.race at oracle.com (Philip Race) Date: Tue, 10 Aug 2021 09:50:21 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com> Message-ID: <5678932c-03be-5c32-6e29-ec6f3bc712fc@oracle.com> Well .. if you know you were the reporter, then it narrows down the JBS search from thousands to less than 10 :-) https://bugs.openjdk.java.net/browse/JDK-8092298 Near as I can tell, that is an issue where we are comparing the FX use of DirectWrite with unknown usage and configuration of some Windows bundled apps and maybe we aren't even sure it is the same font ..? there was a lot of back and forth there. -phil. On 8/10/21 3:56 AM, Pedro Duque Vieira wrote: > I've filed the bug a long time ago so I can't remember exactly the bug > ID or the title I gave it. > > Do you want me to file a new one? Do you want me to attach sample > images (I think you need to do some work around to attach images to a > javafx bug report?)? > > Thanks Philip > > On Mon, Aug 9, 2021 at 4:06 PM Philip Race > wrote: > > That would be a separate piece of work.? I can't imagine much if > any overlap. > Is there a useful bug ID for what you are referring to ? > The glyph images come from DirectWrite on Windows so I am not sure > if there's something specific .. > > -phil. > > On 8/9/21 3:44 AM, Pedro Duque Vieira wrote: >> Hi! >> >> @Phil Race ?If you're going to >> tackle font rendering, would it also be possible to work on >> Windows font rendering? I find that Windows font rendering is >> generally much worse than Mac's. >> >> One example is, for instance, trying to render "Segoe UI" (the >> Windows default font)?, or "Segoe UI Light"??font (or whatever >> variant) with a big font size. The font appears pixelated.. >> >> Thanks, >> >> +1. It is something I intend to get to for 18. >> >> >> -phil. >> >> >> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: >> > May I humbly suggest fixing font rendering color fringe >> issues on macOS >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From aghaisas at openjdk.java.net Wed Aug 11 08:41:30 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 11 Aug 2021 08:41:30 GMT Subject: RFR: 8271484: Tree-/TableCell: NPE when accessing edit event from startEdit In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 14:11:15 GMT, Jeanette Winzenburg wrote: > The NPE was an indirect effect: > > - the bug on part of the cell was an incorrect (== missing) edit location in cellEditEvent - that's fixed in this PR > - a related bug is on part of the implementation of CellEditEvent (assuming that TablePosition != null, [JDK-8269871](https://bugs.openjdk.java.net/browse/JDK-8269871) which is not addressed in this PR > > Fix is to use the cell's state at startEdit for creating the editing location, added tests starting the edit on the cell that failed/passed before/after the fix, also added sanity tests with starting edit on the control that passed before/after. Marked as reviewed by aghaisas (Reviewer). The fix looks good to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/592 From fastegal at openjdk.java.net Wed Aug 11 09:32:25 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 11 Aug 2021 09:32:25 GMT Subject: RFR: 8271484: Tree-/TableCell: NPE when accessing edit event from startEdit In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 08:38:45 GMT, Ajit Ghaisas wrote: > > > The fix looks good to me. thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/592 From fastegal at openjdk.java.net Wed Aug 11 09:32:25 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 11 Aug 2021 09:32:25 GMT Subject: Integrated: 8271484: Tree-/TableCell: NPE when accessing edit event from startEdit In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 14:11:15 GMT, Jeanette Winzenburg wrote: > The NPE was an indirect effect: > > - the bug on part of the cell was an incorrect (== missing) edit location in cellEditEvent - that's fixed in this PR > - a related bug is on part of the implementation of CellEditEvent (assuming that TablePosition != null, [JDK-8269871](https://bugs.openjdk.java.net/browse/JDK-8269871) which is not addressed in this PR > > Fix is to use the cell's state at startEdit for creating the editing location, added tests starting the edit on the cell that failed/passed before/after the fix, also added sanity tests with starting edit on the control that passed before/after. This pull request has now been integrated. Changeset: 852d2875 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/852d2875248040ea5eff2b41bd23a4fde02486a9 Stats: 57 lines in 4 files changed: 53 ins; 2 del; 2 mod 8271484: Tree-/TableCell: NPE when accessing edit event from startEdit Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/592 From kcr at openjdk.java.net Wed Aug 11 13:15:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 Aug 2021 13:15:42 GMT Subject: [jfx11u] Integrated: 8270992: Change JavaFX release version in jfx11u to 11.0.13 Message-ID: Update the fix version to 11.0.13 for the start of a new release. ------------- Commit messages: - 8270992: Change JavaFX release version in jfx11u to 11.0.13 Changes: https://git.openjdk.java.net/jfx11u/pull/26/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=26&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270992 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/26.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/26/head:pull/26 PR: https://git.openjdk.java.net/jfx11u/pull/26 From jvos at openjdk.java.net Wed Aug 11 13:15:43 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 11 Aug 2021 13:15:43 GMT Subject: [jfx11u] Integrated: 8270992: Change JavaFX release version in jfx11u to 11.0.13 In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 13:04:02 GMT, Kevin Rushforth wrote: > Update the fix version to 11.0.13 for the start of a new release. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/26 From kcr at openjdk.java.net Wed Aug 11 13:15:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 Aug 2021 13:15:43 GMT Subject: [jfx11u] Integrated: 8270992: Change JavaFX release version in jfx11u to 11.0.13 In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 13:04:02 GMT, Kevin Rushforth wrote: > Update the fix version to 11.0.13 for the start of a new release. This pull request has now been integrated. Changeset: 72df39f3 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/72df39f31ce4132ee09735a8e2a7fb2529172239 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8270992: Change JavaFX release version in jfx11u to 11.0.13 Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx11u/pull/26 From pedro.duquevieira at gmail.com Wed Aug 11 15:14:59 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 11 Aug 2021 16:14:59 +0100 Subject: Enhancements for JavaFX 18 In-Reply-To: <5678932c-03be-5c32-6e29-ec6f3bc712fc@oracle.com> References: <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com> <5678932c-03be-5c32-6e29-ec6f3bc712fc@oracle.com> Message-ID: OK thanks Phillip! Sorry, I might not have done the best job in reporting the issue back then (it's been a while, it was in 2014) :-) I have an example of the exact same Segoe UI font. One is from Photoshop using the text tool with a selected font and the other is from a JavaFX using the same font. The difference is very noticeable. Would you be interested in seeing the two pictures? If so, how can I share them? Thanks again, On Tue, Aug 10, 2021 at 5:50 PM Philip Race wrote: > Well .. if you know you were the reporter, then it narrows down the JBS > search from thousands to less than 10 :-) > > https://bugs.openjdk.java.net/browse/JDK-8092298 > > Near as I can tell, that is an issue where we are comparing the FX use of > DirectWrite with > unknown usage and configuration of some Windows bundled apps and maybe we > aren't > even sure it is the same font .. there was a lot of back and forth there. > > -phil. > > On 8/10/21 3:56 AM, Pedro Duque Vieira wrote: > > I've filed the bug a long time ago so I can't remember exactly the bug ID > or the title I gave it. > > Do you want me to file a new one? Do you want me to attach sample images > (I think you need to do some work around to attach images to a javafx bug > report?)? > > Thanks Philip > > On Mon, Aug 9, 2021 at 4:06 PM Philip Race wrote: > >> That would be a separate piece of work. I can't imagine much if any >> overlap. >> Is there a useful bug ID for what you are referring to ? >> The glyph images come from DirectWrite on Windows so I am not sure if >> there's something specific .. >> >> -phil. >> >> On 8/9/21 3:44 AM, Pedro Duque Vieira wrote: >> >> Hi! >> >> @Phil Race If you're going to tackle font >> rendering, would it also be possible to work on Windows font rendering? I >> find that Windows font rendering is generally much worse than Mac's. >> >> One example is, for instance, trying to render "Segoe UI" (the Windows >> default font) , or "Segoe UI Light" font (or whatever variant) with a big >> font size. The font appears pixelated.. >> >> Thanks, >> >> >>> +1. It is something I intend to get to for 18. >> >> >> -phil. >> >> >> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: >>> > May I humbly suggest fixing font rendering color fringe issues on macOS >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> >> >> > > -- > Pedro Duque Vieira - https://www.pixelduke.com > > > -- Pedro Duque Vieira - https://www.pixelduke.com From pedro.duquevieira at gmail.com Wed Aug 11 15:17:03 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 11 Aug 2021 16:17:03 +0100 Subject: Enhancements for JavaFX 18 In-Reply-To: References: <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com> <5678932c-03be-5c32-6e29-ec6f3bc712fc@oracle.com> Message-ID: .. on one client project I'm involved in, I ended up having to use a static image instead of rendering the text through JavaFX because of the difference in text rendering quality. On Wed, Aug 11, 2021 at 4:14 PM Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > OK thanks Phillip! > > Sorry, I might not have done the best job in reporting the issue back then > (it's been a while, it was in 2014) :-) > > I have an example of the exact same Segoe UI font. One is from Photoshop > using the text tool with a selected font and the other is from a JavaFX > using the same font. The difference is very noticeable. > Would you be interested in seeing the two pictures? If so, how can I share > them? > > Thanks again, > > On Tue, Aug 10, 2021 at 5:50 PM Philip Race > wrote: > >> Well .. if you know you were the reporter, then it narrows down the JBS >> search from thousands to less than 10 :-) >> >> https://bugs.openjdk.java.net/browse/JDK-8092298 >> >> Near as I can tell, that is an issue where we are comparing the FX use of >> DirectWrite with >> unknown usage and configuration of some Windows bundled apps and maybe we >> aren't >> even sure it is the same font .. there was a lot of back and forth there. >> >> -phil. >> >> On 8/10/21 3:56 AM, Pedro Duque Vieira wrote: >> >> I've filed the bug a long time ago so I can't remember exactly the bug ID >> or the title I gave it. >> >> Do you want me to file a new one? Do you want me to attach sample images >> (I think you need to do some work around to attach images to a javafx bug >> report?)? >> >> Thanks Philip >> >> On Mon, Aug 9, 2021 at 4:06 PM Philip Race >> wrote: >> >>> That would be a separate piece of work. I can't imagine much if any >>> overlap. >>> Is there a useful bug ID for what you are referring to ? >>> The glyph images come from DirectWrite on Windows so I am not sure if >>> there's something specific .. >>> >>> -phil. >>> >>> On 8/9/21 3:44 AM, Pedro Duque Vieira wrote: >>> >>> Hi! >>> >>> @Phil Race If you're going to tackle font >>> rendering, would it also be possible to work on Windows font rendering? I >>> find that Windows font rendering is generally much worse than Mac's. >>> >>> One example is, for instance, trying to render "Segoe UI" (the Windows >>> default font) , or "Segoe UI Light" font (or whatever variant) with a big >>> font size. The font appears pixelated.. >>> >>> Thanks, >>> >>> >>>> +1. It is something I intend to get to for 18. >>> >>> >>> -phil. >>> >>> >>> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote: >>>> > May I humbly suggest fixing font rendering color fringe issues on >>>> macOS >>> >>> >>> -- >>> Pedro Duque Vieira - https://www.pixelduke.com >>> >>> >>> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> >> >> > > -- > Pedro Duque Vieira - https://www.pixelduke.com > -- Pedro Duque Vieira - https://www.pixelduke.com From thiago.sayao at gmail.com Wed Aug 11 20:07:48 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 11 Aug 2021 17:07:48 -0300 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: Hi, One feature I will probably submit is touch events on Linux. Cheers. Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > > From dlemmermann at gmail.com Wed Aug 11 20:10:25 2021 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Wed, 11 Aug 2021 22:10:25 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <8060E8A0-B9E7-4BFE-B072-6821C17D1D4C@gmail.com> Frosted glas / blurred background for stages! > Am 11.08.2021 um 22:07 schrieb Thiago Milczarek Say?o : > > Hi, > > One feature I will probably submit is touch events on Linux. > > Cheers. > > Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth < > kevin.rushforth at oracle.com> escreveu: > >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >> and enhancement requests for JavaFX 18. It's the summer, so there may be >> delays as some people are out at various times (including me), but I >> would like to get some of the outstanding enhancement requests moving >> over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the binary >> incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to >> proceed) >> >> * Undecorated interactive stage style (still in early discussion, but >> the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on openjfx-dev >> rather than a reply to this thread. >> >> -- Kevin >> >> >> From nlisker at gmail.com Wed Aug 11 20:17:44 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 11 Aug 2021 23:17:44 +0300 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: > > * Add DirectionalLight > I'll note that this is the first in a line of a few other enhancements, so by no means the only one I'll want to get into 18. The problem is that they change the same areas of the code, so they block each other. On Fri, Jul 30, 2021 at 3:59 PM Kevin Rushforth wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > > From thiago.sayao at gmail.com Wed Aug 11 20:31:28 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 11 Aug 2021 17:31:28 -0300 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: Hi, For the long term solution I would ditch Gtk and use libwayland directly. Inspiration can come from: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/wayland/gdksurface-wayland.c For the short term solution, maybe remove the usage of X11 specific functions and replace for existing Gdk ones and let it handle. By letting gdk handle it it would be necessary to bump up the min required version, so maybe bundle it with javafx. The long term solution is interesting because: * We have the full power of anything supported on wayland; * Gtk is a full toolkit. - Cheers Em ter., 10 de ago. de 2021 ?s 12:45, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > Johan can comment on the details, but I think that is a matter of > investigation. > > As with the AWT work which is under discussion, there are two related, > but different deliverables that should be looked at: > > 1. Running the existing JavaFX GTK port on Wayland in X11 compatibility > mode > 2. A native JavaFX Wayland port > > For both of them, we need a solution to the same "robot" problems that > AWT and other libraries face (there is no standard way to control the > mouse or to read pixels from the screen). > > The fact that we already use GTK for most things should make #2 easier, > and it might be able to share a lot of the code, but it very likely will > need to be its ow backend, since it can't use X11. > > In thinking out loud, one thing to consider might be to have a single > glass GTK platform with different native libraries for Wayland and X11, > since we already have that support to handle gtk2 and gtk3. Maybe > something like: > > gtk2 (legacy and only for X11) > gtk3-x11 > gtk3-wayland > gtk4-x11 > gtk4-wayland > > Not sure whether that makes sense or not. > > I imagine that 1 should be feasible in the JavaFX 18 time frame. A > native Wayland port will be a lot of work, but since JavaFX already uses > GTK for most things, it should be significantly less work than AWT will be. > > -- Kevin > > > On 8/10/2021 8:24 AM, Thiago Milczarek Say?o wrote: > > Hi Johan, > > > > Would you prefer a pure Wayland backend or support it with gdk/GTK on top > > of the current glass backend? > > > > Cheers > > > > Em ter, 10 de ago de 2021 07:52, Johan Vos > escreveu: > > > >> I think we (everyone committing/reviewing in openjdk/jfx) did a great > job > >> with the 17-work: an impressive amount of old and annoying bugs are > fixed. > >> For 18 and beyond, I believe we have to keep working on those old > issues -- > >> at least if they are still relevant. > >> Also, I am 100% ok with the list of issues Kevin mentioned that need to > be > >> moved forward now. > >> > >> Apart from that, I want to have support for Metal and Wayland in JavaFX > 18. > >> > >> - Johan > >> > >> On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth < > >> kevin.rushforth at oracle.com> > >> wrote: > >> > >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > >>> and enhancement requests for JavaFX 18. It's the summer, so there may > be > >>> delays as some people are out at various times (including me), but I > >>> would like to get some of the outstanding enhancement requests moving > >>> over the next few weeks. > >>> > >>> Specifically, I'd like to see the following proceed: > >>> > >>> * Transparent backgrounds in WebView > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > >>> PR: https://github.com/openjdk/jfx/pull/563 > >>> > >>> * Add DirectionalLight > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > >>> PR: https://github.com/openjdk/jfx/pull/548 > >>> > >>> * CSS pseudoclasses :focus-visible and :focus-within > >>> https://bugs.openjdk.java.net/browse/JDK-8268225 > >>> PR: https://github.com/openjdk/jfx/pull/475 > >>> > >>> * Improve property system to facilitate correct usage (minus the binary > >>> incompatible API change) > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) > >>> > >>> And maybe the following: > >>> > >>> * Add CSS themes as a first-class concept (need a consensus on how to > >>> proceed) > >>> > >>> * Undecorated interactive stage style (still in early discussion, but > >>> the concept looks interesting and useful) > >>> > >>> There are probably others I'm forgetting. > >>> > >>> Each of the above should be discussed in their own thread on > openjfx-dev > >>> rather than a reply to this thread. > >>> > >>> -- Kevin > >>> > >>> > >>> > > From nlisker at openjdk.java.net Wed Aug 11 21:33:51 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 11 Aug 2021 21:33:51 GMT Subject: [jfx17] RFR: 8264736: Fix mistakes in FX API docs Message-ID: Fixes documentation mistakes as noted in the JBS issue. ------------- Commit messages: - Additional fix in MouseEvent - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/601/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=601&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264736 Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/601.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/601/head:pull/601 PR: https://git.openjdk.java.net/jfx/pull/601 From tsayao at openjdk.java.net Wed Aug 11 23:42:47 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 11 Aug 2021 23:42:47 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v2] In-Reply-To: References: Message-ID: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Provide test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/de2d8ddc..5530488c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=00-01 Stats: 171 lines in 1 file changed: 171 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Wed Aug 11 23:42:47 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 11 Aug 2021 23:42:47 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: <7wyvJywi-GwKk7XWIrNwf-ne4Xgr-uyDNp7KzUOLQus=.a793e98a-3b30-4bb3-bdfa-61435c44e639@github.com> On Fri, 6 Aug 2021 02:18:38 GMT, Thiago Milczarek Sayao wrote: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Test works on Linux, don't know on other platforms. `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From aghaisas at openjdk.java.net Thu Aug 12 07:55:30 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 12 Aug 2021 07:55:30 GMT Subject: [jfx17] RFR: 8264736: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 21:28:26 GMT, Nir Lisker wrote: > Fixes documentation mistakes as noted in the JBS issue. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/601 From kcr at openjdk.java.net Thu Aug 12 12:27:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 12:27:28 GMT Subject: [jfx17] RFR: 8264736: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 21:28:26 GMT, Nir Lisker wrote: > Fixes documentation mistakes as noted in the JBS issue. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/601 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Aug 12 17:19:39 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 12 Aug 2021 17:19:39 GMT Subject: RFR: JDK-8172095: Let Node.managed become CSS-styleable Message-ID: JDK-8172095: Let Node.managed become CSS-styleable ------------- Commit messages: - JDK-8172095: Let Node.managed become CSS-styleable Changes: https://git.openjdk.java.net/jfx/pull/602/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=602&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8172095 Stats: 39 lines in 4 files changed: 35 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/602.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/602/head:pull/602 PR: https://git.openjdk.java.net/jfx/pull/602 From github.com+88822888+dlittler949 at openjdk.java.net Thu Aug 12 17:19:39 2021 From: github.com+88822888+dlittler949 at openjdk.java.net (Dlittler949) Date: Thu, 12 Aug 2021 17:19:39 GMT Subject: RFR: JDK-8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > JDK-8172095: Let Node.managed become CSS-styleable Marked as reviewed by Dlittler949 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From kcr at openjdk.java.net Thu Aug 12 17:19:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 17:19:40 GMT Subject: RFR: JDK-8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > JDK-8172095: Let Node.managed become CSS-styleable This will need at least a brief discussion on the openjfx-dev mailing list. ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Aug 12 17:19:40 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 12 Aug 2021 17:19:40 GMT Subject: RFR: JDK-8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: <9CHIwKk0SyUHo7_-V2Nz8AFRXbVHyfnh7bcjNYjiHns=.21a79fb9-0f59-4a78-81ee-6093cde6d73b@github.com> On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > JDK-8172095: Let Node.managed become CSS-styleable Past OpenJFX mailing list discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-July/017597.html ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From kcr at openjdk.java.net Thu Aug 12 17:25:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 17:25:25 GMT Subject: RFR: JDK-8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > JDK-8172095: Let Node.managed become CSS-styleable Please start a new thread and reference that one. That thread asks for a new property, but I think what you propose, which is to make the existing `managed` property CSS styleable, is better. Given how simple a request yours is, I expect the discussion will be brief. ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Aug 12 17:38:30 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 12 Aug 2021 17:38:30 GMT Subject: RFR: JDK-8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: <3b8KcEvINjn_Pu3VUCmW0QK6jelKp4l0kvJUdOYmJc4=.b5112e36-64b9-4b96-9681-4f2eb5010c16@github.com> On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > JDK-8172095: Let Node.managed become CSS-styleable Thanks for the feedback. I will create a CSR and start a thread on the mailing list. ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Aug 12 18:35:32 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 12 Aug 2021 18:35:32 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: <8Dhaa22-njLnxs8KCXuk_OH59-VQEkTK1OlrL7Pn4x8=.48f59ec6-f3d7-4c34-92f6-9120d1eea3a2@github.com> On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > 8172095: Let Node.managed become CSS-styleable CSR: https://bugs.openjdk.java.net/browse/JDK-8272386 ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From nlisker at openjdk.java.net Thu Aug 12 19:19:35 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 12 Aug 2021 19:19:35 GMT Subject: [jfx17] Integrated: 8264736: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 21:28:26 GMT, Nir Lisker wrote: > Fixes documentation mistakes as noted in the JBS issue. This pull request has now been integrated. Changeset: 03b7215b Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/03b7215b68c22b73dbec4fd554c3edaccb0102b6 Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod 8264736: Fix mistakes in FX API docs Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/601 From abhinay_agarwal at live.com Thu Aug 12 19:33:51 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Thu, 12 Aug 2021 19:33:51 +0000 Subject: apps compilation fails on ubuntu 20.04 In-Reply-To: References: Message-ID: I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I always switch back to Gradle 6.9 to build a local sdk. ________________________________ From: openjfx-dev on behalf of Thiago Milczarek Say?o Sent: Friday, August 6, 2021 8:05 AM To: openjfx-dev at openjdk.java.net Subject: apps compilation fails on ubuntu 20.04 Hi Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? I have: Apache Ant(TM) version 1.10.7 compiled on October 24 2019 openjdk version "16.0.1" 2021-04-20 I want to run the test apps. -do-compile: [javac] Compiling 143 source files to /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes [javac] error: invalid flag: @/home/tsayao/IdeaProjects/jfx/build/compile.args [javac] Usage: javac [javac] use --help for a list of possible options Thanks. From abhinay_agarwal at live.com Thu Aug 12 19:49:24 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Thu, 12 Aug 2021 19:49:24 +0000 Subject: Managed Property - CSS Styleable Message-ID: Every now and then, I miss having the capability to (un)manage nodes in its Parent via CSS. There have been similar requests[1] in the past. A combination of visibility and -fx-managed would allow developers/designers to completely hide a node via CSS, without altering its height and width. I look forward to any comments on this proposal[2]. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-July/017597.html [2] https://github.com/openjdk/jfx/pull/602 [https://opengraph.githubassets.com/f66826ed60bd99d9bf1116f086c40d622836d36c14788671f6d592fa9d8f6312/openjdk/jfx/pull/602] 8172095: Let Node.managed become CSS-styleable by abhinayagarwal ? Pull Request #602 ? openjdk/jfx Progress Change must not contain extraneous whitespace Commit message must refer to an issue Change must be properly reviewed Integration blocker ?? The change requires a CSR request to be ap... github.com From kevin.rushforth at oracle.com Thu Aug 12 19:52:16 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Aug 2021 12:52:16 -0700 Subject: apps compilation fails on ubuntu 20.04 In-Reply-To: References: Message-ID: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> I still need to catch up on my email, since I still have the original question in my queue. The answer to the original query is that there is a known bug with ant 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 (which is the one we specify in build.properties) or use ant 1.10.8. As for the gradle sdk problem, I've not seen any problems relating to using gradle 7.0.1. Is your repo up to date? Specifically, you need the following commit: https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 -- Kevin [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874 On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I always switch back to Gradle 6.9 to build a local sdk. > ________________________________ > From: openjfx-dev on behalf of Thiago Milczarek Say?o > Sent: Friday, August 6, 2021 8:05 AM > To: openjfx-dev at openjdk.java.net > Subject: apps compilation fails on ubuntu 20.04 > > Hi > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > I have: > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > openjdk version "16.0.1" 2021-04-20 > > I want to run the test apps. > > -do-compile: > [javac] Compiling 143 source files to > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > [javac] error: invalid flag: > @/home/tsayao/IdeaProjects/jfx/build/compile.args > [javac] Usage: javac > [javac] use --help for a list of possible options > > Thanks. From kevin.rushforth at oracle.com Thu Aug 12 19:53:50 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Aug 2021 12:53:50 -0700 Subject: Managed Property - CSS Styleable In-Reply-To: References: Message-ID: This seems like a reasonable enhancement to me. CSS experts: can you think of any issues that we should be mindful of when doing this? -- Kevin On 8/12/2021 12:49 PM, Abhinay Agarwal wrote: > Every now and then, I miss having the capability to (un)manage nodes in its Parent via CSS. There have been similar requests[1] in the past. A combination of visibility and -fx-managed would allow developers/designers to completely hide a node via CSS, without altering its height and width. > > I look forward to any comments on this proposal[2]. > > [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-July/017597.html > [2] https://github.com/openjdk/jfx/pull/602 > [https://opengraph.githubassets.com/f66826ed60bd99d9bf1116f086c40d622836d36c14788671f6d592fa9d8f6312/openjdk/jfx/pull/602] > 8172095: Let Node.managed become CSS-styleable by abhinayagarwal ? Pull Request #602 ? openjdk/jfx > Progress Change must not contain extraneous whitespace Commit message must refer to an issue Change must be properly reviewed Integration blocker ?? The change requires a CSR request to be ap... > github.com > From pedro.duquevieira at gmail.com Thu Aug 12 19:54:29 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 12 Aug 2021 20:54:29 +0100 Subject: Managed Property - CSS Styleable Message-ID: Hi Abhinay, Just my 2 cents.. I like that idea! Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From abhinay_agarwal at live.com Thu Aug 12 20:39:49 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Thu, 12 Aug 2021 20:39:49 +0000 Subject: apps compilation fails on ubuntu 20.04 In-Reply-To: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> References: , <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> Message-ID: Hi Kevin, My local repository is up-to-date with the jfx repository. The failure happens while trying to copy swt-debug.jar: $ sh gradlew sdk ... > Task :swt:classes FAILED FAILURE: Build failed with an exception. * Where: Build file '/tmp/jfx/build.gradle' line: 2677 * What went wrong: Execution failed for task ':swt:classes'. > Entry swt-debug.jar is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.0.1/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details. P.S. Adding a `duplicatesStrategy` to the copy task also helps with the issue. --Abhinay ________________________________ From: openjfx-dev on behalf of Kevin Rushforth Sent: Friday, August 13, 2021 1:22 AM To: openjfx-dev at openjdk.java.net Subject: Re: apps compilation fails on ubuntu 20.04 I still need to catch up on my email, since I still have the original question in my queue. The answer to the original query is that there is a known bug with ant 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 (which is the one we specify in build.properties) or use ant 1.10.8. As for the gradle sdk problem, I've not seen any problems relating to using gradle 7.0.1. Is your repo up to date? Specifically, you need the following commit: https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 -- Kevin [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874 On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I always switch back to Gradle 6.9 to build a local sdk. > ________________________________ > From: openjfx-dev on behalf of Thiago Milczarek Say?o > Sent: Friday, August 6, 2021 8:05 AM > To: openjfx-dev at openjdk.java.net > Subject: apps compilation fails on ubuntu 20.04 > > Hi > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > I have: > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > openjdk version "16.0.1" 2021-04-20 > > I want to run the test apps. > > -do-compile: > [javac] Compiling 143 source files to > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > [javac] error: invalid flag: > @/home/tsayao/IdeaProjects/jfx/build/compile.args > [javac] Usage: javac > [javac] use --help for a list of possible options > > Thanks. From kevin.rushforth at oracle.com Thu Aug 12 20:54:20 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Aug 2021 13:54:20 -0700 Subject: [External] : Re: apps compilation fails on ubuntu 20.04 In-Reply-To: References: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> Message-ID: Interesting. I wonder what it is about your environment that causes the duplicate, since we don't see the problem in our CI builds nor in the GitHub Actions builds. I presume you have done a clean build and still see it? It is possible that you have some SWT classes in your classpath or jlink'ed into your boot JDK? -- Kevin On 8/12/2021 1:39 PM, Abhinay Agarwal wrote: > Hi Kevin, > > My local repository is up-to-date with the jfx repository. > > The failure happens while trying to copy swt-debug.jar: > > $ sh gradlew sdk > > ... > > > Task :swt:classes FAILED > > FAILURE: Build failed with an exception. > > * Where: > Build file '/tmp/jfx/build.gradle' line: 2677 > > * What went wrong: > Execution failed for task ':swt:classes'. > > Entry swt-debug.jar is a duplicate but no duplicate handling > strategy has been set. Please refer to > https://docs.gradle.org/7.0.1/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy > > for details. > > > P.S. Adding a `duplicatesStrategy` to the copy task also helps with > the issue. > > --Abhinay > > ------------------------------------------------------------------------ > *From:* openjfx-dev on behalf of > Kevin Rushforth > *Sent:* Friday, August 13, 2021 1:22 AM > *To:* openjfx-dev at openjdk.java.net > *Subject:* Re: apps compilation fails on ubuntu 20.04 > I still need to catch up on my email, since I still have the original > question in my queue. > > The answer to the original query is that there is a known bug with ant > 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 > (which is the one we specify in build.properties) or use ant 1.10.8. > > As for the gradle sdk problem, I've not seen any problems relating to > using gradle 7.0.1. Is your repo up to date? Specifically, you need the > following commit: > > https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 > > > -- Kevin > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874 > > > > > On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > > > However, "gradlew sdk" fails for me since we upgraded to Gradle > 7.0.1. I always switch back to Gradle 6.9 to build a local sdk. > > ________________________________ > > From: openjfx-dev on behalf of > Thiago Milczarek Say?o > > Sent: Friday, August 6, 2021 8:05 AM > > To: openjfx-dev at openjdk.java.net > > Subject: apps compilation fails on ubuntu 20.04 > > > > Hi > > > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > > > I have: > > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > > openjdk version "16.0.1" 2021-04-20 > > > > I want to run the test apps. > > > > -do-compile: > >????? [javac] Compiling 143 source files to > > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > >????? [javac] error: invalid flag: > > @/home/tsayao/IdeaProjects/jfx/build/compile.args > >????? [javac] Usage: javac > >????? [javac] use --help for a list of possible options > > > > Thanks. > From kcr at openjdk.java.net Thu Aug 12 21:36:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 21:36:24 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v2] In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 23:09:09 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Set since 18 The API for the new property looks fine. I left a couple comments on the javadoc. You can create a Draft CSR when you get a chance. You still need to update `cssref.html` and that will need to be part of the CSR. modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 702: > 700: /** > 701: * Specifies the background color of the webPage, allowing > 702: * some or full transparency. You might want to split this into two sentences, with the part about allowing for transparent being in the second sentence. Another thing you should indicate is how this interacts with the background color in the HTML file (I presume the one in the file takes precedence?). Also "web page" should be two words. modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 704: > 702: * some or full transparency. > 703: * > 704: * Default color: White Use an `@defaultValue` javadoc tag here: @defaultValue {@code Color.WHITE} ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From thiago.sayao at gmail.com Fri Aug 13 00:51:31 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 12 Aug 2021 21:51:31 -0300 Subject: apps compilation fails on ubuntu 20.04 In-Reply-To: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> References: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> Message-ID: I confirm that gradlew apps works using ant from snap package (1.10.11). Em qui., 12 de ago. de 2021 ?s 16:53, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I still need to catch up on my email, since I still have the original > question in my queue. > > The answer to the original query is that there is a known bug with ant > 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 > (which is the one we specify in build.properties) or use ant 1.10.8. > > As for the gradle sdk problem, I've not seen any problems relating to > using gradle 7.0.1. Is your repo up to date? Specifically, you need the > following commit: > > > https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 > > -- Kevin > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874 > > > > On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > > > However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I > always switch back to Gradle 6.9 to build a local sdk. > > ________________________________ > > From: openjfx-dev on behalf of > Thiago Milczarek Say?o > > Sent: Friday, August 6, 2021 8:05 AM > > To: openjfx-dev at openjdk.java.net > > Subject: apps compilation fails on ubuntu 20.04 > > > > Hi > > > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > > > I have: > > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > > openjdk version "16.0.1" 2021-04-20 > > > > I want to run the test apps. > > > > -do-compile: > > [javac] Compiling 143 source files to > > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > > [javac] error: invalid flag: > > @/home/tsayao/IdeaProjects/jfx/build/compile.args > > [javac] Usage: javac > > [javac] use --help for a list of possible options > > > > Thanks. > > From kcr at openjdk.java.net Thu Aug 12 22:57:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 22:57:25 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v5] In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 16:53:08 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > restart github actions The API looks good. The docs look good with a couple suggestions. I'll get back to reviewing the implementation soon. One thing I will note is that the Linux unit test failures are real. I see them on my local Ubuntu 20.04 system, too. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8258: > 8256: * Indicates whether this {@code Node} should visibly indicate focus. > 8257: * This flag is set when the node acquires input focus via keyboard navigation, > 8258: * and it is cleared when the node loses focus, or when {@link #requestFocus()} I'm not sure the comma before `or` is needed. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8285: > 8283: > 8284: /** > 8285: * Indicates whether this {@code Node} or any of its children currently children --> descendants It isn't just the immediate children that will cause a parent node to report `focusWithin`. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Thu Aug 12 23:26:22 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Aug 2021 23:26:22 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 18:14:50 GMT, Kevin Rushforth wrote: > > On Ubuntu 20.04 ... The :apps task fails before and after the fix > > Maybe something with the version of Java you are using? It runs fine my system, and the GitHub actions build is fine. It turns out that I encountered the same issue that was [discussed on the mailing list](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-August/031470.html). ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From michaelstrau2 at gmail.com Thu Aug 12 23:31:27 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 13 Aug 2021 01:31:27 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: I'd like to see pivot properties move forward. The PR seems to be a bit stale, as it has been sitting around for almost two years. PR: https://github.com/openjdk/jfx/pull/53 Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth : > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > From kcr at openjdk.java.net Thu Aug 12 23:44:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Aug 2021 23:44:26 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 12:13:44 GMT, Nir Lisker wrote: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. The API and docs look good. After changing the `@since` to 18, it should be ready for the CSR. I haven't looked at the implementation yet. I did build and try the updated manual test program on Windows and Linux and it looks fine. Long term, I still think there might be value in having a dedicated shader path for directional lights, but that can be a future enhancement. modules/javafx.graphics/src/main/java/javafx/scene/DirectionalLight.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. 2021 modules/javafx.graphics/src/main/java/javafx/scene/DirectionalLight.java line 52: > 50: * source that can be simulated with this light type. > 51: * > 52: * @since 17 18 ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From mcneese.mpickett1 at gmail.com Fri Aug 13 01:39:40 2021 From: mcneese.mpickett1 at gmail.com (Michael Pickett) Date: Thu, 12 Aug 2021 20:39:40 -0500 Subject: Openjfx 11.0.4 has no mvn repo entry Message-ID: Hi everyone, While this may seem like a minor issue, there was a backport for providing media support for libav version 58 that is in that version. https://bugs.openjdk.java.net/browse/JDK-8215894 . Will this version get a mvn repo entry? Thanks for the help. From mariushanl at web.de Fri Aug 13 07:52:00 2021 From: mariushanl at web.de (Marius Hanl) Date: Fri, 13 Aug 2021 09:52:00 +0200 Subject: Managed Property - CSS Styleable In-Reply-To: References: Message-ID: I also think this is a great addition. Gesendet: Donnerstag, 12. August 2021 um 21:49 Uhr Von: "Abhinay Agarwal" An: "openjfx-dev at openjdk.java.net" Betreff: Managed Property - CSS Styleable Every now and then, I miss having the capability to (un)manage nodes in its Parent via CSS. There have been similar requests[1] in the past. A combination of visibility and -fx-managed would allow developers/designers to completely hide a node via CSS, without altering its height and width. I look forward to any comments on this proposal[2]. [1] [1]http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-July/017597. html [2] [2]https://github.com/openjdk/jfx/pull/602 [[3]https://opengraph.githubassets.com/f66826ed60bd99d9bf1116f086c40d62 2836d36c14788671f6d592fa9d8f6312/openjdk/jfx/pull/602]<[4]https://githu b.com/openjdk/jfx/pull/602> 8172095: Let Node.managed become CSS-styleable by abhinayagarwal ? Pull Request #602 ? openjdk/jfx<[5]https://github.com/openjdk/jfx/pull/602> Progress Change must not contain extraneous whitespace Commit message must refer to an issue Change must be properly reviewed Integration blocker !!!️ The change requires a CSR request to be ap... github.com References 1. http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-July/017597.html 2. https://github.com/openjdk/jfx/pull/602 3. https://opengraph.githubassets.com/f66826ed60bd99d9bf1116f086c40d622836d36c14788671f6d592fa9d8f6312/openjdk/jfx/pull/602 4. https://github.com/openjdk/jfx/pull/602 5. https://github.com/openjdk/jfx/pull/602 From abhinay_agarwal at live.com Fri Aug 13 11:15:57 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 13 Aug 2021 11:15:57 +0000 Subject: [External] : Re: apps compilation fails on ubuntu 20.04 In-Reply-To: References: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> , Message-ID: The piece of code responsible for the exception is: for (File f : configurations.compileClasspath.files) { // Have to rename the swt jar because it is some platform specific name but // for the sake of the IDEs we need to have a single stable name that works // on every platform copy { into libsDir from f.getParentFile() include "**/*swt*.jar" includeEmptyDirs = false rename ".*swt.*jar", "swt-debug\\.jar" } } >From the code snippet, it looks like Gradle is being very pro-active and complaining that this could end up with multiple jar files containing "swt" in their name and we need to provide a duplicate strategy for it. We can either provide a duplicatesStrategy or update the above to the following: copy { into libsDir from configurations.compileClasspath.files include "**/*swt*.jar" includeEmptyDirs = false rename ".*swt.*jar", "swt-debug\\.jar" // duplicatesStrategy = DuplicatesStrategy.WARN } ________________________________ From: Kevin Rushforth Sent: Friday, August 13, 2021 2:24 AM To: Abhinay Agarwal ; openjfx-dev at openjdk.java.net Subject: Re: [External] : Re: apps compilation fails on ubuntu 20.04 Interesting. I wonder what it is about your environment that causes the duplicate, since we don't see the problem in our CI builds nor in the GitHub Actions builds. I presume you have done a clean build and still see it? It is possible that you have some SWT classes in your classpath or jlink'ed into your boot JDK? -- Kevin On 8/12/2021 1:39 PM, Abhinay Agarwal wrote: Hi Kevin, My local repository is up-to-date with the jfx repository. The failure happens while trying to copy swt-debug.jar: $ sh gradlew sdk ... > Task :swt:classes FAILED FAILURE: Build failed with an exception. * Where: Build file '/tmp/jfx/build.gradle' line: 2677 * What went wrong: Execution failed for task ':swt:classes'. > Entry swt-debug.jar is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.0.1/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details. P.S. Adding a `duplicatesStrategy` to the copy task also helps with the issue. --Abhinay ________________________________ From: openjfx-dev on behalf of Kevin Rushforth Sent: Friday, August 13, 2021 1:22 AM To: openjfx-dev at openjdk.java.net Subject: Re: apps compilation fails on ubuntu 20.04 I still need to catch up on my email, since I still have the original question in my queue. The answer to the original query is that there is a known bug with ant 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 (which is the one we specify in build.properties) or use ant 1.10.8. As for the gradle sdk problem, I've not seen any problems relating to using gradle 7.0.1. Is your repo up to date? Specifically, you need the following commit: https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 -- Kevin [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874 On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I always switch back to Gradle 6.9 to build a local sdk. > ________________________________ > From: openjfx-dev on behalf of Thiago Milczarek Say?o > Sent: Friday, August 6, 2021 8:05 AM > To: openjfx-dev at openjdk.java.net > Subject: apps compilation fails on ubuntu 20.04 > > Hi > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > I have: > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > openjdk version "16.0.1" 2021-04-20 > > I want to run the test apps. > > -do-compile: > [javac] Compiling 143 source files to > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > [javac] error: invalid flag: > @/home/tsayao/IdeaProjects/jfx/build/compile.args > [javac] Usage: javac > [javac] use --help for a list of possible options > > Thanks. From arapte at openjdk.java.net Fri Aug 13 19:08:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 13 Aug 2021 19:08:39 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes Message-ID: Cherry pick the GTK webkit 2.32.3 changes https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html ------------- Commit messages: - webkit-2.32.3 Changes: https://git.openjdk.java.net/jfx/pull/603/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=603&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272329 Stats: 347 lines in 62 files changed: 199 ins; 9 del; 139 mod Patch: https://git.openjdk.java.net/jfx/pull/603.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/603/head:pull/603 PR: https://git.openjdk.java.net/jfx/pull/603 From kcr at openjdk.java.net Fri Aug 13 22:42:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Aug 2021 22:42:25 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 19:03:41 GMT, Ambarish Rapte wrote: > Cherry pick the GTK webkit 2.32.3 changes > https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html Looks good. Tested on all platforms. I left one question for you, but it's more out of curiosity. modules/javafx.web/src/main/native/Source/WebCore/page/FrameViewLayoutContext.cpp line 393: > 391: const Seconds layoutScheduleThreshold = 250_ms; > 392: m_layoutTimer.startOneShot(layoutScheduleThreshold); > 393: #else I presume there was some change in the imported WebKit commits that made this changes necessary? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/603 From jvos at openjdk.java.net Sat Aug 14 09:16:25 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 14 Aug 2021 09:16:25 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 22:38:08 GMT, Kevin Rushforth wrote: >> Cherry pick the GTK webkit 2.32.3 changes >> https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html > > modules/javafx.web/src/main/native/Source/WebCore/page/FrameViewLayoutContext.cpp line 393: > >> 391: const Seconds layoutScheduleThreshold = 250_ms; >> 392: m_layoutTimer.startOneShot(layoutScheduleThreshold); >> 393: #else > > I presume there was some change in the imported WebKit commits that made this changes necessary? That is a good question. I believe that was actually introduced because of JDK-8260165 (and removed in the next update by commit ed0baf5f23aed0d8aaa72645c8e03fde56d0f0cc) The problem with this 250ms delay is that in case the WebView is not visible, it's contents won't get updated until after 250ms. That is a major pain if the WebView is used for printing only (hence not for rendering). ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From fastegal at openjdk.java.net Sat Aug 14 10:36:40 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 14 Aug 2021 10:36:40 GMT Subject: RFR: 8244419: TextAreaSkin: throws UnsupportedOperation on dispose Message-ID: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> The issue was a glaring contract violation of TextAreaSkin which throws a UnsupportedOperationException. The fix was to remove the throwing and cleanup on dispose which implies in TextAreaBehavior: - remove the listener to focusProperty in dispose in TextAreaSkin: - register all listeners to control properties via skin api - remove installed event filter in dispose - remove direct children (here only the scrollPane) Added tests to guard the listener re-wiring (must pass before and after), and tests to expose side-effects on replacing the skin (fail before, pass after) ------------- Commit messages: - 8244419: TextAreaSkin: throws UnsupportedOperation on dispose Changes: https://git.openjdk.java.net/jfx/pull/604/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=604&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244419 Stats: 392 lines in 8 files changed: 332 ins; 37 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/604.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/604/head:pull/604 PR: https://git.openjdk.java.net/jfx/pull/604 From nlisker at openjdk.java.net Sat Aug 14 13:00:52 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 14 Aug 2021 13:00:52 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: References: Message-ID: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/548/files - new: https://git.openjdk.java.net/jfx/pull/548/files/26c5ed77..adcf1fce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/548/head:pull/548 PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Sat Aug 14 13:00:53 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 14 Aug 2021 13:00:53 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Mon, 28 Jun 2021 12:13:44 GMT, Nir Lisker wrote: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. My commit message was wrong. I updated the `@since` tag, not the copyright year. I'll let the copyright year script do all the changed files together instead of doing it by hand. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From thiago.sayao at gmail.com Sat Aug 14 21:41:06 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sat, 14 Aug 2021 18:41:06 -0300 Subject: Why GTK4 glass backend will not (probably) be an #IFDEF Message-ID: Gtk4 glass implementation will probably be a new glass implementation based on the current one because there are too many "breaking" changes. Changes are listed here: https://docs.gtk.org/gtk4/migrating-3to4.html Specially note: https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-gtkwindow-api-changes (*) https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtk_widget_set_app_paintable (*) https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-grabs https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-non-rgba-visuals https://docs.gtk.org/gtk4/migrating-3to4.html#switch-to-the-new-drag-and-drop-api * Gdk Surface would be used instead of Gtk Window. Backend (Wayland/X11) specific functions will be needed: https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-monitor-api-changes https://docs.gtk.org/gdk4/wayland.html Looking at the Gdk4 implementation, using libwayland* directly would be nice, but simply too hard. So we could use Gtk4 to support wayland and #ifdef GDK_WINDOWING_X11 / GDK_WINDOWING_WAYLAND where necessary. On another note, XTest equivalent (for Robot) is not available on generic wayland compositors. -- Thiago. From pbansal at openjdk.java.net Sun Aug 15 16:29:28 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 15 Aug 2021 16:29:28 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: <7wyvJywi-GwKk7XWIrNwf-ne4Xgr-uyDNp7KzUOLQus=.a793e98a-3b30-4bb3-bdfa-61435c44e639@github.com> References: <7wyvJywi-GwKk7XWIrNwf-ne4Xgr-uyDNp7KzUOLQus=.a793e98a-3b30-4bb3-bdfa-61435c44e639@github.com> Message-ID: On Wed, 11 Aug 2021 23:40:00 GMT, Thiago Milczarek Sayao wrote: > Test works on Linux, don't know on other platforms. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` The fix does solve the issue and looks good to me. The test is failing on Windows 10 and Mac 10.15. As Kevin has mentioned in other comment, if the automated test is too complex, you can change the test to manual one and file a new bug for automated test and assign it to me. I will write an automated in future. ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From pbansal at openjdk.java.net Sun Aug 15 19:44:29 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 15 Aug 2021 19:44:29 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. I ran the testcase attached in JBS with the fix multiple times. I can still reproduce the issue on Ubuntu 20.0 almost always, so the fix does not seem to work for me. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Sun Aug 15 19:49:24 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 15 Aug 2021 19:49:24 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: <7wyvJywi-GwKk7XWIrNwf-ne4Xgr-uyDNp7KzUOLQus=.a793e98a-3b30-4bb3-bdfa-61435c44e639@github.com> Message-ID: On Sun, 15 Aug 2021 16:26:59 GMT, Pankaj Bansal wrote: >> Test works on Linux, don't know on other platforms. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` > >> Test works on Linux, don't know on other platforms. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` > > The fix does solve the issue and looks good to me. > > The test is failing on Windows 10 and Mac 10.15. As Kevin has mentioned in other comment, if the automated test is too complex, you can change the test to manual one and file a new bug for automated test and assign it to me. I will write an automated in future. @pankaj-bansal Do you prefer I switch the test to manual or make the current one only for Linux? ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Sun Aug 15 20:13:23 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 15 Aug 2021 20:13:23 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: <3bjat4WLePrqj9ZLIXfU9QQFNY8Xji2h5OMyTuieVcg=.d30af751-a0b7-4023-af91-41456a5df715@github.com> On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Weird, It works consistently for me on 20.04. Just tested again to be sure. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From pbansal at openjdk.java.net Sun Aug 15 20:27:29 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 15 Aug 2021 20:27:29 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: <7wyvJywi-GwKk7XWIrNwf-ne4Xgr-uyDNp7KzUOLQus=.a793e98a-3b30-4bb3-bdfa-61435c44e639@github.com> Message-ID: On Sun, 15 Aug 2021 16:26:59 GMT, Pankaj Bansal wrote: >> Test works on Linux, don't know on other platforms. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` > >> Test works on Linux, don't know on other platforms. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` > > The fix does solve the issue and looks good to me. > > The test is failing on Windows 10 and Mac 10.15. As Kevin has mentioned in other comment, if the automated test is too complex, you can change the test to manual one and file a new bug for automated test and assign it to me. I will write an automated in future. > @pankaj-bansal Do you prefer I switch the test to manual or make the current one only for Linux? I think it would be better to make it manual and create new JBS bug for automated test. ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Sun Aug 15 21:07:27 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 15 Aug 2021 21:07:27 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v2] In-Reply-To: References: Message-ID: <1xDN4vWR9AylaABZXdqGhXKnd2eM7P0xto5AoAv7GyU=.5cb0bbc3-567b-43e5-9701-ba6c29079b27@github.com> On Wed, 11 Aug 2021 23:42:47 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Provide test JBS: https://bugs.openjdk.java.net/browse/JDK-8272492 Changed test to manual. ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Sun Aug 15 21:18:51 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 15 Aug 2021 21:18:51 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3] In-Reply-To: References: Message-ID: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Change test to manual ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/5530488c..4509462a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=01-02 Stats: 254 lines in 2 files changed: 83 ins; 171 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599 From perini.davide at dpsoftware.org Sun Aug 15 22:43:57 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 16 Aug 2021 00:43:57 +0200 Subject: java: module not found: eu.hansolo.medusa Message-ID: Hi all, I'm trying to use the medusa gauges. I have added those lines to my pom.xml eu.hansolo Medusa 16.0.0 and this to my module-info.java requires eu.hansolo.medusa; I can compile use mvn clean install but I cannot run my main file from intellij. I get this error: java: module not found: eu.hansolo.medusa Any idea? Thanks Davide From tsayao at openjdk.java.net Sun Aug 15 23:00:26 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 15 Aug 2021 23:00:26 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3] In-Reply-To: References: Message-ID: On Sun, 15 Aug 2021 21:18:51 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Change test to manual `gdk_cairo_set_source_pixbuf` is available since gtk 2.8. I can't find the minimum gtk version for 2.0. ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From pbansal at openjdk.java.net Mon Aug 16 06:25:24 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 16 Aug 2021 06:25:24 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: <3bjat4WLePrqj9ZLIXfU9QQFNY8Xji2h5OMyTuieVcg=.d30af751-a0b7-4023-af91-41456a5df715@github.com> References: <3bjat4WLePrqj9ZLIXfU9QQFNY8Xji2h5OMyTuieVcg=.d30af751-a0b7-4023-af91-41456a5df715@github.com> Message-ID: <_rx9AalZNfMzhWtdk8n7ODjN9356jfjuJSPS9hKcPWo=.b58f0693-5921-48d9-8006-8a469929b41e@github.com> On Sun, 15 Aug 2021 20:10:43 GMT, Thiago Milczarek Sayao wrote: > Weird, It works consistently for me on 20.04. Just tested again to be sure. I am running a 20.04 VM. The test fails for me 60-70% of the time. I will request someone in team to try this once. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From arapte at openjdk.java.net Mon Aug 16 07:02:25 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 16 Aug 2021 07:02:25 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: References: Message-ID: On Sat, 14 Aug 2021 09:13:25 GMT, Johan Vos wrote: >> modules/javafx.web/src/main/native/Source/WebCore/page/FrameViewLayoutContext.cpp line 393: >> >>> 391: const Seconds layoutScheduleThreshold = 250_ms; >>> 392: m_layoutTimer.startOneShot(layoutScheduleThreshold); >>> 393: #else >> >> I presume there was some change in the imported WebKit commits that made this changes necessary? > > That is a good question. I believe that was actually introduced because of JDK-8260165 (and removed in the next update by commit ed0baf5f23aed0d8aaa72645c8e03fde56d0f0cc) > > The problem with this 250ms delay is that in case the WebView is not visible, it's contents won't get updated until after 250ms. That is a major pain if the WebView is used for printing only (hence not for rendering). I think it was missed during webkit update, and caused [JDK-8269067](https://bugs.openjdk.java.net/browse/JDK-8269067) : CSSFilterTest fails intermittently in Windows. Taking this change back seems like good idea. ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From tom.schindl at bestsolution.at Mon Aug 16 10:26:00 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 16 Aug 2021 12:26:00 +0200 Subject: Improving/Enhancing Accessibility Support on Windows Message-ID: <144a92ac-fe93-f1fb-b50b-dba3a67f8cfe@bestsolution.at> Hi, I'd like to inform you that we (BestSolution.at) are currently partnering with another company (dvhaus.de) to allow JavaFX applications leverage the complete Window UI Automation API for OpenJFX applications *running on Windows*. The main target of our work is to provide best accessibility support for the Canvas-Node, which is used by our partner company to implement a comprehensive text editor. I don't want to go too deep into the topic, but we explicitly decided: a) not to implement the support into the current cross-platform accessibility API b) provide 100% UI Automation support (ruling out a cross-platform API for now) Of course we know that we are relying on internals and undocumented APIs to intercept the OpenJFX Accessibility API calls and take over control if requested. Long story short - the sources are available at https://github.com/BestSolution-at/openfx-uia Tom Schindl BestSolution.at EDV Systemhaus GmbH From mhanl at openjdk.java.net Mon Aug 16 17:12:43 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 16 Aug 2021 17:12:43 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v3] In-Reply-To: <7mEujwJqKovdWM1oXwgi3fOiGXfLMTdypdszr5Y7QH4=.2d74d22a-5c3f-460e-9e45-de4f231523f2@github.com> References: <7mEujwJqKovdWM1oXwgi3fOiGXfLMTdypdszr5Y7QH4=.2d74d22a-5c3f-460e-9e45-de4f231523f2@github.com> Message-ID: On Wed, 28 Jul 2021 15:12:45 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Reordered commit > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 75: > >> 73: this.listCell = listCell; >> 74: } >> 75: > > this hit me when trying separate out the (accidentally?) single test method: all tests work on the same instance of the cell, so its state is unpredictable. Instead, parameterize on a supplier and let it provide a new cell in setup. I see, another point where I would love we actually use JUnit5. :/ ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From kcr at openjdk.java.net Mon Aug 16 17:42:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 17:42:45 GMT Subject: [jfx11u] RFR: 8262396: Update Mesa 3-D Headers to version 21.0.3 Message-ID: Clean backport of Mesa-3D third-party update. ------------- Commit messages: - 8262396: Update Mesa 3-D Headers to version 21.0.3 Changes: https://git.openjdk.java.net/jfx11u/pull/27/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=27&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262396 Stats: 140 lines in 6 files changed: 100 ins; 18 del; 22 mod Patch: https://git.openjdk.java.net/jfx11u/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/27/head:pull/27 PR: https://git.openjdk.java.net/jfx11u/pull/27 From kcr at openjdk.java.net Mon Aug 16 17:54:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 17:54:35 GMT Subject: [jfx11u] Integrated: 8262396: Update Mesa 3-D Headers to version 21.0.3 In-Reply-To: References: Message-ID: <9eGe4eHywDijWjOy1Chw32sAWM5w5IzcFZ9LNon0BHw=.d4ac15a7-d329-41f7-a5f2-0c2a0cfb0aaa@github.com> On Mon, 16 Aug 2021 17:37:09 GMT, Kevin Rushforth wrote: > Clean backport of Mesa-3D third-party update. This pull request has now been integrated. Changeset: 330b4fad Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/330b4fadb0f3b76f77f0338f26b90979605518c8 Stats: 140 lines in 6 files changed: 100 ins; 18 del; 22 mod 8262396: Update Mesa 3-D Headers to version 21.0.3 Backport-of: ab7c15159d840377e6ceb9a80dd62e074aa80301 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/27 From jvos at openjdk.java.net Mon Aug 16 17:56:31 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 16 Aug 2021 17:56:31 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 06:59:18 GMT, Ambarish Rapte wrote: >> That is a good question. I believe that was actually introduced because of JDK-8260165 (and removed in the next update by commit ed0baf5f23aed0d8aaa72645c8e03fde56d0f0cc) >> >> The problem with this 250ms delay is that in case the WebView is not visible, it's contents won't get updated until after 250ms. That is a major pain if the WebView is used for printing only (hence not for rendering). > > I think this change was lost during webkit update. and it caused a regression [JDK-8269067](https://bugs.openjdk.java.net/browse/JDK-8269067) : CSSFilterTest fails intermittently in Windows. > This change was originally included to enable CSSFilterTest. > Adding back this change sounds like a good idea to me. The original addition of this #ifdef was due to JDK-8260165. That commit introduced the problems I mentioned above (WebView took 250ms to update if not visible), so I don't think it is a good solution. I suggest we discuss that in JDK-8269067 (but not include it in the PR with the cherry-pick of the changes, as it is not in the upstream webkit)? ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From thiago.sayao at gmail.com Mon Aug 16 19:36:52 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 16 Aug 2021 16:36:52 -0300 Subject: Gtk3 minimum required version Message-ID: Hi, Currently the minimum required version is 3.8. Beginning on 3.10 Gtk added support for client-side decorations and the GtkHeaderBar is the default widget to do that. https://docs.gtk.org/gtk3/ctor.HeaderBar.new.html Gtk 3.10 was released Sep/2013. Gtk4 and Gnome apps default to this behaviour. By using it we may be able to get rid of the window sizing problem on glass-gtk which is "decoration sizes" thru _NET_FRAME_EXTENTS which is very error prone (it depends on each window manager). Currently it does a lot of work-arounds to size the window properly because the server does the decoration so there is a problem getting it's size to size the window accordingly. It works, but it's far from pretty. More details here: https://discourse.gnome.org/t/understanding-window-sizing-and-decorations-on-gtk4/7290 By moving to this idea we might be more compatible with other apps and do a better job on the implementation of window sizing. If you put a pure gtk window and a javafx window on Ubuntu 20.04 there are some differences (shadow size and titlebar size). Also, if we want to support wayland we will have to require a greater gtk3 version. Or just support it on Gtk4 where I would follow the HeaderBar (client-side decorations) idea. -- Thiago. From thiago.sayao at gmail.com Mon Aug 16 19:42:27 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 16 Aug 2021 16:42:27 -0300 Subject: Why GTK4 glass backend will not (probably) be an #IFDEF In-Reply-To: References: Message-ID: Correction: * Gdk Surface would be used instead of *Gdk*Window. * GtkDrawingArea widget would be used to draw fx data. Also, after further investigation libwayland is a no, too much work, specially because client side decorations. So for wayland we should stick with Gtk (a greater gtk3 version than 3.8) or starting from Gtk4. -- Thiago. Em s?b., 14 de ago. de 2021 ?s 18:41, Thiago Milczarek Say?o escreveu: > > Gtk4 glass implementation will probably be a new glass implementation > based on the current one because there are too many "breaking" > changes. > > Changes are listed here: > https://docs.gtk.org/gtk4/migrating-3to4.html > > Specially note: > https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-gtkwindow-api-changes (*) > https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtk_widget_set_app_paintable > (*) > https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-grabs > https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-non-rgba-visuals > https://docs.gtk.org/gtk4/migrating-3to4.html#switch-to-the-new-drag-and-drop-api > > * Gdk Surface would be used instead of Gtk Window. > > Backend (Wayland/X11) specific functions will be needed: > https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-monitor-api-changes > https://docs.gtk.org/gdk4/wayland.html > > Looking at the Gdk4 implementation, using libwayland* directly would > be nice, but simply too hard. So we could use Gtk4 to support wayland > and #ifdef GDK_WINDOWING_X11 / GDK_WINDOWING_WAYLAND where necessary. > > On another note, XTest equivalent (for Robot) is not available on > generic wayland compositors. > > -- Thiago. From mhanl at openjdk.java.net Mon Aug 16 19:45:27 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 16 Aug 2021 19:45:27 GMT Subject: RFR: 8244419: TextAreaSkin: throws UnsupportedOperation on dispose In-Reply-To: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> References: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> Message-ID: On Sat, 14 Aug 2021 10:32:00 GMT, Jeanette Winzenburg wrote: > The issue was a glaring contract violation of TextAreaSkin which throws a UnsupportedOperationException. The fix was to remove the throwing and cleanup on dispose which implies > > in TextAreaBehavior: > - remove the listener to focusProperty in dispose > > in TextAreaSkin: > - register all listeners to control properties via skin api > - remove installed event filter in dispose > - remove direct children (here only the scrollPane) > > Added tests to guard the listener re-wiring (must pass before and after), and tests to expose side-effects on replacing the skin (fail before, pass after) Looks good. Verified test failing before and pass after (and some tests pass before/after). ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/604 From arapte at openjdk.java.net Mon Aug 16 20:13:03 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 16 Aug 2021 20:13:03 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes [v2] In-Reply-To: References: Message-ID: > Cherry pick the GTK webkit 2.32.3 changes > https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: revert changes from JDK-8260165 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/603/files - new: https://git.openjdk.java.net/jfx/pull/603/files/40e1e423..b0a4a27c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=603&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=603&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/603.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/603/head:pull/603 PR: https://git.openjdk.java.net/jfx/pull/603 From arapte at openjdk.java.net Mon Aug 16 20:44:29 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 16 Aug 2021 20:44:29 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes [v2] In-Reply-To: References: Message-ID: <5kt_2JPZ9x50Hwh2CgIQINsF8D_MpepwJ8TPz8YHxTw=.f0008a48-2ffa-4655-af87-f6f986301089@github.com> On Mon, 16 Aug 2021 17:53:56 GMT, Johan Vos wrote: >> I think this change was lost during webkit update. and it caused a regression [JDK-8269067](https://bugs.openjdk.java.net/browse/JDK-8269067) : CSSFilterTest fails intermittently in Windows. >> This change was originally included to enable CSSFilterTest. >> Adding back this change sounds like a good idea to me. > > The original addition of this #ifdef was due to JDK-8260165. That commit introduced the problems I mentioned above (WebView took 250ms to update if not visible), so I don't think it is a good solution. > I suggest we discuss that in JDK-8269067 (but not include it in the PR with the cherry-pick of the changes, as it is not in the upstream webkit)? I have reverted this change. The CSSFilterTest.testCSSFilterRendering is already ignored. ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From kcr at openjdk.java.net Mon Aug 16 21:30:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 21:30:42 GMT Subject: [jfx11u] RFR: 8209086: Some javafx.web files are missing GPLv2+Classpath copyright header Message-ID: Clean backport of fix to add missing copyright headers. No changes other than comments. ------------- Commit messages: - 8209086: Some javafx.web files are missing GPLv2+Classpath copyright header Changes: https://git.openjdk.java.net/jfx11u/pull/28/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=28&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209086 Stats: 591 lines in 27 files changed: 591 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx11u/pull/28 From kcr at openjdk.java.net Mon Aug 16 21:45:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 21:45:24 GMT Subject: [jfx11u] Integrated: 8209086: Some javafx.web files are missing GPLv2+Classpath copyright header In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:23:56 GMT, Kevin Rushforth wrote: > Clean backport of fix to add missing copyright headers. No changes other than comments. This pull request has now been integrated. Changeset: 1a021ed4 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/1a021ed47fbb5553ec0462d5d7c80faf7da79c60 Stats: 591 lines in 27 files changed: 591 ins; 0 del; 0 mod 8209086: Some javafx.web files are missing GPLv2+Classpath copyright header Backport-of: 83743d44f7541877c9df2afc3263004e7614f18c ------------- PR: https://git.openjdk.java.net/jfx11u/pull/28 From kcr at openjdk.java.net Mon Aug 16 21:51:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 21:51:30 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes [v2] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:13:03 GMT, Ambarish Rapte wrote: >> Cherry pick the GTK webkit 2.32.3 changes >> https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > revert changes from JDK-8260165 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From kcr at openjdk.java.net Mon Aug 16 22:01:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 22:01:12 GMT Subject: [jfx11u] RFR: 8266462: Update copyright years of javafx.web native sources in jfx11u Message-ID: As mentioned in the JBS bug report, this is needed to minimize gratuitous diffs in the native WebKit sources between mainline and jfx11u. These diffs can make it hard to see whether there is any substantive diff between the two and also can sometimes lead to merge conflicts. In addition to the copyright year changes, which only touched the comments (as with all updates to the copyright year), I corrected one white space difference between jfx and jfx11u. So only a sanity build is needed, which I did. ------------- Commit messages: - 8266462: Update copyright years of javafx.web native sources in jfx11u Changes: https://git.openjdk.java.net/jfx11u/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266462 Stats: 214 lines in 214 files changed: 0 ins; 0 del; 214 mod Patch: https://git.openjdk.java.net/jfx11u/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/29/head:pull/29 PR: https://git.openjdk.java.net/jfx11u/pull/29 From kcr at openjdk.java.net Mon Aug 16 22:01:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 22:01:12 GMT Subject: [jfx11u] RFR: 8266462: Update copyright years of javafx.web native sources in jfx11u In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:55:52 GMT, Kevin Rushforth wrote: > As mentioned in the JBS bug report, this is needed to minimize gratuitous diffs in the native WebKit sources between mainline and jfx11u. These diffs can make it hard to see whether there is any substantive diff between the two and also can sometimes lead to merge conflicts. > > In addition to the copyright year changes, which only touched the comments (as with all updates to the copyright year), I corrected one white space difference between jfx and jfx11u. So only a sanity build is needed, which I did. Reviewer: @arapte or @johanvos (no need for two reviewers for this sort of fix) ------------- PR: https://git.openjdk.java.net/jfx11u/pull/29 From jvos at openjdk.java.net Tue Aug 17 08:02:29 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 17 Aug 2021 08:02:29 GMT Subject: RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes [v2] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:13:03 GMT, Ambarish Rapte wrote: >> Cherry pick the GTK webkit 2.32.3 changes >> https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > revert changes from JDK-8260165 Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From fastegal at openjdk.java.net Tue Aug 17 09:29:26 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 17 Aug 2021 09:29:26 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v3] In-Reply-To: References: <7mEujwJqKovdWM1oXwgi3fOiGXfLMTdypdszr5Y7QH4=.2d74d22a-5c3f-460e-9e45-de4f231523f2@github.com> Message-ID: <3pnT0zLB93SmtKOXMhJnCJXPb2ntyMCtrvAJLI033Bc=.7ee1c126-735f-4d0b-b993-068758d2d68b@github.com> On Mon, 16 Aug 2021 17:09:25 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 75: >> >>> 73: this.listCell = listCell; >>> 74: } >>> 75: >> >> this hit me when trying separate out the (accidentally?) single test method: all tests work on the same instance of the cell, so its state is unpredictable. Instead, parameterize on a supplier and let it provide a new cell in setup. > > I see, another point where I would love we actually use JUnit5. :/ ehh .. this is not resolved - still change required - or what do I miss? ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From mhanl at openjdk.java.net Tue Aug 17 10:17:33 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 17 Aug 2021 10:17:33 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v3] In-Reply-To: <3pnT0zLB93SmtKOXMhJnCJXPb2ntyMCtrvAJLI033Bc=.7ee1c126-735f-4d0b-b993-068758d2d68b@github.com> References: <7mEujwJqKovdWM1oXwgi3fOiGXfLMTdypdszr5Y7QH4=.2d74d22a-5c3f-460e-9e45-de4f231523f2@github.com> <3pnT0zLB93SmtKOXMhJnCJXPb2ntyMCtrvAJLI033Bc=.7ee1c126-735f-4d0b-b993-068758d2d68b@github.com> Message-ID: On Tue, 17 Aug 2021 09:26:12 GMT, Jeanette Winzenburg wrote: >> I see, another point where I would love we actually use JUnit5. :/ > > ehh .. this is not resolved - still change required - or what do I miss? I already changed the tests to use a supplier but didn't pushed it yet. I just resolved this to mark it as read for myself. Will push it today.:) ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From github.com+1864183+micheljung at openjdk.java.net Tue Aug 17 11:43:24 2021 From: github.com+1864183+micheljung at openjdk.java.net (Michel Jung) Date: Tue, 17 Aug 2021 11:43:24 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v2] In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 23:09:09 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Set since 18 I'll throw a party when this finally gets fixed! See also: https://github.com/javafxports/openjdk-jfx/issues/277 ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From github.com+1864183+micheljung at openjdk.java.net Tue Aug 17 11:49:27 2021 From: github.com+1864183+micheljung at openjdk.java.net (Michel Jung) Date: Tue, 17 Aug 2021 11:49:27 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v2] In-Reply-To: References: Message-ID: <_c6Wenp8Upa7ROUpg35btIDqtyXjBSH8T-GC_OZT6WQ=.dcff3a9b-dee5-439f-bcba-e13a3cad0b73@github.com> On Sat, 3 Jul 2021 23:09:09 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Set since 18 Since my comment may have gone unnoticed because I had to check the aggreement box first: See https://github.com/javafxports/openjdk-jfx/issues/277 ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From arapte at openjdk.java.net Tue Aug 17 12:02:29 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 17 Aug 2021 12:02:29 GMT Subject: Integrated: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 19:03:41 GMT, Ambarish Rapte wrote: > Cherry pick the GTK webkit 2.32.3 changes > https://webkitgtk.org/2021/07/23/webkitgtk2.32.3-released.html This pull request has now been integrated. Changeset: ee442e51 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/ee442e516a20e979dc228ab63c6b795b74d49e41 Stats: 341 lines in 61 files changed: 193 ins; 9 del; 139 mod 8272329: Cherry pick GTK WebKit 2.32.3 changes Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/603 From arapte at openjdk.java.net Tue Aug 17 12:49:35 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 17 Aug 2021 12:49:35 GMT Subject: [jfx17] RFR: 8270960: Update copyright header for files modified in 2021 Message-ID: Change to update copyright year of files modified in 2021. ------------- Commit messages: - copyright-2021 Changes: https://git.openjdk.java.net/jfx/pull/605/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=605&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270960 Stats: 682 lines in 682 files changed: 0 ins; 0 del; 682 mod Patch: https://git.openjdk.java.net/jfx/pull/605.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/605/head:pull/605 PR: https://git.openjdk.java.net/jfx/pull/605 From pbansal at openjdk.java.net Tue Aug 17 13:15:26 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 17 Aug 2021 13:15:26 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3] In-Reply-To: References: Message-ID: On Sun, 15 Aug 2021 21:18:51 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Change test to manual The fix works fine and the test passes on all platforms. I have given minor comments about the test. tests/manual/dnd/DndTestDragViewRawImage.java line 59: > 57: }); > 58: > 59: Label label = new Label("Drag image should match source colors when dragged"); Could you please make the instructions a bit more clear? tests/manual/dnd/DndTestDragViewRawImage.java line 83: > 81: return SwingFXUtils.toFXImage(image, null); > 82: } > 83: } There is no newline at the file end ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From mhanl at openjdk.java.net Tue Aug 17 16:15:47 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 17 Aug 2021 16:15:47 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v4] In-Reply-To: References: Message-ID: > This PR sets an unified logic to every **startEdit()** method of all Cell implementations. > So startEdit() is always doing the same now: > > `super.startEdit();` > `if (!isEditing()) { > return; > }` > > This will prevent a NPE while also being cleaner (no more double checks) > The commits are splitted into 4 base commits: > - First commit changes the startEdit() for TableCell implementations (8 files) > - Second commit changes the startEdit() for TreeTableCell implementations (7 files) > - Third commit changes the startEdit() for ListCell implementations (7 files) > - Fourth commit changes the startEdit() for TreeCell implementations (7 files) > > While writing tests, I found out that the CheckBoxListCell and the CheckBoxTreeCell don't disable their CheckBox, which is wrong. > In CheckBoxTableCell and CheckBoxTreeTableCell the CheckBox is disabled, but they don't check their dependencies e.g. TableColumn for null, leading to a NPE if not set. > > I wrote a follow-up and assigned it to myself: https://bugs.openjdk.java.net/browse/JDK-8270042 > The aim of this should be, that all 4 CheckBox...Cells have a proper CheckBox disablement while also being nullsafe. > > ~Note 1: I removed the tests in TableCellTest added in https://github.com/openjdk/jfx/pull/529 in favor of the new parameterized TableCellStartEditTest~ > Note 2: This also fixes https://bugs.openjdk.java.net/browse/JDK-8268295 Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Separated test and made the cell a supplier instead ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/569/files - new: https://git.openjdk.java.net/jfx/pull/569/files/19da9109..fa89fccd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=569&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=569&range=02-03 Stats: 78 lines in 4 files changed: 28 ins; 5 del; 45 mod Patch: https://git.openjdk.java.net/jfx/pull/569.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/569/head:pull/569 PR: https://git.openjdk.java.net/jfx/pull/569 From kcr at openjdk.java.net Tue Aug 17 17:19:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 17:19:40 GMT Subject: [jfx11u] RFR: 8211308: Support HTTP/2 in WebView Message-ID: Clean backport of HTTP/2. This is enabled by default only with running with JDK 12 or later. I have tested this with both JDK 11, where I verified that it HTTP/2 is not enabled, and JDK 15, where I verified that it HTTP/2 is enabled. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). ------------- Commit messages: - 8211308: Support HTTP/2 in WebView Changes: https://git.openjdk.java.net/jfx11u/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 Stats: 1166 lines in 14 files changed: 881 ins; 217 del; 68 mod Patch: https://git.openjdk.java.net/jfx11u/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/30/head:pull/30 PR: https://git.openjdk.java.net/jfx11u/pull/30 From kcr at openjdk.java.net Tue Aug 17 17:19:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 17:19:40 GMT Subject: [jfx11u] RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: Message-ID: <-vJVeQAj6ktSskaV7Om4q7covZQbWXPURmO8L1MDgZo=.881486be-b721-4b56-aebd-948eeb302482@github.com> On Tue, 17 Aug 2021 17:13:36 GMT, Kevin Rushforth wrote: > Clean backport of HTTP/2. This is enabled by default only with running with JDK 12 or later. > > I have tested this with both JDK 11, where I verified that it HTTP/2 is not enabled, and JDK 15, where I verified that it HTTP/2 is enabled. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). @johanvos Even though this is a clean backport, I'd like you to review it before I integrate it. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/30 From kcr at openjdk.java.net Tue Aug 17 17:23:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 17:23:37 GMT Subject: [jfx11u] RFR: 8268915: WebKit build fails with Xcode 12.5 Message-ID: Clean backport of fix to rename `VERSION` to `VERSION.txt` to fix build breakage on Xcode 12.5. ------------- Commit messages: - 8268915: WebKit build fails with Xcode 12.5 Changes: https://git.openjdk.java.net/jfx11u/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268915 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/31/head:pull/31 PR: https://git.openjdk.java.net/jfx11u/pull/31 From kcr at openjdk.java.net Tue Aug 17 17:29:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 17:29:42 GMT Subject: [jfx11u] RFR: 8269147: Update GStreamer to version 1.18.4 Message-ID: <72JuFOrO-AkmOearc1Lxhrk3cI6fUd2WV9kA2vTDsBE=.5638ca20-78b8-45c0-8ae8-825225b6cb61@github.com> Clean backport of third-party update to GStreamer 1.18.4. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). ------------- Commit messages: - 8269147: Update GStreamer to version 1.18.4 Changes: https://git.openjdk.java.net/jfx11u/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=32&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269147 Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod Patch: https://git.openjdk.java.net/jfx11u/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/32/head:pull/32 PR: https://git.openjdk.java.net/jfx11u/pull/32 From kcr at openjdk.java.net Tue Aug 17 17:34:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 17:34:43 GMT Subject: [jfx11u] RFR: 8269131: Update libxml2 to version 2.9.12 Message-ID: <_XBL--0Jy70ZWHG9bA46qbhwfio-ogxNdmmCebEPcks=.738964cf-5af8-404d-b09a-3fe3ff696f73@github.com> Clean backport of third-party update to libxml2 2.9.12. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). ------------- Commit messages: - 8269131: Update libxml2 to version 2.9.12 Changes: https://git.openjdk.java.net/jfx11u/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=33&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269131 Stats: 4134 lines in 62 files changed: 1582 ins; 1362 del; 1190 mod Patch: https://git.openjdk.java.net/jfx11u/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/33/head:pull/33 PR: https://git.openjdk.java.net/jfx11u/pull/33 From kcr at openjdk.java.net Tue Aug 17 18:03:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 18:03:30 GMT Subject: [jfx11u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:33:13 GMT, Kevin Rushforth wrote: > Nearly clean backport of third-party update to WebKit 612.1. There was one minor conflict in one unit test file due to difference in context. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). Reviewers: @arapte @johanvos ------------- PR: https://git.openjdk.java.net/jfx11u/pull/34 From kcr at openjdk.java.net Tue Aug 17 18:03:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 18:03:29 GMT Subject: [jfx11u] RFR: 8268849: Update to 612.1 version of WebKit Message-ID: Nearly clean backport of third-party update to WebKit 612.1. There was one minor conflict in one unit test file due to difference in context. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). ------------- Commit messages: - 8268849: Update to 612.1 version of WebKit Changes: https://git.openjdk.java.net/jfx11u/pull/34/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=34&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268849 Stats: 286061 lines in 5711 files changed: 175196 ins; 68118 del; 42747 mod Patch: https://git.openjdk.java.net/jfx11u/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/34/head:pull/34 PR: https://git.openjdk.java.net/jfx11u/pull/34 From mstrauss at openjdk.java.net Tue Aug 17 18:12:47 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 17 Aug 2021 18:12:47 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v6] In-Reply-To: References: Message-ID: <2Q9dqcRy9nCGwC34rGF9Vk5cLl_GadzBYhKvd_d_dDc=.f80e49b5-8cae-4cd0-89e6-d03158c79c97@github.com> > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: minor wording change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/e0591088..a1da00b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From kcr at openjdk.java.net Tue Aug 17 18:59:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 18:59:31 GMT Subject: [jfx11u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:33:13 GMT, Kevin Rushforth wrote: > Nearly clean backport of third-party update to WebKit 612.1. There was one minor conflict in one unit test file due to difference in context. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). There are two follow-on issues that depend on this one, each of which has a Draft PR out for review: PR #35 and PR #36. As soon as _this_ PR is ready, I will update those two PRs with the latest master (including the commit for this PR) and make them `rfr`. Since they are clean backports, I will then integrate them right after that. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/34 From jvos at openjdk.java.net Tue Aug 17 20:10:33 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 17 Aug 2021 20:10:33 GMT Subject: [jfx11u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:33:13 GMT, Kevin Rushforth wrote: > Nearly clean backport of third-party update to WebKit 612.1. There was one minor conflict in one unit test file due to difference in context. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/34 From kcr at openjdk.java.net Tue Aug 17 23:45:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 17 Aug 2021 23:45:25 GMT Subject: [jfx17] RFR: 8270960: Update copyright header for files modified in 2021 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 12:43:52 GMT, Ambarish Rapte wrote: > Change to update copyright year of files modified in 2021. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/605 From arapte at openjdk.java.net Wed Aug 18 06:26:34 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 18 Aug 2021 06:26:34 GMT Subject: [jfx17] Integrated: 8270960: Update copyright header for files modified in 2021 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 12:43:52 GMT, Ambarish Rapte wrote: > Change to update copyright year of files modified in 2021. This pull request has now been integrated. Changeset: 14b23bcf Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/14b23bcf69a321c44b09e584b30f39e1fa3e6948 Stats: 682 lines in 682 files changed: 0 ins; 0 del; 682 mod 8270960: Update copyright header for files modified in 2021 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/605 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Aug 18 06:48:25 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 18 Aug 2021 06:48:25 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > 8172095: Let Node.managed become CSS-styleable I started a [discussion on the mailing list](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-August/031520.html). Is there anything else pending to move this PR forward? ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From arapte at openjdk.java.net Wed Aug 18 11:44:31 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 18 Aug 2021 11:44:31 GMT Subject: [jfx11u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:33:13 GMT, Kevin Rushforth wrote: > Nearly clean backport of third-party update to WebKit 612.1. There was one minor conflict in one unit test file due to difference in context. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/34 From arapte at openjdk.java.net Wed Aug 18 11:45:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 18 Aug 2021 11:45:32 GMT Subject: [jfx11u] RFR: 8266462: Update copyright years of javafx.web native sources in jfx11u In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:55:52 GMT, Kevin Rushforth wrote: > As mentioned in the JBS bug report, this is needed to minimize gratuitous diffs in the native WebKit sources between mainline and jfx11u. These diffs can make it hard to see whether there is any substantive diff between the two and also can sometimes lead to merge conflicts. > > In addition to the copyright year changes, which only touched the comments (as with all updates to the copyright year), I corrected one white space difference between jfx and jfx11u. So only a sanity build is needed, which I did. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/29 From kcr at openjdk.java.net Wed Aug 18 11:46:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 11:46:28 GMT Subject: [jfx11u] Integrated: 8269147: Update GStreamer to version 1.18.4 In-Reply-To: <72JuFOrO-AkmOearc1Lxhrk3cI6fUd2WV9kA2vTDsBE=.5638ca20-78b8-45c0-8ae8-825225b6cb61@github.com> References: <72JuFOrO-AkmOearc1Lxhrk3cI6fUd2WV9kA2vTDsBE=.5638ca20-78b8-45c0-8ae8-825225b6cb61@github.com> Message-ID: On Tue, 17 Aug 2021 17:22:44 GMT, Kevin Rushforth wrote: > Clean backport of third-party update to GStreamer 1.18.4. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: 49ff8f6f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/49ff8f6fc7dabcd18cb2447852d9e3002e6f3152 Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod 8269147: Update GStreamer to version 1.18.4 Backport-of: 098c0f393ef0849e140c9efd4d083f3282e1fa0e ------------- PR: https://git.openjdk.java.net/jfx11u/pull/32 From kcr at openjdk.java.net Wed Aug 18 11:46:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 11:46:39 GMT Subject: [jfx11u] Integrated: 8268915: WebKit build fails with Xcode 12.5 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:17:59 GMT, Kevin Rushforth wrote: > Clean backport of fix to rename `VERSION` to `VERSION.txt` to fix build breakage on Xcode 12.5. This pull request has now been integrated. Changeset: ebc5926c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/ebc5926c194025afba2d9320077d117cc1e496df Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8268915: WebKit build fails with Xcode 12.5 Backport-of: 8e11b94ff90d6640c8e7a1dc0da83599b9d16b84 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/31 From kcr at openjdk.java.net Wed Aug 18 11:48:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 11:48:24 GMT Subject: [jfx11u] Integrated: 8269131: Update libxml2 to version 2.9.12 In-Reply-To: <_XBL--0Jy70ZWHG9bA46qbhwfio-ogxNdmmCebEPcks=.738964cf-5af8-404d-b09a-3fe3ff696f73@github.com> References: <_XBL--0Jy70ZWHG9bA46qbhwfio-ogxNdmmCebEPcks=.738964cf-5af8-404d-b09a-3fe3ff696f73@github.com> Message-ID: On Tue, 17 Aug 2021 17:27:49 GMT, Kevin Rushforth wrote: > Clean backport of third-party update to libxml2 2.9.12. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: f930bc53 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/f930bc53384abf051be073ded8ac470859129abd Stats: 4134 lines in 62 files changed: 1582 ins; 1362 del; 1190 mod 8269131: Update libxml2 to version 2.9.12 Backport-of: 52c076c50f3cab17628db4dd2b1b37cb2d6ce92a ------------- PR: https://git.openjdk.java.net/jfx11u/pull/33 From kcr at openjdk.java.net Wed Aug 18 12:07:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 12:07:29 GMT Subject: Integrated: Merge jfx17 In-Reply-To: References: Message-ID: <446R1Jk8Dnc-yBwiE53L9RtIGU97m5nec2_Ycgno5vc=.1e3d17e9-5187-4524-a724-2d1e4b32afc0@github.com> On Wed, 18 Aug 2021 11:58:36 GMT, Kevin Rushforth wrote: > Merge `jfx17` into `master`. This pull request has now been integrated. Changeset: fdc88341 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/fdc88341f1df8fb9c99356ada54b25124b77ea6e Stats: 693 lines in 678 files changed: 0 ins; 0 del; 693 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/606 From kcr at openjdk.java.net Wed Aug 18 12:07:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 12:07:29 GMT Subject: Integrated: Merge jfx17 Message-ID: Merge `jfx17` into `master`. ------------- Commit messages: - Merge jfx17 - 8272329: Cherry pick GTK WebKit 2.32.3 changes - 8271484: Tree-/TableCell: NPE when accessing edit event from startEdit - Merge - 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit - Merge - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's - 8240506: TextFieldSkin/Behavior: misbehavior on switching skin - Merge - 8270839: Remove deprecated implementation methods from Scene - ... and 13 more: https://git.openjdk.java.net/jfx/compare/14b23bcf...412a1839 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/606/files Stats: 287952 lines in 5757 files changed: 176641 ins; 68351 del; 42960 mod Patch: https://git.openjdk.java.net/jfx/pull/606.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/606/head:pull/606 PR: https://git.openjdk.java.net/jfx/pull/606 From kcr at openjdk.java.net Wed Aug 18 12:45:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 12:45:39 GMT Subject: [jfx11u] Integrated: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: <-oc5tDMXCqoAmnbC7JE8elIr8Hy9qD0tTo3YjhPqOTQ=.990d4b7a-16e8-4ba1-8c90-8b538e697ba8@github.com> On Tue, 17 Aug 2021 17:33:13 GMT, Kevin Rushforth wrote: > Nearly clean backport of third-party update to WebKit 612.1. There was one minor conflict in one unit test file due to difference in context. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: 929b9c2a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/929b9c2a3a3b84c21923be4288d7a7677cde192b Stats: 286061 lines in 5711 files changed: 175196 ins; 68118 del; 42747 mod 8268849: Update to 612.1 version of WebKit Reviewed-by: jvos, arapte Backport-of: 948df32448b71c4d6c10ccc4c125170dc68b0786 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/34 From kcr at openjdk.java.net Wed Aug 18 12:52:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 12:52:47 GMT Subject: [jfx11u] Integrated: 8270479: WebKit 612.1 build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:39:55 GMT, Kevin Rushforth wrote: > Clean backport of the fix to allow WebKit to continue to build with VS 2017, as a follow-on to the WebKit 612.1 update, so it is based off that branch. Once PR #34 is integrated, I will rebase this branch on top of `master` (to pick up that fix), and take this out of Draft state. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: 7bc9584c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/7bc9584c5ac7cbad5ea497b4668f049adbbe98f3 Stats: 21 lines in 3 files changed: 21 ins; 0 del; 0 mod 8270479: WebKit 612.1 build fails with Visual Studio 2017 Backport-of: 8aaacb5bd5368d544c4c468f85ce9ed4dbf26d07 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/35 From kcr at openjdk.java.net Wed Aug 18 12:52:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 12:52:46 GMT Subject: [jfx11u] Integrated: 8270479: WebKit 612.1 build fails with Visual Studio 2017 Message-ID: Clean backport of the fix to allow WebKit to continue to build with VS 2017, as a follow-on to the WebKit 612.1 update, so it is based off that branch. Once PR #34 is integrated, I will rebase this branch on top of `master` (to pick up that fix), and take this out of Draft state. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). ------------- Commit messages: - 8270479: WebKit 612.1 build fails with Visual Studio 2017 Changes: https://git.openjdk.java.net/jfx11u/pull/35/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=35&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270479 Stats: 21 lines in 3 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/35.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/35/head:pull/35 PR: https://git.openjdk.java.net/jfx11u/pull/35 From kcr at openjdk.java.net Wed Aug 18 12:59:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 12:59:48 GMT Subject: [jfx11u] RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes Message-ID: Clean backport of the fix to cherry pick GTK WebKit 2.32.3 changes, as a follow-on to the WebKit 612.1 update. Once PR #34 is integrated, I will rebase this branch on top of `master` (to pick up that fix), and take this out of Draft state. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). ------------- Commit messages: - 8272329: Cherry pick GTK WebKit 2.32.3 changes Changes: https://git.openjdk.java.net/jfx11u/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272329 Stats: 341 lines in 61 files changed: 193 ins; 9 del; 139 mod Patch: https://git.openjdk.java.net/jfx11u/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/36/head:pull/36 PR: https://git.openjdk.java.net/jfx11u/pull/36 From kcr at openjdk.java.net Wed Aug 18 13:03:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 13:03:27 GMT Subject: [jfx11u] Integrated: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: References: Message-ID: <7thEJ3xoDj-yd9NBQTpuFN-VSlvicDvcf7uo4LY2rjg=.ae925bc1-23b0-475a-a99b-1bd225e35098@github.com> On Tue, 17 Aug 2021 17:59:50 GMT, Kevin Rushforth wrote: > Clean backport of the fix to cherry pick GTK WebKit 2.32.3 changes, as a follow-on to the WebKit 612.1 update. Once PR #34 is integrated, I will rebase this branch on top of `master` (to pick up that fix), and take this out of Draft state. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: 906b61c0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/906b61c0130668a6b8b93211952dbc8c075dd8ef Stats: 341 lines in 61 files changed: 193 ins; 9 del; 139 mod 8272329: Cherry pick GTK WebKit 2.32.3 changes Backport-of: ee442e516a20e979dc228ab63c6b795b74d49e41 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/36 From kcr at openjdk.java.net Wed Aug 18 13:04:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 13:04:35 GMT Subject: [jfx11u] Integrated: 8266462: Update copyright years of javafx.web native sources in jfx11u In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:55:52 GMT, Kevin Rushforth wrote: > As mentioned in the JBS bug report, this is needed to minimize gratuitous diffs in the native WebKit sources between mainline and jfx11u. These diffs can make it hard to see whether there is any substantive diff between the two and also can sometimes lead to merge conflicts. > > In addition to the copyright year changes, which only touched the comments (as with all updates to the copyright year), I corrected one white space difference between jfx and jfx11u. So only a sanity build is needed, which I did. This pull request has now been integrated. Changeset: 78855b1e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/78855b1e6304eade894402891018bbbb6d2c74fc Stats: 214 lines in 214 files changed: 0 ins; 0 del; 214 mod 8266462: Update copyright years of javafx.web native sources in jfx11u Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx11u/pull/29 From kcr at openjdk.java.net Wed Aug 18 14:58:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 14:58:47 GMT Subject: [jfx11u] Integrated: 8271230: Remove obsolete test classes and data files from 3DViewer sample Message-ID: Clean backport to remove obsolete 3DViewer tests. ------------- Commit messages: - 8271230: Remove obsolete test classes and data files from 3DViewer sample Changes: https://git.openjdk.java.net/jfx11u/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=37&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271230 Stats: 7167 lines in 16 files changed: 0 ins; 7167 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/37/head:pull/37 PR: https://git.openjdk.java.net/jfx11u/pull/37 From kcr at openjdk.java.net Wed Aug 18 14:58:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 Aug 2021 14:58:47 GMT Subject: [jfx11u] Integrated: 8271230: Remove obsolete test classes and data files from 3DViewer sample In-Reply-To: References: Message-ID: <0bX3hGwO_gUL3v6EtQiCWKz8WfH4LCVs94kttz8qSSk=.52e1e2ac-30eb-4095-a5e3-e2ecbe6ea648@github.com> On Wed, 18 Aug 2021 14:49:00 GMT, Kevin Rushforth wrote: > Clean backport to remove obsolete 3DViewer tests. This pull request has now been integrated. Changeset: 215aa17e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/215aa17e201886d15f36c8d138f12d7823f99c4f Stats: 7167 lines in 16 files changed: 0 ins; 7167 del; 0 mod 8271230: Remove obsolete test classes and data files from 3DViewer sample Backport-of: 0e5b7887075e8cbe4d2b332c9021ec997f567ed7 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/37 From jonathanvusich at gmail.com Wed Aug 18 19:45:48 2021 From: jonathanvusich at gmail.com (Jonathan Vusich) Date: Wed, 18 Aug 2021 14:45:48 -0500 Subject: Having trouble setting up the JFX project in IntelliJ Message-ID: Hello all, As the title suggests, I am struggling to figure out how to properly set up the JavaFX project in IntelliJ or Eclipse. I can run the tests for JavaFX through Gradle on the command line, so I am sure that I have all of the needed tools and environment variables set correctly. However, my IntelliJ and Eclipse IDEs both show many compile and build errors, and do not allow me to run any of the test apps due to these compile errors. In order to address feedback on a pull request for JavaFX, I need to be able to run the Ensemble8 test application, and I cannot figure out how to do this from the command line alone. Is there something that I am missing that would cause IntelliJ to be able to resolve these compile errors? Or am I just supposed to run everything through the command line? If the latter is true, how do I run the Ensemble8 application through Gradle from the command line? Many thanks to anyone who can provide some answers. Jonathan Vusich From kcr at openjdk.java.net Thu Aug 19 11:45:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Aug 2021 11:45:30 GMT Subject: [jfx11u] RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:13:36 GMT, Kevin Rushforth wrote: > Clean backport of HTTP/2. This is enabled by default only with running with JDK 12 or later. > > I have tested this with both JDK 11, where I verified that it HTTP/2 is not enabled, and JDK 15, where I verified that it HTTP/2 is enabled. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). @johanvos Did you want to review this before I integrate it? ------------- PR: https://git.openjdk.java.net/jfx11u/pull/30 From fastegal at openjdk.java.net Thu Aug 19 12:48:33 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 19 Aug 2021 12:48:33 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v4] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 16:15:47 GMT, Marius Hanl wrote: >> This PR sets an unified logic to every **startEdit()** method of all Cell implementations. >> So startEdit() is always doing the same now: >> >> `super.startEdit();` >> `if (!isEditing()) { >> return; >> }` >> >> This will prevent a NPE while also being cleaner (no more double checks) >> The commits are splitted into 4 base commits: >> - First commit changes the startEdit() for TableCell implementations (8 files) >> - Second commit changes the startEdit() for TreeTableCell implementations (7 files) >> - Third commit changes the startEdit() for ListCell implementations (7 files) >> - Fourth commit changes the startEdit() for TreeCell implementations (7 files) >> >> While writing tests, I found out that the CheckBoxListCell and the CheckBoxTreeCell don't disable their CheckBox, which is wrong. >> In CheckBoxTableCell and CheckBoxTreeTableCell the CheckBox is disabled, but they don't check their dependencies e.g. TableColumn for null, leading to a NPE if not set. >> >> I wrote a follow-up and assigned it to myself: https://bugs.openjdk.java.net/browse/JDK-8270042 >> The aim of this should be, that all 4 CheckBox...Cells have a proper CheckBox disablement while also being nullsafe. >> >> ~Note 1: I removed the tests in TableCellTest added in https://github.com/openjdk/jfx/pull/529 in favor of the new parameterized TableCellStartEditTest~ >> Note 2: This also fixes https://bugs.openjdk.java.net/browse/JDK-8268295 > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Separated test and made the cell a supplier instead added inline comments, plus: there's an open change request in my last review: - not yet covered: sanity test that startEdit really installs the editing visuals - f.i. by checking that its graphic is null before/ not-null after startEdit might be arguable (might have found the failing tests, though, .. or not :) - personally, I would prefer to only resolve if fully addressed: either after adding the change or consenting to not adding it. modules/javafx.controls/src/main/java/javafx/scene/control/cell/ChoiceBoxListCell.java line 304: > 302: if (isEditing()) { > 303: setText(null); > 304: setGraphic(choiceBox); at this point, the cell is editing (backed out earlier, if not) modules/javafx.controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java line 301: > 299: return; > 300: } > 301: (darn, can't add the important lines - which is backing out if treeItem is null) The re-ordering leads to change of behavior, here's a test that's passing/failing before/after: /** * change of behavior: cell must not be editing if treeItem == null. * fails with fix, passes without */ @Test public void testChoiceBoxTreeCellEditing() { TreeView treeView = new TreeView<>(); treeView.setEditable(true); ChoiceBoxTreeCell cell = new ChoiceBoxTreeCell<>(); cell.updateTreeView(treeView); cell.updateItem("TEST", false); cell.startEdit(); assertFalse(cell.isEditing()); assertNull(cell.getGraphic()); } same for ComboBoxTreeCell modules/javafx.controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java line 331: > 329: if (!isEditing()) { > 330: return; > 331: } same as ChoiceBoxTreeCell modules/javafx.controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java line 195: > 193: if (!isEditing()) { > 194: return; > 195: } similar to ChoiceBox/ComboBoxTreeCell, except that a similar test fails both before/after the fix modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 27: > 25: > 26: package test.javafx.scene.control; > 27: the issue is about specialized cells in package xx.cell, the tests should be also reside in that package modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 65: > 63: public static Collection data() { > 64: return wrapAsObjectArray(List.of(ListCell::new, ComboBoxListCell::new, TextFieldListCell::new, > 65: ChoiceBoxListCell::new, () -> new CheckBoxListCell<>(obj -> new SimpleBooleanProperty()))); the issue is about the specialized cells, so I would suggest to remove the base Cell here, it's fully (maybe :) already Doing so, makes it also simpler to test the not/existance of the editing ui (which is not yet addressed in the tests) modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 84: > 82: @Test > 83: public void testStartEditMustNotThrowNPE() { > 84: ListCell listCell = listCellSupplier.get(); the usual pattern is to create the instances is to do so in setup, not in every single test ------------- Changes requested by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/569 From arapte at openjdk.java.net Thu Aug 19 12:51:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 12:51:40 GMT Subject: [jfx11u] RFR: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop Changes: https://git.openjdk.java.net/jfx11u/pull/38/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=38&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264737 Stats: 352 lines in 5 files changed: 349 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/38.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/38/head:pull/38 PR: https://git.openjdk.java.net/jfx11u/pull/38 From arapte at openjdk.java.net Thu Aug 19 12:58:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 12:58:41 GMT Subject: [jfx11u] RFR: 8266860: [macos] Incorrect duration reported for HLS live streams Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8266860: [macos] Incorrect duration reported for HLS live streams Changes: https://git.openjdk.java.net/jfx11u/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=39&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266860 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/39/head:pull/39 PR: https://git.openjdk.java.net/jfx11u/pull/39 From arapte at openjdk.java.net Thu Aug 19 13:36:35 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 13:36:35 GMT Subject: [jfx11u] Integrated: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 12:45:55 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: b2c1622f Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/b2c1622f4f1c1d96d4c487f5f5c15d0e1933f39b Stats: 352 lines in 5 files changed: 349 ins; 0 del; 3 mod 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop Backport-of: 0a6861304e142eed547f3c82b0d2e2a55f91b9b4 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/38 From arapte at openjdk.java.net Thu Aug 19 13:39:25 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 13:39:25 GMT Subject: [jfx11u] Integrated: 8266860: [macos] Incorrect duration reported for HLS live streams In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 12:52:21 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: 097780df Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/097780df729f4ae9b5bff48f97e4c1323627317b Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8266860: [macos] Incorrect duration reported for HLS live streams Backport-of: c511789b106a3f3172aef606419d372bcbca606f ------------- PR: https://git.openjdk.java.net/jfx11u/pull/39 From jvos at openjdk.java.net Thu Aug 19 16:05:34 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 19 Aug 2021 16:05:34 GMT Subject: [jfx11u] RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 11:42:12 GMT, Kevin Rushforth wrote: > @johanvos Did you want to review this before I integrate it? I'm testing, will have a result in < 4 hours from now ------------- PR: https://git.openjdk.java.net/jfx11u/pull/30 From arapte at openjdk.java.net Thu Aug 19 16:10:37 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 16:10:37 GMT Subject: [jfx11u] RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8268219: hlsprogressbuffer should provide PTS after GStreamer update Changes: https://git.openjdk.java.net/jfx11u/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=41&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268219 Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/41/head:pull/41 PR: https://git.openjdk.java.net/jfx11u/pull/41 From arapte at openjdk.java.net Thu Aug 19 16:10:45 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 16:10:45 GMT Subject: [jfx11u] RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8267819: CoInitialize/CoUninitialize should be called on same thread Changes: https://git.openjdk.java.net/jfx11u/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=40&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267819 Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/40/head:pull/40 PR: https://git.openjdk.java.net/jfx11u/pull/40 From arapte at openjdk.java.net Thu Aug 19 16:14:28 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 16:14:28 GMT Subject: [jfx11u] Integrated: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 16:02:13 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: 2eca4512 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/2eca45121632d0a5382bedb52a42468aa6811c00 Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod 8267819: CoInitialize/CoUninitialize should be called on same thread Backport-of: 47700d8ef0175d4b457bb658371d2da4ec0a8181 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/40 From arapte at openjdk.java.net Thu Aug 19 16:17:27 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 16:17:27 GMT Subject: [jfx11u] Integrated: 8268219: hlsprogressbuffer should provide PTS after GStreamer update In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 16:05:20 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: cb152a8e Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/cb152a8ec20fb06416be8d8646d88b2696926acd Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod 8268219: hlsprogressbuffer should provide PTS after GStreamer update Backport-of: 98138c84a7f286731ad12dd5c533cd3fa265bf56 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/41 From arapte at openjdk.java.net Thu Aug 19 17:15:48 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 17:15:48 GMT Subject: [jfx11u] RFR: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later Changes: https://git.openjdk.java.net/jfx11u/pull/42/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=42&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231558 Stats: 208 lines in 7 files changed: 204 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx11u/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/42/head:pull/42 PR: https://git.openjdk.java.net/jfx11u/pull/42 From arapte at openjdk.java.net Thu Aug 19 17:37:28 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 17:37:28 GMT Subject: [jfx11u] Integrated: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 17:10:11 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: e9433d6e Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/e9433d6e9cb1929f44e1c2d10b759cfa01f5c19c Stats: 208 lines in 7 files changed: 204 ins; 0 del; 4 mod 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later Backport-of: 6403d6745578887b7f2ccc10ac02e7cdd04d09c1 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/42 From arapte at openjdk.java.net Thu Aug 19 17:49:42 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 17:49:42 GMT Subject: [jfx11u] RFR: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Changes: https://git.openjdk.java.net/jfx11u/pull/43/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=43&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268718 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx11u/pull/43 From arapte at openjdk.java.net Thu Aug 19 17:52:33 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 17:52:33 GMT Subject: [jfx11u] Integrated: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached In-Reply-To: References: Message-ID: <3iYNLj2sTaXLr6iINJwuhvY3bwvyeGzT5__zbaIZQBk=.80796f43-cd64-4122-b8a8-da9c87e6c30b@github.com> On Thu, 19 Aug 2021 17:43:02 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: 5185c671 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/5185c671f4ad4df2d93dd48df1d78129101e73a1 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Backport-of: 0c98d9608611aa2378b38604e2528935c94e84ae ------------- PR: https://git.openjdk.java.net/jfx11u/pull/43 From nlisker at gmail.com Thu Aug 19 18:25:06 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 19 Aug 2021 21:25:06 +0300 Subject: Having trouble setting up the JFX project in IntelliJ In-Reply-To: References: Message-ID: There are IDE instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE I don't know about IntelliJ since I use Eclipse. The project files there were pending an update at https://github.com/openjdk/jfx/pull/514, but since then projects were removed and more changes are planned, so I closed the PR. Still, you can test the changes there and see if they solve at least some of the issues. I can create a new PR if you are willing to serve as a reviewer because lack of reviewers is what stops the PRs for updating the Eclipse files. Some tests, like ones that use the Robot API, require additional command line arguments to work, so just clicking run on the unit test won't work. I tend to run those from the command line, but it should be possible to make them run from Eclipse somehow. Regular unit tests run for me. On Wed, Aug 18, 2021 at 10:46 PM Jonathan Vusich wrote: > Hello all, > > > > As the title suggests, I am struggling to figure out how to properly set up > the JavaFX project in IntelliJ or Eclipse. I can run the tests for JavaFX > through Gradle on the command line, so I am sure that I have all of the > needed tools and environment variables set correctly. However, my IntelliJ > and Eclipse IDEs both show many compile and build errors, and do not allow > me to run any of the test apps due to these compile errors. In order to > address feedback on a pull request for JavaFX, I need to be able to run the > Ensemble8 test application, and I cannot figure out how to do this from the > command line alone. Is there something that I am missing that would cause > IntelliJ to be able to resolve these compile errors? Or am I just supposed > to run everything through the command line? If the latter is true, how do I > run the Ensemble8 application through Gradle from the command line? Many > thanks to anyone who can provide some answers. > > > > Jonathan Vusich > From arapte at openjdk.java.net Thu Aug 19 18:29:43 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 18:29:43 GMT Subject: [jfx11u] RFR: 8265400: Update to gcc 10.3 on Linux Message-ID: <7xHJOUa7f2pnPKquSaVNpwbfryvWUYkXbM29KxfXzM0=.1077a53d-6706-4c59-a33c-e49badf220f6@github.com> This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8265400: Update to gcc 10.3 on Linux Changes: https://git.openjdk.java.net/jfx11u/pull/44/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=44&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265400 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/44.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/44/head:pull/44 PR: https://git.openjdk.java.net/jfx11u/pull/44 From arapte at openjdk.java.net Thu Aug 19 18:36:28 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 18:36:28 GMT Subject: [jfx11u] Integrated: 8265400: Update to gcc 10.3 on Linux In-Reply-To: <7xHJOUa7f2pnPKquSaVNpwbfryvWUYkXbM29KxfXzM0=.1077a53d-6706-4c59-a33c-e49badf220f6@github.com> References: <7xHJOUa7f2pnPKquSaVNpwbfryvWUYkXbM29KxfXzM0=.1077a53d-6706-4c59-a33c-e49badf220f6@github.com> Message-ID: On Thu, 19 Aug 2021 18:23:05 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: 0dd8eed7 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/0dd8eed79a9c0a2483c477f5fe67c5a8f633e67f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265400: Update to gcc 10.3 on Linux Backport-of: e3e5116e4e9168015c0328dd1fbfffa3b3180626 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/44 From jvos at openjdk.java.net Thu Aug 19 18:42:25 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 19 Aug 2021 18:42:25 GMT Subject: [jfx11u] RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 17:13:36 GMT, Kevin Rushforth wrote: > Clean backport of HTTP/2. This is enabled by default only with running with JDK 12 or later. > > I have tested this with both JDK 11, where I verified that it HTTP/2 is not enabled, and JDK 15, where I verified that it HTTP/2 is enabled. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). basic tests work as expected. We should probably add this to the release notes. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx11u/pull/30 From arapte at openjdk.java.net Thu Aug 19 18:52:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 18:52:39 GMT Subject: [jfx11u] Integrated: 8267121: Illegal access to private "size" field of ArrayList from build.gradle Message-ID: <1j70-BfGkmQREINFLvrPzcQb9p8cmLEFgnVzBo0oUDE=.718b7a93-fe65-4fb1-9cb2-96ffd21dc61c@github.com> This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8267121: Illegal access to private "size" field of ArrayList from build.gradle Changes: https://git.openjdk.java.net/jfx11u/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267121 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/45/head:pull/45 PR: https://git.openjdk.java.net/jfx11u/pull/45 From arapte at openjdk.java.net Thu Aug 19 18:52:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 18:52:40 GMT Subject: [jfx11u] Integrated: 8267121: Illegal access to private "size" field of ArrayList from build.gradle In-Reply-To: <1j70-BfGkmQREINFLvrPzcQb9p8cmLEFgnVzBo0oUDE=.718b7a93-fe65-4fb1-9cb2-96ffd21dc61c@github.com> References: <1j70-BfGkmQREINFLvrPzcQb9p8cmLEFgnVzBo0oUDE=.718b7a93-fe65-4fb1-9cb2-96ffd21dc61c@github.com> Message-ID: On Thu, 19 Aug 2021 18:43:29 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: 3aa3f19e Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/3aa3f19e60206e8fb4c8304cdae01f8b28ea664b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8267121: Illegal access to private "size" field of ArrayList from build.gradle Backport-of: 9c97d9b21232a67a10debdc8dc3b10c419780f7a ------------- PR: https://git.openjdk.java.net/jfx11u/pull/45 From arapte at openjdk.java.net Thu Aug 19 19:00:36 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 19:00:36 GMT Subject: [jfx11u] Integrated: 8267858: Document that title property in WebEngine gets updated asynchronously Message-ID: This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8267858: Document that title property in WebEngine gets updated asynchronously Changes: https://git.openjdk.java.net/jfx11u/pull/46/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=46&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267858 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/46.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/46/head:pull/46 PR: https://git.openjdk.java.net/jfx11u/pull/46 From arapte at openjdk.java.net Thu Aug 19 19:00:36 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 19:00:36 GMT Subject: [jfx11u] Integrated: 8267858: Document that title property in WebEngine gets updated asynchronously In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 18:53:49 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: fdbf3277 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/fdbf327769579d26c3a198fea8810a5b868b95b4 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8267858: Document that title property in WebEngine gets updated asynchronously Backport-of: ca250364aae7a4e071d307ac1091c22776cf9a38 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/46 From nlisker at gmail.com Thu Aug 19 19:03:34 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 19 Aug 2021 22:03:34 +0300 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: > > I'd like to see pivot properties move forward. > The PR seems to be a bit stale, as it has been sitting around for > almost two years. Me too, but there was no decision as to the implementation type. We can continue the discussion on the PR at this point I think. On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? wrote: > I'd like to see pivot properties move forward. > The PR seems to be a bit stale, as it has been sitting around for > almost two years. > > PR: https://github.com/openjdk/jfx/pull/53 > > Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth > : > > > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > > and enhancement requests for JavaFX 18. It's the summer, so there may be > > delays as some people are out at various times (including me), but I > > would like to get some of the outstanding enhancement requests moving > > over the next few weeks. > > > > Specifically, I'd like to see the following proceed: > > > > * Transparent backgrounds in WebView > > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > PR: https://github.com/openjdk/jfx/pull/563 > > > > * Add DirectionalLight > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > PR: https://github.com/openjdk/jfx/pull/548 > > > > * CSS pseudoclasses :focus-visible and :focus-within > > https://bugs.openjdk.java.net/browse/JDK-8268225 > > PR: https://github.com/openjdk/jfx/pull/475 > > > > * Improve property system to facilitate correct usage (minus the binary > > incompatible API change) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > > > And maybe the following: > > > > * Add CSS themes as a first-class concept (need a consensus on how to > > proceed) > > > > * Undecorated interactive stage style (still in early discussion, but > > the concept looks interesting and useful) > > > > There are probably others I'm forgetting. > > > > Each of the above should be discussed in their own thread on openjfx-dev > > rather than a reply to this thread. > > > > -- Kevin > > > > > From arapte at openjdk.java.net Thu Aug 19 19:16:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 19:16:39 GMT Subject: [jfx11u] RFR: 8267892: Add .gitattributes to repo Message-ID: <9PMyYcVvPW668bF-FDPC3ezCISXRgwYCMUbkF4c0mDM=.abf99226-18cc-4542-90eb-d727791eaeae@github.com> This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) ------------- Commit messages: - 8267892: Add .gitattributes to repo Changes: https://git.openjdk.java.net/jfx11u/pull/47/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=47&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267892 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/47/head:pull/47 PR: https://git.openjdk.java.net/jfx11u/pull/47 From arapte at openjdk.java.net Thu Aug 19 19:41:28 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 19 Aug 2021 19:41:28 GMT Subject: [jfx11u] Integrated: 8267892: Add .gitattributes to repo In-Reply-To: <9PMyYcVvPW668bF-FDPC3ezCISXRgwYCMUbkF4c0mDM=.abf99226-18cc-4542-90eb-d727791eaeae@github.com> References: <9PMyYcVvPW668bF-FDPC3ezCISXRgwYCMUbkF4c0mDM=.abf99226-18cc-4542-90eb-d727791eaeae@github.com> Message-ID: On Thu, 19 Aug 2021 19:09:47 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: 3a1e780e Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/3a1e780e60455c771a2b743179c4cb6924c2526c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8267892: Add .gitattributes to repo Backport-of: 5e6d4429159e3fab9ec0aab9720393850d179710 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/47 From jonathanvusich at gmail.com Thu Aug 19 19:56:03 2021 From: jonathanvusich at gmail.com (Jonathan Vusich) Date: Thu, 19 Aug 2021 14:56:03 -0500 Subject: Having trouble setting up the JFX project in IntelliJ In-Reply-To: References: Message-ID: Thanks for the link to the IDE instructions, Nir. I did not see that before. I was trying to import the project as a Gradle project which was not working very well. I have imported the project as an IntelliJ project and seem to be having more success, but I am still getting these module warnings that are preventing me from building the project or running any of the apps. https://imgur.com/a/G6r32HG If anyone else who uses IntelliJ knows how to resolve this, please let me know. On Thu, Aug 19, 2021 at 1:25 PM Nir Lisker wrote: > There are IDE instructions here: > https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE > > I don't know about IntelliJ since I use Eclipse. The project files there > were pending an update at https://github.com/openjdk/jfx/pull/514, but > since then projects were removed and more changes are planned, so I closed > the PR. Still, you can test the changes there and see if they solve at > least some of the issues. I can create a new PR if you are willing to serve > as a reviewer because lack of reviewers is what stops the PRs for updating > the Eclipse files. > > Some tests, like ones that use the Robot API, require additional command > line arguments to work, so just clicking run on the unit test won't work. I > tend to run those from the command line, but it should be possible to make > them run from Eclipse somehow. Regular unit tests run for me. > > On Wed, Aug 18, 2021 at 10:46 PM Jonathan Vusich > wrote: > >> Hello all, >> >> >> >> As the title suggests, I am struggling to figure out how to properly set >> up >> the JavaFX project in IntelliJ or Eclipse. I can run the tests for JavaFX >> through Gradle on the command line, so I am sure that I have all of the >> needed tools and environment variables set correctly. However, my IntelliJ >> and Eclipse IDEs both show many compile and build errors, and do not allow >> me to run any of the test apps due to these compile errors. In order to >> address feedback on a pull request for JavaFX, I need to be able to run >> the >> Ensemble8 test application, and I cannot figure out how to do this from >> the >> command line alone. Is there something that I am missing that would cause >> IntelliJ to be able to resolve these compile errors? Or am I just supposed >> to run everything through the command line? If the latter is true, how do >> I >> run the Ensemble8 application through Gradle from the command line? Many >> thanks to anyone who can provide some answers. >> >> >> >> Jonathan Vusich >> > From kevin.rushforth at oracle.com Thu Aug 19 20:27:57 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Aug 2021 13:27:57 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: Thank you to all who added additional items that they wish to see for JavaFX 18. I haven't forgotten about this thread. I'll answer most of them some time in the next week or so. Worth noting is that there is limited bandwidth for enhancements. Every feature has to pull its own weight, meaning we need to factor in the cost of implementing, reviewing, testing, and maintaining it, as well as the opportunity cost of not doing something else. Those enhancements that have reached general consensus, are far enough along in the process that we have a good idea how much they will "cost", and have a willing contributor and sponsor (for contributors who are not Committers), are more likely to make JavaFX 18. -- Kevin On 7/30/2021 5:56 AM, Kevin Rushforth wrote: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may > be delays as some people are out at various times (including me), but > I would like to get some of the outstanding enhancement requests > moving over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the > binary incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on > openjfx-dev rather than a reply to this thread. > > -- Kevin > > From kevin.rushforth at oracle.com Thu Aug 19 20:35:46 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Aug 2021 13:35:46 -0700 Subject: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: Message-ID: The idea of adding explicit pivot properties was met with general agreement as long as we preserve compatibility (meaning that an auto-computed pivot at the center of the bounds must remain the default). The questions are around what form the API should take. They basically boil down to: 1. How do we indicate whether the pivot is computed vs explicitly specified? 2. Should the pivot position be 3 doubles or a Point3D 3. Do we need a separate pivot for rotation vs scaling My quick thoughts (although I might be able to be persuaded otherwise) are: 1) a boolean property 2) 3 separate doubles 3) no Michael's proposal of a couple months ago [1] would match those answers, and is an interesting approach that I hadn't considered before. The question then is whether want the additional flexibility that it provides and whether it is worth the additional implementation, documentation, and testing that would be needed. It can be a discussion point. I'd like to know what Nir thinks of that idea. I think we can discuss the details of the API in the PR, although while it is Draft, many people will miss the discussion (since it doesn't get sent to the mailing list), so it might be better to at get high-level agreement on the answers to the outstanding API questions on this list? -- Kevin [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 On 8/19/2021 12:03 PM, Nir Lisker wrote: > > I'd like to see pivot properties move forward. > The PR seems to be a bit stale, as it has been sitting around for > almost two years. > > > Me too, but there was no decision as to the implementation type. We > can continue the discussion on the PR at this point I think. > > On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? > > wrote: > > I'd like to see pivot properties move forward. > The PR seems to be a bit stale, as it has been sitting around for > almost two years. > > PR: https://github.com/openjdk/jfx/pull/53 > > > Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth > >: > > > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug > fixes > > and enhancement requests for JavaFX 18. It's the summer, so > there may be > > delays as some people are out at various times (including me), but I > > would like to get some of the outstanding enhancement requests > moving > > over the next few weeks. > > > > Specifically, I'd like to see the following proceed: > > > > * Transparent backgrounds in WebView > > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > > PR: https://github.com/openjdk/jfx/pull/563 > > > > > * Add DirectionalLight > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > > PR: https://github.com/openjdk/jfx/pull/548 > > > > > * CSS pseudoclasses :focus-visible and :focus-within > > https://bugs.openjdk.java.net/browse/JDK-8268225 > > > PR: https://github.com/openjdk/jfx/pull/475 > > > > > * Improve property system to facilitate correct usage (minus the > binary > > incompatible API change) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > > PR: https://github.com/openjdk/jfx/pull/590 > > (Draft) > > > > And maybe the following: > > > > * Add CSS themes as a first-class concept (need a consensus on > how to > > proceed) > > > > * Undecorated interactive stage style (still in early > discussion, but > > the concept looks interesting and useful) > > > > There are probably others I'm forgetting. > > > > Each of the above should be discussed in their own thread on > openjfx-dev > > rather than a reply to this thread. > > > > -- Kevin > > > > > From kcr at openjdk.java.net Thu Aug 19 20:47:32 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Aug 2021 20:47:32 GMT Subject: [jfx11u] RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 18:39:08 GMT, Johan Vos wrote: > We should probably add this to the release notes. Good idea. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/30 From kcr at openjdk.java.net Thu Aug 19 20:47:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 Aug 2021 20:47:33 GMT Subject: [jfx11u] Integrated: 8211308: Support HTTP/2 in WebView In-Reply-To: References: Message-ID: <_aEXNkKRVfFjvT9FjAD58hMR2ti1CCaLbYYHal1_Ix8=.bc50dc86-6e2d-4565-b2dd-66ad68f3ba0f@github.com> On Tue, 17 Aug 2021 17:13:36 GMT, Kevin Rushforth wrote: > Clean backport of HTTP/2. This is enabled by default only with running with JDK 12 or later. > > I have tested this with both JDK 11, where I verified that it HTTP/2 is not enabled, and JDK 15, where I verified that it HTTP/2 is enabled. > > As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: 3f691c64 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/3f691c64be128df2b6fb2baae756453ca006a7df Stats: 1166 lines in 14 files changed: 881 ins; 217 del; 68 mod 8211308: Support HTTP/2 in WebView Reviewed-by: jvos Backport-of: 98035cb2afef0c230d55095f0addeab73693d0ac ------------- PR: https://git.openjdk.java.net/jfx11u/pull/30 From michaelstrau2 at gmail.com Fri Aug 20 00:50:55 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 20 Aug 2021 02:50:55 +0200 Subject: Moving discussions to GitHub? Message-ID: With the GitHub Discussions feature now out of beta*, I'd like to start a conversation on whether it could be a good idea for the OpenJFX project to embrace it as the primary place to discuss and interact with the broader community. While I understand that mailing lists have a long tradition with OpenJDK projects, I feel that they are not a great tool for building and maintaining a community. It's pretty hard to search archived mails and find relevant information or past discussions. Sure, you can do it, but it's not very inviting and accessible. It also seems to me that the mailing list is very disconnected from the people actually using OpenJFX. Since most people already are on GitHub, and most people interested in OpenJFX will find its GitHub repository, it would also seem to be the most logical place to invite people into the community and join our discussions. After all, growing and maintaining a community is fundamental for every open-source project to remain relevant. * https://github.blog/2021-08-17-github-discussions-out-of-beta From sproket at videotron.ca Fri Aug 20 01:18:13 2021 From: sproket at videotron.ca (Dan Howard) Date: Thu, 19 Aug 2021 21:18:13 -0400 Subject: Moving discussions to GitHub? In-Reply-To: References: Message-ID: How do you get people to know that there's a discussion going on? We subscribe to follow things here.? How would people outside find things to get involved? On 8/19/2021 8:50 PM, Michael Strau? wrote: > With the GitHub Discussions feature now out of beta*, I'd like to > start a conversation on whether it could be a good idea for the > OpenJFX project to embrace it as the primary place to discuss and > interact with the broader community. > > While I understand that mailing lists have a long tradition with > OpenJDK projects, I feel that they are not a great tool for building > and maintaining a community. It's pretty hard to search archived mails > and find relevant information or past discussions. Sure, you can do > it, but it's not very inviting and accessible. > > It also seems to me that the mailing list is very disconnected from > the people actually using OpenJFX. Since most people already are on > GitHub, and most people interested in OpenJFX will find its GitHub > repository, it would also seem to be the most logical place to invite > people into the community and join our discussions. > > After all, growing and maintaining a community is fundamental for > every open-source project to remain relevant. > > * https://github.blog/2021-08-17-github-discussions-out-of-beta From philip.race at oracle.com Fri Aug 20 01:39:04 2021 From: philip.race at oracle.com (Philip Race) Date: Thu, 19 Aug 2021 18:39:04 -0700 Subject: Moving discussions to GitHub? In-Reply-To: References: Message-ID: <2c4b0437-943b-2e62-352d-b263ef4ce451@oracle.com> I am not sure that openjfx as an openjdk sponsored project can unilaterally decide this. Nor sure that it makes sense either to be different. And I've not felt the same disconnection you cite or have any idea why this would be better or even match how we work. -phil. On 8/19/21 5:50 PM, Michael Strau? wrote: > With the GitHub Discussions feature now out of beta*, I'd like to > start a conversation on whether it could be a good idea for the > OpenJFX project to embrace it as the primary place to discuss and > interact with the broader community. > > While I understand that mailing lists have a long tradition with > OpenJDK projects, I feel that they are not a great tool for building > and maintaining a community. It's pretty hard to search archived mails > and find relevant information or past discussions. Sure, you can do > it, but it's not very inviting and accessible. > > It also seems to me that the mailing list is very disconnected from > the people actually using OpenJFX. Since most people already are on > GitHub, and most people interested in OpenJFX will find its GitHub > repository, it would also seem to be the most logical place to invite > people into the community and join our discussions. > > After all, growing and maintaining a community is fundamental for > every open-source project to remain relevant. > > * https://github.blog/2021-08-17-github-discussions-out-of-beta From michaelstrau2 at gmail.com Fri Aug 20 01:40:22 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 20 Aug 2021 03:40:22 +0200 Subject: Moving discussions to GitHub? In-Reply-To: References: Message-ID: You can configure GitHub email notifications by clicking on the "Watch" button (it's right next to "Star" and "Fork"). Selecting "All Activity" is probably what you'll want to choose for a "mailing list experience". GitHub Discussions can be organized by categories (for example, "Ideas", "Q&A", "Development", etc.), so people who are stumbling upon the OpenJFX repository will have "obvious" places to go to ask questions or engage in discussions. Am Fr., 20. Aug. 2021 um 03:19 Uhr schrieb Dan Howard : > > How do you get people to know that there's a discussion going on? We > subscribe to follow things here. How would people outside find things > to get involved? From mstrauss at openjdk.java.net Fri Aug 20 05:15:49 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 20 Aug 2021 05:15:49 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fixed undeterministic test failures ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/a1da00b2..d9a715e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=05-06 Stats: 37 lines in 1 file changed: 35 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Fri Aug 20 05:32:23 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 20 Aug 2021 05:32:23 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v5] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 22:54:46 GMT, Kevin Rushforth wrote: > One thing I will note is that the Linux unit test failures are real. That was a bit tough to track down, and a good reminder of why global static state should be avoided at all costs. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From sebastian.stenzel at gmail.com Fri Aug 20 06:28:22 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Fri, 20 Aug 2021 08:28:22 +0200 Subject: Moving discussions to GitHub? (Philip Race) In-Reply-To: References: Message-ID: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> I am among the younger people here on the mailing lists (at least I think so) and I can very much relate to what Michael suggests. So here is my personal answer to the _why_ question: Mailing lists create an enormous barrier to external devs like myself who are willing to contribute: * Signing up to a means of the 80s feels just strange * Signing up to _any_ additional tool is deterring (same holds true for JBS), especially when you're used to low-threshold contributions to other projects can be * Therefore, signing up feels like a liability that you may not want to commit to, if you merely want to express your support for a single comment * It can be hard to find the correct mailing list for the topic you want to discuss * You'll * either receive digests and miss a topic you're interested in * or dozens of additional mails each day, alienating people who just want to follow specific discussions * No proper formatting * No proper linking to code, issues, PRs, ... * Hard to track diverging discussions * Very hard to search - I basically need to use Google and restrict the search to some mail archive * Linking to different topics means you need to either quote the whole thing or link to an archive On the other hand I see one important argument against GitHub Discussions: We have no control over how Discussions will change in the future. Even if they seem suitable today, we can't tell if it may be necessary to switch to yet another tool in 5 years. Each time you switch, you strip connections to discussions that took place on the previous platform. Switching tools always comes with a commitment to it and bears this risk. That said, I agree that this may not be something for OpenJFX to decide for its own. Maybe this discussion belongs on the skara mailing list (did I mention that it's hard to find the right mailing list, a topic belongs to?) Furthermore, changing a process is never easy and will scare people used to the status quo, especially when they've grown familiar with the old process over decades. I've seen this in companies many times. If there is no pressure to change, better tooling is not a strong enough argument to change processes. > On 20. Aug 2021, at 03:39, openjfx-dev-request at openjdk.java.net wrote: > > From: Philip Race > > Subject: Re: Moving discussions to GitHub? > Date: 20. August 2021 at 03:39:04 CEST > To: Michael Strau? >, "openjfx-dev at openjdk.java.net List" > > > > I am not sure that openjfx as an openjdk sponsored project can unilaterally decide this. > Nor sure that it makes sense either to be different. > And I've not felt the same disconnection you cite or have any idea why > this would be better or even match how we work. > > > -phil. > > On 8/19/21 5:50 PM, Michael Strau? wrote: >> With the GitHub Discussions feature now out of beta*, I'd like to >> start a conversation on whether it could be a good idea for the >> OpenJFX project to embrace it as the primary place to discuss and >> interact with the broader community. >> >> While I understand that mailing lists have a long tradition with >> OpenJDK projects, I feel that they are not a great tool for building >> and maintaining a community. It's pretty hard to search archived mails >> and find relevant information or past discussions. Sure, you can do >> it, but it's not very inviting and accessible. >> >> It also seems to me that the mailing list is very disconnected from >> the people actually using OpenJFX. Since most people already are on >> GitHub, and most people interested in OpenJFX will find its GitHub >> repository, it would also seem to be the most logical place to invite >> people into the community and join our discussions. >> >> After all, growing and maintaining a community is fundamental for >> every open-source project to remain relevant. >> >> * https://github.blog/2021-08-17-github-discussions-out-of-beta From johan.vos at gluonhq.com Fri Aug 20 14:30:20 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 20 Aug 2021 16:30:20 +0200 Subject: Moving discussions to GitHub? (Philip Race) In-Reply-To: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> References: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> Message-ID: Hi, I see the value of Github Discussions, but I also see the value of the mailinglists we are currently using. We have to realise though that this particular list is about the *development* of OpenJFX, not about *using* OpenJFX. Therefore, I believe it is ok to be more formal here, and a number of things that make Github discussions more light-weight might imho decrease productivity. But on the other hand, I also agree that the entry level is very high for new developers. Years ago, I advocated for a separate "openjfx-discuss" mailinglist where we would have more informal discussions and brainstorms. We have that list but it's not frequently used. I was probably wrong in suggesting this, as the style and formalism of the mailinglists does not match with discussions amongst developers. The idea of what I had for an "openjfx-discuss" mailinglist might work better on Github Discussions. It would be a low-level entry point where new ideas can be tossed. Personally, I don't see what's wrong with the subscribe page (I love it when technology from the eighties is still working :) ) but realistically, yes, it might turn away developers who might have great ideas and time. In short: I'm +1 on keeping openjfx-dev to the current mailinglist, but I think it could be good if we move openjfx-discuss to a github discussion. - Johan On Fri, Aug 20, 2021 at 8:29 AM Sebastian Stenzel < sebastian.stenzel at gmail.com> wrote: > I am among the younger people here on the mailing lists (at least I think > so) and I can very much relate to what Michael suggests. So here is my > personal answer to the _why_ question: > > Mailing lists create an enormous barrier to external devs like myself who > are willing to contribute: > * Signing up to a means of the 80s feels just strange > * Signing up to _any_ additional tool is deterring (same holds true for > JBS), especially when you're used to low-threshold contributions to other > projects can be > * Therefore, signing up feels like a liability that you may not want to > commit to, if you merely want to express your support for a single comment > * It can be hard to find the correct mailing list for the topic you want > to discuss > * You'll > * either receive digests and miss a topic you're interested in > * or dozens of additional mails each day, alienating people who just > want to follow specific discussions > * No proper formatting > * No proper linking to code, issues, PRs, ... > * Hard to track diverging discussions > * Very hard to search - I basically need to use Google and restrict the > search to some mail archive > * Linking to different topics means you need to either quote the whole > thing or link to an archive > > On the other hand I see one important argument against GitHub Discussions: > We have no control over how Discussions will change in the future. Even if > they seem suitable today, we can't tell if it may be necessary to switch to > yet another tool in 5 years. Each time you switch, you strip connections to > discussions that took place on the previous platform. Switching tools > always comes with a commitment to it and bears this risk. > > That said, I agree that this may not be something for OpenJFX to decide > for its own. Maybe this discussion belongs on the skara mailing list (did I > mention that it's hard to find the right mailing list, a topic belongs to?) > Furthermore, changing a process is never easy and will scare people used to > the status quo, especially when they've grown familiar with the old process > over decades. I've seen this in companies many times. If there is no > pressure to change, better tooling is not a strong enough argument to > change processes. > > > > On 20. Aug 2021, at 03:39, openjfx-dev-request at openjdk.java.net wrote: > > > > From: Philip Race >> > > Subject: Re: Moving discussions to GitHub? > > Date: 20. August 2021 at 03:39:04 CEST > > To: Michael Strau? michaelstrau2 at gmail.com>>, "openjfx-dev at openjdk.java.net openjfx-dev at openjdk.java.net> List" openjfx-dev at openjdk.java.net>> > > > > > > I am not sure that openjfx as an openjdk sponsored project can > unilaterally decide this. > > Nor sure that it makes sense either to be different. > > And I've not felt the same disconnection you cite or have any idea why > > this would be better or even match how we work. > > > > > > -phil. > > > > On 8/19/21 5:50 PM, Michael Strau? wrote: > >> With the GitHub Discussions feature now out of beta*, I'd like to > >> start a conversation on whether it could be a good idea for the > >> OpenJFX project to embrace it as the primary place to discuss and > >> interact with the broader community. > >> > >> While I understand that mailing lists have a long tradition with > >> OpenJDK projects, I feel that they are not a great tool for building > >> and maintaining a community. It's pretty hard to search archived mails > >> and find relevant information or past discussions. Sure, you can do > >> it, but it's not very inviting and accessible. > >> > >> It also seems to me that the mailing list is very disconnected from > >> the people actually using OpenJFX. Since most people already are on > >> GitHub, and most people interested in OpenJFX will find its GitHub > >> repository, it would also seem to be the most logical place to invite > >> people into the community and join our discussions. > >> > >> After all, growing and maintaining a community is fundamental for > >> every open-source project to remain relevant. > >> > >> * https://github.blog/2021-08-17-github-discussions-out-of-beta < > https://github.blog/2021-08-17-github-discussions-out-of-beta> > From kevin.rushforth at oracle.com Fri Aug 20 14:46:53 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Aug 2021 07:46:53 -0700 Subject: Moving discussions to GitHub? (Philip Race) In-Reply-To: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> References: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> Message-ID: <333e02a5-d5e1-11a5-75a3-8c77232007c2@oracle.com> I also completely agree with Phil that this would need to be discussed in the larger context of OpenJDK before it could be considered. The OpenJDK organization intentionally does not use the GitHub issue tracker, Wiki, or discussion forums. I suspect there will be resistance to revisiting this. If you or Michael do want to bring it up, the best place to discuss it would be discuss at openjdk.java.net since this is more of a policy discussion than a technical one (the skara-dev list is for technical discussions). https://mail.openjdk.java.net/mailman/listinfo/discuss And yes I realize that finding the right list isn't always obvious or easy. That problem isn't specific to whether we use mailing lists, Wikis, or some discussion group. It's a general problem of how to organize discussions for a large organization with many sub-groups / areas of interest. There's always the tension between too many and too few different groupings. -- Kevin On 8/19/2021 11:28 PM, Sebastian Stenzel wrote: > I am among the younger people here on the mailing lists (at least I think so) and I can very much relate to what Michael suggests. So here is my personal answer to the _why_ question: > > Mailing lists create an enormous barrier to external devs like myself who are willing to contribute: > * Signing up to a means of the 80s feels just strange > * Signing up to _any_ additional tool is deterring (same holds true for JBS), especially when you're used to low-threshold contributions to other projects can be > * Therefore, signing up feels like a liability that you may not want to commit to, if you merely want to express your support for a single comment > * It can be hard to find the correct mailing list for the topic you want to discuss > * You'll > * either receive digests and miss a topic you're interested in > * or dozens of additional mails each day, alienating people who just want to follow specific discussions > * No proper formatting > * No proper linking to code, issues, PRs, ... > * Hard to track diverging discussions > * Very hard to search - I basically need to use Google and restrict the search to some mail archive > * Linking to different topics means you need to either quote the whole thing or link to an archive > > On the other hand I see one important argument against GitHub Discussions: We have no control over how Discussions will change in the future. Even if they seem suitable today, we can't tell if it may be necessary to switch to yet another tool in 5 years. Each time you switch, you strip connections to discussions that took place on the previous platform. Switching tools always comes with a commitment to it and bears this risk. > > That said, I agree that this may not be something for OpenJFX to decide for its own. Maybe this discussion belongs on the skara mailing list (did I mention that it's hard to find the right mailing list, a topic belongs to?) Furthermore, changing a process is never easy and will scare people used to the status quo, especially when they've grown familiar with the old process over decades. I've seen this in companies many times. If there is no pressure to change, better tooling is not a strong enough argument to change processes. > > >> On 20. Aug 2021, at 03:39, openjfx-dev-request at openjdk.java.net wrote: >> >> From: Philip Race > >> Subject: Re: Moving discussions to GitHub? >> Date: 20. August 2021 at 03:39:04 CEST >> To: Michael Strau? >, "openjfx-dev at openjdk.java.net List" > >> >> >> I am not sure that openjfx as an openjdk sponsored project can unilaterally decide this. >> Nor sure that it makes sense either to be different. >> And I've not felt the same disconnection you cite or have any idea why >> this would be better or even match how we work. >> >> >> -phil. >> >> On 8/19/21 5:50 PM, Michael Strau? wrote: >>> With the GitHub Discussions feature now out of beta*, I'd like to >>> start a conversation on whether it could be a good idea for the >>> OpenJFX project to embrace it as the primary place to discuss and >>> interact with the broader community. >>> >>> While I understand that mailing lists have a long tradition with >>> OpenJDK projects, I feel that they are not a great tool for building >>> and maintaining a community. It's pretty hard to search archived mails >>> and find relevant information or past discussions. Sure, you can do >>> it, but it's not very inviting and accessible. >>> >>> It also seems to me that the mailing list is very disconnected from >>> the people actually using OpenJFX. Since most people already are on >>> GitHub, and most people interested in OpenJFX will find its GitHub >>> repository, it would also seem to be the most logical place to invite >>> people into the community and join our discussions. >>> >>> After all, growing and maintaining a community is fundamental for >>> every open-source project to remain relevant. >>> >>> * https://github.blog/2021-08-17-github-discussions-out-of-beta From kevin.rushforth at oracle.com Fri Aug 20 14:54:12 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Aug 2021 07:54:12 -0700 Subject: Moving discussions to GitHub? In-Reply-To: References: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> Message-ID: <770eac76-c35d-4f06-f5c2-fbc1d4035396@oracle.com> Interesting idea about moving just the openjfx-discuss list to GitHub discussions, although even that will run into some resistance. Enabling any GitHub feature as part of the openjdk organization needs buy-in from the the larger openjdk community, and probably from the OpenJDK Project Lead. -- Kevin On 8/20/2021 7:30 AM, Johan Vos wrote: > Hi, > > I see the value of Github Discussions, but I also see the value of the > mailinglists we are currently using. We have to realise though that this > particular list is about the *development* of OpenJFX, not about *using* > OpenJFX. Therefore, I believe it is ok to be more formal here, and a number > of things that make Github discussions more light-weight might imho > decrease productivity. > > But on the other hand, I also agree that the entry level is very high for > new developers. Years ago, I advocated for a separate "openjfx-discuss" > mailinglist where we would have more informal discussions and brainstorms. > We have that list but it's not frequently used. I was probably wrong in > suggesting this, as the style and formalism of the mailinglists does not > match with discussions amongst developers. > The idea of what I had for an "openjfx-discuss" mailinglist might work > better on Github Discussions. It would be a low-level entry point where new > ideas can be tossed. Personally, I don't see what's wrong with the > subscribe page (I love it when technology from the eighties is still > working :) ) but realistically, yes, it might turn away developers who > might have great ideas and time. > > In short: I'm +1 on keeping openjfx-dev to the current mailinglist, but I > think it could be good if we move openjfx-discuss to a github discussion. > > - Johan > > > On Fri, Aug 20, 2021 at 8:29 AM Sebastian Stenzel < > sebastian.stenzel at gmail.com> wrote: > >> I am among the younger people here on the mailing lists (at least I think >> so) and I can very much relate to what Michael suggests. So here is my >> personal answer to the _why_ question: >> >> Mailing lists create an enormous barrier to external devs like myself who >> are willing to contribute: >> * Signing up to a means of the 80s feels just strange >> * Signing up to _any_ additional tool is deterring (same holds true for >> JBS), especially when you're used to low-threshold contributions to other >> projects can be >> * Therefore, signing up feels like a liability that you may not want to >> commit to, if you merely want to express your support for a single comment >> * It can be hard to find the correct mailing list for the topic you want >> to discuss >> * You'll >> * either receive digests and miss a topic you're interested in >> * or dozens of additional mails each day, alienating people who just >> want to follow specific discussions >> * No proper formatting >> * No proper linking to code, issues, PRs, ... >> * Hard to track diverging discussions >> * Very hard to search - I basically need to use Google and restrict the >> search to some mail archive >> * Linking to different topics means you need to either quote the whole >> thing or link to an archive >> >> On the other hand I see one important argument against GitHub Discussions: >> We have no control over how Discussions will change in the future. Even if >> they seem suitable today, we can't tell if it may be necessary to switch to >> yet another tool in 5 years. Each time you switch, you strip connections to >> discussions that took place on the previous platform. Switching tools >> always comes with a commitment to it and bears this risk. >> >> That said, I agree that this may not be something for OpenJFX to decide >> for its own. Maybe this discussion belongs on the skara mailing list (did I >> mention that it's hard to find the right mailing list, a topic belongs to?) >> Furthermore, changing a process is never easy and will scare people used to >> the status quo, especially when they've grown familiar with the old process >> over decades. I've seen this in companies many times. If there is no >> pressure to change, better tooling is not a strong enough argument to >> change processes. >> >> >>> On 20. Aug 2021, at 03:39, openjfx-dev-request at openjdk.java.net wrote: >>> >>> From: Philip Race >> Subject: Re: Moving discussions to GitHub? >>> Date: 20. August 2021 at 03:39:04 CEST >>> To: Michael Strau? > michaelstrau2 at gmail.com>>, "openjfx-dev at openjdk.java.net > openjfx-dev at openjdk.java.net> List" > openjfx-dev at openjdk.java.net>> >>> >>> I am not sure that openjfx as an openjdk sponsored project can >> unilaterally decide this. >>> Nor sure that it makes sense either to be different. >>> And I've not felt the same disconnection you cite or have any idea why >>> this would be better or even match how we work. >>> >>> >>> -phil. >>> >>> On 8/19/21 5:50 PM, Michael Strau? wrote: >>>> With the GitHub Discussions feature now out of beta*, I'd like to >>>> start a conversation on whether it could be a good idea for the >>>> OpenJFX project to embrace it as the primary place to discuss and >>>> interact with the broader community. >>>> >>>> While I understand that mailing lists have a long tradition with >>>> OpenJDK projects, I feel that they are not a great tool for building >>>> and maintaining a community. It's pretty hard to search archived mails >>>> and find relevant information or past discussions. Sure, you can do >>>> it, but it's not very inviting and accessible. >>>> >>>> It also seems to me that the mailing list is very disconnected from >>>> the people actually using OpenJFX. Since most people already are on >>>> GitHub, and most people interested in OpenJFX will find its GitHub >>>> repository, it would also seem to be the most logical place to invite >>>> people into the community and join our discussions. >>>> >>>> After all, growing and maintaining a community is fundamental for >>>> every open-source project to remain relevant. >>>> >>>> * https://github.blog/2021-08-17-github-discussions-out-of-beta < >> https://github.blog/2021-08-17-github-discussions-out-of-beta> >> From johan.vos at gluonhq.com Fri Aug 20 15:36:00 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 20 Aug 2021 17:36:00 +0200 Subject: Moving discussions to GitHub? In-Reply-To: <770eac76-c35d-4f06-f5c2-fbc1d4035396@oracle.com> References: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> <770eac76-c35d-4f06-f5c2-fbc1d4035396@oracle.com> Message-ID: Right, but I don't think this needs to be done as part of the openjdk organization -- especially not given the informal character I suggest for this list. There are a fair number of options where/how the discussion can be hosted. Ironically, this is something that we might rather have to discuss on the openjfx-discuss list. - Johan On Fri, Aug 20, 2021 at 4:55 PM Kevin Rushforth wrote: > Interesting idea about moving just the openjfx-discuss list to GitHub > discussions, although even that will run into some resistance. Enabling > any GitHub feature as part of the openjdk organization needs buy-in from > the the larger openjdk community, and probably from the OpenJDK Project > Lead. > > -- Kevin > > > On 8/20/2021 7:30 AM, Johan Vos wrote: > > Hi, > > > > I see the value of Github Discussions, but I also see the value of the > > mailinglists we are currently using. We have to realise though that this > > particular list is about the *development* of OpenJFX, not about *using* > > OpenJFX. Therefore, I believe it is ok to be more formal here, and a > number > > of things that make Github discussions more light-weight might imho > > decrease productivity. > > > > But on the other hand, I also agree that the entry level is very high for > > new developers. Years ago, I advocated for a separate "openjfx-discuss" > > mailinglist where we would have more informal discussions and > brainstorms. > > We have that list but it's not frequently used. I was probably wrong in > > suggesting this, as the style and formalism of the mailinglists does not > > match with discussions amongst developers. > > The idea of what I had for an "openjfx-discuss" mailinglist might work > > better on Github Discussions. It would be a low-level entry point where > new > > ideas can be tossed. Personally, I don't see what's wrong with the > > subscribe page (I love it when technology from the eighties is still > > working :) ) but realistically, yes, it might turn away developers who > > might have great ideas and time. > > > > In short: I'm +1 on keeping openjfx-dev to the current mailinglist, but I > > think it could be good if we move openjfx-discuss to a github discussion. > > > > - Johan > > > > > > On Fri, Aug 20, 2021 at 8:29 AM Sebastian Stenzel < > > sebastian.stenzel at gmail.com> wrote: > > > >> I am among the younger people here on the mailing lists (at least I > think > >> so) and I can very much relate to what Michael suggests. So here is my > >> personal answer to the _why_ question: > >> > >> Mailing lists create an enormous barrier to external devs like myself > who > >> are willing to contribute: > >> * Signing up to a means of the 80s feels just strange > >> * Signing up to _any_ additional tool is deterring (same holds true for > >> JBS), especially when you're used to low-threshold contributions to > other > >> projects can be > >> * Therefore, signing up feels like a liability that you may not want to > >> commit to, if you merely want to express your support for a single > comment > >> * It can be hard to find the correct mailing list for the topic you want > >> to discuss > >> * You'll > >> * either receive digests and miss a topic you're interested in > >> * or dozens of additional mails each day, alienating people who just > >> want to follow specific discussions > >> * No proper formatting > >> * No proper linking to code, issues, PRs, ... > >> * Hard to track diverging discussions > >> * Very hard to search - I basically need to use Google and restrict the > >> search to some mail archive > >> * Linking to different topics means you need to either quote the whole > >> thing or link to an archive > >> > >> On the other hand I see one important argument against GitHub > Discussions: > >> We have no control over how Discussions will change in the future. Even > if > >> they seem suitable today, we can't tell if it may be necessary to > switch to > >> yet another tool in 5 years. Each time you switch, you strip > connections to > >> discussions that took place on the previous platform. Switching tools > >> always comes with a commitment to it and bears this risk. > >> > >> That said, I agree that this may not be something for OpenJFX to decide > >> for its own. Maybe this discussion belongs on the skara mailing list > (did I > >> mention that it's hard to find the right mailing list, a topic belongs > to?) > >> Furthermore, changing a process is never easy and will scare people > used to > >> the status quo, especially when they've grown familiar with the old > process > >> over decades. I've seen this in companies many times. If there is no > >> pressure to change, better tooling is not a strong enough argument to > >> change processes. > >> > >> > >>> On 20. Aug 2021, at 03:39, openjfx-dev-request at openjdk.java.net wrote: > >>> > >>> From: Philip Race philip.race at oracle.com > >>> Subject: Re: Moving discussions to GitHub? > >>> Date: 20. August 2021 at 03:39:04 CEST > >>> To: Michael Strau? >> michaelstrau2 at gmail.com>>, "openjfx-dev at openjdk.java.net >> openjfx-dev at openjdk.java.net> List" >> openjfx-dev at openjdk.java.net>> > >>> > >>> I am not sure that openjfx as an openjdk sponsored project can > >> unilaterally decide this. > >>> Nor sure that it makes sense either to be different. > >>> And I've not felt the same disconnection you cite or have any idea why > >>> this would be better or even match how we work. > >>> > >>> > >>> -phil. > >>> > >>> On 8/19/21 5:50 PM, Michael Strau? wrote: > >>>> With the GitHub Discussions feature now out of beta*, I'd like to > >>>> start a conversation on whether it could be a good idea for the > >>>> OpenJFX project to embrace it as the primary place to discuss and > >>>> interact with the broader community. > >>>> > >>>> While I understand that mailing lists have a long tradition with > >>>> OpenJDK projects, I feel that they are not a great tool for building > >>>> and maintaining a community. It's pretty hard to search archived mails > >>>> and find relevant information or past discussions. Sure, you can do > >>>> it, but it's not very inviting and accessible. > >>>> > >>>> It also seems to me that the mailing list is very disconnected from > >>>> the people actually using OpenJFX. Since most people already are on > >>>> GitHub, and most people interested in OpenJFX will find its GitHub > >>>> repository, it would also seem to be the most logical place to invite > >>>> people into the community and join our discussions. > >>>> > >>>> After all, growing and maintaining a community is fundamental for > >>>> every open-source project to remain relevant. > >>>> > >>>> * https://github.blog/2021-08-17-github-discussions-out-of-beta < > >> https://github.blog/2021-08-17-github-discussions-out-of-beta> > >> > > From cjgunzel at gmail.com Fri Aug 20 16:17:02 2021 From: cjgunzel at gmail.com (Chuck Davis) Date: Fri, 20 Aug 2021 09:17:02 -0700 Subject: Moving discussions to GitHub? (Philip Race) In-Reply-To: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> References: <805B49F0-F09B-4FD1-AC4C-452CC61E2F47@gmail.com> Message-ID: I, for one, would be opposed to moving these discussions off the mailing lists. Most of the "issues" are straw men. The mailing lists are a "push" technology so I don't have to do anything special to get the info since my mail client is always on when my computer is on. I do not, and will not, place my code on a platform that is ruled by fiat by an organization as fickle and error prone as Microsoft. Hence, I seldom access anything on GitHub and will not receive any of the discussions if they move there and I have to do another sign-on to retrieve (and attempt to find) the information. In my experience GitHub is not a user friendly place and it IS NOT easy to find ANYTHING there. I don't see any issue with formatting or searching in mailing lists. Maybe users need a better mail client or something. Just my $.02. On Fri, Aug 20, 2021 at 3:27 AM Sebastian Stenzel < sebastian.stenzel at gmail.com> wrote: > I am among the younger people here on the mailing lists (at least I think > so) and I can very much relate to what Michael suggests. So here is my > personal answer to the _why_ question: > > Mailing lists create an enormous barrier to external devs like myself who > are willing to contribute: > * Signing up to a means of the 80s feels just strange > * Signing up to _any_ additional tool is deterring (same holds true for > JBS), especially when you're used to low-threshold contributions to other > projects can be > * Therefore, signing up feels like a liability that you may not want to > commit to, if you merely want to express your support for a single comment > * It can be hard to find the correct mailing list for the topic you want > to discuss > * You'll > * either receive digests and miss a topic you're interested in > * or dozens of additional mails each day, alienating people who just > want to follow specific discussions > * No proper formatting > * No proper linking to code, issues, PRs, ... > * Hard to track diverging discussions > * Very hard to search - I basically need to use Google and restrict the > search to some mail archive > * Linking to different topics means you need to either quote the whole > thing or link to an archive > > On the other hand I see one important argument against GitHub Discussions: > We have no control over how Discussions will change in the future. Even if > they seem suitable today, we can't tell if it may be necessary to switch to > yet another tool in 5 years. Each time you switch, you strip connections to > discussions that took place on the previous platform. Switching tools > always comes with a commitment to it and bears this risk. > > From arapte at openjdk.java.net Fri Aug 20 18:22:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 20 Aug 2021 18:22:40 GMT Subject: [jfx11u] RFR: 8220222: build.gradle does not specify clearly the project dependencies Message-ID: There was a minor merge conflict at line 3933 while cherry picking the commit, otherwise it was clean. Verified build on all platforms. ------------- Commit messages: - 8220222: build.gradle does not specify clearly the project dependencies Changes: https://git.openjdk.java.net/jfx11u/pull/48/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=48&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8220222 Stats: 76 lines in 1 file changed: 65 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx11u/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/48/head:pull/48 PR: https://git.openjdk.java.net/jfx11u/pull/48 From kcr at openjdk.java.net Fri Aug 20 18:32:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 20 Aug 2021 18:32:31 GMT Subject: [jfx11u] RFR: 8220222: build.gradle does not specify clearly the project dependencies In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:17:28 GMT, Ambarish Rapte wrote: > There was a minor merge conflict at line 3933 while cherry picking the commit, otherwise it was clean. > Verified build on all platforms. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx11u/pull/48 From arapte at openjdk.java.net Fri Aug 20 18:36:33 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 20 Aug 2021 18:36:33 GMT Subject: [jfx11u] Integrated: 8220222: build.gradle does not specify clearly the project dependencies In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 18:17:28 GMT, Ambarish Rapte wrote: > There was a minor merge conflict at line 3933 while cherry picking the commit, otherwise it was clean. > Verified build on all platforms. This pull request has now been integrated. Changeset: efcf25ec Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/efcf25ec1e5d2519888feb3c4e1a67fc7c6d64bc Stats: 76 lines in 1 file changed: 65 ins; 0 del; 11 mod 8220222: build.gradle does not specify clearly the project dependencies Reviewed-by: kcr Backport-of: 2826711ef0df316e91b0a9c49442d8dd095538be ------------- PR: https://git.openjdk.java.net/jfx11u/pull/48 From arapte at openjdk.java.net Fri Aug 20 20:21:50 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 20 Aug 2021 20:21:50 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 Message-ID: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 ------------- Commit messages: - corrections for project fxpackager - 8263760: Update gradle to version 7.0.1 Changes: https://git.openjdk.java.net/jfx11u/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=49&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263760 Stats: 148 lines in 13 files changed: 46 ins; 5 del; 97 mod Patch: https://git.openjdk.java.net/jfx11u/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/49/head:pull/49 PR: https://git.openjdk.java.net/jfx11u/pull/49 From tsayao at openjdk.java.net Fri Aug 20 22:22:51 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 20 Aug 2021 22:22:51 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v4] In-Reply-To: References: Message-ID: <9sJVqEm2IPygp3TVG-Nx3xdnqCd4VkDSrJHTwaM2FPM=.fe4a6fa6-5bae-449a-ad04-a17ccb14ae8f@github.com> > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Review requests. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/4509462a..29c6148e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Fri Aug 20 22:22:52 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 20 Aug 2021 22:22:52 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 13:10:53 GMT, Pankaj Bansal wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Change test to manual > > tests/manual/dnd/DndTestDragViewRawImage.java line 59: > >> 57: }); >> 58: >> 59: Label label = new Label("Drag image should match source colors when dragged"); > > Could you please make the instructions a bit more clear? I tried :) ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From kcr at openjdk.java.net Sat Aug 21 00:04:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 21 Aug 2021 00:04:26 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 In-Reply-To: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: On Fri, 20 Aug 2021 20:13:18 GMT, Ambarish Rapte wrote: > There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. > And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. > Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 Looks fine with a couple comments. I tested it with the older gradle `6.3` as well as `7.0.1`. build.gradle line 2758: > 2756: > 2757: dependencies { > 2758: implementation group: "org.apache.ant", name: "ant", version: "1.8.2" Shouldn't this be `antpluginImplementation`? It may not matter as much, since we don't build fxpackager by default in FX 11, but I still think it should be fixed. gradle/wrapper/gradle-wrapper.properties line 4: > 2: distributionPath=wrapper/dists > 3: distributionUrl=https\://services.gradle.org/distributions/gradle-7.0.1-bin.zip > 4: distributionSha256Sum=dccda8aa069563c8ba2f6cdfd0777df0e34a5b4d15138ca8b9757e94f4e8a8cb By adding this line in, you have effectively backported [JDK-8262236](https://bugs.openjdk.java.net/browse/JDK-8262236). I don't see a problem with that, since the fix for that issue was the one-line addition of this checksum. It might be cleaner from a bookkeeping standpoint to include that issue in this PR (i.e., `/issue add 8262236`)? ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From pbansal at openjdk.java.net Sat Aug 21 07:54:25 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 21 Aug 2021 07:54:25 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v4] In-Reply-To: <9sJVqEm2IPygp3TVG-Nx3xdnqCd4VkDSrJHTwaM2FPM=.fe4a6fa6-5bae-449a-ad04-a17ccb14ae8f@github.com> References: <9sJVqEm2IPygp3TVG-Nx3xdnqCd4VkDSrJHTwaM2FPM=.fe4a6fa6-5bae-449a-ad04-a17ccb14ae8f@github.com> Message-ID: On Fri, 20 Aug 2021 22:22:51 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review requests. Looks good to me now ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/599 From nlisker at gmail.com Sat Aug 21 13:19:10 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 21 Aug 2021 16:19:10 +0300 Subject: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: Message-ID: In the previous time this was discussed I suggested a 3rd option, in addition to ObjectProperty and 3 DoubleProperties, which is 3 ObjectPropertys. Advantages: 1. Allows using null to remove any specified user values (null would also be the default), similar to how we would do it with ObjectProperty. No need for another property like a boolean value. 2. Allows changing individual axes and binding to each axis independently, which was a disadvantage of Point3D. 3. With how Valhalla is coming along, it's highly likely that there would be no auto-boxing cost as Double will behave like a primitive. Disadvantages: 1. Using null as the special value does not indicate well that the default behavior is using the center of the node, but there is no indication of it now, except in documentation which will be done anyway. 2. ObjectProperty does not have the specialized methods inherited from DoubleExpression (like #add), so it is more difficult to work with mathematically. This addresses questions 1 and 2. The 2nd point in the disadvantages makes this not too appealing for me, but the other options are also problematic. As for question 3, I think we have to. The main goal of the PR is adding pivot properties to ScaleTransition and RotateTransition. The various transitions work by changing values in Node (FadeTransform changes opacity, RotateTransition changes rotate and rotationAxis etc.). If we don't have separate pivots for rotation and scale in Node, how can we implement these in the transitions? They surely can't use the same one, both because it will be confusing and there will be synching issues. Think about creating 1 RotateTransition and 1 ScaleTransition with different pivots. The order in which you start them will matter because one will change the other (and if forceSync is enabled then one will override the other mid-transition). Having these pivots on Node for direct usage is convenient, but I see it as a secondary goal. It is more of a necessity for the transitions. Notice that the JBS issue [1] is aggregating 3 issues because they are interdependent. As for Michael's proposal, it has the benefit of getting rid of the special computed value of the center of the node and making it clear what the default is. I'm not sure what Michael means by "absolute coordinates", I assume it's relative to the parent, and that "relative to the layout bounds" means relative to the node. This way, setting to 0.5 with "relative to the layout bounds" will indeed mean the center of the node. I find some inconsistency issues with the relativePivot idea: 1. The Scale, Rotate, and Shear transforms use the parent coordinates. That means that if I set a pivoted scale transform on the node, and then use a pivoted scale transition (keeping the default), the pivot will not be the same. This would be very confusing I think. 2. TranslateTransition has a toX property (and Y and Z) that always uses the parent coordinates. That means that if I use a translate transition and a scale transition (keeping the default), I will be working in 2 coordinate systems simultaneously. Also confusing for me. 3. Switching between local and global coordinate systems is a more general issue, and solving it locally just for pivots of 2 transitions seems incomplete and out of place to me in this patch. To expand on point 3, I see 3 generally useful systems: node, parent, and scene. We have methods that transform from one to the other. Despite those, I also find it a lot of work to transform between coordinate systems. This leads me to believe that the idea of toggling between coordinate systems tries to solve a broader issue, one that touches both transforms and transitions (including node properties). As a result, I think that we should implement the current proposal of adding pivots by using the current coordinate system that everything else uses (parent), and then think about better ways of handling coordinate system transformations more generally. [1] https://bugs.openjdk.java.net/browse/JDK-8234712 On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth wrote: > The idea of adding explicit pivot properties was met with general > agreement as long as we preserve compatibility (meaning that an > auto-computed pivot at the center of the bounds must remain the default). > > The questions are around what form the API should take. They basically > boil down to: > > 1. How do we indicate whether the pivot is computed vs explicitly > specified? > 2. Should the pivot position be 3 doubles or a Point3D > 3. Do we need a separate pivot for rotation vs scaling > > My quick thoughts (although I might be able to be persuaded otherwise) are: > > 1) a boolean property > 2) 3 separate doubles > 3) no > > Michael's proposal of a couple months ago [1] would match those answers, > and is an interesting approach that I hadn't considered before. The > question then is whether want the additional flexibility that it provides > and whether it is worth the additional implementation, documentation, and > testing that would be needed. It can be a discussion point. I'd like to > know what Nir thinks of that idea. > > I think we can discuss the details of the API in the PR, although while it > is Draft, many people will miss the discussion (since it doesn't get sent > to the mailing list), so it might be better to at get high-level agreement > on the answers to the outstanding API questions on this list? > > -- Kevin > > [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 > > > On 8/19/2021 12:03 PM, Nir Lisker wrote: > > I'd like to see pivot properties move forward. >> The PR seems to be a bit stale, as it has been sitting around for >> almost two years. > > > Me too, but there was no decision as to the implementation type. We can > continue the discussion on the PR at this point I think. > > On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? > wrote: > >> I'd like to see pivot properties move forward. >> The PR seems to be a bit stale, as it has been sitting around for >> almost two years. >> >> PR: https://github.com/openjdk/jfx/pull/53 >> >> >> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth >> : >> > >> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >> > and enhancement requests for JavaFX 18. It's the summer, so there may be >> > delays as some people are out at various times (including me), but I >> > would like to get some of the outstanding enhancement requests moving >> > over the next few weeks. >> > >> > Specifically, I'd like to see the following proceed: >> > >> > * Transparent backgrounds in WebView >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> > PR: https://github.com/openjdk/jfx/pull/563 >> >> > >> > * Add DirectionalLight >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> > PR: https://github.com/openjdk/jfx/pull/548 >> >> > >> > * CSS pseudoclasses :focus-visible and :focus-within >> > https://bugs.openjdk.java.net/browse/JDK-8268225 >> > PR: https://github.com/openjdk/jfx/pull/475 >> >> > >> > * Improve property system to facilitate correct usage (minus the binary >> > incompatible API change) >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> > PR: https://github.com/openjdk/jfx/pull/590 >> >> (Draft) >> > >> > And maybe the following: >> > >> > * Add CSS themes as a first-class concept (need a consensus on how to >> > proceed) >> > >> > * Undecorated interactive stage style (still in early discussion, but >> > the concept looks interesting and useful) >> > >> > There are probably others I'm forgetting. >> > >> > Each of the above should be discussed in their own thread on openjfx-dev >> > rather than a reply to this thread. >> > >> > -- Kevin >> > >> > >> > > From kcr at openjdk.java.net Sat Aug 21 14:12:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 21 Aug 2021 14:12:21 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 06:45:37 GMT, Abhinay Agarwal wrote: > Is there anything else pending to move this PR forward? Nothing else needed for now. The review can proceed. ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From kevin.rushforth at oracle.com Sat Aug 21 14:33:21 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 21 Aug 2021 07:33:21 -0700 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: Message-ID: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> I didn't page in enough of the discussion before. I remember now why we need separate pivots for rotate and scale, so thank you for reminding me. Btw, I don't think that necessarily means we need a separate switch for whether to use computed vs explicit for each (but that would be a possibility). I agree with the points raised about relative versus "absolute". While it is an intriguing idea, it probably doesn't fit here. While it is a clever idea to use an ObjectProperty rather than a DoubleProperty so we have an out of band value to use for "compute this" I don't think that we should do it that way for a few reasons. First, it's inconsistent with all other number based properties, in a way that could cause usability issues (e.g., you couldn't just pass pivotXProperty() directly to a method that expects a DoubleProperty). Second, I don't like the implications of having separate "auto-compute" flags on each of X, Y, and Z. Third, is the documentation issue you mentioned. So amending my earlier answers to the three questions: 1. A single boolean property for whether to use a compute pivot (the default) vs an explicit pivot; this would apply to both rotate and scale pivots. 2. 3 separate doubles (using DoubleProperty). 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties. -- Kevin On 8/21/2021 6:19 AM, Nir Lisker wrote: > In the previous time this was discussed I suggested a 3rd option, in > addition to ObjectProperty and 3 DoubleProperties, which is 3 > ObjectPropertys. > > Advantages: > 1. Allows using null to remove any specified user values (null would > also be the default), similar to how we would do it with > ObjectProperty. No need for another property like a boolean > value. > 2. Allows changing individual axes and binding to each axis > independently, which was a disadvantage of Point3D. > 3. With how Valhalla is coming along, it's highly likely that there > would be no auto-boxing cost as Double will behave like a primitive. > > Disadvantages: > 1. Using null as the special value does not indicate well that the > default behavior is using the center of the node, but there is no > indication of it now, except in documentation which will be done anyway. > 2. ObjectProperty does not have the specialized methods > inherited from DoubleExpression (like #add), so it is more difficult > to work with mathematically. > > This addresses questions 1 and 2. The 2nd point in the disadvantages > makes this not too appealing for me, but the other options are also > problematic. > > As for question 3, I think we have to. The main goal of the PR is > adding pivot properties to ScaleTransition and RotateTransition. The > various transitions work by changing values in Node (FadeTransform > changes?opacity, RotateTransition changes rotate and rotationAxis > etc.). If we don't have separate pivots for rotation and scale in > Node, how can we implement these in the transitions? They surely can't > use the same one, both because it will be confusing and there will be > synching issues. Think about creating 1 RotateTransition and 1 > ScaleTransition with different pivots. The order in which you start > them will matter because one will change the?other (and if?forceSync > is enabled then one will override the other mid-transition). > Having these pivots on Node for direct usage is convenient, but I see > it as a secondary goal. It is more of a necessity?for the transitions. > Notice that the JBS issue [1] is aggregating 3 issues because they are > interdependent. > > As for Michael's proposal, it has the benefit of getting rid of the > special computed value of the center of the node and making it clear > what the default is. > I'm not sure what Michael means?by "absolute coordinates", I assume > it's relative to the parent, and that "relative to the layout bounds" > means relative to the node. This way, setting to 0.5 with "relative to > the layout bounds" will indeed mean the center of the node. > I find some inconsistency issues with the relativePivot idea: > 1. The Scale, Rotate, and Shear transforms use the parent coordinates. > That means that if I set a pivoted scale transform on the node, and > then use a pivoted scale transition (keeping the default), the pivot > will not be the same. This would be very confusing I think. > 2. TranslateTransition has a toX property (and Y and Z) that always > uses the parent coordinates. That means that if I use a translate > transition and a scale transition (keeping the default), I will be > working in 2 coordinate systems simultaneously. Also confusing for me. > 3. Switching between local and global coordinate systems is a more > general issue, and solving it locally just for pivots of 2 transitions > seems incomplete and out of place to?me in this patch. > > To expand on point 3, I see 3 generally useful systems: node, parent, > and scene. We have methods that transform from one to the other. > Despite those, I also find it a lot of work to transform?between > coordinate systems. This leads me to believe that the idea of toggling > between coordinate systems tries to solve a broader issue, one that > touches both transforms and transitions (including node properties). > As a result, I think that we should implement the current proposal of > adding pivots by using the current coordinate system that everything > else uses (parent), and then think about better ways of handling > coordinate system transformations more generally. > > [1] https://bugs.openjdk.java.net/browse/JDK-8234712 > > > On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth > > wrote: > > The idea of adding explicit pivot properties was met with general > agreement as long as we preserve compatibility (meaning that an > auto-computed pivot at the center of the bounds must remain the > default). > > The questions are around what form the API should take. They > basically boil down to: > > 1. How do we indicate whether the pivot is computed vs explicitly > specified? > 2. Should the pivot position be 3 doubles or a Point3D > 3. Do we need a separate pivot for rotation vs scaling > > My quick thoughts (although I might be able to be persuaded > otherwise) are: > > 1) a boolean property > 2) 3 separate doubles > 3) no > > Michael's proposal of a couple months ago [1] would match those > answers, and is an interesting approach that I hadn't considered > before. The question then is whether want the additional > flexibility that it provides and whether it is worth the > additional implementation, documentation, and testing that would > be needed. It can be a discussion point. I'd like to know what Nir > thinks of that idea. > > I think we can discuss the details of the API in the PR, although > while it is Draft, many people will miss the discussion (since it > doesn't get sent to the mailing list), so it might be better to at > get high-level agreement on the answers to the outstanding API > questions on this list? > > -- Kevin > > [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 > > > > On 8/19/2021 12:03 PM, Nir Lisker wrote: >> >> I'd like to see pivot properties move forward. >> The PR seems to be a bit stale, as it has been sitting around for >> almost two years. >> >> >> Me too, but there was no decision as to the implementation type. >> We can continue the discussion on the PR at this point I think. >> >> On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? >> > wrote: >> >> I'd like to see pivot properties move forward. >> The PR seems to be a bit stale, as it has been sitting around for >> almost two years. >> >> PR: https://github.com/openjdk/jfx/pull/53 >> >> >> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth >> >: >> > >> > Now that JavaFX 17 is in RDP2, we can turn more attention >> to bug fixes >> > and enhancement requests for JavaFX 18. It's the summer, so >> there may be >> > delays as some people are out at various times (including >> me), but I >> > would like to get some of the outstanding enhancement >> requests moving >> > over the next few weeks. >> > >> > Specifically, I'd like to see the following proceed: >> > >> > * Transparent backgrounds in WebView >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> >> > PR: https://github.com/openjdk/jfx/pull/563 >> >> > >> > * Add DirectionalLight >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> >> > PR: https://github.com/openjdk/jfx/pull/548 >> >> > >> > * CSS pseudoclasses :focus-visible and :focus-within >> > https://bugs.openjdk.java.net/browse/JDK-8268225 >> >> > PR: https://github.com/openjdk/jfx/pull/475 >> >> > >> > * Improve property system to facilitate correct usage >> (minus the binary >> > incompatible API change) >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> >> > PR: https://github.com/openjdk/jfx/pull/590 >> >> (Draft) >> > >> > And maybe the following: >> > >> > * Add CSS themes as a first-class concept (need a consensus >> on how to >> > proceed) >> > >> > * Undecorated interactive stage style (still in early >> discussion, but >> > the concept looks interesting and useful) >> > >> > There are probably others I'm forgetting. >> > >> > Each of the above should be discussed in their own thread >> on openjfx-dev >> > rather than a reply to this thread. >> > >> > -- Kevin >> > >> > >> > From michaelstrau2 at gmail.com Sat Aug 21 20:23:26 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 21 Aug 2021 22:23:26 +0200 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> Message-ID: I think that ?computed pivot? is both an unnecessary terminology, and really only one special case of a pivot coordinate in unit space where 0/0 is the top-left corner of the node, and 1/1 is the bottom-right corner of the node (which is what I referred to as ?relative? coordinates). Quite often, it can be more useful to define pivots in unit space, because it?s an easy answer to a problem like ?rotate the node 45 degrees around its top-left corner?. Special-casing the 0.5/0.5 unit coordinate and not allowing any other feels like a lackluster API, and increases the effort for developers to solve a very common problem. >From an implementation perspective, there?s not much of a difference in development and maintenance cost. The projection from unit space to pixel space needs to happen anyway (that?s the ?computed? part in ?computed pivot?), and allowing any coordinate rather than the 0.5/0.5 midpoint is only a single multiplication away. On Saturday, August 21, 2021, Kevin Rushforth wrote: > I didn't page in enough of the discussion before. I remember now why we > need separate pivots for rotate and scale, so thank you for reminding me. > Btw, I don't think that necessarily means we need a separate switch for > whether to use computed vs explicit for each (but that would be a > possibility). > > I agree with the points raised about relative versus "absolute". While it > is an intriguing idea, it probably doesn't fit here. > > While it is a clever idea to use an ObjectProperty rather than a > DoubleProperty so we have an out of band value to use for "compute this" I > don't think that we should do it that way for a few reasons. First, it's > inconsistent with all other number based properties, in a way that could > cause usability issues (e.g., you couldn't just pass pivotXProperty() > directly to a method that expects a DoubleProperty). Second, I don't like > the implications of having separate "auto-compute" flags on each of X, Y, > and Z. Third, is the documentation issue you mentioned. > > So amending my earlier answers to the three questions: > > 1. A single boolean property for whether to use a compute pivot (the > default) vs an explicit pivot; this would apply to both rotate and scale > pivots. > 2. 3 separate doubles (using DoubleProperty). > 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties. > > -- Kevin > > On 8/21/2021 6:19 AM, Nir Lisker wrote: > > In the previous time this was discussed I suggested a 3rd option, in > addition to ObjectProperty and 3 DoubleProperties, which is 3 > ObjectPropertys. > > Advantages: > 1. Allows using null to remove any specified user values (null would also > be the default), similar to how we would do it with > ObjectProperty. No need for another property like a boolean value. > 2. Allows changing individual axes and binding to each axis independently, > which was a disadvantage of Point3D. > 3. With how Valhalla is coming along, it's highly likely that there would > be no auto-boxing cost as Double will behave like a primitive. > > Disadvantages: > 1. Using null as the special value does not indicate well that the default > behavior is using the center of the node, but there is no indication of it > now, except in documentation which will be done anyway. > 2. ObjectProperty does not have the specialized methods inherited > from DoubleExpression (like #add), so it is more difficult to work with > mathematically. > > This addresses questions 1 and 2. The 2nd point in the disadvantages makes > this not too appealing for me, but the other options are also problematic. > > As for question 3, I think we have to. The main goal of the PR is adding > pivot properties to ScaleTransition and RotateTransition. The various > transitions work by changing values in Node (FadeTransform changes opacity, > RotateTransition changes rotate and rotationAxis etc.). If we don't have > separate pivots for rotation and scale in Node, how can we implement these > in the transitions? They surely can't use the same one, both because it > will be confusing and there will be synching issues. Think about creating 1 > RotateTransition and 1 ScaleTransition with different pivots. The order in > which you start them will matter because one will change the other (and > if forceSync is enabled then one will override the other mid-transition). > Having these pivots on Node for direct usage is convenient, but I see it > as a secondary goal. It is more of a necessity for the transitions. Notice > that the JBS issue [1] is aggregating 3 issues because they are > interdependent. > > As for Michael's proposal, it has the benefit of getting rid of the > special computed value of the center of the node and making it clear what > the default is. > I'm not sure what Michael means by "absolute coordinates", I assume it's > relative to the parent, and that "relative to the layout bounds" means > relative to the node. This way, setting to 0.5 with "relative to the layout > bounds" will indeed mean the center of the node. > I find some inconsistency issues with the relativePivot idea: > 1. The Scale, Rotate, and Shear transforms use the parent coordinates. > That means that if I set a pivoted scale transform on the node, and then > use a pivoted scale transition (keeping the default), the pivot will not be > the same. This would be very confusing I think. > 2. TranslateTransition has a toX property (and Y and Z) that always uses > the parent coordinates. That means that if I use a translate transition and > a scale transition (keeping the default), I will be working in 2 coordinate > systems simultaneously. Also confusing for me. > 3. Switching between local and global coordinate systems is a more general > issue, and solving it locally just for pivots of 2 transitions seems > incomplete and out of place to me in this patch. > > To expand on point 3, I see 3 generally useful systems: node, parent, and > scene. We have methods that transform from one to the other. Despite those, > I also find it a lot of work to transform between coordinate systems. This > leads me to believe that the idea of toggling between coordinate systems > tries to solve a broader issue, one that touches both transforms and > transitions (including node properties). As a result, I think that we > should implement the current proposal of adding pivots by using the current > coordinate system that everything else uses (parent), and then think about > better ways of handling coordinate system transformations more generally. > > [1] https://bugs.openjdk.java.net/browse/JDK-8234712 > > On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> The idea of adding explicit pivot properties was met with general >> agreement as long as we preserve compatibility (meaning that an >> auto-computed pivot at the center of the bounds must remain the default). >> >> The questions are around what form the API should take. They basically >> boil down to: >> >> 1. How do we indicate whether the pivot is computed vs explicitly >> specified? >> 2. Should the pivot position be 3 doubles or a Point3D >> 3. Do we need a separate pivot for rotation vs scaling >> >> My quick thoughts (although I might be able to be persuaded otherwise) >> are: >> >> 1) a boolean property >> 2) 3 separate doubles >> 3) no >> >> Michael's proposal of a couple months ago [1] would match those answers, >> and is an interesting approach that I hadn't considered before. The >> question then is whether want the additional flexibility that it provides >> and whether it is worth the additional implementation, documentation, and >> testing that would be needed. It can be a discussion point. I'd like to >> know what Nir thinks of that idea. >> >> I think we can discuss the details of the API in the PR, although while >> it is Draft, many people will miss the discussion (since it doesn't get >> sent to the mailing list), so it might be better to at get high-level >> agreement on the answers to the outstanding API questions on this list? >> >> -- Kevin >> >> [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 >> >> >> >> On 8/19/2021 12:03 PM, Nir Lisker wrote: >> >> I'd like to see pivot properties move forward. >>> The PR seems to be a bit stale, as it has been sitting around for >>> almost two years. >> >> >> Me too, but there was no decision as to the implementation type. We can >> continue the discussion on the PR at this point I think. >> >> On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? >> wrote: >> >>> I'd like to see pivot properties move forward. >>> The PR seems to be a bit stale, as it has been sitting around for >>> almost two years. >>> >>> PR: https://github.com/openjdk/jfx/pull/53 >>> >>> >>> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth >>> : >>> > >>> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >>> > and enhancement requests for JavaFX 18. It's the summer, so there may >>> be >>> > delays as some people are out at various times (including me), but I >>> > would like to get some of the outstanding enhancement requests moving >>> > over the next few weeks. >>> > >>> > Specifically, I'd like to see the following proceed: >>> > >>> > * Transparent backgrounds in WebView >>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> > PR: https://github.com/openjdk/jfx/pull/563 >>> >>> > >>> > * Add DirectionalLight >>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> > PR: https://github.com/openjdk/jfx/pull/548 >>> >>> > >>> > * CSS pseudoclasses :focus-visible and :focus-within >>> > https://bugs.openjdk.java.net/browse/JDK-8268225 >>> > PR: https://github.com/openjdk/jfx/pull/475 >>> >>> > >>> > * Improve property system to facilitate correct usage (minus the binary >>> > incompatible API change) >>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> > PR: https://github.com/openjdk/jfx/pull/590 >>> >>> (Draft) >>> > >>> > And maybe the following: >>> > >>> > * Add CSS themes as a first-class concept (need a consensus on how to >>> > proceed) >>> > >>> > * Undecorated interactive stage style (still in early discussion, but >>> > the concept looks interesting and useful) >>> > >>> > There are probably others I'm forgetting. >>> > >>> > Each of the above should be discussed in their own thread on >>> openjfx-dev >>> > rather than a reply to this thread. >>> > >>> > -- Kevin >>> > >>> > >>> >> >> > From arapte at openjdk.java.net Sun Aug 22 11:32:58 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 22 Aug 2021 11:32:58 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: > There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. > And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. > Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: use antpluginImplementation ------------- Changes: - all: https://git.openjdk.java.net/jfx11u/pull/49/files - new: https://git.openjdk.java.net/jfx11u/pull/49/files/cea09bdf..1dc05179 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=49&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=49&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/49/head:pull/49 PR: https://git.openjdk.java.net/jfx11u/pull/49 From nlisker at gmail.com Sun Aug 22 14:04:52 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 22 Aug 2021 17:04:52 +0300 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> Message-ID: The special case of "center of the node" (the computed pivot) is the current behavior, and it needs to be preserved for backwards compatibility. This is why we were discussing the out of band values issues to begin with. Reading the rest of what you wrote makes me think I didn't understand your terminology. Does the "relativePivot" switch between normalized coordinates and non-normalized coordinates, both in the coordinate system of the node? On Sat, Aug 21, 2021 at 11:23 PM Michael Strau? wrote: > I think that ?computed pivot? is both an unnecessary terminology, and > really only one special case of a pivot coordinate in unit space where 0/0 > is the top-left corner of the node, and 1/1 is the bottom-right corner of > the node (which is what I referred to as ?relative? coordinates). > > Quite often, it can be more useful to define pivots in unit space, because > it?s an easy answer to a problem like ?rotate the node 45 degrees around > its top-left corner?. Special-casing the 0.5/0.5 unit coordinate and not > allowing any other feels like a lackluster API, and increases the effort > for developers to solve a very common problem. > > From an implementation perspective, there?s not much of a difference in > development and maintenance cost. The projection from unit space to pixel > space needs to happen anyway (that?s the ?computed? part in ?computed > pivot?), and allowing any coordinate rather than the 0.5/0.5 midpoint is > only a single multiplication away. > > > > > On Saturday, August 21, 2021, Kevin Rushforth > wrote: > >> I didn't page in enough of the discussion before. I remember now why we >> need separate pivots for rotate and scale, so thank you for reminding me. >> Btw, I don't think that necessarily means we need a separate switch for >> whether to use computed vs explicit for each (but that would be a >> possibility). >> >> I agree with the points raised about relative versus "absolute". While it >> is an intriguing idea, it probably doesn't fit here. >> >> While it is a clever idea to use an ObjectProperty rather than a >> DoubleProperty so we have an out of band value to use for "compute this" I >> don't think that we should do it that way for a few reasons. First, it's >> inconsistent with all other number based properties, in a way that could >> cause usability issues (e.g., you couldn't just pass pivotXProperty() >> directly to a method that expects a DoubleProperty). Second, I don't like >> the implications of having separate "auto-compute" flags on each of X, Y, >> and Z. Third, is the documentation issue you mentioned. >> >> So amending my earlier answers to the three questions: >> >> 1. A single boolean property for whether to use a compute pivot (the >> default) vs an explicit pivot; this would apply to both rotate and scale >> pivots. >> 2. 3 separate doubles (using DoubleProperty). >> 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties. >> >> -- Kevin >> >> On 8/21/2021 6:19 AM, Nir Lisker wrote: >> >> In the previous time this was discussed I suggested a 3rd option, in >> addition to ObjectProperty and 3 DoubleProperties, which is 3 >> ObjectPropertys. >> >> Advantages: >> 1. Allows using null to remove any specified user values (null would also >> be the default), similar to how we would do it with >> ObjectProperty. No need for another property like a boolean value. >> 2. Allows changing individual axes and binding to each axis >> independently, which was a disadvantage of Point3D. >> 3. With how Valhalla is coming along, it's highly likely that there would >> be no auto-boxing cost as Double will behave like a primitive. >> >> Disadvantages: >> 1. Using null as the special value does not indicate well that the >> default behavior is using the center of the node, but there is no >> indication of it now, except in documentation which will be done anyway. >> 2. ObjectProperty does not have the specialized methods inherited >> from DoubleExpression (like #add), so it is more difficult to work with >> mathematically. >> >> This addresses questions 1 and 2. The 2nd point in the disadvantages >> makes this not too appealing for me, but the other options are also >> problematic. >> >> As for question 3, I think we have to. The main goal of the PR is adding >> pivot properties to ScaleTransition and RotateTransition. The various >> transitions work by changing values in Node (FadeTransform changes opacity, >> RotateTransition changes rotate and rotationAxis etc.). If we don't have >> separate pivots for rotation and scale in Node, how can we implement these >> in the transitions? They surely can't use the same one, both because it >> will be confusing and there will be synching issues. Think about creating 1 >> RotateTransition and 1 ScaleTransition with different pivots. The order in >> which you start them will matter because one will change the other (and >> if forceSync is enabled then one will override the other mid-transition). >> Having these pivots on Node for direct usage is convenient, but I see it >> as a secondary goal. It is more of a necessity for the transitions. Notice >> that the JBS issue [1] is aggregating 3 issues because they are >> interdependent. >> >> As for Michael's proposal, it has the benefit of getting rid of the >> special computed value of the center of the node and making it clear what >> the default is. >> I'm not sure what Michael means by "absolute coordinates", I assume it's >> relative to the parent, and that "relative to the layout bounds" means >> relative to the node. This way, setting to 0.5 with "relative to the layout >> bounds" will indeed mean the center of the node. >> I find some inconsistency issues with the relativePivot idea: >> 1. The Scale, Rotate, and Shear transforms use the parent coordinates. >> That means that if I set a pivoted scale transform on the node, and then >> use a pivoted scale transition (keeping the default), the pivot will not be >> the same. This would be very confusing I think. >> 2. TranslateTransition has a toX property (and Y and Z) that always uses >> the parent coordinates. That means that if I use a translate transition and >> a scale transition (keeping the default), I will be working in 2 coordinate >> systems simultaneously. Also confusing for me. >> 3. Switching between local and global coordinate systems is a more >> general issue, and solving it locally just for pivots of 2 transitions >> seems incomplete and out of place to me in this patch. >> >> To expand on point 3, I see 3 generally useful systems: node, parent, and >> scene. We have methods that transform from one to the other. Despite those, >> I also find it a lot of work to transform between coordinate systems. This >> leads me to believe that the idea of toggling between coordinate systems >> tries to solve a broader issue, one that touches both transforms and >> transitions (including node properties). As a result, I think that we >> should implement the current proposal of adding pivots by using the current >> coordinate system that everything else uses (parent), and then think about >> better ways of handling coordinate system transformations more generally. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8234712 >> >> On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> The idea of adding explicit pivot properties was met with general >>> agreement as long as we preserve compatibility (meaning that an >>> auto-computed pivot at the center of the bounds must remain the default). >>> >>> The questions are around what form the API should take. They basically >>> boil down to: >>> >>> 1. How do we indicate whether the pivot is computed vs explicitly >>> specified? >>> 2. Should the pivot position be 3 doubles or a Point3D >>> 3. Do we need a separate pivot for rotation vs scaling >>> >>> My quick thoughts (although I might be able to be persuaded otherwise) >>> are: >>> >>> 1) a boolean property >>> 2) 3 separate doubles >>> 3) no >>> >>> Michael's proposal of a couple months ago [1] would match those answers, >>> and is an interesting approach that I hadn't considered before. The >>> question then is whether want the additional flexibility that it provides >>> and whether it is worth the additional implementation, documentation, and >>> testing that would be needed. It can be a discussion point. I'd like to >>> know what Nir thinks of that idea. >>> >>> I think we can discuss the details of the API in the PR, although while >>> it is Draft, many people will miss the discussion (since it doesn't get >>> sent to the mailing list), so it might be better to at get high-level >>> agreement on the answers to the outstanding API questions on this list? >>> >>> -- Kevin >>> >>> [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 >>> >>> >>> >>> On 8/19/2021 12:03 PM, Nir Lisker wrote: >>> >>> I'd like to see pivot properties move forward. >>>> The PR seems to be a bit stale, as it has been sitting around for >>>> almost two years. >>> >>> >>> Me too, but there was no decision as to the implementation type. We can >>> continue the discussion on the PR at this point I think. >>> >>> On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? >>> wrote: >>> >>>> I'd like to see pivot properties move forward. >>>> The PR seems to be a bit stale, as it has been sitting around for >>>> almost two years. >>>> >>>> PR: https://github.com/openjdk/jfx/pull/53 >>>> >>>> >>>> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth >>>> : >>>> > >>>> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >>>> > and enhancement requests for JavaFX 18. It's the summer, so there may >>>> be >>>> > delays as some people are out at various times (including me), but I >>>> > would like to get some of the outstanding enhancement requests moving >>>> > over the next few weeks. >>>> > >>>> > Specifically, I'd like to see the following proceed: >>>> > >>>> > * Transparent backgrounds in WebView >>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>>> > PR: https://github.com/openjdk/jfx/pull/563 >>>> >>>> > >>>> > * Add DirectionalLight >>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>>> > PR: https://github.com/openjdk/jfx/pull/548 >>>> >>>> > >>>> > * CSS pseudoclasses :focus-visible and :focus-within >>>> > https://bugs.openjdk.java.net/browse/JDK-8268225 >>>> > PR: https://github.com/openjdk/jfx/pull/475 >>>> >>>> > >>>> > * Improve property system to facilitate correct usage (minus the >>>> binary >>>> > incompatible API change) >>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>>> > PR: https://github.com/openjdk/jfx/pull/590 >>>> >>>> (Draft) >>>> > >>>> > And maybe the following: >>>> > >>>> > * Add CSS themes as a first-class concept (need a consensus on how to >>>> > proceed) >>>> > >>>> > * Undecorated interactive stage style (still in early discussion, but >>>> > the concept looks interesting and useful) >>>> > >>>> > There are probably others I'm forgetting. >>>> > >>>> > Each of the above should be discussed in their own thread on >>>> openjfx-dev >>>> > rather than a reply to this thread. >>>> > >>>> > -- Kevin >>>> > >>>> > >>>> >>> >>> >> From michaelstrau2 at gmail.com Sun Aug 22 16:14:03 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 22 Aug 2021 18:14:03 +0200 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> Message-ID: Yes, calling it ?relativePivot? might have been a poor naming choice. The purpose was to toggle between normalized/non-normalized coordinates, effectively allowing developers to customize the ?computed pivot?. So instead of ignoring the specified X/Y/Z pivot coordinates and computing the center of the node, the ?relativePivot? toggle would instead interpret the specified values as normalized coordinates relative to the node. On Sunday, August 22, 2021, Nir Lisker wrote: > The special case of "center of the node" (the computed pivot) is the > current behavior, and it needs to be preserved for backwards compatibility. > This is why we were discussing the out of band values issues to begin with. > > Reading the rest of what you wrote makes me think I didn't understand your > terminology. Does the "relativePivot" switch between normalized coordinates > and non-normalized coordinates, both in the coordinate system of the node? > > On Sat, Aug 21, 2021 at 11:23 PM Michael Strau? > wrote: > >> I think that ?computed pivot? is both an unnecessary terminology, and >> really only one special case of a pivot coordinate in unit space where 0/0 >> is the top-left corner of the node, and 1/1 is the bottom-right corner of >> the node (which is what I referred to as ?relative? coordinates). >> >> Quite often, it can be more useful to define pivots in unit space, >> because it?s an easy answer to a problem like ?rotate the node 45 degrees >> around its top-left corner?. Special-casing the 0.5/0.5 unit coordinate and >> not allowing any other feels like a lackluster API, and increases the >> effort for developers to solve a very common problem. >> >> From an implementation perspective, there?s not much of a difference in >> development and maintenance cost. The projection from unit space to pixel >> space needs to happen anyway (that?s the ?computed? part in ?computed >> pivot?), and allowing any coordinate rather than the 0.5/0.5 midpoint is >> only a single multiplication away. >> >> >> >> >> On Saturday, August 21, 2021, Kevin Rushforth >> wrote: >> >>> I didn't page in enough of the discussion before. I remember now why we >>> need separate pivots for rotate and scale, so thank you for reminding me. >>> Btw, I don't think that necessarily means we need a separate switch for >>> whether to use computed vs explicit for each (but that would be a >>> possibility). >>> >>> I agree with the points raised about relative versus "absolute". While >>> it is an intriguing idea, it probably doesn't fit here. >>> >>> While it is a clever idea to use an ObjectProperty rather than a >>> DoubleProperty so we have an out of band value to use for "compute this" I >>> don't think that we should do it that way for a few reasons. First, it's >>> inconsistent with all other number based properties, in a way that could >>> cause usability issues (e.g., you couldn't just pass pivotXProperty() >>> directly to a method that expects a DoubleProperty). Second, I don't like >>> the implications of having separate "auto-compute" flags on each of X, Y, >>> and Z. Third, is the documentation issue you mentioned. >>> >>> So amending my earlier answers to the three questions: >>> >>> 1. A single boolean property for whether to use a compute pivot (the >>> default) vs an explicit pivot; this would apply to both rotate and scale >>> pivots. >>> 2. 3 separate doubles (using DoubleProperty). >>> 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties. >>> >>> -- Kevin >>> >>> On 8/21/2021 6:19 AM, Nir Lisker wrote: >>> >>> In the previous time this was discussed I suggested a 3rd option, in >>> addition to ObjectProperty and 3 DoubleProperties, which is 3 >>> ObjectPropertys. >>> >>> Advantages: >>> 1. Allows using null to remove any specified user values (null would >>> also be the default), similar to how we would do it with >>> ObjectProperty. No need for another property like a boolean value. >>> 2. Allows changing individual axes and binding to each axis >>> independently, which was a disadvantage of Point3D. >>> 3. With how Valhalla is coming along, it's highly likely that there >>> would be no auto-boxing cost as Double will behave like a primitive. >>> >>> Disadvantages: >>> 1. Using null as the special value does not indicate well that the >>> default behavior is using the center of the node, but there is no >>> indication of it now, except in documentation which will be done anyway. >>> 2. ObjectProperty does not have the specialized methods >>> inherited from DoubleExpression (like #add), so it is more difficult to >>> work with mathematically. >>> >>> This addresses questions 1 and 2. The 2nd point in the disadvantages >>> makes this not too appealing for me, but the other options are also >>> problematic. >>> >>> As for question 3, I think we have to. The main goal of the PR is adding >>> pivot properties to ScaleTransition and RotateTransition. The various >>> transitions work by changing values in Node (FadeTransform changes opacity, >>> RotateTransition changes rotate and rotationAxis etc.). If we don't have >>> separate pivots for rotation and scale in Node, how can we implement these >>> in the transitions? They surely can't use the same one, both because it >>> will be confusing and there will be synching issues. Think about creating 1 >>> RotateTransition and 1 ScaleTransition with different pivots. The order in >>> which you start them will matter because one will change the other (and >>> if forceSync is enabled then one will override the other mid-transition). >>> Having these pivots on Node for direct usage is convenient, but I see it >>> as a secondary goal. It is more of a necessity for the transitions. Notice >>> that the JBS issue [1] is aggregating 3 issues because they are >>> interdependent. >>> >>> As for Michael's proposal, it has the benefit of getting rid of the >>> special computed value of the center of the node and making it clear what >>> the default is. >>> I'm not sure what Michael means by "absolute coordinates", I assume it's >>> relative to the parent, and that "relative to the layout bounds" means >>> relative to the node. This way, setting to 0.5 with "relative to the layout >>> bounds" will indeed mean the center of the node. >>> I find some inconsistency issues with the relativePivot idea: >>> 1. The Scale, Rotate, and Shear transforms use the parent coordinates. >>> That means that if I set a pivoted scale transform on the node, and then >>> use a pivoted scale transition (keeping the default), the pivot will not be >>> the same. This would be very confusing I think. >>> 2. TranslateTransition has a toX property (and Y and Z) that always uses >>> the parent coordinates. That means that if I use a translate transition and >>> a scale transition (keeping the default), I will be working in 2 coordinate >>> systems simultaneously. Also confusing for me. >>> 3. Switching between local and global coordinate systems is a more >>> general issue, and solving it locally just for pivots of 2 transitions >>> seems incomplete and out of place to me in this patch. >>> >>> To expand on point 3, I see 3 generally useful systems: node, parent, >>> and scene. We have methods that transform from one to the other. Despite >>> those, I also find it a lot of work to transform between coordinate >>> systems. This leads me to believe that the idea of toggling between >>> coordinate systems tries to solve a broader issue, one that touches both >>> transforms and transitions (including node properties). As a result, I >>> think that we should implement the current proposal of adding pivots by >>> using the current coordinate system that everything else uses (parent), and >>> then think about better ways of handling coordinate system transformations >>> more generally. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8234712 >>> >>> On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> The idea of adding explicit pivot properties was met with general >>>> agreement as long as we preserve compatibility (meaning that an >>>> auto-computed pivot at the center of the bounds must remain the default). >>>> >>>> The questions are around what form the API should take. They basically >>>> boil down to: >>>> >>>> 1. How do we indicate whether the pivot is computed vs explicitly >>>> specified? >>>> 2. Should the pivot position be 3 doubles or a Point3D >>>> 3. Do we need a separate pivot for rotation vs scaling >>>> >>>> My quick thoughts (although I might be able to be persuaded otherwise) >>>> are: >>>> >>>> 1) a boolean property >>>> 2) 3 separate doubles >>>> 3) no >>>> >>>> Michael's proposal of a couple months ago [1] would match those >>>> answers, and is an interesting approach that I hadn't considered before. >>>> The question then is whether want the additional flexibility that it >>>> provides and whether it is worth the additional implementation, >>>> documentation, and testing that would be needed. It can be a discussion >>>> point. I'd like to know what Nir thinks of that idea. >>>> >>>> I think we can discuss the details of the API in the PR, although while >>>> it is Draft, many people will miss the discussion (since it doesn't get >>>> sent to the mailing list), so it might be better to at get high-level >>>> agreement on the answers to the outstanding API questions on this list? >>>> >>>> -- Kevin >>>> >>>> [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 >>>> >>>> >>>> >>>> On 8/19/2021 12:03 PM, Nir Lisker wrote: >>>> >>>> I'd like to see pivot properties move forward. >>>>> The PR seems to be a bit stale, as it has been sitting around for >>>>> almost two years. >>>> >>>> >>>> Me too, but there was no decision as to the implementation type. We can >>>> continue the discussion on the PR at this point I think. >>>> >>>> On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? >>>> wrote: >>>> >>>>> I'd like to see pivot properties move forward. >>>>> The PR seems to be a bit stale, as it has been sitting around for >>>>> almost two years. >>>>> >>>>> PR: https://github.com/openjdk/jfx/pull/53 >>>>> >>>>> >>>>> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth >>>>> : >>>>> > >>>>> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug >>>>> fixes >>>>> > and enhancement requests for JavaFX 18. It's the summer, so there >>>>> may be >>>>> > delays as some people are out at various times (including me), but I >>>>> > would like to get some of the outstanding enhancement requests moving >>>>> > over the next few weeks. >>>>> > >>>>> > Specifically, I'd like to see the following proceed: >>>>> > >>>>> > * Transparent backgrounds in WebView >>>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>>>> > PR: https://github.com/openjdk/jfx/pull/563 >>>>> >>>>> > >>>>> > * Add DirectionalLight >>>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>>>> > PR: https://github.com/openjdk/jfx/pull/548 >>>>> >>>>> > >>>>> > * CSS pseudoclasses :focus-visible and :focus-within >>>>> > https://bugs.openjdk.java.net/browse/JDK-8268225 >>>>> > PR: https://github.com/openjdk/jfx/pull/475 >>>>> >>>>> > >>>>> > * Improve property system to facilitate correct usage (minus the >>>>> binary >>>>> > incompatible API change) >>>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>>>> > PR: https://github.com/openjdk/jfx/pull/590 >>>>> >>>>> (Draft) >>>>> > >>>>> > And maybe the following: >>>>> > >>>>> > * Add CSS themes as a first-class concept (need a consensus on how to >>>>> > proceed) >>>>> > >>>>> > * Undecorated interactive stage style (still in early discussion, but >>>>> > the concept looks interesting and useful) >>>>> > >>>>> > There are probably others I'm forgetting. >>>>> > >>>>> > Each of the above should be discussed in their own thread on >>>>> openjfx-dev >>>>> > rather than a reply to this thread. >>>>> > >>>>> > -- Kevin >>>>> > >>>>> > >>>>> >>>> >>>> >>> From arapte at openjdk.java.net Sun Aug 22 18:40:28 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sun, 22 Aug 2021 18:40:28 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: On Fri, 20 Aug 2021 23:18:58 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> use antpluginImplementation > > build.gradle line 2758: > >> 2756: >> 2757: dependencies { >> 2758: implementation group: "org.apache.ant", name: "ant", version: "1.8.2" > > Shouldn't this be `antpluginImplementation`? It may not matter as much, since we don't build fxpackager by default in FX 11, but I still think it should be fixed. This is corrected in next commit. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From nlisker at gmail.com Sun Aug 22 19:54:40 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 22 Aug 2021 22:54:40 +0300 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> Message-ID: Now I understand what you meant. However, the concept of normalized coordinates does not appear anywhere in JavaFX (at least not in these contexts). I still think that coordinate transformations should be handled via dedicated means, like coordinate system transformations are. Maybe when we work on mapped bindings (I forgot that I need to review that) this pain point will be alleviated. Kevin, what if we only set the initial value of the pivot (doesn't matter what the implementation detail is) to the center of the node for backwards compatibility, but if the developer changes it to a custom value then it's on them to compute the value again if they want to go back? The default behavior remains. Another relevant point is that Transitions do something similar with their from_, to_ and by_ methods. They start with Double.NaN to signal that the value should be ignored. While the developer can reset the value to NaN, it is not something that is likely to happen during, say, an interpolation or as a result of a binding. On Sun, Aug 22, 2021 at 7:14 PM Michael Strau? wrote: > Yes, calling it ?relativePivot? might have been a poor naming choice. The > purpose was to toggle between normalized/non-normalized coordinates, > effectively allowing developers to customize the ?computed pivot?. > > So instead of ignoring the specified X/Y/Z pivot coordinates and computing > the center of the node, the ?relativePivot? toggle would instead interpret > the specified values as normalized coordinates relative to the node. > > > On Sunday, August 22, 2021, Nir Lisker wrote: > >> The special case of "center of the node" (the computed pivot) is the >> current behavior, and it needs to be preserved for backwards compatibility. >> This is why we were discussing the out of band values issues to begin with. >> >> Reading the rest of what you wrote makes me think I didn't >> understand your terminology. Does the "relativePivot" switch between >> normalized coordinates and non-normalized coordinates, both in the >> coordinate system of the node? >> >> On Sat, Aug 21, 2021 at 11:23 PM Michael Strau? >> wrote: >> >>> I think that ?computed pivot? is both an unnecessary terminology, and >>> really only one special case of a pivot coordinate in unit space where 0/0 >>> is the top-left corner of the node, and 1/1 is the bottom-right corner of >>> the node (which is what I referred to as ?relative? coordinates). >>> >>> Quite often, it can be more useful to define pivots in unit space, >>> because it?s an easy answer to a problem like ?rotate the node 45 degrees >>> around its top-left corner?. Special-casing the 0.5/0.5 unit coordinate and >>> not allowing any other feels like a lackluster API, and increases the >>> effort for developers to solve a very common problem. >>> >>> From an implementation perspective, there?s not much of a difference in >>> development and maintenance cost. The projection from unit space to pixel >>> space needs to happen anyway (that?s the ?computed? part in ?computed >>> pivot?), and allowing any coordinate rather than the 0.5/0.5 midpoint is >>> only a single multiplication away. >>> >>> >>> >>> >>> On Saturday, August 21, 2021, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> I didn't page in enough of the discussion before. I remember now why we >>>> need separate pivots for rotate and scale, so thank you for reminding me. >>>> Btw, I don't think that necessarily means we need a separate switch for >>>> whether to use computed vs explicit for each (but that would be a >>>> possibility). >>>> >>>> I agree with the points raised about relative versus "absolute". While >>>> it is an intriguing idea, it probably doesn't fit here. >>>> >>>> While it is a clever idea to use an ObjectProperty rather than >>>> a DoubleProperty so we have an out of band value to use for "compute this" >>>> I don't think that we should do it that way for a few reasons. First, it's >>>> inconsistent with all other number based properties, in a way that could >>>> cause usability issues (e.g., you couldn't just pass pivotXProperty() >>>> directly to a method that expects a DoubleProperty). Second, I don't like >>>> the implications of having separate "auto-compute" flags on each of X, Y, >>>> and Z. Third, is the documentation issue you mentioned. >>>> >>>> So amending my earlier answers to the three questions: >>>> >>>> 1. A single boolean property for whether to use a compute pivot (the >>>> default) vs an explicit pivot; this would apply to both rotate and scale >>>> pivots. >>>> 2. 3 separate doubles (using DoubleProperty). >>>> 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties. >>>> >>>> -- Kevin >>>> >>>> On 8/21/2021 6:19 AM, Nir Lisker wrote: >>>> >>>> In the previous time this was discussed I suggested a 3rd option, in >>>> addition to ObjectProperty and 3 DoubleProperties, which is 3 >>>> ObjectPropertys. >>>> >>>> Advantages: >>>> 1. Allows using null to remove any specified user values (null would >>>> also be the default), similar to how we would do it with >>>> ObjectProperty. No need for another property like a boolean value. >>>> 2. Allows changing individual axes and binding to each axis >>>> independently, which was a disadvantage of Point3D. >>>> 3. With how Valhalla is coming along, it's highly likely that there >>>> would be no auto-boxing cost as Double will behave like a primitive. >>>> >>>> Disadvantages: >>>> 1. Using null as the special value does not indicate well that the >>>> default behavior is using the center of the node, but there is no >>>> indication of it now, except in documentation which will be done anyway. >>>> 2. ObjectProperty does not have the specialized methods >>>> inherited from DoubleExpression (like #add), so it is more difficult to >>>> work with mathematically. >>>> >>>> This addresses questions 1 and 2. The 2nd point in the disadvantages >>>> makes this not too appealing for me, but the other options are also >>>> problematic. >>>> >>>> As for question 3, I think we have to. The main goal of the PR is >>>> adding pivot properties to ScaleTransition and RotateTransition. The >>>> various transitions work by changing values in Node (FadeTransform >>>> changes opacity, RotateTransition changes rotate and rotationAxis etc.). If >>>> we don't have separate pivots for rotation and scale in Node, how can we >>>> implement these in the transitions? They surely can't use the same one, >>>> both because it will be confusing and there will be synching issues. Think >>>> about creating 1 RotateTransition and 1 ScaleTransition with different >>>> pivots. The order in which you start them will matter because one will >>>> change the other (and if forceSync is enabled then one will override the >>>> other mid-transition). >>>> Having these pivots on Node for direct usage is convenient, but I see >>>> it as a secondary goal. It is more of a necessity for the transitions. >>>> Notice that the JBS issue [1] is aggregating 3 issues because they are >>>> interdependent. >>>> >>>> As for Michael's proposal, it has the benefit of getting rid of the >>>> special computed value of the center of the node and making it clear what >>>> the default is. >>>> I'm not sure what Michael means by "absolute coordinates", I assume >>>> it's relative to the parent, and that "relative to the layout bounds" means >>>> relative to the node. This way, setting to 0.5 with "relative to the layout >>>> bounds" will indeed mean the center of the node. >>>> I find some inconsistency issues with the relativePivot idea: >>>> 1. The Scale, Rotate, and Shear transforms use the parent coordinates. >>>> That means that if I set a pivoted scale transform on the node, and then >>>> use a pivoted scale transition (keeping the default), the pivot will not be >>>> the same. This would be very confusing I think. >>>> 2. TranslateTransition has a toX property (and Y and Z) that always >>>> uses the parent coordinates. That means that if I use a translate >>>> transition and a scale transition (keeping the default), I will be working >>>> in 2 coordinate systems simultaneously. Also confusing for me. >>>> 3. Switching between local and global coordinate systems is a more >>>> general issue, and solving it locally just for pivots of 2 transitions >>>> seems incomplete and out of place to me in this patch. >>>> >>>> To expand on point 3, I see 3 generally useful systems: node, parent, >>>> and scene. We have methods that transform from one to the other. Despite >>>> those, I also find it a lot of work to transform between coordinate >>>> systems. This leads me to believe that the idea of toggling between >>>> coordinate systems tries to solve a broader issue, one that touches both >>>> transforms and transitions (including node properties). As a result, I >>>> think that we should implement the current proposal of adding pivots by >>>> using the current coordinate system that everything else uses (parent), and >>>> then think about better ways of handling coordinate system transformations >>>> more generally. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234712 >>>> >>>> On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> The idea of adding explicit pivot properties was met with general >>>>> agreement as long as we preserve compatibility (meaning that an >>>>> auto-computed pivot at the center of the bounds must remain the default). >>>>> >>>>> The questions are around what form the API should take. They basically >>>>> boil down to: >>>>> >>>>> 1. How do we indicate whether the pivot is computed vs explicitly >>>>> specified? >>>>> 2. Should the pivot position be 3 doubles or a Point3D >>>>> 3. Do we need a separate pivot for rotation vs scaling >>>>> >>>>> My quick thoughts (although I might be able to be persuaded otherwise) >>>>> are: >>>>> >>>>> 1) a boolean property >>>>> 2) 3 separate doubles >>>>> 3) no >>>>> >>>>> Michael's proposal of a couple months ago [1] would match those >>>>> answers, and is an interesting approach that I hadn't considered before. >>>>> The question then is whether want the additional flexibility that it >>>>> provides and whether it is worth the additional implementation, >>>>> documentation, and testing that would be needed. It can be a discussion >>>>> point. I'd like to know what Nir thinks of that idea. >>>>> >>>>> I think we can discuss the details of the API in the PR, although >>>>> while it is Draft, many people will miss the discussion (since it doesn't >>>>> get sent to the mailing list), so it might be better to at get high-level >>>>> agreement on the answers to the outstanding API questions on this list? >>>>> >>>>> -- Kevin >>>>> >>>>> [1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918 >>>>> >>>>> >>>>> >>>>> On 8/19/2021 12:03 PM, Nir Lisker wrote: >>>>> >>>>> I'd like to see pivot properties move forward. >>>>>> The PR seems to be a bit stale, as it has been sitting around for >>>>>> almost two years. >>>>> >>>>> >>>>> Me too, but there was no decision as to the implementation type. We >>>>> can continue the discussion on the PR at this point I think. >>>>> >>>>> On Fri, Aug 13, 2021 at 2:32 AM Michael Strau? < >>>>> michaelstrau2 at gmail.com> wrote: >>>>> >>>>>> I'd like to see pivot properties move forward. >>>>>> The PR seems to be a bit stale, as it has been sitting around for >>>>>> almost two years. >>>>>> >>>>>> PR: https://github.com/openjdk/jfx/pull/53 >>>>>> >>>>>> >>>>>> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth >>>>>> : >>>>>> > >>>>>> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug >>>>>> fixes >>>>>> > and enhancement requests for JavaFX 18. It's the summer, so there >>>>>> may be >>>>>> > delays as some people are out at various times (including me), but I >>>>>> > would like to get some of the outstanding enhancement requests >>>>>> moving >>>>>> > over the next few weeks. >>>>>> > >>>>>> > Specifically, I'd like to see the following proceed: >>>>>> > >>>>>> > * Transparent backgrounds in WebView >>>>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>>>>> > PR: https://github.com/openjdk/jfx/pull/563 >>>>>> >>>>>> > >>>>>> > * Add DirectionalLight >>>>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>>>>> > PR: https://github.com/openjdk/jfx/pull/548 >>>>>> >>>>>> > >>>>>> > * CSS pseudoclasses :focus-visible and :focus-within >>>>>> > https://bugs.openjdk.java.net/browse/JDK-8268225 >>>>>> > PR: https://github.com/openjdk/jfx/pull/475 >>>>>> >>>>>> > >>>>>> > * Improve property system to facilitate correct usage (minus the >>>>>> binary >>>>>> > incompatible API change) >>>>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>>>>> > PR: https://github.com/openjdk/jfx/pull/590 >>>>>> >>>>>> (Draft) >>>>>> > >>>>>> > And maybe the following: >>>>>> > >>>>>> > * Add CSS themes as a first-class concept (need a consensus on how >>>>>> to >>>>>> > proceed) >>>>>> > >>>>>> > * Undecorated interactive stage style (still in early discussion, >>>>>> but >>>>>> > the concept looks interesting and useful) >>>>>> > >>>>>> > There are probably others I'm forgetting. >>>>>> > >>>>>> > Each of the above should be discussed in their own thread on >>>>>> openjfx-dev >>>>>> > rather than a reply to this thread. >>>>>> > >>>>>> > -- Kevin >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>> From nlisker at gmail.com Sun Aug 22 23:45:00 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 23 Aug 2021 02:45:00 +0300 Subject: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: Getting this moving again as well. > Another option could be to mirror the `Color` API in both `Border` and > `Background`, like in the following examples: Color.rgb(125, 100, 75) > Border.rgb(125, 100, 75) > Background.rgb(125, 100, 75) Color.gray(127) > Border.gray(127) > Background.gray(127) > Color.web("orange", 0.5) > Border.web("orange", 0.5) > Background.web("orange", 0.5) This is possible, but I don't think it saves much. This API in Color makes it easy to create a color, so just using that directly in the border/background seems convenient enough to me. Comparing Border.rgb(125, 100, 75); with Border.of(Color.rgb(125, 100, 75)); // whatever the method name ends up being tells me that funneling all the color creation ways into one method in border/background is efficient enough to not merit multiple methods. We could also mirror the named color constants, which would enable a > very compact syntax: > StackPane pane = new StackPane(); > pane.setBorder(Border.RED); > pane.setBackground(Background.BLUE); This is very similar to how "red" or "blue" are valid values for > "-fx-border" or "-fx-background" in CSS. I rather not duplicate hundreds of constants just to be able to do pane.setBorder(Border.RED); instead of pane.setBorder(Border.of(Color.RED)); On Tue, Jun 8, 2021 at 2:41 AM Nir Lisker wrote: > Does this constitute sufficient interest in the enhancement? > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > wrote: > >> Another option could be to mirror the `Color` API in both `Border` and >> `Background`, like in the following examples: >> >> Color.rgb(125, 100, 75) >> Border.rgb(125, 100, 75) >> Background.rgb(125, 100, 75) >> >> Color.gray(127) >> Border.gray(127) >> Background.gray(127) >> >> Color.web("orange", 0.5) >> Border.web("orange", 0.5) >> Background.web("orange", 0.5) >> >> We could also mirror the named color constants, which would enable a >> very compact syntax: >> >> StackPane pane = new StackPane(); >> pane.setBorder(Border.RED); >> pane.setBackground(Background.BLUE); >> >> This is very similar to how "red" or "blue" are valid values for >> "-fx-border" or "-fx-background" in CSS. >> > From arapte at openjdk.java.net Mon Aug 23 10:09:33 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 23 Aug 2021 10:09:33 GMT Subject: RFR: 8244419: TextAreaSkin: throws UnsupportedOperation on dispose In-Reply-To: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> References: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> Message-ID: On Sat, 14 Aug 2021 10:32:00 GMT, Jeanette Winzenburg wrote: > The issue was a glaring contract violation of TextAreaSkin which throws a UnsupportedOperationException. The fix was to remove the throwing and cleanup on dispose which implies > > in TextAreaBehavior: > - remove the listener to focusProperty in dispose > > in TextAreaSkin: > - register all listeners to control properties via skin api > - remove installed event filter in dispose > - remove direct children (here only the scrollPane) > > Added tests to guard the listener re-wiring (must pass before and after), and tests to expose side-effects on replacing the skin (fail before, pass after) Looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/604 From cstein at openjdk.java.net Mon Aug 23 10:53:43 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 10:53:43 GMT Subject: RFR: 8267472: JavaFX modules to include version information Message-ID: https://bugs.openjdk.java.net/browse/JDK-8267472 ------------- Commit messages: - Compile version information into modules Changes: https://git.openjdk.java.net/jfx/pull/608/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=608&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267472 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/608.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/608/head:pull/608 PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 11:43:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 11:43:25 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 Even though this is a straightforward change, I'd like two reviewers. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 11:54:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 11:54:31 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: On Sun, 22 Aug 2021 11:32:58 GMT, Ambarish Rapte wrote: >> There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. >> And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. >> Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > use antpluginImplementation Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From jvos at openjdk.java.net Mon Aug 23 11:57:30 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 23 Aug 2021 11:57:30 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: <09Mh1eyyVRPISwNXgxkTRgHSjn6QJMia-x5U4EerNYQ=.98e8dfef-f319-47f7-afea-d7921b9e0ea2@github.com> On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 This looks good. I'm running the build process and will report once finished. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From fastegal at openjdk.java.net Mon Aug 23 12:10:30 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 23 Aug 2021 12:10:30 GMT Subject: Integrated: 8244419: TextAreaSkin: throws UnsupportedOperation on dispose In-Reply-To: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> References: <2iRJWkkrYpLZunRapIYEKPE6IhfVmGisihX6OSfQMgw=.84f87e7e-e751-4d72-9863-5b1fce691f0a@github.com> Message-ID: On Sat, 14 Aug 2021 10:32:00 GMT, Jeanette Winzenburg wrote: > The issue was a glaring contract violation of TextAreaSkin which throws a UnsupportedOperationException. The fix was to remove the throwing and cleanup on dispose which implies > > in TextAreaBehavior: > - remove the listener to focusProperty in dispose > > in TextAreaSkin: > - register all listeners to control properties via skin api > - remove installed event filter in dispose > - remove direct children (here only the scrollPane) > > Added tests to guard the listener re-wiring (must pass before and after), and tests to expose side-effects on replacing the skin (fail before, pass after) This pull request has now been integrated. Changeset: 5e9f6171 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/5e9f6171289ea20e2d700f2422a4eae50287dd41 Stats: 391 lines in 8 files changed: 332 ins; 37 del; 22 mod 8244419: TextAreaSkin: throws UnsupportedOperation on dispose Reviewed-by: mhanl, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/604 From kcr at openjdk.java.net Mon Aug 23 12:27:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 12:27:35 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: On Sun, 22 Aug 2021 11:32:58 GMT, Ambarish Rapte wrote: >> There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. >> And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. >> Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > use antpluginImplementation @johanvos can you also review this? ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From jvos at openjdk.java.net Mon Aug 23 12:31:34 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 23 Aug 2021 12:31:34 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: <87RSzrdW319EB4mdaZroUAIhxCxpqX42mUH2HOdS0zI=.6ecf44e9-40e0-41e9-9a69-30be9cb5586a@github.com> On Sun, 22 Aug 2021 11:32:58 GMT, Ambarish Rapte wrote: >> There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. >> And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. >> Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > use antpluginImplementation Marked as reviewed by jvos (Reviewer). Already did, but forgot to look at the results. Looks good to me. We might remove the fxpackager part, but it doesn't hurt being there either. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From kcr at openjdk.java.net Mon Aug 23 12:39:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 12:39:34 GMT Subject: [jfx11u] RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: <3pIa05EMJSa_2lNCiy4TAhwxW4vigFekwCCev-aldeg=.6a0ff47c-0fac-4723-b458-10b218649e5a@github.com> On Sun, 22 Aug 2021 11:32:58 GMT, Ambarish Rapte wrote: >> There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. >> And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. >> Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > use antpluginImplementation Thanks. > We might remove the fxpackager part, but it doesn't hurt being there either. Since they aren't being built (and might no longer be buildable), we could consider backporting [JDK-8203379](https://bugs.openjdk.java.net/browse/JDK-8203379) to jfx11u remove the sources in a future update release. As it is, these sources serve no purpose other than as a source of "technical debt". ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From sykora at openjdk.java.net Mon Aug 23 13:02:33 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Mon, 23 Aug 2021 13:02:33 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 Looks good to me. Only, since gradle 6.4 (see https://github.com/gradle/gradle/issues/2177), you can directly set the module version like this: project.compileJava { ... options.javaModuleVersion.set("$RELEASE_VERSION_SHORT") } I'm not sure if this is more elegant? With Gradle 7, this option is also no longer incubating. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 13:17:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 13:17:26 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 @sormuras Can you enable GitHub actions runs for your personal fork of `jfx`? That way we can see the test results as part of the review of this PR. See [Checks](https://github.com/openjdk/jfx/pull/608/checks) for more info. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From arapte at openjdk.java.net Mon Aug 23 13:31:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 23 Aug 2021 13:31:39 GMT Subject: [jfx11u] Integrated: 8263760: Update gradle to version 7.0.1 In-Reply-To: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> References: <1pQW2Ubc0bAEJCeYGiD-TTFLbWFRMk0q_pdJ-qmR39E=.c7946412-3c34-4f79-be2f-7f16d5a00b5e@github.com> Message-ID: On Fri, 20 Aug 2021 20:13:18 GMT, Ambarish Rapte wrote: > There were two minor merge conflicts in `build.gradle` and one conflict in `gradle/wrapper/gradle-wrapper.properties` while cherry picking the change. > And it also required similar changes to be made for project fxpackager. The [first commit](https://github.com/openjdk/jfx11u/pull/49/commits/7700a6d1a7c82df8fc269f1de6f3bd5119fb3397) is the original cherry pick and [second commit](https://github.com/openjdk/jfx11u/pull/49/commits/cea09bdfc96374ce00560c13e6730ab76f8b20e9) is the additional changes for fxpackager. > Verified the build on all three platforms with gradle 7.0.1 and apache ant 1.10.5 This pull request has now been integrated. Changeset: 80c06708 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/80c06708932bc28b7d76cd40cad39c50422788bf Stats: 148 lines in 13 files changed: 46 ins; 5 del; 97 mod 8263760: Update gradle to version 7.0.1 8240336: JavaFX build uses deprecated features that will be removed in gradle 7 8262236: Configure Gradle checksum verification Reviewed-by: kcr, jvos Backport-of: 111bac4180a646662a81223bdbb56880789d5a90 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/49 From cstein at openjdk.java.net Mon Aug 23 14:03:37 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 14:03:37 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 Enabled actions on my fork - do I need to do something to trigger them now manually? They don't seem to start: https://github.com/sormuras/jfx/actions/workflows/submit.yml ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 14:03:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 14:03:37 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 13:57:36 GMT, Christian Stein wrote: > Enabled actions on my fork - do I need to do something to trigger them now manually? You need to push a (possibly empty) commit to your branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 14:03:38 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 14:03:38 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 12:59:46 GMT, Joeri Sykora wrote: > [...] I'm not sure if this is more elegant? With Gradle 7, this option is also no longer incubating. As long as `--module-source-path` et al aren't supported by Gradle, I'd suggest to keep Java module related options at a single place. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 14:10:56 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 14:10:56 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8267472 Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Pass module version also to `jmod` ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/608/files - new: https://git.openjdk.java.net/jfx/pull/608/files/5d2262ac..e9eabd0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=608&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=608&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/608.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/608/head:pull/608 PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 14:10:57 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 14:10:57 GMT Subject: RFR: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 The submit workflow just started: https://github.com/sormuras/jfx/actions/runs/1158948963 I'm not sure, if passing `--module-version` to `jmod` is needed (as the `module-info.class` should already contain the compiled version information) -- but a) it triggered the workflow and b) it shouln't hurt to set the same version twice. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 14:15:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 14:15:37 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v2] In-Reply-To: References: Message-ID: <83GVEdCmmCZfYcqjdeK8IoGNmN8_uno4G-NyR_LvT5Q=.244581fb-99c8-4147-84b5-ffc1f49289c0@github.com> On Mon, 23 Aug 2021 14:10:56 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Pass module version also to `jmod` I think there may be two other tasks where the `--module-version` is needed: [:graphics:compileFullJava](https://github.com/openjdk/jfx/blob/e9eabd0dbd305a860b8083daf5229764a290e9ef/build.gradle#L2208) and [:web:compileJavaDOMBindingTask](https://github.com/openjdk/jfx/blob/e9eabd0dbd305a860b8083daf5229764a290e9ef/build.gradle#L3603). build.gradle line 3929: > 3927: options.compilerArgs.addAll([ > 3928: '-implicit:none', > 3929: '--module-version', "$RELEASE_VERSION_SHORT", I'm not sure this is needed (although it doesn't hurt), since the shims are only used for testing and are not included in any jar file. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From github.com+86982738+rahulk178 at openjdk.java.net Mon Aug 23 14:18:50 2021 From: github.com+86982738+rahulk178 at openjdk.java.net (Rahul Kumar) Date: Mon, 23 Aug 2021 14:18:50 GMT Subject: RFR: 8169098: [TestBug] Manual test case for JDK-8089915 Message-ID: Adding a new manual test case for accept attribute of input tag. This test is to verify the fix for [JDK-8089915](https://bugs.openjdk.java.net/browse/JDK-8089915) . We have tested the test cases on all three platforms and its working as expected. ------------- Commit messages: - Incorporate review changes - whitespace correction - JDK-8169098: Manual Test case Changes: https://git.openjdk.java.net/jfx/pull/607/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=607&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8169098 Stats: 111 lines in 1 file changed: 111 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/607.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/607/head:pull/607 PR: https://git.openjdk.java.net/jfx/pull/607 From kcr at openjdk.java.net Mon Aug 23 14:18:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 14:18:51 GMT Subject: RFR: 8169098: [TestBug] Manual test case for JDK-8089915 In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 15:58:21 GMT, Rahul Kumar wrote: > Adding a new manual test case for accept attribute of input tag. > This test is to verify the fix for [JDK-8089915](https://bugs.openjdk.java.net/browse/JDK-8089915) . > We have tested the test cases on all three platforms and its working as expected. The test looks good to me. I left two minor formatting comments. tests/manual/web/InputTypeAcceptAttributeTest.java line 26: > 24: */ > 25: > 26: Minor: can you remove the extra blank line? tests/manual/web/InputTypeAcceptAttributeTest.java line 37: > 35: import javafx.stage.Stage; > 36: import javafx.scene.layout.VBox; > 37: import javafx.scene.layout.HBox; Suggestion: maybe sort the list of imports? ------------- PR: https://git.openjdk.java.net/jfx/pull/607 From cstein at openjdk.java.net Mon Aug 23 14:20:32 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 14:20:32 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v2] In-Reply-To: <83GVEdCmmCZfYcqjdeK8IoGNmN8_uno4G-NyR_LvT5Q=.244581fb-99c8-4147-84b5-ffc1f49289c0@github.com> References: <83GVEdCmmCZfYcqjdeK8IoGNmN8_uno4G-NyR_LvT5Q=.244581fb-99c8-4147-84b5-ffc1f49289c0@github.com> Message-ID: On Mon, 23 Aug 2021 14:06:31 GMT, Kevin Rushforth wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass module version also to `jmod` > > build.gradle line 3929: > >> 3927: options.compilerArgs.addAll([ >> 3928: '-implicit:none', >> 3929: '--module-version', "$RELEASE_VERSION_SHORT", > > I'm not sure this is needed (although it doesn't hurt), since the shims are only used for testing and are not included in any jar file. Seeing version information in stack traces of failed tests can be helpful. ;-) ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 14:24:32 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 14:24:32 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 14:10:56 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Pass module version also to `jmod` > I think there may be two other tasks where the --module-version is needed: :graphics:compileFullJava and :web:compileJavaDOMBindingTask. So far to the "single place where Java module related options are found" argument. Aren't they covered by the `allprojects { ... }` and ... // If I am a module.... if (project.hasProperty('moduleSourcePath') && (project.hasProperty('buildModule') && project.buildModule)) { ... }` ... ``` ...selector? ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From github.com+86982738+rahulk178 at openjdk.java.net Mon Aug 23 14:27:08 2021 From: github.com+86982738+rahulk178 at openjdk.java.net (Rahul Kumar) Date: Mon, 23 Aug 2021 14:27:08 GMT Subject: RFR: 8169098: [TestBug] Manual test case for JDK-8089915 [v2] In-Reply-To: References: Message-ID: > Adding a new manual test case for accept attribute of input tag. > This test is to verify the fix for [JDK-8089915](https://bugs.openjdk.java.net/browse/JDK-8089915) . > We have tested the test cases on all three platforms and its working as expected. Rahul Kumar has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/607/files - new: https://git.openjdk.java.net/jfx/pull/607/files/3b93c3e1..2cf9661e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=607&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=607&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/607.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/607/head:pull/607 PR: https://git.openjdk.java.net/jfx/pull/607 From github.com+86982738+rahulk178 at openjdk.java.net Mon Aug 23 14:27:12 2021 From: github.com+86982738+rahulk178 at openjdk.java.net (Rahul Kumar) Date: Mon, 23 Aug 2021 14:27:12 GMT Subject: RFR: 8169098: [TestBug] Manual test case for JDK-8089915 [v2] In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 16:06:00 GMT, Kevin Rushforth wrote: >> Rahul Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporate review comment > > tests/manual/web/InputTypeAcceptAttributeTest.java line 26: > >> 24: */ >> 25: >> 26: > > Minor: can you remove the extra blank line? I have updated the review comments. > tests/manual/web/InputTypeAcceptAttributeTest.java line 37: > >> 35: import javafx.stage.Stage; >> 36: import javafx.scene.layout.VBox; >> 37: import javafx.scene.layout.HBox; > > Suggestion: maybe sort the list of imports? I have updated the review comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/607 From jpereda at openjdk.java.net Mon Aug 23 14:52:53 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 23 Aug 2021 14:52:53 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v3] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback from reviewer ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/fcd75f55..9676bb0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=01-02 Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Mon Aug 23 14:52:56 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 23 Aug 2021 14:52:56 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v2] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 21:28:53 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Set since 18 > > modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 702: > >> 700: /** >> 701: * Specifies the background color of the webPage, allowing >> 702: * some or full transparency. > > You might want to split this into two sentences, with the part about allowing for transparent being in the second sentence. Another thing you should indicate is how this interacts with the background color in the HTML file (I presume the one in the file takes precedence?). Also "web page" should be two words. Done > modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 704: > >> 702: * some or full transparency. >> 703: * >> 704: * Default color: White > > Use an `@defaultValue` javadoc tag here: > > > @defaultValue {@code Color.WHITE} Done ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Mon Aug 23 15:02:34 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 23 Aug 2021 15:02:34 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v2] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 21:33:57 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Set since 18 > > The API for the new property looks fine. I left a couple comments on the javadoc. > > You can create a Draft CSR when you get a chance. You still need to update `cssref.html` and that will need to be part of the CSR. @kevinrushforth the CSR was already created here: https://bugs.openjdk.java.net/browse/JDK-8269848 Do I need to update its code with the latest changes of this PR? As for the `cssref.html` update, do I add it as a commit to this PR, or as a new PR with the CSR id? ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Mon Aug 23 16:46:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 16:46:30 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v2] In-Reply-To: References: <83GVEdCmmCZfYcqjdeK8IoGNmN8_uno4G-NyR_LvT5Q=.244581fb-99c8-4147-84b5-ffc1f49289c0@github.com> Message-ID: On Mon, 23 Aug 2021 14:17:20 GMT, Christian Stein wrote: >> build.gradle line 3929: >> >>> 3927: options.compilerArgs.addAll([ >>> 3928: '-implicit:none', >>> 3929: '--module-version', "$RELEASE_VERSION_SHORT", >> >> I'm not sure this is needed (although it doesn't hurt), since the shims are only used for testing and are not included in any jar file. > > Seeing version information in stack traces of failed tests can be helpful. ;-) OK, that seems reasonable, and I can't think of any downside. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 16:52:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 16:52:24 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 14:21:28 GMT, Christian Stein wrote: > Aren't they covered by the allprojects { ... } and No. These options are used for the `compileJava` task in all projects. They do not affect the two compile tasks I mentioned. You can see that if you look at the following temporary build file: modules/javafx.graphics/build/tmp/compileFullJava/java-compiler-args.txt The same will be true for the `compileJavaDOMBindingTask` task I mentioned, if you build WebKit. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 18:18:51 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 18:18:51 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: References: Message-ID: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> > https://bugs.openjdk.java.net/browse/JDK-8267472 Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Add module version to `graphics` and `web` project's compiler args ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/608/files - new: https://git.openjdk.java.net/jfx/pull/608/files/e9eabd0d..3fdb277d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=608&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=608&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/608.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/608/head:pull/608 PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 18:24:29 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 18:24:29 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> References: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> Message-ID: On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add module version to `graphics` and `web` project's compiler args Added version information to both places. fwiw, in JUnit 5's integration tests, we verify that all module descriptors of published modules match some [Golden Files](https://github.com/junit-team/junit5/tree/main/platform-tooling-support-tests/projects/jar-describe-module) produced by `jar --describe-module --file ...jar`. This includes a check for the version being correctly compiled into and reported by them. Is there something like that in place for JavaFX's modular JAR files? ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From jvos at openjdk.java.net Mon Aug 23 18:43:32 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 23 Aug 2021 18:43:32 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: References: <83GVEdCmmCZfYcqjdeK8IoGNmN8_uno4G-NyR_LvT5Q=.244581fb-99c8-4147-84b5-ffc1f49289c0@github.com> Message-ID: On Mon, 23 Aug 2021 16:43:34 GMT, Kevin Rushforth wrote: >> Seeing version information in stack traces of failed tests can be helpful. ;-) > > OK, that seems reasonable, and I can't think of any downside. The only thing that makes me slightly nervous is seeing that this is needed on a number of places, leading to more code duplication (and the build.gradle is already rather large). But that is not a problem introduced with this PR, so I'm not requesting a change for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Mon Aug 23 18:50:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 18:50:24 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> References: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> Message-ID: On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add module version to `graphics` and `web` project's compiler args No, we don't have such a check. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 18:50:25 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 18:50:25 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: References: <83GVEdCmmCZfYcqjdeK8IoGNmN8_uno4G-NyR_LvT5Q=.244581fb-99c8-4147-84b5-ffc1f49289c0@github.com> Message-ID: On Mon, 23 Aug 2021 18:40:55 GMT, Johan Vos wrote: >> OK, that seems reasonable, and I can't think of any downside. > > The only thing that makes me slightly nervous is seeing that this is needed on a number of places, leading to more code duplication (and the build.gradle is already rather large). But that is not a problem introduced with this PR, so I'm not requesting a change for this. Yeah. At least, the four duplicated places look very similar to each other. Perhaps, those lines (adding module-related compiler args) can be extracted into a dedicated method. But that should be done, if at all, in a different task/PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Mon Aug 23 18:53:27 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 23 Aug 2021 18:53:27 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> References: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> Message-ID: <0rvNwDKpMdO9J1aGyI2JXed8tTkyGYjg8Wi1kIoSGQY=.c9949831-5976-4670-a366-3f330a2d7b4b@github.com> On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add module version to `graphics` and `web` project's compiler args Perhaps something for JFX 18-ea... ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From duncanmak at gmail.com Mon Aug 23 19:10:36 2021 From: duncanmak at gmail.com (Duncan Mak) Date: Mon, 23 Aug 2021 15:10:36 -0400 Subject: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: It feels more clear to me to see:Border.stroke(Paint stroke) and Background.fill(Paint fill) I vote in favor of those instead of Border.or and Background.of. On Sun, Aug 22, 2021 at 7:46 PM Nir Lisker wrote: > Getting this moving again as well. > > > > Another option could be to mirror the `Color` API in both `Border` and > > `Background`, like in the following examples: > > > Color.rgb(125, 100, 75) > > Border.rgb(125, 100, 75) > > Background.rgb(125, 100, 75) > > > Color.gray(127) > > Border.gray(127) > > Background.gray(127) > > > > Color.web("orange", 0.5) > > Border.web("orange", 0.5) > > Background.web("orange", 0.5) > > > This is possible, but I don't think it saves much. This API in Color makes > it easy to create a color, so just using that directly in the > border/background seems convenient enough to me. Comparing > Border.rgb(125, 100, 75); > with > Border.of(Color.rgb(125, 100, 75)); // whatever the method name ends up > being > tells me that funneling all the color creation ways into one method in > border/background is efficient enough to not merit multiple methods. > > We could also mirror the named color constants, which would enable a > > very compact syntax: > > > > > StackPane pane = new StackPane(); > > pane.setBorder(Border.RED); > > pane.setBackground(Background.BLUE); > > > This is very similar to how "red" or "blue" are valid values for > > "-fx-border" or "-fx-background" in CSS. > > > I rather not duplicate hundreds of constants just to be able to do > pane.setBorder(Border.RED); > instead of > pane.setBorder(Border.of(Color.RED)); > > On Tue, Jun 8, 2021 at 2:41 AM Nir Lisker wrote: > > > Does this constitute sufficient interest in the enhancement? > > > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > > wrote: > > > >> Another option could be to mirror the `Color` API in both `Border` and > >> `Background`, like in the following examples: > >> > >> Color.rgb(125, 100, 75) > >> Border.rgb(125, 100, 75) > >> Background.rgb(125, 100, 75) > >> > >> Color.gray(127) > >> Border.gray(127) > >> Background.gray(127) > >> > >> Color.web("orange", 0.5) > >> Border.web("orange", 0.5) > >> Background.web("orange", 0.5) > >> > >> We could also mirror the named color constants, which would enable a > >> very compact syntax: > >> > >> StackPane pane = new StackPane(); > >> pane.setBorder(Border.RED); > >> pane.setBackground(Background.BLUE); > >> > >> This is very similar to how "red" or "blue" are valid values for > >> "-fx-border" or "-fx-background" in CSS. > >> > > > -- Duncan. From kcr at openjdk.java.net Mon Aug 23 22:41:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 23 Aug 2021 22:41:29 GMT Subject: RFR: 8169098: [TestBug] Manual test case for JDK-8089915 [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 14:27:08 GMT, Rahul Kumar wrote: >> Adding a new manual test case for accept attribute of input tag. >> This test is to verify the fix for [JDK-8089915](https://bugs.openjdk.java.net/browse/JDK-8089915) . >> We have tested the test cases on all three platforms and its working as expected. > > Rahul Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comment Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/607 From michaelstrau2 at gmail.com Tue Aug 24 02:25:03 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 24 Aug 2021 04:25:03 +0200 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> Message-ID: I think normalized coordinates are a very natural fit for the definition of a pivot point, which is why the current default value is an implicitly-specified normalized coordinate. Adding general-purpose coordinate transformations here feels like bringing a sledgehammer to crack a nut. Having a property with an automagically updated "initial" value is quite non-standard behavior for properties. It would appear as if the property was bound, yet there's no binding. That's markedly different from a Transition's 'from' and 'to' properties, which are standard properties with normal behavior. A running transition doesn't bind to those properties, it uses a snapshot of their values when the transition starts. On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker wrote: > > Now I understand what you meant. However, the concept of normalized coordinates does not appear anywhere in JavaFX (at least not in these contexts). I still think that coordinate transformations should be handled via dedicated means, like coordinate system transformations are. Maybe when we work on mapped bindings (I forgot that I need to review that) this pain point will be alleviated. > > Kevin, what if we only set the initial value of the pivot (doesn't matter what the implementation detail is) to the center of the node for backwards compatibility, but if the developer changes it to a custom value then it's on them to compute the value again if they want to go back? The default behavior remains. > Another relevant point is that Transitions do something similar with their from_, to_ and by_ methods. They start with Double.NaN to signal that the value should be ignored. While the developer can reset the value to NaN, it is not something that is likely to happen during, say, an interpolation or as a result of a binding. > From psadhukhan at openjdk.java.net Tue Aug 24 05:15:40 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 24 Aug 2021 05:15:40 GMT Subject: RFR: 8272779: Package docs for javafx.embed.swing are misleading Message-ID: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> The API docs for the javafx.embed.swing package are misleading in that they only talk about the JFXPanel capability (embedding a JavaFX Scene in a Swing JComponent) and ignore the SwingNode functionality entirely. Fix the package doc. ------------- Commit messages: - Fix - Fix Changes: https://git.openjdk.java.net/jfx/pull/609/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272779 Stats: 18 lines in 1 file changed: 13 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/609/head:pull/609 PR: https://git.openjdk.java.net/jfx/pull/609 From psadhukhan at openjdk.java.net Tue Aug 24 05:51:51 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 24 Aug 2021 05:51:51 GMT Subject: RFR: 8272779: Package docs for javafx.embed.swing are misleading [v2] In-Reply-To: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> References: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> Message-ID: > The API docs for the javafx.embed.swing package are misleading in that they only talk about the JFXPanel capability (embedding a JavaFX Scene in a Swing JComponent) and ignore the SwingNode functionality entirely. > Fix the package doc. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/609/files - new: https://git.openjdk.java.net/jfx/pull/609/files/88b9b285..dd60daad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=609&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=609&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/609/head:pull/609 PR: https://git.openjdk.java.net/jfx/pull/609 From jvos at openjdk.java.net Tue Aug 24 07:28:26 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 24 Aug 2021 07:28:26 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> References: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> Message-ID: <1CUhTZA4VbEW6BIekGVmAtspKFHMp1kY6niw48WOqI4=.2018feca-df58-4bc0-ac1f-83b1267c6768@github.com> On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add module version to `graphics` and `web` project's compiler args I believe this is good to go now. As stated in a comment, the code duplication is a bit worrying, but we need to tackle this in other issues. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/608 From aghaisas at openjdk.java.net Tue Aug 24 11:20:25 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 24 Aug 2021 11:20:25 GMT Subject: RFR: 8090158: Wrong implementation of adjustValue in scrollBars In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 09:12:05 GMT, Hadzic Samir wrote: > JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158) > > The javadoc of the ScrollBar#adjustValue specifically says that it will adjust the value based on the block increment value. Therefore, there is no reason to stop at the given value when reaching an end. Fix looks good. I have few minor comments on the newly added unit tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/ScrollBarTest.java line 429: > 427: scrollBar.setValue(90.0); > 428: scrollBar.adjustValue(0.95); //This should block increment to the max value > 429: assertEquals(scrollBar.getValue(), 100.0, 0.0); Minor : First two parameters to assertEquals are - expected value and actual value respectively. You should reorder scrollBar.getValue() and 100.0. modules/javafx.controls/src/test/java/test/javafx/scene/control/ScrollBarTest.java line 442: > 440: scrollBar.setMax(100.0); > 441: scrollBar.setValue(10.0); > 442: scrollBar.adjustValue(0.05); //This should block increment to the max value Comment needs correction: This should decrement to the min value modules/javafx.controls/src/test/java/test/javafx/scene/control/ScrollBarTest.java line 443: > 441: scrollBar.setValue(10.0); > 442: scrollBar.adjustValue(0.05); //This should block increment to the max value > 443: assertEquals(scrollBar.getValue(), 0.0, 0.0); Minor : First two parameters to assertEquals are - expected value and actual value respectively. You should reorder scrollBar.getValue() and 0.0. ------------- PR: https://git.openjdk.java.net/jfx/pull/582 From github.com+86982738+rahulk178 at openjdk.java.net Tue Aug 24 11:47:28 2021 From: github.com+86982738+rahulk178 at openjdk.java.net (Rahul Kumar) Date: Tue, 24 Aug 2021 11:47:28 GMT Subject: Integrated: 8169098: [TestBug] Manual test case for JDK-8089915 In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 15:58:21 GMT, Rahul Kumar wrote: > Adding a new manual test case for accept attribute of input tag. > This test is to verify the fix for [JDK-8089915](https://bugs.openjdk.java.net/browse/JDK-8089915) . > We have tested the test cases on all three platforms and its working as expected. This pull request has now been integrated. Changeset: 66a45caf Author: Rahul Kumar Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/66a45cafea84a3498a6006aa320f02ce0e8f5a25 Stats: 111 lines in 1 file changed: 111 ins; 0 del; 0 mod 8169098: [TestBug] Manual test case for JDK-8089915 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/607 From kcr at openjdk.java.net Tue Aug 24 12:15:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Aug 2021 12:15:26 GMT Subject: RFR: 8272779: Package docs for javafx.embed.swing are misleading [v2] In-Reply-To: References: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> Message-ID: <6ZH3w0IcXTQ4uPNqFEyrRxiuFf4hzb4RkPDk9ZyPmBU=.4e95e64a-e6d5-48fa-89a0-805e546ad5da@github.com> On Tue, 24 Aug 2021 05:51:51 GMT, Prasanta Sadhukhan wrote: >> The API docs for the javafx.embed.swing package are misleading in that they only talk about the JFXPanel capability (embedding a JavaFX Scene in a Swing JComponent) and ignore the SwingNode functionality entirely. >> Fix the package doc. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix Looks pretty good with a few comments. modules/javafx.swing/src/main/java/javafx/embed/swing/package.html line 39: > 37: > 38: > 39:

Provides the set of classes to use JavaFX inside Swing applications.

Unless you also remove this initial sentence, the docs are still misleading, since only the first sentence shows up in the module summary for a package. modules/javafx.swing/src/main/java/javafx/embed/swing/package.html line 51: > 49: The {@link javafx.embed.swing.SwingNode} class is used to embed > 50: a Swing content into a JavaFX application. > 51: The content to be displayed is specified with the SwingNode.setContent method `SwingNode.setContent` should either use `{@link ...}` or `{@code ...}` modules/javafx.swing/src/main/java/javafx/embed/swing/package.html line 52: > 50: a Swing content into a JavaFX application. > 51: The content to be displayed is specified with the SwingNode.setContent method > 52: that accepts an instance of Swing {@code JComponent}. The hierarchy of components instance of _a_ Swing ... modules/javafx.swing/src/main/java/javafx/embed/swing/package.html line 56: > 54: components, otherwise {@code SwingNode} may fail to paint it. The content gets > 55: repainted automatically. All the input and focus events are forwarded to the > 56: {@code JComponent} instance transparently to the developer.

I might suggest removing the "transparently to the developer" part of this from the package description, since you don't also say that for `JFXPanel`, and someone might wonder whether there is something they need to do in the `JFXPanel` case. Both of the class descriptions include this language, so I think that's sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/609 From psadhukhan at openjdk.java.net Tue Aug 24 12:54:50 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 24 Aug 2021 12:54:50 GMT Subject: RFR: 8272779: Package docs for javafx.embed.swing are misleading [v3] In-Reply-To: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> References: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> Message-ID: > The API docs for the javafx.embed.swing package are misleading in that they only talk about the JFXPanel capability (embedding a JavaFX Scene in a Swing JComponent) and ignore the SwingNode functionality entirely. > Fix the package doc. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix review comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/609/files - new: https://git.openjdk.java.net/jfx/pull/609/files/dd60daad..eecd971b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=609&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=609&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/609/head:pull/609 PR: https://git.openjdk.java.net/jfx/pull/609 From kcr at openjdk.java.net Tue Aug 24 14:05:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Aug 2021 14:05:29 GMT Subject: RFR: 8267472: JavaFX modules to include version information [v3] In-Reply-To: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> References: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com> Message-ID: On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote: >> https://bugs.openjdk.java.net/browse/JDK-8267472 > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Add module version to `graphics` and `web` project's compiler args Looks good. I agree that we should not try to address the duplication as part of this PR (there is good reason for needing the two special compile tasks and the shims task, but reducing duplication could still be useful). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/608 From cstein at openjdk.java.net Tue Aug 24 14:58:26 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 24 Aug 2021 14:58:26 GMT Subject: Integrated: 8267472: JavaFX modules to include version information In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote: > https://bugs.openjdk.java.net/browse/JDK-8267472 This pull request has now been integrated. Changeset: c2e69145 Author: Christian Stein Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/c2e69145fa74c2c8df2986a0a8ff4756a91e8acd Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8267472: JavaFX modules to include version information Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/608 From kcr at openjdk.java.net Tue Aug 24 15:05:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Aug 2021 15:05:31 GMT Subject: RFR: 8272779: Package docs for javafx.embed.swing are misleading [v3] In-Reply-To: References: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> Message-ID: On Tue, 24 Aug 2021 12:54:50 GMT, Prasanta Sadhukhan wrote: >> The API docs for the javafx.embed.swing package are misleading in that they only talk about the JFXPanel capability (embedding a JavaFX Scene in a Swing JComponent) and ignore the SwingNode functionality entirely. >> Fix the package doc. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix review comment Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/609 From kevin.rushforth at oracle.com Tue Aug 24 15:15:48 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Aug 2021 08:15:48 -0700 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> Message-ID: <2f6ee873-423f-a798-ce23-be3064e77273@oracle.com> I definitely don't like having a "magic" initial value that can't be reset, so that won't work. And while we could use NaN as an out of band value meaning "computed", that still runs into the problem of allowing for the odd case where X is computed and Y is specified. If we do go with the idea of allowing the coordinates to be a percentage of the bounding box, with 0.5 as the default, then we could be informed by what ImagePattern does. It defines a "proportional" property as follows: "a boolean that indicates whether start and end locations are proportional or absolute. If this flag is true, the two end points are defined in a coordinate space where coordinates in the range |[0..1]| are scaled to map onto the bounds of the shape that the pattern fills. If this flag is false, then the coordinates are specified in the local coordinate system of the node." That's basically what we are doing if we go with Michael's idea. So if we do this, the two boolean properties could be named something like scalePivotProportional and rotatePivotProportional, with a default of true. What do you think? -- Kevin On 8/23/2021 7:25 PM, Michael Strau? wrote: > I think normalized coordinates are a very natural fit for the > definition of a pivot point, which is why the current default value is > an implicitly-specified normalized coordinate. Adding general-purpose > coordinate transformations here feels like bringing a sledgehammer to > crack a nut. > > Having a property with an automagically updated "initial" value is > quite non-standard behavior for properties. It would appear as if the > property was bound, yet there's no binding. That's markedly different > from a Transition's 'from' and 'to' properties, which are standard > properties with normal behavior. A running transition doesn't bind to > those properties, it uses a snapshot of their values when the > transition starts. > > > On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker wrote: >> Now I understand what you meant. However, the concept of normalized coordinates does not appear anywhere in JavaFX (at least not in these contexts). I still think that coordinate transformations should be handled via dedicated means, like coordinate system transformations are. Maybe when we work on mapped bindings (I forgot that I need to review that) this pain point will be alleviated. >> >> Kevin, what if we only set the initial value of the pivot (doesn't matter what the implementation detail is) to the center of the node for backwards compatibility, but if the developer changes it to a custom value then it's on them to compute the value again if they want to go back? The default behavior remains. >> Another relevant point is that Transitions do something similar with their from_, to_ and by_ methods. They start with Double.NaN to signal that the value should be ignored. While the developer can reset the value to NaN, it is not something that is likely to happen during, say, an interpolation or as a result of a binding. >> From mariushanl at web.de Tue Aug 24 15:57:42 2021 From: mariushanl at web.de (Marius Hanl) Date: Tue, 24 Aug 2021 17:57:42 +0200 Subject: =?UTF-8?Q?Aw=3A=C2=A0Re=3A_Convenience_factori?= =?UTF-8?Q?es_for_Border_and_Background?= In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: I want to see this as well. Do we want to continue creating a draft for this? Am 23.08.21, 01:48 schrieb Nir Lisker : Getting this moving again as well. > Another option could be to mirror the `Color` API in both `Border` and > `Background`, like in the following examples: Color.rgb(125, 100, 75) > Border.rgb(125, 100, 75) > Background.rgb(125, 100, 75) Color.gray(127) > Border.gray(127) > Background.gray(127) > Color.web("orange", 0.5) > Border.web("orange", 0.5) > Background.web("orange", 0.5) This is possible, but I don't think it saves much. This API in Color makes it easy to create a color, so just using that directly in the border/background seems convenient enough to me. Comparing Border.rgb(125, 100, 75); with Border.of(Color.rgb(125, 100, 75)); // whatever the method name ends up being tells me that funneling all the color creation ways into one method in border/background is efficient enough to not merit multiple methods. We could also mirror the named color constants, which would enable a > very compact syntax: > StackPane pane = new StackPane(); > pane.setBorder(Border.RED); > pane.setBackground(Background.BLUE); This is very similar to how "red" or "blue" are valid values for > "-fx-border" or "-fx-background" in CSS. I rather not duplicate hundreds of constants just to be able to do pane.setBorder(Border.RED); instead of pane.setBorder(Border.of(Color.RED)); On Tue, Jun 8, 2021 at 2:41 AM Nir Lisker wrote: > Does this constitute sufficient interest in the enhancement? > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > wrote: > >> Another option could be to mirror the `Color` API in both `Border` and >> `Background`, like in the following examples: >> >> Color.rgb(125, 100, 75) >> Border.rgb(125, 100, 75) >> Background.rgb(125, 100, 75) >> >> Color.gray(127) >> Border.gray(127) >> Background.gray(127) >> >> Color.web("orange", 0.5) >> Border.web("orange", 0.5) >> Background.web("orange", 0.5) >> >> We could also mirror the named color constants, which would enable a >> very compact syntax: >> >> StackPane pane = new StackPane(); >> pane.setBorder(Border.RED); >> pane.setBackground(Background.BLUE); >> >> This is very similar to how "red" or "blue" are valid values for >> "-fx-border" or "-fx-background" in CSS. >> > From nlisker at gmail.com Tue Aug 24 16:29:31 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 24 Aug 2021 19:29:31 +0300 Subject: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: I have one at https://github.com/openjdk/jfx/pull/610. On Tue, Aug 24, 2021 at 6:58 PM Marius Hanl wrote: > I want to see this as well. > Do we want to continue creating a draft for this? > > Am 23.08.21, 01:48 schrieb Nir Lisker : > > Getting this moving again as well. > > Another option could be to mirror the `Color` API in both `Border` > and > > `Background`, like in the following examples: > Color.rgb(125, 100, 75) > > Border.rgb(125, 100, 75) > > Background.rgb(125, 100, 75) > Color.gray(127) > > Border.gray(127) > > Background.gray(127) > > Color.web("orange", 0.5) > > Border.web("orange", 0.5) > > Background.web("orange", 0.5) > This is possible, but I don't think it saves much. This API in Color > makes > it easy to create a color, so just using that directly in the > border/background seems convenient enough to me. Comparing > Border.rgb(125, 100, 75); > with > Border.of(Color.rgb(125, 100, 75)); // whatever the method name ends > up > being > tells me that funneling all the color creation ways into one method > in > border/background is efficient enough to not merit multiple methods. > We could also mirror the named color constants, which would enable a > > very compact syntax: > > StackPane pane = new StackPane(); > > pane.setBorder(Border.RED); > > pane.setBackground(Background.BLUE); > This is very similar to how "red" or "blue" are valid values for > > "-fx-border" or "-fx-background" in CSS. > I rather not duplicate hundreds of constants just to be able to do > pane.setBorder(Border.RED); > instead of > pane.setBorder(Border.of(Color.RED)); > On Tue, Jun 8, 2021 at 2:41 AM Nir Lisker wrote: > > Does this constitute sufficient interest in the enhancement? > > > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > > > wrote: > > > >> Another option could be to mirror the `Color` API in both > `Border` and > >> `Background`, like in the following examples: > >> > >> Color.rgb(125, 100, 75) > >> Border.rgb(125, 100, 75) > >> Background.rgb(125, 100, 75) > >> > >> Color.gray(127) > >> Border.gray(127) > >> Background.gray(127) > >> > >> Color.web("orange", 0.5) > >> Border.web("orange", 0.5) > >> Background.web("orange", 0.5) > >> > >> We could also mirror the named color constants, which would > enable a > >> very compact syntax: > >> > >> StackPane pane = new StackPane(); > >> pane.setBorder(Border.RED); > >> pane.setBackground(Background.BLUE); > >> > >> This is very similar to how "red" or "blue" are valid values for > >> "-fx-border" or "-fx-background" in CSS. > >> > > > From nlisker at openjdk.java.net Tue Aug 24 21:28:41 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 24 Aug 2021 21:28:41 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background Message-ID: Added convenience factory factory methods for Background and Border. ------------- Commit messages: - Reverted import organization - Added convenience factory methods Changes: https://git.openjdk.java.net/jfx/pull/610/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272870 Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/610.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/610/head:pull/610 PR: https://git.openjdk.java.net/jfx/pull/610 From kcr at openjdk.java.net Tue Aug 24 21:39:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 24 Aug 2021 21:39:34 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 14:59:57 GMT, Jose Pereda wrote: > Do I need to update its code with the latest changes of this PR? Yes, although you can "batch up" the changes if you like until the review is far enough along that the API is unlikely to change. One comment on the CSR is that the specification section is concerned with interface changes. So you can (and should) elide the body of any public methods and just leave the method signature and API docs. For properties, the private field is often included in the CSR, since that's what you hang the API docs on. For the styleable property, it should be sufficient to include the diffs for `cssref.html` once you have them (see below). > As for the cssref.html update, do I add it as a commit to this PR, or as a new PR with the CSR id? Add it as a commit to this PR (btw, the JBS ID of the CSR is never used directly as an issue resolved by a PR; it is instead associated with a bug or enhancement that is). ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Tue Aug 24 22:12:01 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 24 Aug 2021 22:12:01 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Update cssref.html ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/9676bb0b..3a75240c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=02-03 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Tue Aug 24 22:15:28 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 24 Aug 2021 22:15:28 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 22:12:01 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Update cssref.html Ok, thanks for the clarifications. I've updated the CSR accordingly, and pushed the change for `cssref.html`. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From psadhukhan at openjdk.java.net Wed Aug 25 06:45:28 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 25 Aug 2021 06:45:28 GMT Subject: Integrated: 8272779: Package docs for javafx.embed.swing are misleading In-Reply-To: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> References: <3exiF6xviE_-OPCQwXM6gJBGnjNf53frLfEvdsTTC4A=.2976f5e1-0722-44a4-85a0-fddabfbb9235@github.com> Message-ID: On Tue, 24 Aug 2021 05:10:40 GMT, Prasanta Sadhukhan wrote: > The API docs for the javafx.embed.swing package are misleading in that they only talk about the JFXPanel capability (embedding a JavaFX Scene in a Swing JComponent) and ignore the SwingNode functionality entirely. > Fix the package doc. This pull request has now been integrated. Changeset: 91f01709 Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jfx/commit/91f017091786654a4564a5a054dbd22e6a01c120 Stats: 19 lines in 1 file changed: 12 ins; 0 del; 7 mod 8272779: Package docs for javafx.embed.swing are misleading Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/609 From kcr at openjdk.java.net Thu Aug 26 00:16:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 Aug 2021 00:16:29 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 22:12:01 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Update cssref.html I left a couple more comments on the API docs, and a few comments / questions on the implementation. I've tested this on Windows, but still need to test on the other two platforms. modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Graphics.java line 70: > 68: context.updateCompositeMode(CompositeMode.CLEAR); > 69: Paint oldPaint = getPaint(); > 70: setPaint(Color.TRANSPARENT); // any color will do... Is this change necessary? If so, then the comment is probably wrong. modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 459: > 457: public void setClip(WCRectangle c) { > 458: if (!isOpaque) { > 459: clearRect((int)c.getX(), (int)c.getY(), Are you sure that there are no ill effects from clearing the rectangle every time a clip is set on a non-opaque context? This seems like a surprising side effect. modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 615: > 613: twkSetTransparent(frameID, isBackgroundTransparent()); > 614: twkSetBackgroundColor(frameID, backgroundColor); > 615: repaintAll(); Is this needed unconditionally? Or only when the background is not opaque? modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 637: > 635: twkSetBackgroundColor(frameID, backgroundColor); > 636: } > 637: repaintAll(); Same question as above. modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 703: > 701: * Specifies the background color of the web page. > 702: * > 703: * With this property, the WebView control's background I recommend code style for `WebView`. modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 707: > 705: * level of transparency. > 706: * > 707: * However, if the HTML content being loaded set its own Typo: set --> sets modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 708: > 706: * > 707: * However, if the HTML content being loaded set its own > 708: * background color, it will take precedence. Maybe say the "that color" (instead of "it") will take precedence? modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 733: > 731: Color color = get(); > 732: page.setBackgroundColor(color != null ? color.hashCode() : > 733: DEFAULT_PAGE_FILL.hashCode()); This is relying on an undocumented, implementation detail. The current implementation of `Color::hashCode` happens to do what you want, but it is not specified. It seems safer to create a utility method to do this. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From github.com+1864183+micheljung at openjdk.java.net Thu Aug 26 01:33:28 2021 From: github.com+1864183+micheljung at openjdk.java.net (Michel Jung) Date: Thu, 26 Aug 2021 01:33:28 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: <4Vs2oRBRwSnBwM2z2Kcb060QyqbjmDeLjNeSe3Hws9E=.646027a4-eec0-4c9d-895d-40fcb1b00a38@github.com> On Wed, 25 Aug 2021 23:32:47 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update cssref.html > > modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 708: > >> 706: * >> 707: * However, if the HTML content being loaded set its own >> 708: * background color, it will take precedence. > > Maybe say the "that color" (instead of "it") will take precedence? Also, JavaDoc is HTML so if you want paragraphs you need to use `

` ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From michaelstrau2 at gmail.com Thu Aug 26 05:02:44 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 26 Aug 2021 07:02:44 +0200 Subject: CSS themes update Message-ID: Circling back to CSS themes. I've posted an update on the API: https://github.com/openjdk/jfx/pull/511#issuecomment-906092328 Comments appreciated. From thevenet.fred at free.fr Thu Aug 26 07:29:38 2021 From: thevenet.fred at free.fr (Frederic Thevenet) Date: Thu, 26 Aug 2021 09:29:38 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. Message-ID: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> Hi, A change was introduced In JDK-8264770 that swaps the use of ChangeListeners to InvalidationListeners within the internal implementation of BidirectionalBinding [1]. While this change shouldn't normally affect third party applications, it turned out to break the scrolling facilities used by the widely used rich text widget RichTextFX [2]. After a short investigation, I believe the root cause lies within another library by the same author called ReactFX [3], which aims to bring reactive programming techniques to JavaFX; in order to do so it seems to expands on but also sometime overrides the built-in bindings and events mechanisms. Now, I do believe that this is probably an exceptional case, and it is also quite possible that it? is the result of an unsafe/incorrect use of internal implementations by the third party library, but with that said I can't help but feeling a bit nervous about the wider implications of that change with regard to compatibility of existing apps and OpenJFX 17. At the very least I believe it is important to raise awareness about potential compatibility issues among the community. For your information, I reached out to the maintainers of RichTextFX and proposed a workaround (replacing the use of a bidirectional binding by a pair of explicit ChangeListeners), which, while not very elegant, seems to fix the particular issue I discovered [4], but unfortunately it seems development on the underlying ReactFX is no longer active (last commit in 2016). -- Fred [1] https://bugs.openjdk.java.net/browse/JDK-8264770 [2] https://github.com/FXMisc/RichTextFX [3] https://github.com/ReactFX/reactfx.github.io [4] https://github.com/FXMisc/Flowless/issues/97 From fastegal at swingempire.de Thu Aug 26 12:03:27 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 26 Aug 2021 14:03:27 +0200 Subject: Can't login to jbs .. Message-ID: <20210826140327.Horde.G3DvVQQOcRAD7xtpAM78nQ6@webmail.df.eu> .. general problem or just me? How to solve? Thanks for any help, Jeanette From jayathirth.d.v at oracle.com Thu Aug 26 12:04:37 2021 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 26 Aug 2021 12:04:37 +0000 Subject: Can't login to jbs .. In-Reply-To: <20210826140327.Horde.G3DvVQQOcRAD7xtpAM78nQ6@webmail.df.eu> References: <20210826140327.Horde.G3DvVQQOcRAD7xtpAM78nQ6@webmail.df.eu> Message-ID: <7C158548-8DEA-4708-A697-6AB01F12348F@oracle.com> I am also facing the issue. Looks like some generic issue. Thanks, Jay > On 26-Aug-2021, at 5:33 PM, Jeanette Winzenburg wrote: > > > .. general problem or just me? How to solve? > > Thanks for any help, > Jeanette > From kevin.rushforth at oracle.com Thu Aug 26 12:57:43 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Aug 2021 05:57:43 -0700 Subject: Can't login to jbs .. In-Reply-To: <7C158548-8DEA-4708-A697-6AB01F12348F@oracle.com> References: <20210826140327.Horde.G3DvVQQOcRAD7xtpAM78nQ6@webmail.df.eu> <7C158548-8DEA-4708-A697-6AB01F12348F@oracle.com> Message-ID: Can you try again? I was able to login a few minutes ago, so this outage might be resolved. -- Kevin On 8/26/2021 5:04 AM, Jayathirth D V wrote: > I am also facing the issue. Looks like some generic issue. > > Thanks, > Jay > >> On 26-Aug-2021, at 5:33 PM, Jeanette Winzenburg wrote: >> >> >> .. general problem or just me? How to solve? >> >> Thanks for any help, >> Jeanette >> From fastegal at swingempire.de Thu Aug 26 13:09:36 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 26 Aug 2021 15:09:36 +0200 Subject: Can't login to jbs .. In-Reply-To: References: <20210826140327.Horde.G3DvVQQOcRAD7xtpAM78nQ6@webmail.df.eu> <7C158548-8DEA-4708-A697-6AB01F12348F@oracle.com> Message-ID: <20210826150936.Horde.mIyoC1821AIym9EBh2p-zQ7@webmail.df.eu> yeah, working again - thanks everybody :) Zitat von Kevin Rushforth : > Can you try again? I was able to login a few minutes ago, so this > outage might be resolved. > > -- Kevin > > > On 8/26/2021 5:04 AM, Jayathirth D V wrote: >> I am also facing the issue. Looks like some generic issue. >> >> Thanks, >> Jay >> >>> On 26-Aug-2021, at 5:33 PM, Jeanette Winzenburg >>> wrote: >>> >>> >>> .. general problem or just me? How to solve? >>> >>> Thanks for any help, >>> Jeanette >>> From j.tosovsky at email.cz Thu Aug 26 13:31:24 2021 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Thu, 26 Aug 2021 15:31:24 +0200 Subject: Reducing the size of JavaFX native image app Message-ID: <004501d79a7e$ab1de960$0159bc20$@email.cz> Dear All, when building a minimum JavaFX?app [1] for Windows platform using Gluon's?maven plugin [2] incorporating GraalVM native image, the final exe size is approx. 60 MB. It is quite large. I've been searching for the help on StackOverflow [3], but there is no response for last 6 months. I am afraid this can be considered as a major JavaFX cons comparing to other desktop app frameworks (Flutter, Tauri). Do you see some room for reducing this size by some JavaFX engine tweaks in a long term? There was some discussion JavaFX needs some Swing stuff because of printing support. If this part is refactored, would this have some impact on the app size? Another option for Windows could be switching from embedded WebKit to MS WebView2 [4]. Relying on web engine shipped with OS has definitely some drawbacks, but the app size could be reduced signifficantly. I like JavaFX, it suits my needs, but producing executables of reasonable size would make me (+ JavaFX community) happier. And could persuade those undecided. Thanks, Jan _________ [1] https://github.com/drifted-in/hello-javafx [2] https://github.com/gluonhq/gluonfx-maven-plugin [3] https://stackoverflow.com/questions/66250311/reducing-the-size-of-javafx-nat ive-image-app [4] https://docs.microsoft.com/en-us/microsoft-edge/webview2/ From fastegal at openjdk.java.net Thu Aug 26 14:14:40 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 26 Aug 2021 14:14:40 GMT Subject: RFR: 8269871: CellEditEvent: must not throw NPE in accessors Message-ID: The issue is unguarded access to tablePosition though it might be null (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610) The fix is to check against null in each accessor. Also required to fix the default onEditCommit handlers in Tree/TableColumn to really cope with null TablePostion on the event. Added tests that failed/pass before/after the fix. Note that there was an old test (in Tree/TableColumnTest each), that failed after the fix because it expected the NPE. Fixed by removing the expected parameter. ------------- Commit messages: - 8269871: CellEditEvent: must not throw NPE in accessors Changes: https://git.openjdk.java.net/jfx/pull/611/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269871 Stats: 413 lines in 6 files changed: 393 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/611.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/611/head:pull/611 PR: https://git.openjdk.java.net/jfx/pull/611 From nlisker at gmail.com Thu Aug 26 14:40:22 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 26 Aug 2021 17:40:22 +0300 Subject: Reducing the size of JavaFX native image app In-Reply-To: <004501d79a7e$ab1de960$0159bc20$@email.cz> References: <004501d79a7e$ab1de960$0159bc20$@email.cz> Message-ID: > > the final exe size is approx. 60 MB > I assume that includes the JDK modules. JavaFX itself is not that large. Can you identify which modules you are packing (maybe with jdeps) and what are their sizes? On Thu, Aug 26, 2021 at 4:32 PM Jan Tosovsky wrote: > Dear All, > > when building a minimum JavaFX app [1] for Windows platform using > Gluon's maven plugin [2] incorporating GraalVM native image, the final exe > size is approx. 60 MB. It is quite large. I've been searching for the help > on StackOverflow [3], but there is no response for last 6 months. I am > afraid this can be considered as a major JavaFX cons comparing to other > desktop app frameworks (Flutter, Tauri). > > Do you see some room for reducing this size by some JavaFX engine tweaks in > a long term? There was some discussion JavaFX needs some Swing stuff > because > of printing support. If this part is refactored, would this have some > impact > on the app size? > Another option for Windows could be switching from embedded WebKit to MS > WebView2 [4]. Relying on web engine shipped with OS has definitely some > drawbacks, but the app size could be reduced signifficantly. > > I like JavaFX, it suits my needs, but producing executables of reasonable > size would make me (+ JavaFX community) happier. And could persuade those > undecided. > > Thanks, > > Jan > _________ > [1] https://github.com/drifted-in/hello-javafx > [2] https://github.com/gluonhq/gluonfx-maven-plugin > [3] > > https://stackoverflow.com/questions/66250311/reducing-the-size-of-javafx-nat > ive-image-app > > [4] https://docs.microsoft.com/en-us/microsoft-edge/webview2/ > > From phil at adonax.com Thu Aug 26 17:46:18 2021 From: phil at adonax.com (Phil Freihofner) Date: Thu, 26 Aug 2021 10:46:18 -0700 Subject: WebView and WebGL Message-ID: <3894f2f3-8a4f-0de5-0a0c-2010cca39fe8@adonax.com> All this recent, great activity on WebView makes me wonder: are there plans in place, or any teams actively working on enabling WebGL? I was recently shown, and tried myself to display|a site at webglsamples ||with no success. What are the hurdles? Are they mostly technical, or is it mostly a matter of getting the proper permissions and authorizations?| From jpereda at openjdk.java.net Thu Aug 26 18:45:34 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 26 Aug 2021 18:45:34 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 23:20:37 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update cssref.html > > modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Graphics.java line 70: > >> 68: context.updateCompositeMode(CompositeMode.CLEAR); >> 69: Paint oldPaint = getPaint(); >> 70: setPaint(Color.TRANSPARENT); // any color will do... > > Is this change necessary? If so, then the comment is probably wrong. Yes, the change is required. As it was, when using `-fx-page-fill: transparent`, a black area is visible the first time the content is rendered (until an event triggers a new pass and clears it). You are right, the comment is not valid anymore, as only Transparent will work after this PR. I'll remove it ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kevin.rushforth at oracle.com Thu Aug 26 18:55:06 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Aug 2021 11:55:06 -0700 Subject: WebView and WebGL In-Reply-To: <3894f2f3-8a4f-0de5-0a0c-2010cca39fe8@adonax.com> References: <3894f2f3-8a4f-0de5-0a0c-2010cca39fe8@adonax.com> Message-ID: It would be a lot of work, and not something we are likely to do any time soon. -- Kevin On 8/26/2021 10:46 AM, Phil Freihofner wrote: > All this recent, great activity on WebView makes me wonder: are there > plans in place, or any teams actively working on enabling WebGL? I was > recently shown, and tried myself to display|a site at webglsamples > ||with no success. What are the hurdles? Are they mostly technical, or > is it mostly a matter of getting the proper permissions and > authorizations?| From jpereda at openjdk.java.net Fri Aug 27 09:29:26 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 09:29:26 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 23:49:10 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update cssref.html > > modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 733: > >> 731: Color color = get(); >> 732: page.setBackgroundColor(color != null ? color.hashCode() : >> 733: DEFAULT_PAGE_FILL.hashCode()); > > This is relying on an undocumented, implementation detail. The current implementation of `Color::hashCode` happens to do what you want, but it is not specified. It seems safer to create a utility method to do this. Yes, that makes total sense. In fact, there was also the need to add a new [method](https://github.com/openjdk/jfx/pull/563/files#diff-b80bc720bf639cde38c5197a7619561221abcd34fb9ff7a933f4b932a1f36735R2579) in `WebPage` to read back the color from the int value, so I was thinking that it would be better to add a new method to `WebPage` like: public void setBackgroundColor(Color backgroundColor) { int int32Color = WebPage.getBackgroundInt32Color(backgroundColor); setBackgroundColor(int32Color); } private static int getBackgroundInt32Color(Color color) { // implementation similar to Color::hashCode } and from webView we could simply do: page.setBackgroundColor(color); Thoughts? ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Fri Aug 27 09:35:28 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 09:35:28 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> On Wed, 25 Aug 2021 23:23:00 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update cssref.html > > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 459: > >> 457: public void setClip(WCRectangle c) { >> 458: if (!isOpaque) { >> 459: clearRect((int)c.getX(), (int)c.getY(), > > Are you sure that there are no ill effects from clearing the rectangle every time a clip is set on a non-opaque context? This seems like a surprising side effect. Initially, this was needed when there was some level of transparency: when scrolling the old content was not cleared and you could see it at its old position. For the full transparency case, this is still the case, but for translucent colors (0 < opacity < 1) I can't reproduce it anymore, so I'll modify this to apply only `if (isTransparent) { clearRect(); }`. I don't see a performance drop because of this. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From fastegal at openjdk.java.net Fri Aug 27 11:23:34 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 27 Aug 2021 11:23:34 GMT Subject: RFR: 8269081: Tree/ListViewSkin: must remove flow on dispose Message-ID: <7RgCoBT0MIeJkxgYffwL6o1oNldqfqds75JgQoHInXk=.2de3fbf9-97be-4645-9795-cd0ae9257d89@github.com> left-over issue from cleanup of Tree/ListViewSkin: direct children that have been added by the skin must be removed in dispose fixed by removing the flow (which allowed to revert the previous cleanup of event handlers/cellfactory) added tests to verify - constant child count after replacing skin - no memory leak when switching skin while showing ------------- Commit messages: - 826908: Tree/ListViewSkin: must remove flow on dispose Changes: https://git.openjdk.java.net/jfx/pull/612/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=612&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269081 Stats: 90 lines in 3 files changed: 68 ins; 18 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/612.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/612/head:pull/612 PR: https://git.openjdk.java.net/jfx/pull/612 From jpereda at openjdk.java.net Fri Aug 27 11:50:27 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 11:50:27 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: Message-ID: <0StNbMYOTSlCR2qs0uL9vKIG7jkuuJ85Z-aqTdBw0ng=.e3bbdf73-ae85-4195-9c00-11cbb31198a0@github.com> On Wed, 25 Aug 2021 23:24:35 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update cssref.html > > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 615: > >> 613: twkSetTransparent(frameID, isBackgroundTransparent()); >> 614: twkSetBackgroundColor(frameID, backgroundColor); >> 615: repaintAll(); > > Is this needed unconditionally? Or only when the background is not opaque? This is required for any background color opacity level, but it is only needed when the background value changes (so it will be called a very limited number of times). The issue happens when changing the background color, if the current scroll position is not 0. The comment at this similar [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java#L565) still holds. > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 637: > >> 635: twkSetBackgroundColor(frameID, backgroundColor); >> 636: } >> 637: repaintAll(); > > Same question as above. Same answer as above. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From michaelstrau2 at gmail.com Fri Aug 27 12:19:32 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 27 Aug 2021 14:19:32 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> Message-ID: I don't think this is a bug in either JavaFX or ReactFX. See my comment here: https://github.com/FXMisc/Flowless/pull/98#discussion_r697393606 From kcr at openjdk.java.net Fri Aug 27 13:09:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 Aug 2021 13:09:30 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> References: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> Message-ID: <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> On Fri, 27 Aug 2021 09:32:24 GMT, Jose Pereda wrote: >> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 459: >> >>> 457: public void setClip(WCRectangle c) { >>> 458: if (!isOpaque) { >>> 459: clearRect((int)c.getX(), (int)c.getY(), >> >> Are you sure that there are no ill effects from clearing the rectangle every time a clip is set on a non-opaque context? This seems like a surprising side effect. > > Initially, this was needed when there was some level of transparency: when scrolling the old content was not cleared and you could see it at its old position. > > For the full transparency case, this is still the case, but for translucent colors (0 < opacity < 1) I can't reproduce it anymore, so I'll modify this to apply only `if (isTransparent) { clearRect(); }`. > > I don't see a performance drop because of this. I'm more worried about correctness than performance. Setting a clip does not necessarily imply that the clipped region should be cleared. So this feels a bit like a workaround for a missing `clearRect` elsewhere. I wonder if there is code somewhere that assumes that if the fill color is fully transparent it can skip the call to `clearRect`? >> modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 733: >> >>> 731: Color color = get(); >>> 732: page.setBackgroundColor(color != null ? color.hashCode() : >>> 733: DEFAULT_PAGE_FILL.hashCode()); >> >> This is relying on an undocumented, implementation detail. The current implementation of `Color::hashCode` happens to do what you want, but it is not specified. It seems safer to create a utility method to do this. > > Yes, that makes total sense. > > In fact, there was also the need to add a new [method](https://github.com/openjdk/jfx/pull/563/files#diff-b80bc720bf639cde38c5197a7619561221abcd34fb9ff7a933f4b932a1f36735R2579) in `WebPage` to read back the color from the int value, so I was thinking that it would be better to add a new method to `WebPage` like: > > > public void setBackgroundColor(Color backgroundColor) { > int int32Color = WebPage.getBackgroundInt32Color(backgroundColor); > setBackgroundColor(int32Color); > } > > private static int getBackgroundInt32Color(Color color) { > // implementation similar to Color::hashCode > } > > and from webView we could simply do: > > page.setBackgroundColor(color); > > > Thoughts? Yes, this seems a good solution. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Fri Aug 27 13:42:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 Aug 2021 13:42:26 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > Michael Strau? 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' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows @tiainen or @arapte can one of you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From kcr at openjdk.java.net Fri Aug 27 14:18:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 Aug 2021 14:18:26 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 16:29:11 GMT, Nir Lisker wrote: > Added convenience factory factory methods for Background and Border. The API looks good. I left a couple comments on the javadoc. I presume you will add some unit tests? modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 362: > 360: * @implNote this call is equivalent to > 361: *

> 362: * {@code new Background(new BackgroundFill(fill, null, null));} This should either be `@implSpec` or part of the API spec (no tag), since it's more than just a note. Also, the text should start with a capital letter, since the body of an `implSpec` section (along with `implNote` and `apiNote`) is one or more paragraphs. In this case a single paragraph might be better: @implSpec This call is equivalent to {@code new Background(new BackgroundFill(fill, null, null));}. modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 364: > 362: * {@code new Background(new BackgroundFill(fill, null, null));} > 363: * @param fill the fill of the background > 364: * @return a new background of the given fill Need to add `@since 18` modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 400: > 398: * {@code new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, null));} > 399: * @param stroke the stroke of the border > 400: * @return a new border of the given stroke Same comments about the javadoc as above. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From jpereda at openjdk.java.net Fri Aug 27 15:41:59 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 15:41:59 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v5] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Color to int32 conversion and more changes based on feedback ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/3a75240c..5c7567b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=03-04 Stats: 30 lines in 3 files changed: 13 ins; 5 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Fri Aug 27 15:48:28 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 15:48:28 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> References: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> Message-ID: On Fri, 27 Aug 2021 13:06:18 GMT, Kevin Rushforth wrote: >> Yes, that makes total sense. >> >> In fact, there was also the need to add a new [method](https://github.com/openjdk/jfx/pull/563/files#diff-b80bc720bf639cde38c5197a7619561221abcd34fb9ff7a933f4b932a1f36735R2579) in `WebPage` to read back the color from the int value, so I was thinking that it would be better to add a new method to `WebPage` like: >> >> >> public void setBackgroundColor(Color backgroundColor) { >> int int32Color = WebPage.getBackgroundInt32Color(backgroundColor); >> setBackgroundColor(int32Color); >> } >> >> private static int getBackgroundInt32Color(Color color) { >> // implementation similar to Color::hashCode >> } >> >> and from webView we could simply do: >> >> page.setBackgroundColor(color); >> >> >> Thoughts? > > Yes, this seems a good solution. I've pushed it. Now we have these three public methods: public void setBackgroundColor(long frameID, int backgroundColor); public void setBackgroundColor(int backgroundColor); public void setBackgroundColor(Color backgroundColor); but we only call the last one from WebView to call the second one from WebPage. I don't see any call done to the first one. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kevin.rushforth at oracle.com Fri Aug 27 16:58:22 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 09:58:22 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: <999a48e4-ec31-d5a5-aded-0049fbcb00c0@gmail.com> References: <999a48e4-ec31-d5a5-aded-0049fbcb00c0@gmail.com> Message-ID: <9d5bb63f-28ec-bf97-1e67-46874c950e39@oracle.com> As more of a general comment (not just to you), I wasn't really asking for a laundry list of bugs or enhancements that people would like to see fixed. Rather, I was thinking about the things that were already "in flight" or "on the radar", so we could see about moving some of them forward. Having said that, the first step for any of the bugs on yours or anyone else's wish list would be to files a bug in JBS with a reproducible test case. Some of the ones listed below already have a bug filed, but most do not. -- Kevin On 8/4/2021 10:05 AM, Ty Young wrote: > You want a list of bugs that could be fixed? Today's your lucky day! > > > * Resizing a JavaFX window under Linux (still) causes graphical > glitches, needing -Dprism.forceUploadingPainter=true or, IIRC, > software rendering to "fix". > > > * Resizing ALSO causes graphical glitching on the bottom and right > sides on both Windows AND Linux. > > > * Resizing an app with a TableView in view results in the TableView's > integrated scrollbars flickering in and out of existence when there is > plenty of space left. The less UI content there is, the less this is > likely to happen - but it absolutely does happen with *just* a > TableView as the root node, you gotta play with it. > > > * Resizing the application from the left causes UI jitter. > > > * JavaFX in general seems to have trouble keeping up with user > resizing. Rapidly resizing an application with a DividerPane(TreeView > left, content right) results in inconsistent positioning than if it > was done slowly, in the very least. > > > * Alt tabbing with a UI component being selected(Slider thumb, > scrollbar) results in that component's color being stuck in whatever > color is the CSS selected state. > > > * You can middle and right click drag a slider thumb and scroll bars, > which does not trigger a CSS state change, which is not consistent > with MenuBar items. > > > * JavaFX does not seem to calculate the size of a GridPane or TilePane > with elements correctly. This results in content in ScrollPanes that > is clearly larger in height than the viewport but ScrollPane does not > show its scrollbars - only mouse wheel works without forcing the > scrollbars to always show or transition state bugs when putting a > GridPane/TilePane inside a TitlePane(or maybe it's TilePane -> > TitlePane -> TilePane that's the issue? No clue.) > > > * XY Chart data that is off screen (-1, -1) has lines drawn to them > despite being... off screen. Bug or feature? > > > * Setting the Y axis side to Side.RIGHT causes a white space with > custom CSS: https://imgur.com/a/4P1Oj1Q. > > > Might be missing some. > > > A few features, while I'm here: > > > * API property to force a TableView's height to be the exact amount > needed to display its headers and all its rows. > > > * API to disable TableView's scrollbars completely. > > > * A late "showing" property for when the application has been shown to > the user and all first viewing UI components have had their sizes > calculated and are being displayed, if it doesn't exist already and > I'm completely blind. > > > On 7/30/21 7:56 AM, Kevin Rushforth wrote: >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug >> fixes and enhancement requests for JavaFX 18. It's the summer, so >> there may be delays as some people are out at various times >> (including me), but I would like to get some of the outstanding >> enhancement requests moving over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the >> binary incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to >> proceed) >> >> * Undecorated interactive stage style (still in early discussion, but >> the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on >> openjfx-dev rather than a reply to this thread. >> >> -- Kevin >> >> From kevin.rushforth at oracle.com Fri Aug 27 16:58:57 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 09:58:57 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl> References: <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl> Message-ID: This is a rather large addition to the properties API, but there seems to be enough interest in it that it might be worth getting to the point of a concrete proposal that we could discuss on the list. I wouldn't expect it for JavaFX 18, since it will almost certainly take longer than that. Which makes this a good time to remind folks that the development model under the six month release cycle is such that features go in when ready, rather than necessarily being tied to a specific release. -- Kevin On 8/4/2021 3:25 PM, John Hendrikx wrote: > Perhaps: > > Fluent bindings for ObservableValue > https://github.com/openjdk/jfx/pull/434 > > It was received well I think, and there was some interest from Nir > Lisker to work on a proposal. > > --John > > On 30/07/2021 14:56, Kevin Rushforth wrote: >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >> and enhancement requests for JavaFX 18. It's the summer, so there may be >> delays as some people are out at various times (including me), but I >> would like to get some of the outstanding enhancement requests moving >> over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the binary >> incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to >> proceed) >> >> * Undecorated interactive stage style (still in early discussion, but >> the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on openjfx-dev >> rather than a reply to this thread. >> >> -- Kevin >> >> From kevin.rushforth at oracle.com Fri Aug 27 16:59:22 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 09:59:22 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> Message-ID: <1d5b2bd6-31a7-3506-e761-03ad409c362d@oracle.com> Yes, it would be great to finally solve this one. It would need someone who is willing and able to to drive it, though. -- Kevin On 8/4/2021 2:58 AM, Jeanette Winzenburg wrote: > > my suggestion would be the longstanding commit-edit-on-focus-lost - > solved by an enhancement to the editing api on virtualized controls > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug >> fixes and enhancement requests for JavaFX 18. It's the summer, so >> there may be delays as some people are out at various times >> (including me), but I would like to get some of the outstanding >> enhancement requests moving over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the >> binary incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to >> proceed) >> >> * Undecorated interactive stage style (still in early discussion, but >> the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on >> openjfx-dev rather than a reply to this thread. >> >> -- Kevin > > > From kevin.rushforth at oracle.com Fri Aug 27 16:59:35 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 09:59:35 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> Message-ID: <5e3139cb-6b16-3102-3793-91e920664a30@oracle.com> We aren't currently planning to do this any time soon, although there does seem to be plenty of interest in the system tray support. -- Kevin On 8/4/2021 7:47 AM, Scott Palmer wrote: > +1 to that. > > I would also like to see some progress with system tray support and microphone & webcam access. > > Scott > >> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg wrote: >> >> ? >> my suggestion would be the longstanding commit-edit-on-focus-lost - solved by an enhancement to the editing api on virtualized controls >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. >>> >>> Specifically, I'd like to see the following proceed: >>> >>> * Transparent backgrounds in WebView >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> PR: https://github.com/openjdk/jfx/pull/563 >>> >>> * Add DirectionalLight >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> PR: https://github.com/openjdk/jfx/pull/548 >>> >>> * CSS pseudoclasses :focus-visible and :focus-within >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> PR: https://github.com/openjdk/jfx/pull/475 >>> >>> * Improve property system to facilitate correct usage (minus the binary incompatible API change) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>> >>> And maybe the following: >>> >>> * Add CSS themes as a first-class concept (need a consensus on how to proceed) >>> >>> * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) >>> >>> There are probably others I'm forgetting. >>> >>> Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. >>> >>> -- Kevin >> >> From kevin.rushforth at oracle.com Fri Aug 27 16:59:46 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 09:59:46 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: <8060E8A0-B9E7-4BFE-B072-6821C17D1D4C@gmail.com> References: <8060E8A0-B9E7-4BFE-B072-6821C17D1D4C@gmail.com> Message-ID: <1dbe0452-7e41-6793-bf1b-b6ba29e2ae49@oracle.com> That's an interesting idea, although it's not on our radar. This might be hard to do in a platform-independent way. It's not likely something we would do ourselves, so it would need an owner and we would need to discuss -- Kevin On 8/11/2021 1:10 PM, Dirk Lemmermann wrote: > Frosted glas / blurred background for stages! > >> Am 11.08.2021 um 22:07 schrieb Thiago Milczarek Say?o : >> >> Hi, >> >> One feature I will probably submit is touch events on Linux. >> >> Cheers. >> >> Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth < >> kevin.rushforth at oracle.com> escreveu: >> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >>> and enhancement requests for JavaFX 18. It's the summer, so there may be >>> delays as some people are out at various times (including me), but I >>> would like to get some of the outstanding enhancement requests moving >>> over the next few weeks. >>> >>> Specifically, I'd like to see the following proceed: >>> >>> * Transparent backgrounds in WebView >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> PR: https://github.com/openjdk/jfx/pull/563 >>> >>> * Add DirectionalLight >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> PR: https://github.com/openjdk/jfx/pull/548 >>> >>> * CSS pseudoclasses :focus-visible and :focus-within >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> PR: https://github.com/openjdk/jfx/pull/475 >>> >>> * Improve property system to facilitate correct usage (minus the binary >>> incompatible API change) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>> >>> And maybe the following: >>> >>> * Add CSS themes as a first-class concept (need a consensus on how to >>> proceed) >>> >>> * Undecorated interactive stage style (still in early discussion, but >>> the concept looks interesting and useful) >>> >>> There are probably others I'm forgetting. >>> >>> Each of the above should be discussed in their own thread on openjfx-dev >>> rather than a reply to this thread. >>> >>> -- Kevin >>> >>> >>> From jpereda at openjdk.java.net Fri Aug 27 17:01:00 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 17:01:00 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Use color to int32 converter instead of hash ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/5c7567b7..941ba714 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From kevin.rushforth at oracle.com Fri Aug 27 17:06:00 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 10:06:00 -0700 Subject: [External] : Re: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: Definitely agree with the first one. Getting rid of the vestigial applet code in the implementation would be good cleanup. As for the second, I like the idea of deprecating the gtk2 support "for removal" (it's not API, but conceptually it similar). Since gtk2 is no longer supported by any Linux distro I don't see any reason to keep maintaining gtk2. The path for doing this would be to print a "deprecated for removal" warning message when the gtk2 library it is loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. I'll file an RFE for the first part (the deprecation for removal). Wayland has already been discussed in another thread. -- Kevin On 8/9/2021 2:39 PM, Thiago Milczarek Say?o wrote: > I would add: > > * Remove deprecated applets/web start code; > * Mark for removal or remove Gtk2 support . Gtk3 has been around for > 10 years. > * Work to support wayland, as it will probably be the default in the > future. > > - Thiago. > > > Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth > > escreveu: > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug > fixes > and enhancement requests for JavaFX 18. It's the summer, so there > may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > PR: https://github.com/openjdk/jfx/pull/563 > > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > PR: https://github.com/openjdk/jfx/pull/548 > > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > > PR: https://github.com/openjdk/jfx/pull/475 > > > * Improve property system to facilitate correct usage (minus the > binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > PR: https://github.com/openjdk/jfx/pull/590 > > (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on > openjfx-dev > rather than a reply to this thread. > > -- Kevin > > From jpereda at openjdk.java.net Fri Aug 27 17:37:28 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 27 Aug 2021 17:37:28 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> References: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> Message-ID: <93SV4Qk57pLyW711Z7cxfOP6qbN6rBOfdJR_WXHiVR8=.611ad06d-f2d2-4a64-96cd-16a729b3632c@github.com> On Fri, 27 Aug 2021 13:05:24 GMT, Kevin Rushforth wrote: >> Initially, this was needed when there was some level of transparency: when scrolling the old content was not cleared and you could see it at its old position. >> >> For the full transparency case, this is still the case, but for translucent colors (0 < opacity < 1) I can't reproduce it anymore, so I'll modify this to apply only `if (isTransparent) { clearRect(); }`. >> >> I don't see a performance drop because of this. > > I'm more worried about correctness than performance. Setting a clip does not necessarily imply that the clipped region should be cleared. So this feels a bit like a workaround for a missing `clearRect` elsewhere. I wonder if there is code somewhere that assumes that if the fill color is fully transparent it can skip the call to `clearRect`? I guess the assumption might be the other way around? Since the fill color was not transparent, there was no need to clear the area, when rendering the same solid rect at the new position? If you check this [comment](https://bugs.openjdk.java.net/browse/JDK-8090547?focusedCommentId=13808421&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13808421), there is already a mention that `WCPageBackBufferImpl::copyArea` doesn't care about the alpha channel. The proposed patch: texture.createGraphics().clearQuad(x+dx, y+dy, x+dx+w, y+dy+h); could work if we could apply it conditionally only for alpha == 0 (or maybe also for alpha < 1). My current approach with `clearRect` ultimately calls `clearQuad`, so both might be doing the same after all. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From nlisker at openjdk.java.net Fri Aug 27 17:40:48 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 27 Aug 2021 17:40:48 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: > Added convenience factory factory methods for Background and Border. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Corrected comment tags ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/610/files - new: https://git.openjdk.java.net/jfx/pull/610/files/33ef548a..bb54859e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=00-01 Stats: 8 lines in 2 files changed: 2 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/610.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/610/head:pull/610 PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Fri Aug 27 17:48:31 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 27 Aug 2021 17:48:31 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 14:15:06 GMT, Kevin Rushforth wrote: > I presume you will add some unit tests? Yes, when the implementation is settled upon. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From johan.vos at gluonhq.com Fri Aug 27 18:27:29 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 27 Aug 2021 20:27:29 +0200 Subject: [External] : Re: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: I agree with both suggestions (also with the Wayland one, but that indeed belongs in a different thread -- I'm working on that one locally). - Johan On Fri, Aug 27, 2021 at 7:07 PM Kevin Rushforth wrote: > Definitely agree with the first one. Getting rid of the vestigial applet > code in the implementation would be good cleanup. > > As for the second, I like the idea of deprecating the gtk2 support "for > removal" (it's not API, but conceptually it similar). Since gtk2 is no > longer supported by any Linux distro I don't see any reason to keep > maintaining gtk2. The path for doing this would be to print a > "deprecated for removal" warning message when the gtk2 library it is > loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. I'll > file an RFE for the first part (the deprecation for removal). > > Wayland has already been discussed in another thread. > > -- Kevin > > > > On 8/9/2021 2:39 PM, Thiago Milczarek Say?o wrote: > > I would add: > > > > * Remove deprecated applets/web start code; > > * Mark for removal or remove Gtk2 support . Gtk3 has been around for > > 10 years. > > * Work to support wayland, as it will probably be the default in the > > future. > > > > - Thiago. > > > > > > Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth > > > > escreveu: > > > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug > > fixes > > and enhancement requests for JavaFX 18. It's the summer, so there > > may be > > delays as some people are out at various times (including me), but I > > would like to get some of the outstanding enhancement requests moving > > over the next few weeks. > > > > Specifically, I'd like to see the following proceed: > > > > * Transparent backgrounds in WebView > > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > > > PR: https://github.com/openjdk/jfx/pull/563 > > < > https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/563__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKgtBVjHVs$ > > > > > > * Add DirectionalLight > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > > > PR: https://github.com/openjdk/jfx/pull/548 > > < > https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/548__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKgiWYnbRD$ > > > > > > * CSS pseudoclasses :focus-visible and :focus-within > > https://bugs.openjdk.java.net/browse/JDK-8268225 > > > > PR: https://github.com/openjdk/jfx/pull/475 > > < > https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/475__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKgreYERKS$ > > > > > > * Improve property system to facilitate correct usage (minus the > > binary > > incompatible API change) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > > > PR: https://github.com/openjdk/jfx/pull/590 > > < > https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/590__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKggImJHfK$ > > > > (Draft) > > > > And maybe the following: > > > > * Add CSS themes as a first-class concept (need a consensus on how to > > proceed) > > > > * Undecorated interactive stage style (still in early discussion, but > > the concept looks interesting and useful) > > > > There are probably others I'm forgetting. > > > > Each of the above should be discussed in their own thread on > > openjfx-dev > > rather than a reply to this thread. > > > > -- Kevin > > > > > > From kevin.rushforth at oracle.com Fri Aug 27 18:39:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 11:39:42 -0700 Subject: [External] : Re: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <9060b3bb-5de9-57d5-a320-0450b544bf00@oracle.com> Thanks. As a follow-on though, it seems possible that not having GTK 2 support might help in our efforts to support GTK 4 or Wayland, but maybe that's wishful thinking on my part. -- Kevin On 8/27/2021 11:27 AM, Johan Vos wrote: > I agree with both suggestions (also with the Wayland one, but that > indeed belongs in a different thread -- I'm working on that one locally). > > - Johan > > > On Fri, Aug 27, 2021 at 7:07 PM Kevin Rushforth > > wrote: > > Definitely agree with the first one. Getting rid of the vestigial > applet > code in the implementation would be good cleanup. > > As for the second, I like the idea of deprecating the gtk2 support > "for > removal" (it's not API, but conceptually it similar). Since gtk2 > is no > longer supported by any Linux distro I don't see any reason to keep > maintaining gtk2. The path for doing this would be to print a > "deprecated for removal" warning message when the gtk2 library it is > loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. I'll > file an RFE for the first part (the deprecation for removal). > > Wayland has already been discussed in another thread. > > -- Kevin > > > > On 8/9/2021 2:39 PM, Thiago Milczarek Say?o wrote: > > I would add: > > > > * Remove deprecated applets/web start code; > > * Mark for removal or remove Gtk2 support . Gtk3 has been around > for > > 10 years. > > * Work to support wayland, as it will probably be the default in > the > > future. > > > > - Thiago. > > > > > > Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth > > > >> escreveu: > > > >? ? ?Now that JavaFX 17 is in RDP2, we can turn more attention to bug > >? ? ?fixes > >? ? ?and enhancement requests for JavaFX 18. It's the summer, so > there > >? ? ?may be > >? ? ?delays as some people are out at various times (including > me), but I > >? ? ?would like to get some of the outstanding enhancement > requests moving > >? ? ?over the next few weeks. > > > >? ? ?Specifically, I'd like to see the following proceed: > > > >? ? ?* Transparent backgrounds in WebView > >? ? ?JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > >? ? ? > > >? ? ?PR: https://github.com/openjdk/jfx/pull/563 > > >? ? > ? > > > > >? ? ?* Add DirectionalLight > >? ? ?JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > >? ? ? > > >? ? ?PR: https://github.com/openjdk/jfx/pull/548 > > >? ? > ? > > > > >? ? ?* CSS pseudoclasses :focus-visible and :focus-within > > https://bugs.openjdk.java.net/browse/JDK-8268225 > > >? ? ? > > >? ? ?PR: https://github.com/openjdk/jfx/pull/475 > > >? ? > ? > > > > >? ? ?* Improve property system to facilitate correct usage (minus the > >? ? ?binary > >? ? ?incompatible API change) > >? ? ?JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > >? ? ? > > >? ? ?PR: https://github.com/openjdk/jfx/pull/590 > > >? ? > ? > > >? ? ?(Draft) > > > >? ? ?And maybe the following: > > > >? ? ?* Add CSS themes as a first-class concept (need a consensus > on how to > >? ? ?proceed) > > > >? ? ?* Undecorated interactive stage style (still in early > discussion, but > >? ? ?the concept looks interesting and useful) > > > >? ? ?There are probably others I'm forgetting. > > > >? ? ?Each of the above should be discussed in their own thread on > >? ? ?openjfx-dev > >? ? ?rather than a reply to this thread. > > > >? ? ?-- Kevin > > > > > From kevin.rushforth at oracle.com Fri Aug 27 18:47:30 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 11:47:30 -0700 Subject: [External] : Re: Enhancements for JavaFX 18 In-Reply-To: <9060b3bb-5de9-57d5-a320-0450b544bf00@oracle.com> References: <9060b3bb-5de9-57d5-a320-0450b544bf00@oracle.com> Message-ID: Btw, I filed the following Enhancement for deprecating GTK 2 for removal: https://bugs.openjdk.java.net/browse/JDK-8273089 And I dug up the bug I had previously filed to remove the unused applet implementation code: https://bugs.openjdk.java.net/browse/JDK-8201538 -- Kevin On 8/27/2021 11:39 AM, Kevin Rushforth wrote: > Thanks. As a follow-on though, it seems possible that not having GTK 2 > support might help in our efforts to support GTK 4 or Wayland, but > maybe that's wishful thinking on my part. > > -- Kevin > > > > On 8/27/2021 11:27 AM, Johan Vos wrote: >> I agree with both suggestions (also with the Wayland one, but that >> indeed belongs in a different thread -- I'm working on that one >> locally). >> >> - Johan >> >> >> On Fri, Aug 27, 2021 at 7:07 PM Kevin Rushforth >> > wrote: >> >> Definitely agree with the first one. Getting rid of the vestigial >> applet >> code in the implementation would be good cleanup. >> >> As for the second, I like the idea of deprecating the gtk2 >> support "for >> removal" (it's not API, but conceptually it similar). Since gtk2 >> is no >> longer supported by any Linux distro I don't see any reason to keep >> maintaining gtk2. The path for doing this would be to print a >> "deprecated for removal" warning message when the gtk2 library it is >> loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. >> I'll >> file an RFE for the first part (the deprecation for removal). >> >> Wayland has already been discussed in another thread. >> >> -- Kevin >> >> >> >> On 8/9/2021 2:39 PM, Thiago Milczarek Say?o wrote: >> > I would add: >> > >> > * Remove deprecated applets/web start code; >> > * Mark for removal or remove Gtk2 support . Gtk3 has been >> around for >> > 10 years. >> > * Work to support wayland, as it will probably be the default >> in the >> > future. >> > >> > - Thiago. >> > >> > >> > Em sex., 30 de jul. de 2021 ?s 09:59, Kevin Rushforth >> > >> > >> escreveu: >> > >> >? ? ?Now that JavaFX 17 is in RDP2, we can turn more attention >> to bug >> >? ? ?fixes >> >? ? ?and enhancement requests for JavaFX 18. It's the summer, so >> there >> >? ? ?may be >> >? ? ?delays as some people are out at various times (including >> me), but I >> >? ? ?would like to get some of the outstanding enhancement >> requests moving >> >? ? ?over the next few weeks. >> > >> >? ? ?Specifically, I'd like to see the following proceed: >> > >> >? ? ?* Transparent backgrounds in WebView >> >? ? ?JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> >> >? ? ?> > >> >? ? ?PR: https://github.com/openjdk/jfx/pull/563 >> >> >? ? >> ?> > >> > >> >? ? ?* Add DirectionalLight >> >? ? ?JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> >> >? ? ?> > >> >? ? ?PR: https://github.com/openjdk/jfx/pull/548 >> >> >? ? >> ?> > >> > >> >? ? ?* CSS pseudoclasses :focus-visible and :focus-within >> > https://bugs.openjdk.java.net/browse/JDK-8268225 >> >> >? ? ?> > >> >? ? ?PR: https://github.com/openjdk/jfx/pull/475 >> >> >? ? >> ?> > >> > >> >? ? ?* Improve property system to facilitate correct usage >> (minus the >> >? ? ?binary >> >? ? ?incompatible API change) >> >? ? ?JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> >> >? ? ?> > >> >? ? ?PR: https://github.com/openjdk/jfx/pull/590 >> >> >? ? >> ?> > >> >? ? ?(Draft) >> > >> >? ? ?And maybe the following: >> > >> >? ? ?* Add CSS themes as a first-class concept (need a consensus >> on how to >> >? ? ?proceed) >> > >> >? ? ?* Undecorated interactive stage style (still in early >> discussion, but >> >? ? ?the concept looks interesting and useful) >> > >> >? ? ?There are probably others I'm forgetting. >> > >> >? ? ?Each of the above should be discussed in their own thread on >> >? ? ?openjfx-dev >> >? ? ?rather than a reply to this thread. >> > >> >? ? ?-- Kevin >> > >> > >> > From fastegal at swingempire.de Fri Aug 27 21:47:12 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 27 Aug 2021 23:47:12 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: <1d5b2bd6-31a7-3506-e761-03ad409c362d@oracle.com> References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> <1d5b2bd6-31a7-3506-e761-03ad409c362d@oracle.com> Message-ID: <20210827234712.Horde.3bIwVQUim_QAKBLSsv73Yw8@webmail.df.eu> Zitat von Kevin Rushforth : > Yes, it would be great to finally solve this one. It would need > someone who is willing and able to to drive it, though. > > -- Kevin Well, I think myself being both - with a little help of my friends ;) -- Jeanette > > > On 8/4/2021 2:58 AM, Jeanette Winzenburg wrote: >> >> my suggestion would be the longstanding commit-edit-on-focus-lost - >> solved by an enhancement to the editing api on virtualized controls >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug >>> fixes and enhancement requests for JavaFX 18. It's the summer, so >>> there may be delays as some people are out at various times >>> (including me), but I would like to get some of the outstanding >>> enhancement requests moving over the next few weeks. >>> >>> Specifically, I'd like to see the following proceed: >>> >>> * Transparent backgrounds in WebView >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> PR: https://github.com/openjdk/jfx/pull/563 >>> >>> * Add DirectionalLight >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> PR: https://github.com/openjdk/jfx/pull/548 >>> >>> * CSS pseudoclasses :focus-visible and :focus-within >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> PR: https://github.com/openjdk/jfx/pull/475 >>> >>> * Improve property system to facilitate correct usage (minus the >>> binary incompatible API change) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>> >>> And maybe the following: >>> >>> * Add CSS themes as a first-class concept (need a consensus on how >>> to proceed) >>> >>> * Undecorated interactive stage style (still in early discussion, >>> but the concept looks interesting and useful) >>> >>> There are probably others I'm forgetting. >>> >>> Each of the above should be discussed in their own thread on >>> openjfx-dev rather than a reply to this thread. >>> >>> -- Kevin >> >> >> From almatvee at openjdk.java.net Fri Aug 27 22:11:02 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 27 Aug 2021 22:11:02 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app Message-ID: - Added FXMediaPlayer test application. - This app uses all media APIs and very handy in verifying media builds during development. - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. ------------- Commit messages: - 8270107: Open source FXMediaPlayer test app Changes: https://git.openjdk.java.net/jfx/pull/613/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=613&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270107 Stats: 5970 lines in 26 files changed: 5970 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/613.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/613/head:pull/613 PR: https://git.openjdk.java.net/jfx/pull/613 From kevin.rushforth at oracle.com Fri Aug 27 22:17:08 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 Aug 2021 15:17:08 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: <20210827234712.Horde.3bIwVQUim_QAKBLSsv73Yw8@webmail.df.eu> References: <20210804115813.Horde.KLuWd-Zc_6E6PZdYxahKvA2@webmail.df.eu> <1d5b2bd6-31a7-3506-e761-03ad409c362d@oracle.com> <20210827234712.Horde.3bIwVQUim_QAKBLSsv73Yw8@webmail.df.eu> Message-ID: <3ce98aad-5f84-e2a4-1167-edc41bf90712@oracle.com> On 8/27/2021 2:47 PM, Jeanette Winzenburg wrote: > > Zitat von Kevin Rushforth : > >> Yes, it would be great to finally solve this one. It would need >> someone who is willing and able to to drive it, though. >> >> -- Kevin > > Well, I think myself being both - with a little help of my friends ;) Excellent! I was hoping you might volunteer for this, but didn't want to presume. -- Kevin > > -- Jeanette >> >> >> On 8/4/2021 2:58 AM, Jeanette Winzenburg wrote: >>> >>> my suggestion would be the longstanding commit-edit-on-focus-lost - >>> solved by an enhancement to the editing api on virtualized controls >>> >>> -- Jeanette >>> >>> Zitat von Kevin Rushforth : >>> >>>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug >>>> fixes and enhancement requests for JavaFX 18. It's the summer, so >>>> there may be delays as some people are out at various times >>>> (including me), but I would like to get some of the outstanding >>>> enhancement requests moving over the next few weeks. >>>> >>>> Specifically, I'd like to see the following proceed: >>>> >>>> * Transparent backgrounds in WebView >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>>> PR: https://github.com/openjdk/jfx/pull/563 >>>> >>>> * Add DirectionalLight >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>>> PR: https://github.com/openjdk/jfx/pull/548 >>>> >>>> * CSS pseudoclasses :focus-visible and :focus-within >>>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>>> PR: https://github.com/openjdk/jfx/pull/475 >>>> >>>> * Improve property system to facilitate correct usage (minus the >>>> binary incompatible API change) >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>>> >>>> And maybe the following: >>>> >>>> * Add CSS themes as a first-class concept (need a consensus on how >>>> to proceed) >>>> >>>> * Undecorated interactive stage style (still in early discussion, >>>> but the concept looks interesting and useful) >>>> >>>> There are probably others I'm forgetting. >>>> >>>> Each of the above should be discussed in their own thread on >>>> openjfx-dev rather than a reply to this thread. >>>> >>>> -- Kevin >>> >>> >>> > > > From kcr at openjdk.java.net Fri Aug 27 23:36:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 27 Aug 2021 23:36:26 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. By way of background this is a lightly cleaned up version of a closed-source test program that we are open sourcing in order to facilitate testing various media features. Even though it is a test program, I'd like a second pair of eyes on it. ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From nlisker at gmail.com Fri Aug 27 23:56:35 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 28 Aug 2021 02:56:35 +0300 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: <2f6ee873-423f-a798-ce23-be3064e77273@oracle.com> References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> <2f6ee873-423f-a798-ce23-be3064e77273@oracle.com> Message-ID: The problem I have with additional booleans is that they are not reflected in the transitions, and to a lesser extent in the transforms. I'm going to have to write an implementation and test it out to know how well this works and how much trouble it really saves. And while we could use NaN as an out of band value meaning "computed", that > still runs into the problem of allowing for the odd case where X is > computed and Y is specified. I don't see this as a problem. Each direction is independent. The bigger problem I see is the surprise factor of NaN as a computed value. On Tue, Aug 24, 2021 at 6:16 PM Kevin Rushforth wrote: > I definitely don't like having a "magic" initial value that can't be > reset, so that won't work. And while we could use NaN as an out of band > value meaning "computed", that still runs into the problem of allowing for > the odd case where X is computed and Y is specified. > > If we do go with the idea of allowing the coordinates to be a percentage > of the bounding box, with 0.5 as the default, then we could be informed by > what ImagePattern does. It defines a "proportional" property as follows: > > "a boolean that indicates whether start and end locations are proportional > or absolute. If this flag is true, the two end points are defined in a > coordinate space where coordinates in the range [0..1] are scaled to map > onto the bounds of the shape that the pattern fills. If this flag is false, > then the coordinates are specified in the local coordinate system of the > node." > > That's basically what we are doing if we go with Michael's idea. So if we > do this, the two boolean properties could be named something like > scalePivotProportional and rotatePivotProportional, with a default of true. > > What do you think? > > -- Kevin > > > > On 8/23/2021 7:25 PM, Michael Strau? wrote: > > I think normalized coordinates are a very natural fit for the > definition of a pivot point, which is why the current default value is > an implicitly-specified normalized coordinate. Adding general-purpose > coordinate transformations here feels like bringing a sledgehammer to > crack a nut. > > Having a property with an automagically updated "initial" value is > quite non-standard behavior for properties. It would appear as if the > property was bound, yet there's no binding. That's markedly different > from a Transition's 'from' and 'to' properties, which are standard > properties with normal behavior. A running transition doesn't bind to > those properties, it uses a snapshot of their values when the > transition starts. > > > On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker wrote: > > Now I understand what you meant. However, the concept of normalized coordinates does not appear anywhere in JavaFX (at least not in these contexts). I still think that coordinate transformations should be handled via dedicated means, like coordinate system transformations are. Maybe when we work on mapped bindings (I forgot that I need to review that) this pain point will be alleviated. > > Kevin, what if we only set the initial value of the pivot (doesn't matter what the implementation detail is) to the center of the node for backwards compatibility, but if the developer changes it to a custom value then it's on them to compute the value again if they want to go back? The default behavior remains. > Another relevant point is that Transitions do something similar with their from_, to_ and by_ methods. They start with Double.NaN to signal that the value should be ignored. While the developer can reset the value to NaN, it is not something that is likely to happen during, say, an interpolation or as a result of a binding. > > > > From jvos at openjdk.java.net Sat Aug 28 13:27:26 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 28 Aug 2021 13:27:26 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. That's great. I agree a global media sample would be an excellent improvement for testing (regression on) media. I notice there are a number of netbeans-impl files, which is ok for me, unless we want to avoid ide-specific impl files? It would be nice if this sample can leverage openjfx-global properties, i.e. I see it now has java source level set to 1.9. Rather than requesting many changes (e.g. bump java version) before it is in the repository, I think it would be good to do some sanity tests on the different platforms and then include it. I plan to do that later this weekend. ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From michaelstrau2 at gmail.com Sat Aug 28 14:09:30 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 28 Aug 2021 16:09:30 +0200 Subject: CSS themes update In-Reply-To: References: Message-ID: A point for discussion: Rather than re-using the setUserAgentStylesheet(String) API for themes, another option would be to introduce an additional setTheme(Theme) API, so that this code: Application.setUserAgentStylesheet(new MyTheme().toURL()); could be expressed like this: Application.setTheme(new MyTheme()); In this case, setting a theme could either 1. override a user-agent stylesheet 2. go before a user-agent stylesheet 3. go after a user-agent stylesheet One advantage of a separate API would be that it avoids the need to pass themes by a string URL and retains the strong typing afforded by a specialized API. On the other hand, an advantage of the existing string API would be that it works with the "javafx.userAgentStylesheetUrl" VM option, and it allows specifying themes as text attributes in FXML files: On Thu, Aug 26, 2021 at 7:02 AM Michael Strau? wrote: > > Circling back to CSS themes. I've posted an update on the API: > https://github.com/openjdk/jfx/pull/511#issuecomment-906092328 > > Comments appreciated. From kcr at openjdk.java.net Sat Aug 28 15:54:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 28 Aug 2021 15:54:24 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. I agree with getting it in now (after testing) and then improving it after it is in the repo. Btw, the `nbproject/` files were derived from those in the `apps/toys/` directory, for example, [apps/toys/Hello/nbproject/](https://github.com/openjdk/jfx/tree/68db44a2c80f420c967c64bb85988178a3cf6d9c/apps/toys/Hello/nbproject), and similarly are used to build using `ant`. So they aren't really IDE files any longer, even though that's where they originated back in the FX 2 time frame. A good cleanup effort would be to rewrite them to remove the NetBeans project structure, but that would be a larger effort than just this one manual test program. ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From hjohn at xs4all.nl Sat Aug 28 20:14:49 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 28 Aug 2021 22:14:49 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> Message-ID: <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> Was it taken into account that when you register an invalidation listener: property1.setValue(property2.getValue()); property1.addListener(binding); property2.addListener(binding); ... that if property2 is currently invalid it will not send any further invalidations? Property1 is revalidated (because of the getValue call), but property2 (if already invalid) will not become valid with that setValue call. Before when they were ChangeListeners, both properties became valid after a bidirectional binding, now that doesn't seem to be the case anymore. --John On 26/08/2021 09:29, Frederic Thevenet wrote: > Hi, > > A change was introduced In JDK-8264770 that swaps the use of > ChangeListeners to InvalidationListeners within the internal > implementation of BidirectionalBinding [1]. > > While this change shouldn't normally affect third party applications, it > turned out to break the scrolling facilities used by the widely used > rich text widget RichTextFX [2]. > > After a short investigation, I believe the root cause lies within > another library by the same author called ReactFX [3], which aims to > bring reactive programming techniques to JavaFX; in order to do so it > seems to expands on but also sometime overrides the built-in bindings > and events mechanisms. > > Now, I do believe that this is probably an exceptional case, and it is > also quite possible that it is the result of an unsafe/incorrect use of > internal implementations by the third party library, but with that said > I can't help but feeling a bit nervous about the wider implications of > that change with regard to compatibility of existing apps and OpenJFX > 17. At the very least I believe it is important to raise awareness about > potential compatibility issues among the community. > > For your information, I reached out to the maintainers of RichTextFX and > proposed a workaround (replacing the use of a bidirectional binding by a > pair of explicit ChangeListeners), which, while not very elegant, seems > to fix the particular issue I discovered [4], but unfortunately it seems > development on the underlying ReactFX is no longer active (last commit > in 2016). > > -- Fred > > [1] https://bugs.openjdk.java.net/browse/JDK-8264770 > > [2] https://github.com/FXMisc/RichTextFX > > [3] https://github.com/ReactFX/reactfx.github.io > > [4] https://github.com/FXMisc/Flowless/issues/97 > From hjohn at xs4all.nl Sat Aug 28 20:36:54 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 28 Aug 2021 22:36:54 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> Message-ID: Sorry, I swapped the properties around. Here is another attempt: The bindings added do not validate the properties anymore as it is an invalidation listener now instead of a change listener. This doesn't matter for property2 as its getValue is called which will force its revalidation, but for property1 this is not the case. If property1 was already in an invalid state when the binding was made (because someone changed its value but nobody was listening) then calling setValue again will not revalidate it. The invalidation listener added at this point also will not receive anything until something revalidates the property, so any changes made after the bidirectional binding is established to this property will not be copied to the other property (although the other way around will work). --John On 28/08/2021 22:14, John Hendrikx wrote: > Was it taken into account that when you register an invalidation listener: > > property1.setValue(property2.getValue()); > property1.addListener(binding); > property2.addListener(binding); > > ... that if property2 is currently invalid it will not send any further > invalidations? > > Property1 is revalidated (because of the getValue call), but property2 > (if already invalid) will not become valid with that setValue call. > > Before when they were ChangeListeners, both properties became valid > after a bidirectional binding, now that doesn't seem to be the case > anymore. > > --John > > > On 26/08/2021 09:29, Frederic Thevenet wrote: >> Hi, >> >> A change was introduced In JDK-8264770 that swaps the use of >> ChangeListeners to InvalidationListeners within the internal >> implementation of BidirectionalBinding [1]. >> >> While this change shouldn't normally affect third party applications, it >> turned out to break the scrolling facilities used by the widely used >> rich text widget RichTextFX [2]. >> >> After a short investigation, I believe the root cause lies within >> another library by the same author called ReactFX [3], which aims to >> bring reactive programming techniques to JavaFX; in order to do so it >> seems to expands on but also sometime overrides the built-in bindings >> and events mechanisms. >> >> Now, I do believe that this is probably an exceptional case, and it is >> also quite possible that it is the result of an unsafe/incorrect use of >> internal implementations by the third party library, but with that said >> I can't help but feeling a bit nervous about the wider implications of >> that change with regard to compatibility of existing apps and OpenJFX >> 17. At the very least I believe it is important to raise awareness about >> potential compatibility issues among the community. >> >> For your information, I reached out to the maintainers of RichTextFX and >> proposed a workaround (replacing the use of a bidirectional binding by a >> pair of explicit ChangeListeners), which, while not very elegant, seems >> to fix the particular issue I discovered [4], but unfortunately it seems >> development on the underlying ReactFX is no longer active (last commit >> in 2016). >> >> -- Fred >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8264770 >> >> [2] https://github.com/FXMisc/RichTextFX >> >> [3] https://github.com/ReactFX/reactfx.github.io >> >> [4] https://github.com/FXMisc/Flowless/issues/97 >> > From jhendrikx at openjdk.java.net Sat Aug 28 20:36:31 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 28 Aug 2021 20:36:31 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing [v2] In-Reply-To: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> References: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> Message-ID: <2aE82u5hRBt2GNATrMrzvVlEZ-wponOr-rassUe7nEw=.18b74ef6-919c-4f1a-8a13-aace0bfc1722@github.com> On Fri, 14 May 2021 22:30:16 GMT, Michael Strau? wrote: >> The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). >> >> However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. >> >> ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). >> >> The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. >> >> This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. >> >> I've filed a bug report with the same title. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added missing oldValue assignments modules/javafx.base/src/main/java/com/sun/javafx/binding/BidirectionalBinding.java line 157: > 155: > 156: property1.setValue((T)property2.getValue()); > 157: property1.addListener(binding); About lines 156-158: property1.setValue(property2.getValue()); property1.addListener(binding); property2.addListener(binding); The bindings added do not validate the properties anymore as it is an invalidation listener now instead of a change listener. This doesn't matter for `property2` as its `getValue` is called which will force its revalidation, but for `property1` this is not the case. This small program demonstrates this: SimpleDoubleProperty p = new SimpleDoubleProperty(2); InvalidationListener invalidationListener = obs -> System.out.println("Invalidated"); p.addListener(invalidationListener); p.setValue(3); p.setValue(4); The program as expected only prints `invalidated` once. ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From hjohn at xs4all.nl Sat Aug 28 21:00:54 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 28 Aug 2021 23:00:54 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> Message-ID: This actually isn't an issue because adding an invalidation listener revalidates the property as well (I'm not sure why, but I noticed this before while working on fluent bindings). However, there is another issue. When I recreate a bidirectional with two invalidation listeners with special logic to ignore my own invalidation listener triggering again when the other property gets updated. When you include this logic (using the "updating" field in the current code) in combination with invalidation listeners, the field that was just updated does NOT get revalidated. Any further changes to that field will therefore not trigger an invalidation event and the bidirectional nature of the binding breaks. Try this example: import javafx.application.Application; import javafx.beans.InvalidationListener; import javafx.beans.Observable; import javafx.beans.property.SimpleDoubleProperty; import javafx.stage.Stage; public class TestBug8264770 extends Application { public static void main(String[] args) { Application.launch(args); } static SimpleDoubleProperty p1 = new SimpleDoubleProperty(2); static SimpleDoubleProperty p2 = new SimpleDoubleProperty(3); @Override public void start(Stage stage) throws Exception { InvalidationListener invalidationListener = obs -> invalidated(obs); p1.addListener(invalidationListener); p2.addListener(invalidationListener); p1.setValue(4); p2.setValue(5); // Prints p1 = 4.0 (!!) System.out.println("Expect p1 to be 5, but was: " + p1.getValue()); } private boolean updating = false; private void invalidated(Observable source) { if (!updating) { try { updating = true; if(source == p1) { System.out.println("Setting p2 to " + p1.get()); p2.set(p1.get()); } else { System.out.println("Setting p1 to " + p2.get()); p1.set(p2.get()); } } finally { updating = false; } } } } --John On 28/08/2021 22:14, John Hendrikx wrote: > Was it taken into account that when you register an invalidation listener: > > property1.setValue(property2.getValue()); > property1.addListener(binding); > property2.addListener(binding); > > ... that if property2 is currently invalid it will not send any further > invalidations? > > Property1 is revalidated (because of the getValue call), but property2 > (if already invalid) will not become valid with that setValue call. > > Before when they were ChangeListeners, both properties became valid > after a bidirectional binding, now that doesn't seem to be the case > anymore. > > --John > > > On 26/08/2021 09:29, Frederic Thevenet wrote: >> Hi, >> >> A change was introduced In JDK-8264770 that swaps the use of >> ChangeListeners to InvalidationListeners within the internal >> implementation of BidirectionalBinding [1]. >> >> While this change shouldn't normally affect third party applications, it >> turned out to break the scrolling facilities used by the widely used >> rich text widget RichTextFX [2]. >> >> After a short investigation, I believe the root cause lies within >> another library by the same author called ReactFX [3], which aims to >> bring reactive programming techniques to JavaFX; in order to do so it >> seems to expands on but also sometime overrides the built-in bindings >> and events mechanisms. >> >> Now, I do believe that this is probably an exceptional case, and it is >> also quite possible that it is the result of an unsafe/incorrect use of >> internal implementations by the third party library, but with that said >> I can't help but feeling a bit nervous about the wider implications of >> that change with regard to compatibility of existing apps and OpenJFX >> 17. At the very least I believe it is important to raise awareness about >> potential compatibility issues among the community. >> >> For your information, I reached out to the maintainers of RichTextFX and >> proposed a workaround (replacing the use of a bidirectional binding by a >> pair of explicit ChangeListeners), which, while not very elegant, seems >> to fix the particular issue I discovered [4], but unfortunately it seems >> development on the underlying ReactFX is no longer active (last commit >> in 2016). >> >> -- Fred >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8264770 >> >> [2] https://github.com/FXMisc/RichTextFX >> >> [3] https://github.com/ReactFX/reactfx.github.io >> >> [4] https://github.com/FXMisc/Flowless/issues/97 >> > From nlisker at gmail.com Sat Aug 28 23:34:50 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 29 Aug 2021 02:34:50 +0300 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> Message-ID: > > This actually isn't an issue because adding an invalidation listener > revalidates the property as well (I'm not sure why, but I noticed this > before while working on fluent bindings). > There is an open issue on this: https://bugs.openjdk.java.net/browse/JDK-8208750. This is also the cause for the When binding evaluating the 'false' branch unneededly. Maybe this is a good time to have a look if this can be changed. The problem is finding how much code relies on this unspecified behavior. On Sun, Aug 29, 2021 at 12:01 AM John Hendrikx wrote: > This actually isn't an issue because adding an invalidation listener > revalidates the property as well (I'm not sure why, but I noticed this > before while working on fluent bindings). > > However, there is another issue. When I recreate a bidirectional with > two invalidation listeners with special logic to ignore my own > invalidation listener triggering again when the other property gets > updated. > > When you include this logic (using the "updating" field in the current > code) in combination with invalidation listeners, the field that was > just updated does NOT get revalidated. Any further changes to that > field will therefore not trigger an invalidation event and the > bidirectional nature of the binding breaks. > > Try this example: > > import javafx.application.Application; > import javafx.beans.InvalidationListener; > import javafx.beans.Observable; > import javafx.beans.property.SimpleDoubleProperty; > import javafx.stage.Stage; > > public class TestBug8264770 extends Application { > > public static void main(String[] args) { > Application.launch(args); > } > > static SimpleDoubleProperty p1 = new SimpleDoubleProperty(2); > static SimpleDoubleProperty p2 = new SimpleDoubleProperty(3); > > @Override > public void start(Stage stage) throws Exception { > InvalidationListener invalidationListener = obs -> invalidated(obs); > > p1.addListener(invalidationListener); > p2.addListener(invalidationListener); > > p1.setValue(4); > p2.setValue(5); > > // Prints p1 = 4.0 (!!) > System.out.println("Expect p1 to be 5, but was: " + p1.getValue()); > } > > private boolean updating = false; > > private void invalidated(Observable source) { > if (!updating) { > try { > updating = true; > > if(source == p1) { > System.out.println("Setting p2 to " + p1.get()); > p2.set(p1.get()); > } > else { > System.out.println("Setting p1 to " + p2.get()); > p1.set(p2.get()); > } > } > finally { > updating = false; > } > } > } > } > > --John > > On 28/08/2021 22:14, John Hendrikx wrote: > > Was it taken into account that when you register an invalidation > listener: > > > > property1.setValue(property2.getValue()); > > property1.addListener(binding); > > property2.addListener(binding); > > > > ... that if property2 is currently invalid it will not send any further > > invalidations? > > > > Property1 is revalidated (because of the getValue call), but property2 > > (if already invalid) will not become valid with that setValue call. > > > > Before when they were ChangeListeners, both properties became valid > > after a bidirectional binding, now that doesn't seem to be the case > > anymore. > > > > --John > > > > > > On 26/08/2021 09:29, Frederic Thevenet wrote: > >> Hi, > >> > >> A change was introduced In JDK-8264770 that swaps the use of > >> ChangeListeners to InvalidationListeners within the internal > >> implementation of BidirectionalBinding [1]. > >> > >> While this change shouldn't normally affect third party applications, it > >> turned out to break the scrolling facilities used by the widely used > >> rich text widget RichTextFX [2]. > >> > >> After a short investigation, I believe the root cause lies within > >> another library by the same author called ReactFX [3], which aims to > >> bring reactive programming techniques to JavaFX; in order to do so it > >> seems to expands on but also sometime overrides the built-in bindings > >> and events mechanisms. > >> > >> Now, I do believe that this is probably an exceptional case, and it is > >> also quite possible that it is the result of an unsafe/incorrect use of > >> internal implementations by the third party library, but with that said > >> I can't help but feeling a bit nervous about the wider implications of > >> that change with regard to compatibility of existing apps and OpenJFX > >> 17. At the very least I believe it is important to raise awareness about > >> potential compatibility issues among the community. > >> > >> For your information, I reached out to the maintainers of RichTextFX and > >> proposed a workaround (replacing the use of a bidirectional binding by a > >> pair of explicit ChangeListeners), which, while not very elegant, seems > >> to fix the particular issue I discovered [4], but unfortunately it seems > >> development on the underlying ReactFX is no longer active (last commit > >> in 2016). > >> > >> -- Fred > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8264770 > >> > >> [2] https://github.com/FXMisc/RichTextFX > >> > >> [3] https://github.com/ReactFX/reactfx.github.io > >> > >> [4] https://github.com/FXMisc/Flowless/issues/97 > >> > > > From michaelstrau2 at gmail.com Sun Aug 29 04:18:11 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 29 Aug 2021 06:18:11 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> Message-ID: Thanks for the investigation! I've prepared a PR that fixes this issue: https://github.com/openjdk/jfx/pull/614 On Sat, Aug 28, 2021 at 11:02 PM John Hendrikx wrote: > > This actually isn't an issue because adding an invalidation listener > revalidates the property as well (I'm not sure why, but I noticed this > before while working on fluent bindings). > > However, there is another issue. When I recreate a bidirectional with > two invalidation listeners with special logic to ignore my own > invalidation listener triggering again when the other property gets > updated. > > When you include this logic (using the "updating" field in the current > code) in combination with invalidation listeners, the field that was > just updated does NOT get revalidated. Any further changes to that > field will therefore not trigger an invalidation event and the > bidirectional nature of the binding breaks. > > Try this example: > > import javafx.application.Application; > import javafx.beans.InvalidationListener; > import javafx.beans.Observable; > import javafx.beans.property.SimpleDoubleProperty; > import javafx.stage.Stage; > > public class TestBug8264770 extends Application { > > public static void main(String[] args) { > Application.launch(args); > } > > static SimpleDoubleProperty p1 = new SimpleDoubleProperty(2); > static SimpleDoubleProperty p2 = new SimpleDoubleProperty(3); > > @Override > public void start(Stage stage) throws Exception { > InvalidationListener invalidationListener = obs -> invalidated(obs); > > p1.addListener(invalidationListener); > p2.addListener(invalidationListener); > > p1.setValue(4); > p2.setValue(5); > > // Prints p1 = 4.0 (!!) > System.out.println("Expect p1 to be 5, but was: " + p1.getValue()); > } > > private boolean updating = false; > > private void invalidated(Observable source) { > if (!updating) { > try { > updating = true; > > if(source == p1) { > System.out.println("Setting p2 to " + p1.get()); > p2.set(p1.get()); > } > else { > System.out.println("Setting p1 to " + p2.get()); > p1.set(p2.get()); > } > } > finally { > updating = false; > } > } > } > } > > --John > From github.com+1864183+micheljung at openjdk.java.net Sun Aug 29 06:41:43 2021 From: github.com+1864183+micheljung at openjdk.java.net (Michel Jung) Date: Sun, 29 Aug 2021 06:41:43 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v5] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 15:41:59 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Color to int32 conversion and more changes based on feedback modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 629: > 627: try { > 628: log.fine("setBackgroundColor int32: " + backgroundColor + > 629: " for all frames"); I don't know JavaFX's PlatformLogger but this should probably be: Suggestion: log.fine("setBackgroundColor int32: {} for all frames", backgroundColor); or: Suggestion: if(log.isTraceEnabled()) { log.fine("setBackgroundColor int32: {} for all frames", backgroundColor); } Even though this probably isn't something that's called very often :) ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From hjohn at xs4all.nl Sun Aug 29 15:22:52 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 29 Aug 2021 17:22:52 +0200 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> Message-ID: <0e077439-e0a3-2eb3-a3f3-badb746df1b4@xs4all.nl> On 29/08/2021 01:34, Nir Lisker wrote: >> >> This actually isn't an issue because adding an invalidation listener >> revalidates the property as well (I'm not sure why, but I noticed this >> before while working on fluent bindings). >> > > There is an open issue on this: > https://bugs.openjdk.java.net/browse/JDK-8208750. > > This is also the cause for the When binding evaluating the 'false' branch > unneededly. Maybe this is a good time to have a look if this can be > changed. The problem is finding how much code relies on this unspecified > behavior. Yeah, I fear that changing this now may introduce subtle problems, both in JavaFX itself and quite some user and library code. Invalidation and ChangeListeners are quite often chosen without much thought in user code, where the consideration is more whether you want the old value or whether you want to avoid boxing. Such code just calls "get" to make it similar to a ChangeListener, even though there still is a subtle difference which, in the current implementation, is hidden. Current code using the invalidation + get variant would break if the property in question was already invalid at the time of registration, as then no further invalidations would be received in the absence of something external revalidating that property. Once it is revalidated once, the code would function as "intended", which further hides the problem (ie, problem only occurs once or only at startup or something). If fixing this proves too risky, we probably should document Bindings#when with a warning and perhaps offer an alternative (fluent bindings or a new Bindings method that just takes a mapping function :)). --John From swpalmer at openjdk.java.net Sun Aug 29 16:12:28 2021 From: swpalmer at openjdk.java.net (Scott Palmer) Date: Sun, 29 Aug 2021 16:12:28 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. > On Aug 28, 2021, at 11:51 AM, Kevin Rushforth ***@***.***> wrote: > > > I agree with getting it in now (after testing) and then improving it after it is in the repo. > > Btw, the nbproject/ files were derived from those in the apps/toys/ directory, for example, apps/toys/Hello/nbproject/ , and similarly are used to build using ant. So they aren't really IDE files any longer, even though that's where they originated back in the FX 2 time frame. > > A good cleanup effort would be to rewrite them to remove the NetBeans project structure, but that would be a larger effort than just this one manual test program. > Would be nice to have part of the cleanup convert projects to Gradle to be consistent with the rest of the project. Scott ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From alessandro.parisi406 at gmail.com Sun Aug 29 17:55:12 2021 From: alessandro.parisi406 at gmail.com (Alessandro Parisi) Date: Sun, 29 Aug 2021 19:55:12 +0200 Subject: RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed Message-ID: > > OK, I think you've answered my first and third questions. The broader > question then is whether this fills a general need, and if so, is > allowing for a dynamic user agent style on a Control the best way to > provide this feature? I'd like to hear from some of the other developers > on this list. > > As for the second question, I don't think the API you propose for > dynamic user agent style-sheets is feasible in a way that maintains > compatibility. The current API model is that the control itself provides > its userAgentStylesheet by overriding the get method, returning a String > specific to that control (or possibly a specific instance of that > control, if the designer of that control wants to add such logic for > some reason). You can't compatibly turn this API into a standard > property. Our properties have final set/get/property methods for a > reason. Namely, to satisfy the invariant that calling the set or get > method is identical to calling the property method (this is key to > allowing bindings and listeners to work in a consistent and predictable > manner). Also, since existing controls that override the getter, they > will know nothing about the setter. Applications may wonder why > setUserAgentStylesheet(sheet) does not imply > sheet.equals(getUserAgentStyleSheet()). > > Off the top of my head I can think of three ways to resolve this > depending on what app developers and custom controls developers would > prefer to see: > > A. Provide a property with some other name (i.e., not > userAgentStylesheet). If the value of this new property is non-null it > takes precedence over the userAgentStylesheet. When it changes, it > causes the necessary reevaluation to happen. This is the closest to what > you propose, but preserves backward compatibility. This add some > additional complexity, which may or may not be justified. > > B. Provide an "updateUserAgentStylesheet(String)" method that acts > "like" a setter, but a control would be free to ignore (and a control > that overrides the "getter" today would certainly ignore). This seems > messy and has its own consistency issues. And it still doesn't solve the > question of how the control indicates that it has change its user agent > stylesheet. > > C. Leave it up to the control to decide when and how to change the value > of its userAgentStylesheet. Provide a boolean > "dynamicUserAgentStylesheet" property indicating whether the > userAgentStylesheet is dynamic (most likely likely the control would set > it for itself). There might also need to be a way for a control to > indicate that its value has changed. Given your use cases, this seems > like a good fit. > > There may be more options - e.g., a hybrid of B and C if setting this > under app control is a thing many apps want to do (although in that > case, why not just go with option A)? Maybe there something else I'm not > thinking of right now that would work. > > A follow-up question is whether and how this would interact with the > proposed theming API that is also under discussion (maybe that > discussion could be revived)? > > Before we spend too much more time on the API discussion, I want to hear > from other developers on the list as to the value proposition of doing > this and how they would like to see it done. > > -- Kevin > > I would exclude A and C solutions as they would add some unnecessary complexity in my opinion. I kinda like solution B, I like the idea of an update method, but I don't see how a control would be able to ignore it. Also, let's say a control overrides the getter, why a call to the "update" method should be ignored, it's up to the user to decide if the userAgent should be changed right? To be honest, these solutions, and particularly the B one, seem to be good solution if you want to keep backwards compatibility but let's suppose solution B is implemented, we end up having to methods for the userAgent a "getter" and an "updater". At this point, without taking into account backwards compatibility, I'd rather delete the "getter" and keep only the "updater", apps/libraries that override the getter would just need to remove the override and instead make a call to the "updater" in the constructor or in an "initializer" method of some sort As for the theming API there's one thing that I don't understand. If we introduce a theming API then what's the point of the userAgentStylesheet exactly? From nlisker at gmail.com Sun Aug 29 19:50:45 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 29 Aug 2021 22:50:45 +0300 Subject: Re-examine the risks of JDK-8264770 breaking third party libraries and applications. In-Reply-To: <0e077439-e0a3-2eb3-a3f3-badb746df1b4@xs4all.nl> References: <64818082-655b-67c6-df3a-cdab878fbbb9@free.fr> <97196bc4-f74e-0a4e-1d47-10dd30b2452b@xs4all.nl> <0e077439-e0a3-2eb3-a3f3-badb746df1b4@xs4all.nl> Message-ID: I'll try to change the behavior locally and see how much of JavaFX breaks as a result. I don't think that a lot of code relies on the property being in a valid state while in fact it isn't when attaching a listener. I could be wrong... On Sun, Aug 29, 2021 at 6:23 PM John Hendrikx wrote: > > > On 29/08/2021 01:34, Nir Lisker wrote: > >> > >> This actually isn't an issue because adding an invalidation listener > >> revalidates the property as well (I'm not sure why, but I noticed this > >> before while working on fluent bindings). > >> > > > > There is an open issue on this: > > https://bugs.openjdk.java.net/browse/JDK-8208750. > > > > This is also the cause for the When binding evaluating the 'false' branch > > unneededly. Maybe this is a good time to have a look if this can be > > changed. The problem is finding how much code relies on this unspecified > > behavior. > > Yeah, I fear that changing this now may introduce subtle problems, both > in JavaFX itself and quite some user and library code. > > Invalidation and ChangeListeners are quite often chosen without much > thought in user code, where the consideration is more whether you want > the old value or whether you want to avoid boxing. Such code just calls > "get" to make it similar to a ChangeListener, even though there still is > a subtle difference which, in the current implementation, is hidden. > > Current code using the invalidation + get variant would break if the > property in question was already invalid at the time of registration, as > then no further invalidations would be received in the absence of > something external revalidating that property. Once it is revalidated > once, the code would function as "intended", which further hides the > problem (ie, problem only occurs once or only at startup or something). > > If fixing this proves too risky, we probably should document > Bindings#when with a warning and perhaps offer an alternative (fluent > bindings or a new Bindings method that just takes a mapping function :)). > > --John > > > > > > From nlisker at gmail.com Sun Aug 29 22:39:42 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 30 Aug 2021 01:39:42 +0300 Subject: "Execution optimizations have been disabled for task" during building Message-ID: Hi, When running builds, gradle reports Execution optimizations have been disabled for task ':base:copyClassFilesWin' to ensure correctness due to the following reasons: - Gradle detected a problem with the following location: 'C:\...\jfx\modules\javafx.base\build\module-classes'. Reason: Task ':base:copyClassFilesWin' uses this output of task ':base:buildModuleWin' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.0.1/userguide/validation_problems.html#implicit_dependency for more details about this problem. Same happens on other tasks: :base:copyLibFilesWin :base:modularJarStandaloneWin :base:copyLibFilesStandaloneWin etc. I don't remember seeing this before. It doesn't cause any failures but thought I'd ask. From fastegal at swingempire.de Mon Aug 30 09:20:33 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 30 Aug 2021 11:20:33 +0200 Subject: "Execution optimizations have been disabled for task" during building In-Reply-To: References: Message-ID: <20210830112033.Horde.BYfxokNaul2soixD1LGC2w1@webmail.df.eu> Hi Nir, looks similar to https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-May/030563.html which I'm seeing since May - don't know (and didn't dig ;) why or how to solve, I simply ignore them. -- Jeanette Zitat von Nir Lisker : > Hi, > > When running builds, gradle reports > > Execution optimizations have been disabled for task > ':base:copyClassFilesWin' to ensure correctness due to the following > reasons: > - Gradle detected a problem with the following location: > 'C:\...\jfx\modules\javafx.base\build\module-classes'. Reason: Task > ':base:copyClassFilesWin' uses this output of task ':base:buildModuleWin' > without declaring an explicit or implicit dependency. This can lead to > incorrect results being produced, depending on what order the tasks are > executed. Please refer to > https://docs.gradle.org/7.0.1/userguide/validation_problems.html#implicit_dependency > for more details about this problem. > > Same happens on other tasks: > :base:copyLibFilesWin > :base:modularJarStandaloneWin > :base:copyLibFilesStandaloneWin > etc. > > I don't remember seeing this before. It doesn't cause any failures but > thought I'd ask. From mstrauss at openjdk.java.net Mon Aug 30 13:33:44 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 30 Aug 2021 13:33:44 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties Message-ID: This PR fixes a bug that was introduced in #454. Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: @State(Scope.Benchmark) public class BindingBenchmark { DoubleProperty property1 = new SimpleDoubleProperty(); DoubleProperty property2 = new SimpleDoubleProperty(); public BindingBenchmark() { property2.bindBidirectional(property1); } @Benchmark public void benchmark() { for (int i = 0; i < 10000000; ++i) { property1.set((i % 2 == 0) ? 12345.0 : 54321.0); } } } | Benchmark | Mode | Cnt | Score | Error | Units | |-----------|------|-----|-------|-------|--------| | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | ------------- Commit messages: - fixed invalidation bug - added failing test Changes: https://git.openjdk.java.net/jfx/pull/614/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=614&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273138 Stats: 54 lines in 2 files changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/614.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/614/head:pull/614 PR: https://git.openjdk.java.net/jfx/pull/614 From mstrauss at openjdk.java.net Mon Aug 30 13:33:45 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 30 Aug 2021 13:33:45 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | @kevinrushforth Should this be a new JBS ticket, or should we re-open [8264770](https://bugs.openjdk.java.net/browse/JDK-8264770) and associate this PR with it? ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From jhendrikx at openjdk.java.net Mon Aug 30 13:33:45 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 30 Aug 2021 13:33:45 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <_V0q5dNEx6bi5EjSbsUx9wcBq9sjMXuEzS042H3Zw5I=.15b2dc5b-5e57-4186-831b-e43a3d5e3e0f@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | This change looks good to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From kcr at openjdk.java.net Mon Aug 30 13:33:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 30 Aug 2021 13:33:45 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <8oDkIVBQG2WKPmnRXAvINCEL5C7f-Y_I5EqaJ00Epp0=.ca91fc4f-98a8-43c8-9e1c-ed54b0c97685@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | > Should this be a new JBS ticket, or should we re-open 8264770 and associate this PR with it? The former. We never reopen a bug that was resolved/fixed by a commit in the repo. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From jvos at openjdk.java.net Tue Aug 31 07:40:43 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 31 Aug 2021 07:40:43 GMT Subject: [jfx11u] RFR: 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. Message-ID: 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. Reviewed-by: kcr, jvos Backport LONG-COMMIT-HASH ------------- Commit messages: - 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. Changes: https://git.openjdk.java.net/jfx11u/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8185447 Stats: 120 lines in 16 files changed: 113 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx11u/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/50/head:pull/50 PR: https://git.openjdk.java.net/jfx11u/pull/50 From jvos at openjdk.java.net Tue Aug 31 07:49:48 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 31 Aug 2021 07:49:48 GMT Subject: [jfx11u] RFR: 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so Message-ID: clean patch 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so Reviewed-by: kcr ------------- Commit messages: - 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so Changes: https://git.openjdk.java.net/jfx11u/pull/51/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=51&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211362 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx11u/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/51/head:pull/51 PR: https://git.openjdk.java.net/jfx11u/pull/51 From jvos at openjdk.java.net Tue Aug 31 08:01:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 31 Aug 2021 08:01:41 GMT Subject: [jfx11u] RFR: 8269374: Menu inoperable after setting stage to second monitor Message-ID: clean patch 8269374: Menu inoperable after setting stage to second monitorc Reviewed-by: kcr, arapte ------------- Commit messages: - 8269374: Menu inoperable after setting stage to second monitor Changes: https://git.openjdk.java.net/jfx11u/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=52&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269374 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/52/head:pull/52 PR: https://git.openjdk.java.net/jfx11u/pull/52 From nlisker at gmail.com Tue Aug 31 15:52:34 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 31 Aug 2021 18:52:34 +0300 Subject: Eager Evaluation of Invalidation Listeners Message-ID: Hi, This is a continuation of the discussion that stemmed from changing bidirectional bindings to use invalidation listeners instead of change listeners [1]. The relevant issue in JBS is [2]. I have looked at removing the eager evaluation when attaching an invalidation listener. I found that tests, for example, the method BooleanPropertyBaseTest#testAddingListenerWillAlwaysReceiveInvalidationEvent (only lines 428-432 are relevant) set the following requirement: 1. Start with a property in an invalid state. 2. Attach an invalidation listener. 3. Set a value which is different than the current one. Result: an invalidation event must be sent. This means that attaching an invalidation listener must validate the property, which is (at least currently) only possible by evaluating the value. This is in contrast to the comment in the JBS that invalidation listeners should not generally force eager evaluation. It is also in contrast to this line in the class doc of ObservableValue: "Implementations in this library mark themselves as invalid when the first invalidation event occurs. They do not generate any more invalidation events until their value is recomputed and valid again." So, either the requirement set by the tests is wrong, or invalidation listeners really do need to behave according to the test and the docs missed a practical requirement, or my analysis is wrong. There are more tests that fail, but the ones I looked at rely on the same concept. For example, Node_LocalToParentTransform_Test#shouldBeNotifiedWhenNodeTransforms() tests the Node#LazyTransformProperty property. Interestingly, this one is initialized with an invalid state, while Simple___Property are initialized as valid. Thoughts? [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2021-August/031778.html [2] https://bugs.openjdk.java.net/browse/JDK-8208750 From kcr at openjdk.java.net Tue Aug 31 16:34:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 31 Aug 2021 16:34:51 GMT Subject: RFR: 8201538: Remove implementation support for applets from JavaFX Message-ID: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed. ## Notes to reviewers: The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called. ### Shared Code The following were removed from the shared code. #### Removed Java classes com.sun.javafx.tk.AppletWindow com.sun.javafx.tk.quantum.GlassAppletWindow #### Removed methods The following methods were removed in the parent class and all subclasses. com.sun.glass.ui.Application: public abstract Window createWindow(long parent) com.sun.glass.ui.Window: public boolean getAppletMode() public void setAppletMode(boolean appletMode) public void dispatchNpapiEvent(Map eventInfo) protected abstract long _createChildWindow(long parent) protected Window(long parent) protected abstract int _getEmbeddedX(long ptr) protected abstract int _getEmbeddedY(long ptr) com.sun.javafx.tk.Toolkit: public abstract AppletWindow createAppletWindow(...) public abstract void closeAppletWindow() com.sun.javafx.tk.quantum.WindowStage: static void setAppletWindow(GlassAppletWindow aw) static GlassAppletWindow getAppletWindow() ### Linux (Gtk) Java code The following classes or methods were removed: com.sun.glass.ui.gtk.GtkChildWindow (class removed) com.sun.glass.ui.gtk.GtkWindow: protected GtkWindow(long parent) ### Linux (Gtk) native glass: The following native classes were removed: WindowContextChild WindowContextPlug ### macOS Java code The following classes or methods were removed: com.sun.glass.events.mac.NpapiEvent (class removed) com.sun.glass.ui.mac.MacApplication: native protected String _getRemoteLayerServerName() com.sun.glass.ui.View: public int getNativeRemoteLayerId(String serverName) com.sun.glass.ui.mac.MacView: native protected int _getNativeRemoteLayerId(long ptr, String serverName) native protected void _hostRemoteLayerId(long ptr, int nativeLayerId) com.sun.glass.ui.mac.MacWindow: protected MacWindow(long parent) ### macOS native code The following native classes were removed: GlassEmbeddedWindow* GlassNSEvent GlassView3D+Remote RemoteLayerSupport I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was: - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`. ### Windows Java code The following classes or methods were removed: com.sun.glass.ui.win.WinChildWindow (class removed) com.sun.glass.ui.win.WinWindow: protected WinWindow(long parent) ### Windows native code After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following: GlassApplication::InstallMouseLLHook GlassApplication::UninstallMouseLLHook ### iOS Java code com.sun.glass.ui.ios.IosWindow: protected IosWindow(long parent) ### iOS native code With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed: Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong) As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon. ------------- Commit messages: - 8201538: Remove implementation support for applets from JavaFX Changes: https://git.openjdk.java.net/jfx/pull/615/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=615&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8201538 Stats: 3424 lines in 64 files changed: 32 ins; 3308 del; 84 mod Patch: https://git.openjdk.java.net/jfx/pull/615.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/615/head:pull/615 PR: https://git.openjdk.java.net/jfx/pull/615 From kcr at openjdk.java.net Tue Aug 31 16:34:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 31 Aug 2021 16:34:51 GMT Subject: RFR: 8201538: Remove implementation support for applets from JavaFX In-Reply-To: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> References: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> Message-ID: On Tue, 31 Aug 2021 16:28:53 GMT, Kevin Rushforth wrote: > This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed. > > ## Notes to reviewers: > > The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called. > > ### Shared Code > > The following were removed from the shared code. > > #### Removed Java classes > > > com.sun.javafx.tk.AppletWindow > com.sun.javafx.tk.quantum.GlassAppletWindow > > > #### Removed methods > > The following methods were removed in the parent class and all subclasses. > > > com.sun.glass.ui.Application: > public abstract Window createWindow(long parent) > > com.sun.glass.ui.Window: > public boolean getAppletMode() > public void setAppletMode(boolean appletMode) > public void dispatchNpapiEvent(Map eventInfo) > protected abstract long _createChildWindow(long parent) > protected Window(long parent) > protected abstract int _getEmbeddedX(long ptr) > protected abstract int _getEmbeddedY(long ptr) > > com.sun.javafx.tk.Toolkit: > public abstract AppletWindow createAppletWindow(...) > public abstract void closeAppletWindow() > > com.sun.javafx.tk.quantum.WindowStage: > static void setAppletWindow(GlassAppletWindow aw) > static GlassAppletWindow getAppletWindow() > > > > ### Linux (Gtk) Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.gtk.GtkChildWindow (class removed) > > com.sun.glass.ui.gtk.GtkWindow: > protected GtkWindow(long parent) > > > ### Linux (Gtk) native glass: > > The following native classes were removed: > > > WindowContextChild > WindowContextPlug > > > ### macOS Java code > > The following classes or methods were removed: > > > com.sun.glass.events.mac.NpapiEvent (class removed) > > com.sun.glass.ui.mac.MacApplication: > native protected String _getRemoteLayerServerName() > > com.sun.glass.ui.View: > public int getNativeRemoteLayerId(String serverName) > > com.sun.glass.ui.mac.MacView: > native protected int _getNativeRemoteLayerId(long ptr, String serverName) > native protected void _hostRemoteLayerId(long ptr, int nativeLayerId) > > com.sun.glass.ui.mac.MacWindow: > protected MacWindow(long parent) > > > ### macOS native code > > The following native classes were removed: > > > GlassEmbeddedWindow* > GlassNSEvent > GlassView3D+Remote > RemoteLayerSupport > > > I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was: > > > - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle > screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild > > > This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`. > > ### Windows Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.win.WinChildWindow (class removed) > > com.sun.glass.ui.win.WinWindow: > protected WinWindow(long parent) > > > ### Windows native code > > After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following: > > > GlassApplication::InstallMouseLLHook > GlassApplication::UninstallMouseLLHook > > > ### iOS Java code > > > com.sun.glass.ui.ios.IosWindow: > protected IosWindow(long parent) > > > ### iOS native code > > With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed: > > > Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong) > > > As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 157: > 155: if (isPrimaryStage && (null != appletWindow)) { > 156: platformWindow = app.createWindow(appletWindow.getGlassWindow().getNativeWindow()); > 157: } else { The diffs in this method below this point are mostly caused by indentation. I recommend reviewers select the "Hide whitespace changes" option. ------------- PR: https://git.openjdk.java.net/jfx/pull/615 From jvos at openjdk.java.net Tue Aug 31 20:06:49 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 31 Aug 2021 20:06:49 GMT Subject: [jfx11u] Integrated: 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 07:35:33 GMT, Johan Vos wrote: > 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. > > Reviewed-by: kcr, jvos > Backport LONG-COMMIT-HASH This pull request has now been integrated. Changeset: f9a00e69 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/f9a00e69302ad0abc521bf6377bf1e87e382578e Stats: 120 lines in 16 files changed: 113 ins; 0 del; 7 mod 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. Backport-of: 0e7cf623d3cc6dc25b944ef739acaf2de27d125b ------------- PR: https://git.openjdk.java.net/jfx11u/pull/50 From jvos at openjdk.java.net Tue Aug 31 20:14:51 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 31 Aug 2021 20:14:51 GMT Subject: [jfx11u] Integrated: 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 07:43:28 GMT, Johan Vos wrote: > clean patch > 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so > Reviewed-by: kcr This pull request has now been integrated. Changeset: 319d2f09 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/319d2f09623781b6f863b27655ce2fdf97fe67a9 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so Backport-of: ed5cfe72e0da4e4b90eb83cac7c50fe761f28c04 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/51 From jvos at openjdk.java.net Tue Aug 31 20:35:55 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 31 Aug 2021 20:35:55 GMT Subject: [jfx11u] Integrated: 8269374: Menu inoperable after setting stage to second monitor In-Reply-To: References: Message-ID: <13qKEiMaemdlldRuLGAdntODaxKfr5lEo3f_e69-iDo=.54449b98-ec8e-4807-97bc-d033b9796895@github.com> On Tue, 31 Aug 2021 07:44:34 GMT, Johan Vos wrote: > clean patch > 8269374: Menu inoperable after setting stage to second monitorc > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 8037b355 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/8037b355e33156ab53e9496c4e9bb573787b0642 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8269374: Menu inoperable after setting stage to second monitor Backport-of: c490ddfdb1255add00dd7b0f14fe03857c6946c5 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/52 From thiago.sayao at gmail.com Tue Aug 31 21:02:39 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 31 Aug 2021 18:02:39 -0300 Subject: Gtk4 and Wayland Message-ID: Hi, I did some investigation on gtk4 and wayland. After some research I ended up with the conclusion that the best way is to do a separate gtk4 backend, that would support X11 and Wayland. This would be a good start: https://github.com/openjdk/jfx/pull/77/files Why? Gtk4 moves the decoration to the client side, which is GREAT since knowing the window size with decoration was a real pain. We probably won't want to do all the decoration work, Gtk does that, but on GtkWindow level, not GdkSurface (which replaces GdkWindow). Thus the move to use "more Gtk" (hence "less Gdk") which is exactly what the PR does. It also removes Applet code This is also a good starting point: https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html --Thiago. From hjohn at xs4all.nl Tue Aug 31 21:28:10 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 31 Aug 2021 23:28:10 +0200 Subject: Eager Evaluation of Invalidation Listeners In-Reply-To: References: Message-ID: <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl> On 31/08/2021 17:52, Nir Lisker wrote: > Hi, > > This is a continuation of the discussion that stemmed from changing > bidirectional bindings to use invalidation listeners instead of change > listeners [1]. > > The relevant issue in JBS is [2]. > > I have looked at removing the eager evaluation when attaching an > invalidation listener. I found that tests, for example, the > method BooleanPropertyBaseTest#testAddingListenerWillAlwaysReceiveInvalidationEvent > (only lines 428-432 are relevant) set the following requirement: > > 1. Start with a property in an invalid state. > 2. Attach an invalidation listener. > 3. Set a value which is different than the current one. > Result: an invalidation event must be sent. > > This means that attaching an invalidation listener must validate the > property, which is (at least currently) only possible by evaluating the > value. > > This is in contrast to the comment in the JBS that invalidation listeners > should not generally force eager evaluation. It is also in contrast to this > line in the class doc of ObservableValue: > "Implementations in this library mark themselves as invalid when the first > invalidation event occurs. They do not generate any more invalidation > events until their value is recomputed and valid again." > > So, either the requirement set by the tests is wrong, or invalidation > listeners really do need to behave according to the test and the docs > missed a practical requirement, or my analysis is wrong. What I'm thinking is that perhaps the revalidation on registering a new InvalidationListener was done intentionally as there is no mechanism to query the current valid state of an observable (#isValid). So in order to make sure that a new interested invalidation listener does not miss the fact that a property was *already* invalid, the easiest solution might have been to revalidate it upon registration of a new listener -- then again, this does not communicate this fact, it only does so when the property changes again. An interesting solution could be to send out an Invalidation event eagerly only to a newly registered listener if said property was invalid at the time of registration; this would inform the new listener that the property was already invalid but would not notify any existing listeners (as they already know the property to be invalid). > There are more tests that fail, but the ones I looked at rely on the same > concept. For > example, Node_LocalToParentTransform_Test#shouldBeNotifiedWhenNodeTransforms() > tests the Node#LazyTransformProperty property. Interestingly, this one is > initialized with an invalid state, while Simple___Property are initialized > as valid. > > Thoughts? Perhaps we could consider the registration of an invalidation listener to be infrequent enough to be of little consequence, although I agree that the documentation and tests are not in agreement. --John