From dlemmermann at gmail.com Tue Oct 1 12:05:26 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Tue, 1 Oct 2019 14:05:26 +0200 Subject: Changes to layout behavior? Message-ID: <058EEFF4-86E5-4B76-A089-71FF9A145212@gmail.com> Hi, I recently noticed that some of my frameworks constantly run the layoutChildren() method of their skins when they are being executed with Java 11+. I assume the reason is that I am adding nodes to the scenegraph INSIDE the layoutChildren() method. This used to work very well, but now it causes an infinite loop. The controls are still responsive, but I can see high CPU and memory usage because of it. Does anyone know what has changed between 8 and 11 that could have caused this change in behavior? ?Dirk jfx-days.com From kevin.rushforth at oracle.com Tue Oct 1 16:13:45 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 1 Oct 2019 09:13:45 -0700 Subject: Skara transition: jfx-dev/rt repo and javafxports/openjdk-jfx sandbox frozen Message-ID: <9c45fca9-bae7-4d64-6ada-151914d8fda4@oracle.com> As announced in this message [1], we are transitioning the official openjfx mainline repo from Mercurial (hosted on hg.openjdk.java.net) to GIT (hosted on github.com). Effective immediately, the HG openjfx/jfx-dev/rt [2] repo is frozen. No more pushes to this repo will be accepted. Similarly, no more pull requests will be accepted against the GitHub javafxports/openjdk-jfx [3] sandbox repo. I have one final push to HG which will add the .jcheck/conf file needed by Skara [4]. I will do some sanity testing, and then the HG repo will be made read-only. I will send an announcement tomorrow morning when the new GitHub openjdk/jfx [5] repo is open for accepting pull requests. In the mean time, you can fork and clone the new repo as indicated here [6] to prepare for this. Let me know if you have any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt [3] https://github.com/javafxports/openjdk-jfx [4] https://bugs.openjdk.java.net/browse/JDK-8231310 [5] https://github.com/openjdk/jfx [6] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html From kcr at openjdk.org Wed Oct 2 13:48:58 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Oct 2019 13:48:58 GMT Subject: RFR: 8231735: gradle checkrepo is obsolete and doesn't work with git Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231735 This removes the obsolete `checkrepo` and `checkrepoall` gradle tasks. They use a script which assumes Mercurial support, and so no longer run. Also, with `git jcheck` support now available, these tasks are no longer needed. ---------------- Commits: - 3b44a0d4: 8231735: gradle checkrepo is obsolete and doesn't work with git Changes: https://git.openjdk.java.net/jfx/pull/2/files Webrev: https://webrevs.openjdk.java.net/jfx/2/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231735 Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/2/head:pull/2 PR: https://git.openjdk.java.net/jfx/pull/2 From kevin.rushforth at oracle.com Wed Oct 2 13:50:57 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 2 Oct 2019 06:50:57 -0700 Subject: Skara transition: openjdk/jfx GitHub repo is ready to accept pull requests In-Reply-To: <9c45fca9-bae7-4d64-6ada-151914d8fda4@oracle.com> References: <9c45fca9-bae7-4d64-6ada-151914d8fda4@oracle.com> Message-ID: <05e95501-11bc-90b1-ef06-4655598dbcb3@oracle.com> The openjdk/jfx repo is now open and accepting pull requests. Refer to the links in the included message below for more information. One thing to note: there is not yet a CI job hooked up to the repo. Contributors, Committers, and Reviewers need to take this into account when testing. Please report any problems that you run into by replying to this thread. Thanks. -- Kevin On 10/1/2019 9:13 AM, Kevin Rushforth wrote: > As announced in this message [1], we are transitioning the official > openjfx mainline repo from Mercurial (hosted on hg.openjdk.java.net) > to GIT (hosted on github.com). Effective immediately, the HG > openjfx/jfx-dev/rt [2] repo is frozen. No more pushes to this repo > will be accepted. Similarly, no more pull requests will be accepted > against the GitHub javafxports/openjdk-jfx [3] sandbox repo. > > I have one final push to HG which will add the .jcheck/conf file > needed by Skara [4]. I will do some sanity testing, and then the HG > repo will be made read-only. > > I will send an announcement tomorrow morning when the new GitHub > openjdk/jfx [5] repo is open for accepting pull requests. In the mean > time, you can fork and clone the new repo as indicated here [6] to > prepare for this. > > Let me know if you have any questions. > > -- Kevin > > [1] > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt > [3] https://github.com/javafxports/openjdk-jfx > [4] https://bugs.openjdk.java.net/browse/JDK-8231310 > [5] https://github.com/openjdk/jfx > [6] > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html From kcr at openjdk.org Wed Oct 2 14:11:39 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Oct 2019 14:11:39 GMT Subject: RFR: 8231590: Update location of jfx repo to GitHub in third-party legal files In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 14:11:37 GMT, Kevin Rushforth wrote: > https://bugs.openjdk.java.net/browse/JDK-8231590 > > Replaces http://hg.openjdk.java.net/openjfx/jfx/rt with https://github.com/openjdk/jfx in three thred-party legal files. After this change, there are no more references to `hg.openjdk.java.net` in the repo. > > ---------------- > > Commits: > - 0e606978: 8231590: Update location of jfx repo to GitHub in third-party legal files > > Changes: https://git.openjdk.java.net/jfx/pull/3/files > Webrev: https://webrevs.openjdk.java.net/jfx/3/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231590 > Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/3.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/3/head:pull/3 @sashamatveev can you review this? PR: https://git.openjdk.java.net/jfx/pull/3 From kcr at openjdk.org Wed Oct 2 14:11:37 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Oct 2019 14:11:37 GMT Subject: RFR: 8231590: Update location of jfx repo to GitHub in third-party legal files Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231590 Replaces http://hg.openjdk.java.net/openjfx/jfx/rt with https://github.com/openjdk/jfx in three thred-party legal files. After this change, there are no more references to `hg.openjdk.java.net` in the repo. ---------------- Commits: - 0e606978: 8231590: Update location of jfx repo to GitHub in third-party legal files Changes: https://git.openjdk.java.net/jfx/pull/3/files Webrev: https://webrevs.openjdk.java.net/jfx/3/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231590 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/3/head:pull/3 PR: https://git.openjdk.java.net/jfx/pull/3 From tsayao at openjdk.org Wed Oct 2 19:54:48 2019 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 2 Oct 2019 19:54:48 GMT Subject: RFR: 8225571: Port DND source to use GTK instead of GDK Message-ID: https://bugs.openjdk.java.net/browse/JDK-8225571 To run tests (on the root of the source tree): /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 ---------------- Commits: - 3d650b2b: Gtk DND port for Linux Changes: https://git.openjdk.java.net/jfx/pull/4/files Webrev: https://webrevs.openjdk.java.net/jfx/4/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225571 Stats: 669 lines in 5 files changed: 81 ins; 442 del; 146 mod Patch: https://git.openjdk.java.net/jfx/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4 PR: https://git.openjdk.java.net/jfx/pull/4 From tsayao at openjdk.org Wed Oct 2 19:54:50 2019 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 2 Oct 2019 19:54:50 GMT Subject: RFR: 8225571: Port DND source to use GTK instead of GDK In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 19:54:50 GMT, Kevin Rushforth wrote: > On Wed, 2 Oct 2019 19:54:48 GMT, Thiago Milczarek Sayao wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8225571 >> >> To run tests (on the root of the source tree): >> ./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 >> >> ---------------- >> >> Commits: >> - 3d650b2b: Gtk DND port for Linux >> >> Changes: https://git.openjdk.java.net/jfx/pull/4/files >> Webrev: https://webrevs.openjdk.java.net/jfx/4/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8225571 >> Stats: 669 lines in 5 files changed: 81 ins; 442 del; 146 mod >> Patch: https://git.openjdk.java.net/jfx/pull/4.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4 > > @tsayao In your case `/covered` isn't what's needed. You have an OpenJDK ID so should do this instead: > >> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user tsayao" as summary for the issue. Yes, noticed that while reading the comment again. I have opened an issue. Thanks. PR: https://git.openjdk.java.net/jfx/pull/4 From kcr at openjdk.org Wed Oct 2 19:54:50 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Oct 2019 19:54:50 GMT Subject: RFR: 8225571: Port DND source to use GTK instead of GDK In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 19:54:48 GMT, Thiago Milczarek Sayao wrote: > https://bugs.openjdk.java.net/browse/JDK-8225571 > > To run tests (on the root of the source tree): > ./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 > > ---------------- > > Commits: > - 3d650b2b: Gtk DND port for Linux > > Changes: https://git.openjdk.java.net/jfx/pull/4/files > Webrev: https://webrevs.openjdk.java.net/jfx/4/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8225571 > Stats: 669 lines in 5 files changed: 81 ins; 442 del; 146 mod > Patch: https://git.openjdk.java.net/jfx/pull/4.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4 @tsayao In your case `/covered` isn't what's needed. You have an OpenJDK ID so should do this instead: > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user tsayao" as summary for the issue. PR: https://git.openjdk.java.net/jfx/pull/4 From kcr at openjdk.org Wed Oct 2 20:02:22 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Oct 2019 20:02:22 GMT Subject: RFR: 8225571: Port DND source to use GTK instead of GDK In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 19:54:50 GMT, Thiago Milczarek Sayao wrote: > On Wed, 2 Oct 2019 19:54:50 GMT, Kevin Rushforth wrote: > >> On Wed, 2 Oct 2019 19:54:48 GMT, Thiago Milczarek Sayao wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8225571 >>> >>> To run tests (on the root of the source tree): >>> ./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 >>> >>> ---------------- >>> >>> Commits: >>> - 3d650b2b: Gtk DND port for Linux >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/4/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/4/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8225571 >>> Stats: 669 lines in 5 files changed: 81 ins; 442 del; 146 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/4.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4 >> >> @tsayao In your case `/covered` isn't what's needed. You have an OpenJDK ID so should do this instead: >> >>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user tsayao" as summary for the issue. > > Yes, noticed that while reading the comment again. I have opened an issue. Thanks. @pankaj-bansal can you review this as well? PR: https://git.openjdk.java.net/jfx/pull/4 From kevin.rushforth at oracle.com Wed Oct 2 21:10:28 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 2 Oct 2019 14:10:28 -0700 Subject: Changes to layout behavior? In-Reply-To: <058EEFF4-86E5-4B76-A089-71FF9A145212@gmail.com> References: <058EEFF4-86E5-4B76-A089-71FF9A145212@gmail.com> Message-ID: <5159062e-cfac-3ef0-8362-285500677bf3@oracle.com> There were a few bug fixes in layout and scene graph in JDK 9 and 10 that might be relevant. Here are a couple to look at: https://bugs.openjdk.java.net/browse/JDK-8137252 https://bugs.openjdk.java.net/browse/JDK-8173796 -- Kevin On 10/1/2019 5:05 AM, Dirk Lemmermann wrote: > Hi, > > I recently noticed that some of my frameworks constantly run the layoutChildren() method of their skins when they are being executed with Java 11+. I assume the reason is that I am adding nodes to the scenegraph INSIDE the layoutChildren() method. This used to work very well, but now it causes an infinite loop. The controls are still responsive, but I can see high CPU and memory usage because of it. > > Does anyone know what has changed between 8 and 11 that could have caused this change in behavior? > > ?Dirk > jfx-days.com > From aghaisas at openjdk.org Thu Oct 3 16:30:19 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Oct 2019 16:30:19 GMT Subject: [Approved] RFR: 8231735: gradle checkrepo is obsolete and doesn't work with git In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 13:48:58 GMT, Kevin Rushforth wrote: > https://bugs.openjdk.java.net/browse/JDK-8231735 > > This removes the obsolete `checkrepo` and `checkrepoall` gradle tasks. They use a script which assumes Mercurial support, and so no longer run. Also, with `git jcheck` support now available, these tasks are no longer needed. > > ---------------- > > Commits: > - 3b44a0d4: 8231735: gradle checkrepo is obsolete and doesn't work with git > > Changes: https://git.openjdk.java.net/jfx/pull/2/files > Webrev: https://webrevs.openjdk.java.net/jfx/2/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231735 > Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/2.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/2/head:pull/2 Approved by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/2 From duke at openjdk.java.net Thu Oct 3 16:58:23 2019 From: duke at openjdk.java.net (duke) Date: Thu, 3 Oct 2019 16:58:23 GMT Subject: [Integrated] RFR: 8231735: gradle checkrepo is obsolete and doesn't work with git In-Reply-To: References: Message-ID: Changeset: f595cc19 Author: Kevin Rushforth Date: 2019-10-03 16:58:02 +0000 URL: https://git.openjdk.java.net/jfx/commit/f595cc19 8231735: gradle checkrepo is obsolete and doesn't work with git Reviewed-by: aghaisas ! build.gradle From almatvee at openjdk.org Thu Oct 3 21:31:15 2019 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 3 Oct 2019 21:31:15 GMT Subject: [Approved] RFR: 8231590: Update location of jfx repo to GitHub in third-party legal files In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 14:11:37 GMT, Kevin Rushforth wrote: > https://bugs.openjdk.java.net/browse/JDK-8231590 > > Replaces http://hg.openjdk.java.net/openjfx/jfx/rt with https://github.com/openjdk/jfx in three thred-party legal files. After this change, there are no more references to `hg.openjdk.java.net` in the repo. > > ---------------- > > Commits: > - 0e606978: 8231590: Update location of jfx repo to GitHub in third-party legal files > > Changes: https://git.openjdk.java.net/jfx/pull/3/files > Webrev: https://webrevs.openjdk.java.net/jfx/3/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231590 > Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/3.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/3/head:pull/3 Looks good. ---------------- Approved by almatvee (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/3 From duke at openjdk.java.net Thu Oct 3 21:49:21 2019 From: duke at openjdk.java.net (duke) Date: Thu, 3 Oct 2019 21:49:21 GMT Subject: [Integrated] RFR: 8231590: Update location of jfx repo to GitHub in third-party legal files In-Reply-To: References: Message-ID: Changeset: 0a0d34a0 Author: Kevin Rushforth Date: 2019-10-03 21:48:44 +0000 URL: https://git.openjdk.java.net/jfx/commit/0a0d34a0 8231590: Update location of jfx repo to GitHub in third-party legal files Reviewed-by: almatvee ! modules/javafx.media/src/main/legal/glib.md ! modules/javafx.media/src/main/legal/gstreamer.md ! modules/javafx.web/src/main/legal/webkit.md From kcr at openjdk.org Thu Oct 3 23:15:56 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Oct 2019 23:15:56 GMT Subject: RFR: 8231854: Change Mercurial to git in various README files Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231854 Follow-on fix to [JDK-8231590](https://bugs.openjdk.java.net/browse/JDK-8231590) -- PR #3 -- to change Mercurial or hg to git in a few README files where appropriate. ---------------- Commits: - bb9544ac: 8231854: Change Mercurial to git in various README files Changes: https://git.openjdk.java.net/jfx/pull/7/files Webrev: https://webrevs.openjdk.java.net/jfx/7/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231854 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/7/head:pull/7 PR: https://git.openjdk.java.net/jfx/pull/7 From shadzic at openjdk.org Fri Oct 4 06:13:48 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Fri, 4 Oct 2019 06:13:48 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation Message-ID: Allright, this is a fix for JDK-8207957 ---------------- Commits: - 969ebb51: Fixing TableColumnHeaderTest - 9d379619: Removing Tablecolumnbasehelper - 4fe020fc: Fix javadoc for TableColumnHeader - c422c80f: Minor modification and uni test added. - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader - d91c56e5: First attempt to extract resizeColumnToFitContent Changes: https://git.openjdk.java.net/jfx/pull/6/files Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx/pull/6 From Dell.Green at ideaworks.co.uk Fri Oct 4 08:43:26 2019 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Fri, 4 Oct 2019 08:43:26 +0000 Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains Message-ID: Please review the fix for Updated armv6hf crosslibs script with new domains: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 https://github.com/openjdk/jfx/pull/8 From Dell.Green at ideaworks.co.uk Fri Oct 4 09:07:00 2019 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Fri, 4 Oct 2019 09:07:00 +0000 Subject: Subject: RFR: 8087980: Add property to disable Monocle cursor Message-ID: Please review the fix for Add property to disable Monocle cursor: https://bugs.openjdk.java.net/browse/JDK-8087980 https://github.com/openjdk/jfx/pull/5 From dlemmermann at gmail.com Fri Oct 4 09:59:17 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 4 Oct 2019 11:59:17 +0200 Subject: Custom Fonts in User Agent Stylesheets Message-ID: <0855FF38-13C5-4F64-8DC0-21B09BA683A7@gmail.com> I noticed today that the custom fonts I defined in a user agent stylesheet of a custom control are not being used. It only started working when I ?manually? added the stylesheet to the control via getStylesheets().add() instead of overriding getUserAgentStylesheet(). Does anyone know if this is intentional or a bug? Are there certain things that JavaFX does not support depending on the ?type? of stylesheet? Dirk From kevin.rushforth at oracle.com Fri Oct 4 12:36:01 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 Oct 2019 05:36:01 -0700 Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: Message-ID: <5d89cc54-2844-025a-2570-8042f17fbfc1@oracle.com> There is no longer a need to manually send RFR emails. Once your OCA status has been re-confirmed and entered into the Skara configuration, which is a one-time step, the Skara bot will send the RFR. Until then, we cannot review it. Thank you for your patience. -- Kevin On 10/4/2019 1:43 AM, Dell Green wrote: > > Please review the fix for Updated armv6hf crosslibs script with new > domains: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 > https://github.com/openjdk/jfx/pull/8 From ghb at openjdk.org Fri Oct 4 12:49:12 2019 From: ghb at openjdk.org (Guru Hb) Date: Fri, 4 Oct 2019 12:49:12 GMT Subject: [Approved] RFR: 8231854: Change Mercurial to git in various README files In-Reply-To: References: Message-ID: <01l1OtooO8B9mBSbQSGVSb9N5upZ1PTvr-jBVdMyV0Y=.975c46b4-ad2f-4b8c-9cbf-fd19cbc31606@github.com> On Thu, 3 Oct 2019 23:15:56 GMT, Kevin Rushforth wrote: > https://bugs.openjdk.java.net/browse/JDK-8231854 > > Follow-on fix to [JDK-8231590](https://bugs.openjdk.java.net/browse/JDK-8231590) -- PR #3 -- to change Mercurial or hg to git in a few README files where appropriate. > > ---------------- > > Commits: > - bb9544ac: 8231854: Change Mercurial to git in various README files > > Changes: https://git.openjdk.java.net/jfx/pull/7/files > Webrev: https://webrevs.openjdk.java.net/jfx/7/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231854 > Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/7.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/7/head:pull/7 Approved by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/7 From duke at openjdk.java.net Fri Oct 4 13:01:37 2019 From: duke at openjdk.java.net (duke) Date: Fri, 4 Oct 2019 13:01:37 GMT Subject: [Integrated] RFR: 8231854: Change Mercurial to git in various README files In-Reply-To: References: Message-ID: <46fc6337-20af-4458-9e2f-19bc48048601@openjdk.java.net> Changeset: c6eb0918 Author: Kevin Rushforth Date: 2019-10-04 12:59:35 +0000 URL: https://git.openjdk.java.net/jfx/commit/c6eb0918 8231854: Change Mercurial to git in various README files Reviewed-by: ghb ! apps/samples/Ensemble8/UPDATING-lucene.txt ! modules/javafx.media/src/main/legal/glib.md ! modules/javafx.media/src/main/legal/gstreamer.md ! modules/javafx.web/src/main/legal/webkit.md From David.Grieve at microsoft.com Fri Oct 4 13:38:35 2019 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 4 Oct 2019 13:38:35 +0000 Subject: Custom Fonts in User Agent Stylesheets In-Reply-To: <0855FF38-13C5-4F64-8DC0-21B09BA683A7@gmail.com> References: <0855FF38-13C5-4F64-8DC0-21B09BA683A7@gmail.com> Message-ID: This seems like a bug. Certainly overriding Region#getUserAgentStylesheet() is the preferred way of customizing styles for a control. Maybe the styles from the Region UA stylesheet aren?t being considered when doing a font lookup. That would for sure be a bug. But there are a lot of moving parts. Are there other stylesheets that might take precedence? Are there other styles in the custom stylesheet that are/are not working? Do you have a short example that reproduces the issue? Sent from Mail for Windows 10 ________________________________ From: openjfx-dev on behalf of Dirk Lemmermann Sent: Friday, October 4, 2019 5:59:17 AM To: openjfx-dev at openjdk.java.net Mailing Subject: Custom Fonts in User Agent Stylesheets I noticed today that the custom fonts I defined in a user agent stylesheet of a custom control are not being used. It only started working when I ?manually? added the stylesheet to the control via getStylesheets().add() instead of overriding getUserAgentStylesheet(). Does anyone know if this is intentional or a bug? Are there certain things that JavaFX does not support depending on the ?type? of stylesheet? Dirk From kcr at openjdk.org Fri Oct 4 23:00:00 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Oct 2019 23:00:00 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: > Allright, this is a fix for JDK-8207957 > > ---------------- > > Commits: > - 969ebb51: Fixing TableColumnHeaderTest > - 9d379619: Removing Tablecolumnbasehelper > - 4fe020fc: Fix javadoc for TableColumnHeader > - c422c80f: Minor modification and uni test added. > - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override > - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader > - d91c56e5: First attempt to extract resizeColumnToFitContent > > Changes: https://git.openjdk.java.net/jfx/pull/6/files > Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 JBS bug: [JDK-8207957](https://bugs.openjdk.java.net/browse/JDK-8207957) Review comments from preliminary review: [javafxports/openjdk-jfx/pull/289](https://github.com/javafxports/openjdk-jfx/pull/289) PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Fri Oct 4 23:03:00 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Oct 2019 23:03:00 GMT Subject: RFR: 8225571: Port DND source to use GTK instead of GDK In-Reply-To: References: Message-ID: On Wed, 2 Oct 2019 20:02:22 GMT, Kevin Rushforth wrote: > On Wed, 2 Oct 2019 19:54:50 GMT, Thiago Milczarek Sayao wrote: > >> On Wed, 2 Oct 2019 19:54:50 GMT, Kevin Rushforth wrote: >> >>> On Wed, 2 Oct 2019 19:54:48 GMT, Thiago Milczarek Sayao wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8225571 >>>> >>>> To run tests (on the root of the source tree): >>>> ./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 >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 3d650b2b: Gtk DND port for Linux >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/4/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/4/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8225571 >>>> Stats: 669 lines in 5 files changed: 81 ins; 442 del; 146 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/4.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4 >>> >>> @tsayao In your case `/covered` isn't what's needed. You have an OpenJDK ID so should do this instead: >>> >>>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user tsayao" as summary for the issue. >> >> Yes, noticed that while reading the comment again. I have opened an issue. Thanks. > > @pankaj-bansal can you review this as well? Preliminary review was here: [javafxports/openjdk-jfx/pull/490](https://github.com/javafxports/openjdk-jfx/pull/490) PR: https://git.openjdk.java.net/jfx/pull/4 From fastegal at openjdk.org Mon Oct 7 10:19:22 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 7 Oct 2019 10:19:22 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: > Allright, this is a fix for JDK-8207957 > > ---------------- > > Commits: > - 969ebb51: Fixing TableColumnHeaderTest > - 9d379619: Removing Tablecolumnbasehelper > - 4fe020fc: Fix javadoc for TableColumnHeader > - c422c80f: Minor modification and uni test added. > - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override > - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader > - d91c56e5: First attempt to extract resizeColumnToFitContent > > Changes: https://git.openjdk.java.net/jfx/pull/6/files > Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > 607: if (!tc.isResizable()) return; > 608: > 609: Object control = this.getTableSkin().getSkinnable(); see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482258 - this api still looks unhealthy .. PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Mon Oct 7 10:22:11 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 7 Oct 2019 10:22:11 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: > Allright, this is a fix for JDK-8207957 > > ---------------- > > Commits: > - 969ebb51: Fixing TableColumnHeaderTest > - 9d379619: Removing Tablecolumnbasehelper > - 4fe020fc: Fix javadoc for TableColumnHeader > - c422c80f: Minor modification and uni test added. > - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override > - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader > - d91c56e5: First attempt to extract resizeColumnToFitContent > > Changes: https://git.openjdk.java.net/jfx/pull/6/files > Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: > 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call > 600: * {@code super()}) to provide their custom algorithm. > 601: * see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Mon Oct 7 17:22:29 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Oct 2019 17:22:29 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: <5Ap-4h04FlD5VYiLxHobsWY4kOayJpwRgJynzknW-3A=.47b1832c-b6ba-4094-bd16-7c19f11a4bce@github.com> References: <5Ap-4h04FlD5VYiLxHobsWY4kOayJpwRgJynzknW-3A=.47b1832c-b6ba-4094-bd16-7c19f11a4bce@github.com> Message-ID: On Mon, 7 Oct 2019 13:35:52 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >> >> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >> >> ---------------- >> >> Commits: >> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >> >> Changes: https://git.openjdk.java.net/jfx/pull/8/files >> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 > > /signed > /covered > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231870 > > https://www.oracle.com/technetwork/community/oca-486395.html#i > > Ideaworks Ltd. - OpenJDK OpenJFX - dellgreen > > i don't know why jcheck is failing this, when a different pull-request i submitted yesterday works fine. They both look like they adhere to the guidelines? For some reason the RFR email wasn't sent. The Skara team is looking into this and should have a solution soon. In the mean time, we can proceed with the review. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Mon Oct 7 17:23:00 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Oct 2019 17:23:00 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <5Ap-4h04FlD5VYiLxHobsWY4kOayJpwRgJynzknW-3A=.47b1832c-b6ba-4094-bd16-7c19f11a4bce@github.com> Message-ID: On Mon, 7 Oct 2019 17:22:29 GMT, Kevin Rushforth wrote: > On Mon, 7 Oct 2019 13:35:52 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >> >>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>> >>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>> >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>> >>> ---------------- >>> >>> Commits: >>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >> >> /signed >> /covered >> >> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >> >> https://www.oracle.com/technetwork/community/oca-486395.html#i >> >> Ideaworks Ltd. - OpenJDK OpenJFX - dellgreen >> >> i don't know why jcheck is failing this, when a different pull-request i submitted yesterday works fine. They both look like they adhere to the guidelines? > > For some reason the RFR email wasn't sent. The Skara team is looking into this and should have a solution soon. In the mean time, we can proceed with the review. @johanvos can you review this? PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Mon Oct 7 17:30:11 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Oct 2019 17:30:11 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: Message-ID: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. > > Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 > > ---------------- > > Commits: > - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy > > Changes: https://git.openjdk.java.net/jfx/pull/8/files > Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/8.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: > 231: http://archive.debian.org/debian/ wheezy main armhf \ > 232: libatk1.0-dev \ > 233: libatk1.0-0 \ The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: > 391: $DESTINATION \ > 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ > 393: libraspberrypi-dev Same comment hear about using an `https` URL if possible. I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. PR: https://git.openjdk.java.net/jfx/pull/8 From 2093023+kenzierocks at github.github.io Mon Oct 7 17:42:21 2019 From: 2093023+kenzierocks at github.github.io (Kenzie Togami) Date: Mon, 7 Oct 2019 17:42:21 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> Message-ID: On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: > On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >> >> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >> >> ---------------- >> >> Commits: >> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >> >> Changes: https://git.openjdk.java.net/jfx/pull/8/files >> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 > > buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: > >> 231: http://archive.debian.org/debian/ wheezy main armhf \ >> 232: libatk1.0-dev \ >> 233: libatk1.0-0 \ > > The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. > > buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: > >> 391: $DESTINATION \ >> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >> 393: libraspberrypi-dev > > Same comment hear about using an `https` URL if possible. > > I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. PR: https://git.openjdk.java.net/jfx/pull/8 From ilya.kazakevich at jetbrains.com Mon Oct 7 22:14:39 2019 From: ilya.kazakevich at jetbrains.com (Ilya Kazakevich) Date: Tue, 8 Oct 2019 01:14:39 +0300 Subject: genVSproperties.bat: why unset variables? Message-ID: Hello. I was trying to build jfx for Windows using cygwin. I launched cygwin from VS prompt with all variables set, but when build failed, I realized that ``windows_tools.properties`` is almost empty. It happened because ``genVSproperties.bat`` failed to locate my toolchain and it explicitly removed my variables! REM Clean out the current settings set INCLUDE= set LIB= set LIBPATH= Why so? Is not it better to remove this lines and always launch build via VS prompt? After all, this is what it was created for) Ilya. From mike.ennen at gmail.com Mon Oct 7 22:45:08 2019 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 7 Oct 2019 15:45:08 -0700 Subject: genVSproperties.bat: why unset variables? In-Reply-To: References: Message-ID: Ilya, I also had trouble with genVSproperties.bat (as did other historically) This led me to create a Powershell build script which was merged to upstream: https://github.com/openjdk/jfx/blob/master/tools/scripts/build.ps1 I strongly recommend using it when building locally on Windows. On Mon, Oct 7, 2019 at 3:16 PM Ilya Kazakevich < ilya.kazakevich at jetbrains.com> wrote: > Hello. > > I was trying to build jfx for Windows using cygwin. > I launched cygwin from VS prompt with all variables set, but when build > failed, > I realized that ``windows_tools.properties`` is almost empty. > > It happened because ``genVSproperties.bat`` failed to locate my toolchain > and > it explicitly removed my variables! > > REM Clean out the current settings > set INCLUDE= > set LIB= > set LIBPATH= > > Why so? Is not it better to remove this lines and always launch build via > VS prompt? > After all, this is what it was created for) > > Ilya. > -- Michael Ennen From jvos at openjdk.org Tue Oct 8 08:41:40 2019 From: jvos at openjdk.org (Johan Vos) Date: Tue, 8 Oct 2019 08:41:40 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> Message-ID: On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: > >> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >> >>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>> >>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>> >>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>> >>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>> >>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>> >>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>> 232: libatk1.0-dev \ >>>> 233: libatk1.0-0 \ >>> >>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>> >>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>> >>>> 391: $DESTINATION \ >>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>> 393: libraspberrypi-dev >>> >>> Same comment hear about using an `https` URL if possible. >>> >>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >> >> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >> >> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. > > https for legacy.raspbian.org works I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. I think this PR is good as it is, as it fixes something that was broken. However, in general I think the concept of this crosslibs script is broken for a number of reasons: 1. for none of the other targets, we have a script for downloading the toolchain. 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. I therefore propose to merge this PR. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Tue Oct 8 11:58:43 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Oct 2019 11:58:43 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> Message-ID: On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: > On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >> >>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>> >>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>> >>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>> >>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>> >>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>> >>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>> >>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>> 232: libatk1.0-dev \ >>>>> 233: libatk1.0-0 \ >>>> >>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>> >>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>> >>>>> 391: $DESTINATION \ >>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>> 393: libraspberrypi-dev >>>> >>>> Same comment hear about using an `https` URL if possible. >>>> >>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>> >>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>> >>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >> >> https for legacy.raspbian.org works > > I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. > I think this PR is good as it is, as it fixes something that was broken. > > However, in general I think the concept of this crosslibs script is broken for a number of reasons: > 1. for none of the other targets, we have a script for downloading the toolchain. > 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. > > Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. > > I therefore propose to merge this PR. I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Tue Oct 8 11:59:52 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Oct 2019 11:59:52 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> Message-ID: On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: > On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: > >> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >> >>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >>> >>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>>> >>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>> >>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>>> >>>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>>> >>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>>> >>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>>> >>>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>>> 232: libatk1.0-dev \ >>>>>> 233: libatk1.0-0 \ >>>>> >>>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>>> >>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>>> >>>>>> 391: $DESTINATION \ >>>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>>> 393: libraspberrypi-dev >>>>> >>>>> Same comment hear about using an `https` URL if possible. >>>>> >>>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>>> >>>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>>> >>>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>> >>> https for legacy.raspbian.org works >> >> I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. >> I think this PR is good as it is, as it fixes something that was broken. >> >> However, in general I think the concept of this crosslibs script is broken for a number of reasons: >> 1. for none of the other targets, we have a script for downloading the toolchain. >> 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. >> >> Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. >> >> I therefore propose to merge this PR. > > I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. Looks like that worked and reran jcheck. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Tue Oct 8 12:02:22 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Oct 2019 12:02:22 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> Message-ID: On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth wrote: > On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: > >> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: >> >>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>> >>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >>>> >>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>> >>>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>>>> >>>>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>>>> >>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>>>> >>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>>>> >>>>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>>>> 232: libatk1.0-dev \ >>>>>>> 233: libatk1.0-0 \ >>>>>> >>>>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>>>> >>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>>>> >>>>>>> 391: $DESTINATION \ >>>>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>>>> 393: libraspberrypi-dev >>>>>> >>>>>> Same comment hear about using an `https` URL if possible. >>>>>> >>>>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>>>> >>>>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>>>> >>>>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>>> >>>> https for legacy.raspbian.org works >>> >>> I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. >>> I think this PR is good as it is, as it fixes something that was broken. >>> >>> However, in general I think the concept of this crosslibs script is broken for a number of reasons: >>> 1. for none of the other targets, we have a script for downloading the toolchain. >>> 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. >>> >>> Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. >>> >>> I therefore propose to merge this PR. >> >> I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. > > Looks like that worked and reran jcheck. Please ignore the above comments. I added them to the wrong PR. This PR was and still is ready for review. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Tue Oct 8 12:03:46 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Oct 2019 12:03:46 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. > > NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. > > A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. > > ---------------- > > Commits: > - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor > > Changes: https://git.openjdk.java.net/jfx/pull/5/files > Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/5.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. ---------------- Disapproved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/5 From kcr at openjdk.org Tue Oct 8 12:03:45 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Oct 2019 12:03:45 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: On Tue, 8 Oct 2019 12:03:44 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >> >> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >> >> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >> >> ---------------- >> >> Commits: >> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >> >> Changes: https://git.openjdk.java.net/jfx/pull/5/files >> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > > /signed > /covered > > https://www.oracle.com/technetwork/community/oca-486395.html#i > > Ideaworks Ltd. - OpenJDK OpenJFX - dellgreen Hold on a minute. There is clearly some bug in the Skara tooling, since this change has *not* yet been reviewed, and is therefore *not* ready to integrate. am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. PR: https://git.openjdk.java.net/jfx/pull/5 From kcr at openjdk.org Tue Oct 8 13:54:22 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Oct 2019 13:54:22 GMT Subject: RFR: 8226754: FX build fails using gradle 5.6+ or 6 Message-ID: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. The changes are as follows: 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` 3. Specify no metadata for ivy repositories 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. ---------------- Commits: - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 Changes: https://git.openjdk.java.net/jfx/pull/9/files Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 PR: https://git.openjdk.java.net/jfx/pull/9 From john at status6.com Tue Oct 8 15:28:31 2019 From: john at status6.com (John Neffenger) Date: Tue, 8 Oct 2019 08:28:31 -0700 Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> Message-ID: <72978cb4-1403-63ac-77a0-9de1aec7102c@status6.com> On 10/8/19 1:41 AM, Johan Vos wrote: > Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. It would be nice to use the cross-compile tools that come with my system (Ubuntu 16.04) as I do when building the JDK. I may be able to help with that once I understand Gradle a lot better. For the JDK, I install the package "crossbuild-essential-armhf" and I get the GNU C Compiler for armhf: build/linux-arm-server-release/configure.log ==================================================== A new configuration has been successfully created in /home/ubuntu/src/jdk13/build/linux-arm-server-release using configure arguments '--openjdk-target=arm-linux-gnueabihf --with-native-debug-symbols=none'. ... Tools summary: * Boot JDK: openjdk version "12.0.2" 2019-07-16 OpenJDK Runtime Environment (build 12.0.2+10) OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode, sharing) (at /home/ubuntu/opt/jdk-12.0.2) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 5.4.0 (at /usr/bin/arm-linux-gnueabihf-gcc) * C++ Compiler: Version 5.4.0 (at /usr/bin/arm-linux-gnueabihf-g++) ==================================================== Is a package like this not available where we build JavaFX for armhf? John From sverre.moe at gmail.com Tue Oct 8 17:08:38 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 8 Oct 2019 19:08:38 +0200 Subject: JavaFX dialog window size regression In-Reply-To: References: Message-ID: Can we get the fix for JDK-8179073 [1] backported to JavaFX 11? As discussed on the openjfx GitHub issue #222 [2]. It seems to have a fix already in PR #456 [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8179073 [2] https://github.com/javafxports/openjdk-jfx/issues/222 [3] https://github.com/javafxports/openjdk-jfx/pull/456 /Sverre tor. 26. apr. 2018 kl. 21:35 skrev Sverre Moe : > I filed a bug report a while back. Since I didn't have access I could > not comment or update in that issue. > > https://bugs.openjdk.java.net/browse/JDK-8179073 > > With Java 9, a JavaFX dialogs got tiny and did not size up to its content. > This worked fine when I was running JDK 9 build 161, but after JDK 9 > build 165 the dialog window did not size up to show any of its > content. > > The code exampled I provided with that bug report still produces a > tiny dialog window with both jdk-9.0.4 and jdk-10.0.1 > > Setting the Dialog size to fixed width/height does not work, but if > with setResizable(true) the Dialog gets its full size. > > It has been a while since I have used Java 9. Today I got the same > problem while trying to exit SceneBuilder 9 downloaded from Gluon. > > I was wondering if I should re-create this bug report on the GitHub > OpenJFX repository? > From jvos at openjdk.org Wed Oct 9 07:41:24 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 9 Oct 2019 07:41:24 GMT Subject: [Approved] RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: Message-ID: On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. > > Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 > > ---------------- > > Commits: > - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy > > Changes: https://git.openjdk.java.net/jfx/pull/8/files > Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/8.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 I am ok with the PR as is. The decision on how to install build tools (e.g. via apt-get, via a zip download, over http, over https) is not part of the code repository, and can be specific to the distributor. This PR fixes something that was broken (unavailable host) so +1 for this. ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/8 From jvos at openjdk.org Wed Oct 9 07:50:44 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 9 Oct 2019 07:50:44 GMT Subject: RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: On Tue, 8 Oct 2019 13:54:22 GMT, Kevin Rushforth wrote: > JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) > > As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). > > The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). > > The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. > > The changes are as follows: > > 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x > 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` > 3. Specify no metadata for ivy repositories > 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir > 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) > > I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. > > ---------------- > > Commits: > - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 > > Changes: https://git.openjdk.java.net/jfx/pull/9/files > Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 > Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/9.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 build.gradle line 1836: > 1835: url JFX_DEPS_URL > 1836: metadataSources { > 1837: artifact() >From the JBS entry, I understood for now you wanted to keep layout (instead of patternLayout): https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14293009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14293009 I understand the reasoning behind this (not using an incubating API), so I wonder why it is changed in this PR? PR: https://git.openjdk.java.net/jfx/pull/9 From tom.schindl at bestsolution.at Wed Oct 9 08:13:55 2019 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 9 Oct 2019 10:13:55 +0200 Subject: Question on Git History Message-ID: Hi, I'm not sure I fully understand that hg => git translation but do we see the full history https://github.com/openjdk/jfx of files or just a partial version? If I eg look at https://github.com/openjdk/jfx/commits/master/modules/javafx.graphics/src/main/java/javafx/scene/Node.java I doubt this is the fully history of this class (eg including OpenJFX-8). Another strange thing is that I see by looking at the tags (https://github.com/openjdk/jfx/tags) and releases I (https://github.com/openjdk/jfx/releases). There are some 8u* tags/releases but it's by far not all of them. Why is that? Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From venatorxoa at gmail.com Wed Oct 9 09:06:30 2019 From: venatorxoa at gmail.com (Vincent MOLLIERE) Date: Wed, 9 Oct 2019 11:06:30 +0200 Subject: Problem of compilation of OpenJFX Message-ID: Hello, I'm trying to build the latest version of OpenJFX on Windows and I have a compilation problem in JSLVisitor, it cannot find the import com.sun.scenario.effect.compiler.JSLBaseVisitor and neither do I. Where this file can be found/generated ? Thank you in advance for your help ! From kcr at openjdk.org Wed Oct 9 12:24:29 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 12:24:29 GMT Subject: RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: On Wed, 9 Oct 2019 07:50:44 GMT, Johan Vos wrote: > On Tue, 8 Oct 2019 13:54:22 GMT, Kevin Rushforth wrote: > >> JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) >> >> As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). >> >> The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). >> >> The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. >> >> The changes are as follows: >> >> 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x >> 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` >> 3. Specify no metadata for ivy repositories >> 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir >> 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) >> >> I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. >> >> ---------------- >> >> Commits: >> - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 >> >> Changes: https://git.openjdk.java.net/jfx/pull/9/files >> Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 >> Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod >> Patch: https://git.openjdk.java.net/jfx/pull/9.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 > > build.gradle line 1836: > >> 1835: url JFX_DEPS_URL >> 1836: metadataSources { >> 1837: artifact() > > From the JBS entry, I understood for now you wanted to keep layout (instead of patternLayout): https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14293009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14293009 > > I understand the reasoning behind this (not using an incubating API), so I wonder why it is changed in this PR? I think you meant to point to [this earlier comment](https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14273845&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14273845) that I made back in June. Yes, I had indicated that I wanted to wait until gradle 6 builds were available before switching from `layout` to `patternLayout`, in case they made any changes. Your question does raise a good point, though: Should we wait until we actually want to switch to gradle 6 before making this change? If so, then it might make sense to split this change into two bugs: the `layout` --> `patternLayout` changes, which would wait until we switch to gradle 6, and the rest, which would be done now. I could go either way. Which do you prefer? PR: https://git.openjdk.java.net/jfx/pull/9 From shadzic at openjdk.org Wed Oct 9 12:25:26 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 9 Oct 2019 12:25:26 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Wed Oct 9 12:26:31 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 9 Oct 2019 12:26:31 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: > On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: > >> Allright, this is a fix for JDK-8207957 >> >> ---------------- >> >> Commits: >> - 969ebb51: Fixing TableColumnHeaderTest >> - 9d379619: Removing Tablecolumnbasehelper >> - 4fe020fc: Fix javadoc for TableColumnHeader >> - c422c80f: Minor modification and uni test added. >> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >> - d91c56e5: First attempt to extract resizeColumnToFitContent >> >> Changes: https://git.openjdk.java.net/jfx/pull/6/files >> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: > >> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >> 600: * {@code super()}) to provide their custom algorithm. >> 601: * > > see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. PR: https://git.openjdk.java.net/jfx/pull/6 From jvos at openjdk.org Wed Oct 9 12:38:09 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 9 Oct 2019 12:38:09 GMT Subject: RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: On Wed, 9 Oct 2019 12:24:29 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 07:50:44 GMT, Johan Vos wrote: > >> On Tue, 8 Oct 2019 13:54:22 GMT, Kevin Rushforth wrote: >> >>> JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) >>> >>> As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). >>> >>> The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). >>> >>> The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. >>> >>> The changes are as follows: >>> >>> 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x >>> 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` >>> 3. Specify no metadata for ivy repositories >>> 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir >>> 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) >>> >>> I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. >>> >>> ---------------- >>> >>> Commits: >>> - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/9/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 >>> Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/9.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 >> >> build.gradle line 1836: >> >>> 1835: url JFX_DEPS_URL >>> 1836: metadataSources { >>> 1837: artifact() >> >> From the JBS entry, I understood for now you wanted to keep layout (instead of patternLayout): https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14293009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14293009 >> >> I understand the reasoning behind this (not using an incubating API), so I wonder why it is changed in this PR? > > I think you meant to point to [this earlier comment](https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14273845&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14273845) that I made back in June. Yes, I had indicated that I wanted to wait until gradle 6 builds were available before switching from `layout` to `patternLayout`, in case they made any changes. > > Your question does raise a good point, though: Should we wait until we actually want to switch to gradle 6 before making this change? If so, then it might make sense to split this change into two bugs: the `layout` --> `patternLayout` changes, which would wait until we switch to gradle 6, and the rest, which would be done now. > > I could go either way. Which do you prefer? https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.repositories.IvyArtifactRepository.html still shows `patternLayout` to be incubating. Gradle doesn't have an excellent track record for finishing incubating API's (e.g. https://github.com/spring-projects/spring-boot/issues/11640). Hence, I think it is indeed safer not to switch from a deprecated API to an incubating API (and as a result, split the PR so that the `layout` --> `patternLayout` is not included for now. I don't have a very strong opinion on this though, so if you want to keep the changes, I don't object that. PR: https://git.openjdk.java.net/jfx/pull/9 From kevin.rushforth at oracle.com Wed Oct 9 13:16:17 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 Oct 2019 06:16:17 -0700 Subject: Question on Git History In-Reply-To: References: Message-ID: <87d0dcc5-04bb-1a2e-f5e1-cf75cbfd21e6@oracle.com> inline On 10/9/2019 1:13 AM, Tom Schindl wrote: > Hi, > > I'm not sure I fully understand that hg => git translation but do we see > the full history https://github.com/openjdk/jfx of files or just a > partial version? It's a full history, identical to the HG repo. > If I eg look at > https://github.com/openjdk/jfx/commits/master/modules/javafx.graphics/src/main/java/javafx/scene/Node.java > I doubt this is the fully history of this class (eg including OpenJFX-8). This is a known limitation of the GitHub UI interface. The history for a file is shown using the equivalent of "git log filename" which won't show history across file renames. If you have a local clone you can do this: git log --follow filename Btw, this is the same behavior that you will see with HG: "hg log filename" will not follow renames, but "hg log --follow filename" does. > Another strange thing is that I see by looking at the tags > (https://github.com/openjdk/jfx/tags) and releases I > (https://github.com/openjdk/jfx/releases). There are some 8u* > tags/releases but it's by far not all of them. Why is that? This also matches the HG repo, as can be seen here: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/tags The only reason it has any 8u tags at all is that up until partway through the 8u60 release, we were doing all FX development in 8u and forward syncing all changesets to 9. We stopped auto-syncing after 8u60-b08 as announced in this message [1]. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2015-March/016826.html From kevin.rushforth at oracle.com Wed Oct 9 13:19:59 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 9 Oct 2019 06:19:59 -0700 Subject: Problem of compilation of OpenJFX In-Reply-To: References: Message-ID: <39119d10-5785-27b4-5c33-9110357079c3@oracle.com> This class is generated by antlr during the build: modules/javafx.graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler/JSLBaseVisitor.java You? may be using an old 3.x version of anltlr, although the build should download the latest antlr4 for you. Make sure that you have a clean repo with no leftovers from an older build. -- Kevin On 10/9/2019 2:06 AM, Vincent MOLLIERE wrote: > Hello, > I'm trying to build the latest version of OpenJFX on Windows and I have a > compilation problem in JSLVisitor, it cannot find the > import com.sun.scenario.effect.compiler.JSLBaseVisitor and neither do I. > Where this file can be found/generated ? > Thank you in advance for your help ! From github.com+24428922+arun-Joseph at openjdk.org Wed Oct 9 13:25:54 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Wed, 9 Oct 2019 13:25:54 GMT Subject: RFR: 8218640: Update ICU4C to version 64.2 Message-ID: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> We currently use ICU4C version 62.1. We should update to the latest stable version 64.2. http://site.icu-project.org/home ---------------- Commits: - b56b720e: 8218640: Update ICU4C to version 64.2 Changes: https://git.openjdk.java.net/jfx/pull/10/files Webrev: https://webrevs.openjdk.java.net/jfx/10/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8218640 Stats: 41065 lines in 430 files changed: 23684 ins; 7205 del; 10176 mod Patch: https://git.openjdk.java.net/jfx/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/10/head:pull/10 PR: https://git.openjdk.java.net/jfx/pull/10 From kcr at openjdk.org Wed Oct 9 13:34:28 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 13:34:28 GMT Subject: RFR: 8218640: Update ICU4C to version 64.2 In-Reply-To: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> References: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> Message-ID: On Wed, 9 Oct 2019 13:25:54 GMT, Arun Joseph wrote: > We currently use ICU4C version 62.1. We should update to the latest stable version 64.2. > http://site.icu-project.org/home > > ---------------- > > Commits: > - b56b720e: 8218640: Update ICU4C to version 64.2 > > Changes: https://git.openjdk.java.net/jfx/pull/10/files > Webrev: https://webrevs.openjdk.java.net/jfx/10/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8218640 > Stats: 41065 lines in 430 files changed: 23684 ins; 7205 del; 10176 mod > Patch: https://git.openjdk.java.net/jfx/pull/10.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/10/head:pull/10 This will need two reviewers. Also, @johanvos @tiainen - can one of you do a test build to make sure that there are no problems with this update? PR: https://git.openjdk.java.net/jfx/pull/10 From venatorxoa at gmail.com Wed Oct 9 14:01:18 2019 From: venatorxoa at gmail.com (Vincent MOLLIERE) Date: Wed, 9 Oct 2019 16:01:18 +0200 Subject: Problem of compilation of OpenJFX In-Reply-To: <39119d10-5785-27b4-5c33-9110357079c3@oracle.com> References: <39119d10-5785-27b4-5c33-9110357079c3@oracle.com> Message-ID: Thank you for you answer but its seems its using the 4.7.2. I pasted the java-compiler-args.txt of the command generating the files : -source 11 -target 11 -d D:\\Git\\jfx\\modules\\javafx.graphics\\build\\classes\\java\\jslc -nowarn -g:source,lines,vars -sourcepath "" -proc:none -s D:\\Git\\jfx\\modules\\javafx.graphics\\build\\generated\\sources\\annotationProcessor\\java\\jslc -XDuseUnsharedTable=true -classpath C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4\\4.7.2\\34fc363424d3b060b660f84974a82d6bdc7ebe0c\\antlr4-4.7.2-complete.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4-runtime\\4.7.2\\e27d8ab4f984f9d186f54da984a6ab1cccac755e\\antlr4-runtime-4.7.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\ST4\\4.1\\467d508be07a542ad0a68ffcaed2d561c5fb2e0c\\ST4-4.1.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr-runtime\\3.5.2\\cd9cd41361c155f3af0f653009dcecb08d8b4afd\\antlr-runtime-3.5.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.abego.treelayout\\org.abego.treelayout.core\\1.0.3\\457216e8e6578099ae63667bb1e4439235892028\\org.abego.treelayout.core-1.0.3.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.glassfish\\javax.json\\1.0.4\\3178f73569fd7a1e5ffc464e680f7a8cc784b85a\\javax.json-1.0.4.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\com.ibm.icu\\icu4j\\61.1\\28d33b5e44e72edcc66a5da7a34a42147f38d987\\icu4j-61.1.jar -XDignore.symbol.file -encoding UTF-8 D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\ES2Backend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\GLSLBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\HLSLBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\SLBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\prism\\PrismBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWCallScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWFuncImpls.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWTreeScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MECallScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEFuncImpls.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\METreeScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEBackend.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSECallScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEFuncImpls.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSETreeScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\JSLC.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BaseType.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BinaryOpType.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\CoreSymbols.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\FuncImpl.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Function.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Param.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Precision.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Qualifier.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\SymbolTable.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Type.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\UnaryOpType.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Variable.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\ThrowingErrorListener.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ArrayAccessExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BinaryExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BreakStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CallExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CompoundStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ContinueStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DeclStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DiscardStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DoWhileStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Expr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExprStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExtDecl.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FieldSelectExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ForStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FuncDef.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\GlueBlock.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\JSLVisitor.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\LiteralExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ParenExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ProgramUnit.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ReturnStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\SelectStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Stmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Tree.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeMaker.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeScanner.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeVisitor.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\UnaryExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VarDecl.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VariableExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VectorCtorExpr.java D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\WhileStmt.java D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLBaseListener.java D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLLexer.java D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLListener.java D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLParser.java What do you think about it ? Le mer. 9 oct. 2019 ? 15:20, Kevin Rushforth a ?crit : > This class is generated by antlr during the build: > > > modules/javafx.graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler/JSLBaseVisitor.java > > You may be using an old 3.x version of anltlr, although the build > should download the latest antlr4 for you. Make sure that you have a > clean repo with no leftovers from an older build. > > -- Kevin > > On 10/9/2019 2:06 AM, Vincent MOLLIERE wrote: > > Hello, > > I'm trying to build the latest version of OpenJFX on Windows and I have a > > compilation problem in JSLVisitor, it cannot find the > > import com.sun.scenario.effect.compiler.JSLBaseVisitor and neither do I. > > Where this file can be found/generated ? > > Thank you in advance for your help ! > > From kcr at openjdk.org Wed Oct 9 15:18:58 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 15:18:58 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: <8J_Tk8_6Zo_uNr-mkzdP3k1p5gA6YA09pZ_gLy_1eT4=.f7bf734f-d918-4408-90d9-c8bbb178a329@github.com> References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> <8J_Tk8_6Zo_uNr-mkzdP3k1p5gA6YA09pZ_gLy_1eT4=.f7bf734f-d918-4408-90d9-c8bbb178a329@github.com> Message-ID: On Wed, 9 Oct 2019 07:43:43 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > On Tue, 8 Oct 2019 12:02:22 GMT, Kevin Rushforth wrote: > >> On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth wrote: >> >>> On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: >>>> >>>>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>> >>>>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >>>>>> >>>>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>>>>>> >>>>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>>> >>>>>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>>>>>> >>>>>>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>>>>>> >>>>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>>>>>> >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>> Commits: >>>>>>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>>>>>> >>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>>>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>>>>>> >>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>>>>>> >>>>>>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>>>>>> 232: libatk1.0-dev \ >>>>>>>>> 233: libatk1.0-0 \ >>>>>>>> >>>>>>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>>>>>> >>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>>>>>> >>>>>>>>> 391: $DESTINATION \ >>>>>>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>>>>>> 393: libraspberrypi-dev >>>>>>>> >>>>>>>> Same comment hear about using an `https` URL if possible. >>>>>>>> >>>>>>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>>>>>> >>>>>>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>>>>>> >>>>>>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>>>>> >>>>>> https for legacy.raspbian.org works >>>>> >>>>> I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. >>>>> I think this PR is good as it is, as it fixes something that was broken. >>>>> >>>>> However, in general I think the concept of this crosslibs script is broken for a number of reasons: >>>>> 1. for none of the other targets, we have a script for downloading the toolchain. >>>>> 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. >>>>> >>>>> Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. >>>>> >>>>> I therefore propose to merge this PR. >>>> >>>> I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. >>> >>> Looks like that worked and reran jcheck. >> >> Please ignore the above comments. I added them to the wrong PR. >> >> This PR was and still is ready for review. > > I'll suspend testing of the https domains as previously mentioned. @dellgreen once you are ready, go ahead and issue the `/integrate` command. Presuming that @johanvos will sponsor this, he can then issue the `/sponsor` command after double-checking the commit message, etc. PR: https://git.openjdk.java.net/jfx/pull/8 From nlisker at openjdk.org Wed Oct 9 15:49:21 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 9 Oct 2019 15:49:21 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/6/files > - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java line 170: > 169: TableColumnHeader columnHeader = tableHeader.getColumnHeaderFor(column); > 170: if(columnHeader != null){ > 171: columnHeader.resizeColumnToFitContent(-1); Space after `if` and before `{`. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > 607: protected void resizeColumnToFitContent(int maxRows) { > 608: TableColumnBase tc = getTableColumn(); > 609: if (!tc.isResizable()) return; Here's my suggestion (mind the max character length per line): Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells.

Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 618: > 617: } > 618: > 619: private void resizeColumnToFitContent(TableView tv, TableColumn tc, TableViewSkinBase tableSkin, int maxRows) { I think we put a space when casting, like `(TableView) control`. Not sure if it is a rule. Since you are adding new API you will need to file a CSR once the API review id done. ---------------- Disapproved by nlisker (Committer). PR: https://git.openjdk.java.net/jfx/pull/6 From mike.ennen at gmail.com Wed Oct 9 15:50:58 2019 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 9 Oct 2019 08:50:58 -0700 Subject: Problem of compilation of OpenJFX In-Reply-To: References: <39119d10-5785-27b4-5c33-9110357079c3@oracle.com> Message-ID: Can you paste the full build log somewhere (not inline on the mailing list)? On Wed, Oct 9, 2019 at 7:02 AM Vincent MOLLIERE wrote: > Thank you for you answer but its seems its using the 4.7.2. I pasted the > java-compiler-args.txt of the command generating the files : > -source > 11 > -target > 11 > -d > D:\\Git\\jfx\\modules\\javafx.graphics\\build\\classes\\java\\jslc > -nowarn > -g:source,lines,vars > -sourcepath > "" > -proc:none > -s > > D:\\Git\\jfx\\modules\\javafx.graphics\\build\\generated\\sources\\annotationProcessor\\java\\jslc > -XDuseUnsharedTable=true > -classpath > > C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4\\4.7.2\\34fc363424d3b060b660f84974a82d6bdc7ebe0c\\antlr4-4.7.2-complete.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4-runtime\\4.7.2\\e27d8ab4f984f9d186f54da984a6ab1cccac755e\\antlr4-runtime-4.7.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\ST4\\4.1\\467d508be07a542ad0a68ffcaed2d561c5fb2e0c\\ST4-4.1.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr-runtime\\3.5.2\\cd9cd41361c155f3af0f653009dcecb08d8b4afd\\antlr-runtime-3.5.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.abego.treelayout\\org.abego.treelayout.core\\1.0.3\\457216e8e6578099ae63667bb1e4439235892028\\org.abego.treelayout.core-1.0.3.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.glassfish\\javax.json\\1.0.4\\3178f73569fd7a1e5ffc464e680f7a8cc784b85a\\javax.json-1.0.4.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\com.ibm.icu\\icu4j\\61.1\\28d33b5e44e72edcc66a5da7a34a42147f38d987\\icu4j-61.1.jar > -XDignore.symbol.file > -encoding > UTF-8 > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\ES2Backend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\GLSLBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\HLSLBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\SLBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\prism\\PrismBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWCallScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWFuncImpls.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWTreeScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MECallScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEFuncImpls.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\METreeScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEBackend.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSECallScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEFuncImpls.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSETreeScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\JSLC.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BaseType.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BinaryOpType.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\CoreSymbols.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\FuncImpl.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Function.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Param.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Precision.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Qualifier.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\SymbolTable.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Type.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\UnaryOpType.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Variable.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\ThrowingErrorListener.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ArrayAccessExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BinaryExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BreakStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CallExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CompoundStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ContinueStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DeclStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DiscardStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DoWhileStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Expr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExprStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExtDecl.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FieldSelectExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ForStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FuncDef.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\GlueBlock.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\JSLVisitor.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\LiteralExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ParenExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ProgramUnit.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ReturnStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\SelectStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Stmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Tree.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeMaker.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeScanner.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeVisitor.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\UnaryExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VarDecl.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VariableExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VectorCtorExpr.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\WhileStmt.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLBaseListener.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLLexer.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLListener.java > > D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLParser.java > > What do you think about it ? > > Le mer. 9 oct. 2019 ? 15:20, Kevin Rushforth > a > ?crit : > > > This class is generated by antlr during the build: > > > > > > > modules/javafx.graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler/JSLBaseVisitor.java > > > > You may be using an old 3.x version of anltlr, although the build > > should download the latest antlr4 for you. Make sure that you have a > > clean repo with no leftovers from an older build. > > > > -- Kevin > > > > On 10/9/2019 2:06 AM, Vincent MOLLIERE wrote: > > > Hello, > > > I'm trying to build the latest version of OpenJFX on Windows and I > have a > > > compilation problem in JSLVisitor, it cannot find the > > > import com.sun.scenario.effect.compiler.JSLBaseVisitor and neither do > I. > > > Where this file can be found/generated ? > > > Thank you in advance for your help ! > > > > > -- Michael Ennen From kcr at openjdk.org Wed Oct 9 16:01:38 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 16:01:38 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: > On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: > >> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >> >>> Allright, this is a fix for JDK-8207957 >>> >>> ---------------- >>> >>> Commits: >>> - 969ebb51: Fixing TableColumnHeaderTest >>> - 9d379619: Removing Tablecolumnbasehelper >>> - 4fe020fc: Fix javadoc for TableColumnHeader >>> - c422c80f: Minor modification and uni test added. >>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >> >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >> >>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>> 600: * {@code super()}) to provide their custom algorithm. >>> 601: * >> >> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) > > Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. > > I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Wed Oct 9 16:09:07 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 16:09:07 GMT Subject: RFR: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: > Fix for https://github.com/javafxports/openjdk-jfx/issues/573 > > Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 > > I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. > > ---------------- > > Commits: > - e9df9db5: Adding double-quote for HTMLEditorSkin font-family > > Changes: https://git.openjdk.java.net/jfx/pull/12/files > Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 > Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod > Patch: https://git.openjdk.java.net/jfx/pull/12.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 @Maxoudela please edit the title as follows: 1. Remove the space before the `:` (that extra space is why jcheck failed) 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest PR: https://git.openjdk.java.net/jfx/pull/12 From shadzic at openjdk.org Wed Oct 9 16:09:06 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 9 Oct 2019 16:09:06 GMT Subject: RFR: 8230231: font-family not updated in HTMLEditor Message-ID: Fix for https://github.com/javafxports/openjdk-jfx/issues/573 Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. ---------------- Commits: - e9df9db5: Adding double-quote for HTMLEditorSkin font-family Changes: https://git.openjdk.java.net/jfx/pull/12/files Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 PR: https://git.openjdk.java.net/jfx/pull/12 From shadzic at openjdk.org Wed Oct 9 16:09:58 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 9 Oct 2019 16:09:58 GMT Subject: RFR: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: > >> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >> >> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >> >> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >> >> ---------------- >> >> Commits: >> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >> >> Changes: https://git.openjdk.java.net/jfx/pull/12/files >> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 > > @Maxoudela please edit the title as follows: > > 1. Remove the space before the `:` (that extra space is why jcheck failed) > 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. > > As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: > > gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. I'll try to add a test asap, thanks for the pointer. PR: https://git.openjdk.java.net/jfx/pull/12 From jvos at openjdk.org Wed Oct 9 16:10:28 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 9 Oct 2019 16:10:28 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> <8J_Tk8_6Zo_uNr-mkzdP3k1p5gA6YA09pZ_gLy_1eT4=.f7bf734f-d918-4408-90d9-c8bbb178a329@github.com> Message-ID: On Wed, 9 Oct 2019 15:18:58 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 07:43:43 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> On Tue, 8 Oct 2019 12:02:22 GMT, Kevin Rushforth wrote: >> >>> On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: >>>>> >>>>>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>> >>>>>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >>>>>>> >>>>>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>>>>>>> >>>>>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>>>> >>>>>>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>>>>>>> >>>>>>>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>>>>>>> >>>>>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>>>>>>> >>>>>>>>>> ---------------- >>>>>>>>>> >>>>>>>>>> Commits: >>>>>>>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>>>>>>> >>>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>>>>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>>>>>>> >>>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>>>>>>> >>>>>>>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>>>>>>> 232: libatk1.0-dev \ >>>>>>>>>> 233: libatk1.0-0 \ >>>>>>>>> >>>>>>>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>>>>>>> >>>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>>>>>>> >>>>>>>>>> 391: $DESTINATION \ >>>>>>>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>>>>>>> 393: libraspberrypi-dev >>>>>>>>> >>>>>>>>> Same comment hear about using an `https` URL if possible. >>>>>>>>> >>>>>>>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>>>>>>> >>>>>>>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>>>>>>> >>>>>>>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>>>>>> >>>>>>> https for legacy.raspbian.org works >>>>>> >>>>>> I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. >>>>>> I think this PR is good as it is, as it fixes something that was broken. >>>>>> >>>>>> However, in general I think the concept of this crosslibs script is broken for a number of reasons: >>>>>> 1. for none of the other targets, we have a script for downloading the toolchain. >>>>>> 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. >>>>>> >>>>>> Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. >>>>>> >>>>>> I therefore propose to merge this PR. >>>>> >>>>> I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. >>>> >>>> Looks like that worked and reran jcheck. >>> >>> Please ignore the above comments. I added them to the wrong PR. >>> >>> This PR was and still is ready for review. >> >> I'll suspend testing of the https domains as previously mentioned. > > @dellgreen once you are ready, go ahead and issue the `/integrate` command. Presuming that @johanvos will sponsor this, he can then issue the `/sponsor` command after double-checking the commit message, etc. While checking, I notice that this PR has a different title than the title of the corresponding bug in JBS: https://bugs.openjdk.java.net/browse/JDK-8231870. @kevin can we simply edit the title of the PR to match the one in JBS? PR: https://git.openjdk.java.net/jfx/pull/8 From shadzic at openjdk.org Wed Oct 9 16:11:49 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 9 Oct 2019 16:11:49 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/6/files > - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > 607: protected void resizeColumnToFitContent(int maxRows) { > 608: TableColumnBase tc = getTableColumn(); > 609: if (!tc.isResizable()) return; I have put the `since 14`, because if merged, it will be available in OpenJFX 14 right? (It was 13 before) PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Wed Oct 9 16:17:39 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 16:17:39 GMT Subject: RFR: 8231870: Updated armv6hf crosslibs script with new domains In-Reply-To: References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> <8J_Tk8_6Zo_uNr-mkzdP3k1p5gA6YA09pZ_gLy_1eT4=.f7bf734f-d918-4408-90d9-c8bbb178a329@github.com> Message-ID: <4TWsBV7Kdyo1_CGDvYbVyCZ6Jazyk7CO_U_vPahf3Zs=.4e3fa976-7cfe-4d4e-aacd-3cf997751752@github.com> On Wed, 9 Oct 2019 16:10:28 GMT, Johan Vos wrote: > On Wed, 9 Oct 2019 15:18:58 GMT, Kevin Rushforth wrote: > >> On Wed, 9 Oct 2019 07:43:43 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >> >>> On Tue, 8 Oct 2019 12:02:22 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: >>>>>> >>>>>>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>> >>>>>>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >>>>>>>> >>>>>>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>>>>>>>> >>>>>>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>>>>> >>>>>>>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>>>>>>>> >>>>>>>>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>>>>>>>> >>>>>>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>>>>>>>> >>>>>>>>>>> ---------------- >>>>>>>>>>> >>>>>>>>>>> Commits: >>>>>>>>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>>>>>>>> >>>>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>>>>>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>>>>>>>> >>>>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>>>>>>>> >>>>>>>>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>>>>>>>> 232: libatk1.0-dev \ >>>>>>>>>>> 233: libatk1.0-0 \ >>>>>>>>>> >>>>>>>>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>>>>>>>> >>>>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>>>>>>>> >>>>>>>>>>> 391: $DESTINATION \ >>>>>>>>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>>>>>>>> 393: libraspberrypi-dev >>>>>>>>>> >>>>>>>>>> Same comment hear about using an `https` URL if possible. >>>>>>>>>> >>>>>>>>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>>>>>>>> >>>>>>>>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>>>>>>>> >>>>>>>>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>>>>>>> >>>>>>>> https for legacy.raspbian.org works >>>>>>> >>>>>>> I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. >>>>>>> I think this PR is good as it is, as it fixes something that was broken. >>>>>>> >>>>>>> However, in general I think the concept of this crosslibs script is broken for a number of reasons: >>>>>>> 1. for none of the other targets, we have a script for downloading the toolchain. >>>>>>> 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. >>>>>>> >>>>>>> Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. >>>>>>> >>>>>>> I therefore propose to merge this PR. >>>>>> >>>>>> I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. >>>>> >>>>> Looks like that worked and reran jcheck. >>>> >>>> Please ignore the above comments. I added them to the wrong PR. >>>> >>>> This PR was and still is ready for review. >>> >>> I'll suspend testing of the https domains as previously mentioned. >> >> @dellgreen once you are ready, go ahead and issue the `/integrate` command. Presuming that @johanvos will sponsor this, he can then issue the `/sponsor` command after double-checking the commit message, etc. > > While checking, I notice that this PR has a different title than the title of the corresponding bug in JBS: https://bugs.openjdk.java.net/browse/JDK-8231870. > @kevin can we simply edit the title of the PR to match the one in JBS? Btw, my username is @kevinrushforth so you notified someone else on the above comment... Yes, editing the title to match the JBS issue is a very good thing to do. Since you are sponsoring it, go ahead and do that. I don't know for certain whether the bot will pick it up (since the contributor has already done a `/integrate`) -- it will be a good test. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Wed Oct 9 16:18:49 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 16:18:49 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 16:11:49 GMT, Hadzic Samir wrote: > On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > >> 607: protected void resizeColumnToFitContent(int maxRows) { >> 608: TableColumnBase tc = getTableColumn(); >> 609: if (!tc.isResizable()) return; > > I have put the `since 14`, because if merged, it will be available in OpenJFX 14 right? (It was 13 before) Correct. PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Wed Oct 9 16:24:29 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 16:24:29 GMT Subject: RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: On Wed, 9 Oct 2019 12:38:09 GMT, Johan Vos wrote: > On Wed, 9 Oct 2019 12:24:29 GMT, Kevin Rushforth wrote: > >> On Wed, 9 Oct 2019 07:50:44 GMT, Johan Vos wrote: >> >>> On Tue, 8 Oct 2019 13:54:22 GMT, Kevin Rushforth wrote: >>> >>>> JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) >>>> >>>> As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). >>>> >>>> The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). >>>> >>>> The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. >>>> >>>> The changes are as follows: >>>> >>>> 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x >>>> 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` >>>> 3. Specify no metadata for ivy repositories >>>> 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir >>>> 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) >>>> >>>> I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/9/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 >>>> Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/9.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 >>> >>> build.gradle line 1836: >>> >>>> 1835: url JFX_DEPS_URL >>>> 1836: metadataSources { >>>> 1837: artifact() >>> >>> From the JBS entry, I understood for now you wanted to keep layout (instead of patternLayout): https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14293009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14293009 >>> >>> I understand the reasoning behind this (not using an incubating API), so I wonder why it is changed in this PR? >> >> I think you meant to point to [this earlier comment](https://bugs.openjdk.java.net/browse/JDK-8226754?focusedCommentId=14273845&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14273845) that I made back in June. Yes, I had indicated that I wanted to wait until gradle 6 builds were available before switching from `layout` to `patternLayout`, in case they made any changes. >> >> Your question does raise a good point, though: Should we wait until we actually want to switch to gradle 6 before making this change? If so, then it might make sense to split this change into two bugs: the `layout` --> `patternLayout` changes, which would wait until we switch to gradle 6, and the rest, which would be done now. >> >> I could go either way. Which do you prefer? > > https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.repositories.IvyArtifactRepository.html still shows `patternLayout` to be incubating. Gradle doesn't have an excellent track record for finishing incubating API's (e.g. https://github.com/spring-projects/spring-boot/issues/11640). > Hence, I think it is indeed safer not to switch from a deprecated API to an incubating API (and as a result, split the PR so that the `layout` --> `patternLayout` is not included for now. > > I don't have a very strong opinion on this though, so if you want to keep the changes, I don't object that. OK, I'll go ahead and update this PR to split out the `layout` --> `patternLayout` changes. I'll file a new issue to upgrade to gradle 6, targeted to `tbd` for now, since we don't know when gradle 6 will be released. The `layout` --> `patternLayout` changes can be done as part of the actual upgrade. PR: https://git.openjdk.java.net/jfx/pull/9 From jvos at openjdk.org Wed Oct 9 16:58:38 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 9 Oct 2019 16:58:38 GMT Subject: RFR: 8231870: CrossLibs script for armv6hf toolchain download fails In-Reply-To: <4TWsBV7Kdyo1_CGDvYbVyCZ6Jazyk7CO_U_vPahf3Zs=.4e3fa976-7cfe-4d4e-aacd-3cf997751752@github.com> References: <4uZB2wyWcxrhyGDWH2AznISNd7TMShQIChQxP2QlA4s=.b772b018-a8dd-48ce-89cb-23e3f8ab718a@github.com> <8J_Tk8_6Zo_uNr-mkzdP3k1p5gA6YA09pZ_gLy_1eT4=.f7bf734f-d918-4408-90d9-c8bbb178a329@github.com> <4TWsBV7Kdyo1_CGDvYbVyCZ6Jazyk7CO_U_vPahf3Zs=.4e3fa976-7cfe-4d4e-aacd-3cf997751752@github.com> Message-ID: On Wed, 9 Oct 2019 16:17:39 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 16:10:28 GMT, Johan Vos wrote: > >> On Wed, 9 Oct 2019 15:18:58 GMT, Kevin Rushforth wrote: >> >>> On Wed, 9 Oct 2019 07:43:43 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>> >>>> On Tue, 8 Oct 2019 12:02:22 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: >>>>>> >>>>>>> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: >>>>>>> >>>>>>>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>>> >>>>>>>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote: >>>>>>>>> >>>>>>>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. >>>>>>>>>>>> >>>>>>>>>>>> Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>>>>>>>>>>> >>>>>>>>>>>> ---------------- >>>>>>>>>>>> >>>>>>>>>>>> Commits: >>>>>>>>>>>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy >>>>>>>>>>>> >>>>>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>>>>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>>>>>>>>>>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>>>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>>>>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>>>>>>>>>> >>>>>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>>>>>>>>>> >>>>>>>>>>>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>>>>>>>>>>> 232: libatk1.0-dev \ >>>>>>>>>>>> 233: libatk1.0-0 \ >>>>>>>>>>> >>>>>>>>>>> The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. >>>>>>>>>>> >>>>>>>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>>>>>>>>>> >>>>>>>>>>>> 391: $DESTINATION \ >>>>>>>>>>>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>>>>>>>>>>> 393: libraspberrypi-dev >>>>>>>>>>> >>>>>>>>>>> Same comment hear about using an `https` URL if possible. >>>>>>>>>>> >>>>>>>>>>> I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>>>>>>>>> >>>>>>>>>> In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. >>>>>>>>>> >>>>>>>>>> Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>>>>>>>> >>>>>>>>> https for legacy.raspbian.org works >>>>>>>> >>>>>>>> I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. >>>>>>>> I think this PR is good as it is, as it fixes something that was broken. >>>>>>>> >>>>>>>> However, in general I think the concept of this crosslibs script is broken for a number of reasons: >>>>>>>> 1. for none of the other targets, we have a script for downloading the toolchain. >>>>>>>> 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. >>>>>>>> >>>>>>>> Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. >>>>>>>> >>>>>>>> I therefore propose to merge this PR. >>>>>>> >>>>>>> I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. >>>>>> >>>>>> Looks like that worked and reran jcheck. >>>>> >>>>> Please ignore the above comments. I added them to the wrong PR. >>>>> >>>>> This PR was and still is ready for review. >>>> >>>> I'll suspend testing of the https domains as previously mentioned. >>> >>> @dellgreen once you are ready, go ahead and issue the `/integrate` command. Presuming that @johanvos will sponsor this, he can then issue the `/sponsor` command after double-checking the commit message, etc. >> >> While checking, I notice that this PR has a different title than the title of the corresponding bug in JBS: https://bugs.openjdk.java.net/browse/JDK-8231870. >> @kevin can we simply edit the title of the PR to match the one in JBS? > > Btw, my username is @kevinrushforth so you notified someone else on the above comment... > > Yes, editing the title to match the JBS issue is a very good thing to do. Since you are sponsoring it, go ahead and do that. I don't know for certain whether the bot will pick it up (since the contributor has already done a `/integrate`) -- it will be a good test. I don't see a way to edit the commit message, so I'll just sponsor it and see if the bot modifies the commit message with the new title or not. PR: https://git.openjdk.java.net/jfx/pull/8 From kcr at openjdk.org Wed Oct 9 17:16:10 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 17:16:10 GMT Subject: [Rev 01] RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - a928b41f: Revert ivy layout pattern changes per review comments Changes: - all: https://git.openjdk.java.net/jfx/pull/9/files - new: https://git.openjdk.java.net/jfx/pull/9/files/bc6bd441..a928b41f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/9/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/9/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 Stats: 21 lines in 2 files changed: 0 ins; 15 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 PR: https://git.openjdk.java.net/jfx/pull/9 From jvos at openjdk.org Wed Oct 9 18:58:30 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 9 Oct 2019 18:58:30 GMT Subject: [Rev 01] RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: On Wed, 9 Oct 2019 17:16:10 GMT, Kevin Rushforth wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - a928b41f: Revert ivy layout pattern changes per review comments > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/9/files > - new: https://git.openjdk.java.net/jfx/pull/9/files/bc6bd441..a928b41f > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/9/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/9/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 > Stats: 21 lines in 2 files changed: 0 ins; 15 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/9.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 Looks good. However, automated testing on Windows failed. I believe this is an infrastructure issue, but I want to investigate it in detail tomorrow. PR: https://git.openjdk.java.net/jfx/pull/9 From kcr at openjdk.org Wed Oct 9 20:09:58 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Oct 2019 20:09:58 GMT Subject: RFR: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir wrote: > On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: > >> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: >> >>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >>> >>> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >>> >>> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >>> >>> ---------------- >>> >>> Commits: >>> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/12/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >>> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 >> >> @Maxoudela please edit the title as follows: >> >> 1. Remove the space before the `:` (that extra space is why jcheck failed) >> 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. >> >> As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: >> >> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest > > Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. > > I'll try to add a test asap, thanks for the pointer. > I'm sorry for posting the Pull request like that No problem. I mainly wanted to make sure that you knew why the RFR wasn't sent. As for the note about the title matching, the contributing guidelines don't mention that and I now realize that they should -- I'll add that along with some other improvements I'll be making. > I'll try to add a test asap, thanks for the pointer. Great, thanks. PR: https://git.openjdk.java.net/jfx/pull/12 From kcr at openjdk.org Thu Oct 10 00:53:01 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 10 Oct 2019 00:53:01 GMT Subject: [Approved] RFR: 8218640: Update ICU4C to version 64.2 In-Reply-To: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> References: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> Message-ID: On Wed, 9 Oct 2019 13:25:54 GMT, Arun Joseph wrote: > We currently use ICU4C version 62.1. We should update to the latest stable version 64.2. > http://site.icu-project.org/home > > ---------------- > > Commits: > - b56b720e: 8218640: Update ICU4C to version 64.2 > > Changes: https://git.openjdk.java.net/jfx/pull/10/files > Webrev: https://webrevs.openjdk.java.net/jfx/10/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8218640 > Stats: 41065 lines in 430 files changed: 23684 ins; 7205 del; 10176 mod > Patch: https://git.openjdk.java.net/jfx/pull/10.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/10/head:pull/10 Looks good. I ran sanity tests on all three platforms. This still needs a review from @guruhb and confirmation from Gluon that it doesn't break the build. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/10 From ghb at openjdk.org Thu Oct 10 03:58:41 2019 From: ghb at openjdk.org (Guru Hb) Date: Thu, 10 Oct 2019 03:58:41 GMT Subject: [Approved] RFR: 8218640: Update ICU4C to version 64.2 In-Reply-To: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> References: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> Message-ID: On Wed, 9 Oct 2019 13:25:54 GMT, Arun Joseph wrote: > We currently use ICU4C version 62.1. We should update to the latest stable version 64.2. > http://site.icu-project.org/home > > ---------------- > > Commits: > - b56b720e: 8218640: Update ICU4C to version 64.2 > > Changes: https://git.openjdk.java.net/jfx/pull/10/files > Webrev: https://webrevs.openjdk.java.net/jfx/10/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8218640 > Stats: 41065 lines in 430 files changed: 23684 ins; 7205 del; 10176 mod > Patch: https://git.openjdk.java.net/jfx/pull/10.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/10/head:pull/10 +1 Looks good to me ---------------- Approved by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/10 From venatorxoa at gmail.com Thu Oct 10 06:02:34 2019 From: venatorxoa at gmail.com (Vincent MOLLIERE) Date: Thu, 10 Oct 2019 08:02:34 +0200 Subject: Problem of compilation of OpenJFX In-Reply-To: References: <39119d10-5785-27b4-5c33-9110357079c3@oracle.com> Message-ID: Here the log of the gradle with the task compileJslcJava : https://paste.ubuntu.com/p/5ZqZZJBSPF/ Here the log of the java-compiler-args.txt : https://paste.ubuntu.com/p/r72CMkFTHy/ Thank you for your help Le mer. 9 oct. 2019 ? 17:51, Michael Ennen a ?crit : > Can you paste the full build log somewhere (not inline on the mailing > list)? > > On Wed, Oct 9, 2019 at 7:02 AM Vincent MOLLIERE > wrote: > >> Thank you for you answer but its seems its using the 4.7.2. I pasted the >> java-compiler-args.txt of the command generating the files : >> -source >> 11 >> -target >> 11 >> -d >> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\classes\\java\\jslc >> -nowarn >> -g:source,lines,vars >> -sourcepath >> "" >> -proc:none >> -s >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\generated\\sources\\annotationProcessor\\java\\jslc >> -XDuseUnsharedTable=true >> -classpath >> >> C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4\\4.7.2\\34fc363424d3b060b660f84974a82d6bdc7ebe0c\\antlr4-4.7.2-complete.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4-runtime\\4.7.2\\e27d8ab4f984f9d186f54da984a6ab1cccac755e\\antlr4-runtime-4.7.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\ST4\\4.1\\467d508be07a542ad0a68ffcaed2d561c5fb2e0c\\ST4-4.1.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr-runtime\\3.5.2\\cd9cd41361c155f3af0f653009dcecb08d8b4afd\\antlr-runtime-3.5.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.abego.treelayout\\org.abego.treelayout.core\\1.0.3\\457216e8e6578099ae63667bb1e4439235892028\\org.abego.treelayout.core-1.0.3.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.glassfish\\javax.json\\1.0.4\\3178f73569fd7a1e5ffc464e680f7a8cc784b85a\\javax.json-1.0.4.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\com.ibm.icu\\icu4j\\61.1\\28d33b5e44e72edcc66a5da7a34a42147f38d987\\icu4j-61.1.jar >> -XDignore.symbol.file >> -encoding >> UTF-8 >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\ES2Backend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\GLSLBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\HLSLBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\SLBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\prism\\PrismBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWCallScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWFuncImpls.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWTreeScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MECallScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEFuncImpls.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\METreeScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEBackend.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSECallScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEFuncImpls.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSETreeScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\JSLC.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BaseType.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BinaryOpType.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\CoreSymbols.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\FuncImpl.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Function.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Param.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Precision.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Qualifier.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\SymbolTable.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Type.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\UnaryOpType.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Variable.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\ThrowingErrorListener.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ArrayAccessExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BinaryExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BreakStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CallExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CompoundStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ContinueStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DeclStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DiscardStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DoWhileStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Expr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExprStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExtDecl.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FieldSelectExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ForStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FuncDef.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\GlueBlock.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\JSLVisitor.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\LiteralExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ParenExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ProgramUnit.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ReturnStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\SelectStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Stmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Tree.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeMaker.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeScanner.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeVisitor.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\UnaryExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VarDecl.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VariableExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VectorCtorExpr.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\WhileStmt.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLBaseListener.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLLexer.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLListener.java >> >> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLParser.java >> >> What do you think about it ? >> >> Le mer. 9 oct. 2019 ? 15:20, Kevin Rushforth >> a >> ?crit : >> >> > This class is generated by antlr during the build: >> > >> > >> > >> modules/javafx.graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler/JSLBaseVisitor.java >> > >> > You may be using an old 3.x version of anltlr, although the build >> > should download the latest antlr4 for you. Make sure that you have a >> > clean repo with no leftovers from an older build. >> > >> > -- Kevin >> > >> > On 10/9/2019 2:06 AM, Vincent MOLLIERE wrote: >> > > Hello, >> > > I'm trying to build the latest version of OpenJFX on Windows and I >> have a >> > > compilation problem in JSLVisitor, it cannot find the >> > > import com.sun.scenario.effect.compiler.JSLBaseVisitor and neither do >> I. >> > > Where this file can be found/generated ? >> > > Thank you in advance for your help ! >> > >> > >> > > > -- > Michael Ennen > From shadzic at openjdk.org Thu Oct 10 08:32:19 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 10 Oct 2019 08:32:19 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 15:49:21 GMT, Nir Lisker wrote: > On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java line 170: > >> 169: TableColumnHeader columnHeader = tableHeader.getColumnHeaderFor(column); >> 170: if(columnHeader != null){ >> 171: columnHeader.resizeColumnToFitContent(-1); > > Space after `if` and before `{`. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > >> 607: protected void resizeColumnToFitContent(int maxRows) { >> 608: TableColumnBase tc = getTableColumn(); >> 609: if (!tc.isResizable()) return; > > Here's my suggestion (mind the max character length per line): > > Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells. >

> Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 618: > >> 617: } >> 618: >> 619: private void resizeColumnToFitContent(TableView tv, TableColumn tc, TableViewSkinBase tableSkin, int maxRows) { > > I think we put a space when casting, like `(TableView) control`. Not sure if it is a rule. > > Since you are adding new API you will need to file a CSR once the API review id done. > > ---------------- > > Disapproved by nlisker (Committer). Seems good but I have a minor doubt on "header cell". Can the header be considered as a "cell"? PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Thu Oct 10 08:40:24 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 10 Oct 2019 08:40:24 GMT Subject: [Rev 02] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 49abc7c7: Add space and update Javadoc for tableColumnHeader and NestedTableColumnHeader Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new: https://git.openjdk.java.net/jfx/pull/6/files/e846e51c..49abc7c7 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/6/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.01-02 Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 Stats: 9 lines in 2 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Thu Oct 10 09:12:57 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 10 Oct 2019 09:12:57 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir wrote: > >> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: >> >>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: >>> >>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >>>> >>>> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >>>> >>>> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >>>> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 >>> >>> @Maxoudela please edit the title as follows: >>> >>> 1. Remove the space before the `:` (that extra space is why jcheck failed) >>> 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. >>> >>> As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: >>> >>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >> >> Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. >> >> I'll try to add a test asap, thanks for the pointer. > >> I'm sorry for posting the Pull request like that > > No problem. I mainly wanted to make sure that you knew why the RFR wasn't sent. As for the note about the title matching, the contributing guidelines don't mention that and I now realize that they should -- I'll add that along with some other improvements I'll be making. > >> I'll try to add a test asap, thanks for the pointer. > > Great, thanks. Hum I do not succeed in running the existing test either. Here is my log. Apparently, the tests are failing because the WebView is null and not initialized. Do you have any clue of what I've been doing wrong? Should I try to update my gradle version and JDK version maybe? gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest Starting a Gradle Daemon (subsequent builds will be faster) > Configure project : MACOSX_MIN_VERSION = 10.9 MACOSX_SDK_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk ***************************************************************** Unsupported gradle version 4.8 in use. Only version 5.3 is supported. Use this version at your own risk ***************************************************************** gradle.gradleVersion: 4.8 OS_NAME: mac os x OS_ARCH: x86_64 JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home JDK_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home java.runtime.version: 11.0.1+13 java version: 11.0.1 java build number: 13 jdk.runtime.version: 11.0.1+13 jdk version: 11.0.1 jdk build number: 13 minimum jdk version: 11 minimum jdk build number: 28 XCODE version: Xcode10.1-MacOSX10.14+1.0 cmake version: 3.13.3 ninja version: 1.8.2 ant version: 1.10.5 HAS_JAVAFX_MODULES: false STUB_RUNTIME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home CONF: Debug NUM_COMPILE_THREADS: 1 COMPILE_TARGETS: mac COMPILE_FLAGS_FILES: buildSrc/mac.gradle HUDSON_JOB_NAME: not_hudson HUDSON_BUILD_NUMBER: 0000 PROMOTED_BUILD_NUMBER: 0 PRODUCT_NAME: OpenJFX RELEASE_VERSION: 14 RELEASE_SUFFIX: -internal RELEASE_VERSION_SHORT: 14-internal RELEASE_VERSION_LONG: 14-internal+0-2019-10-10-110056 RELEASE_VERSION_PADDED: 14.0.0.0 MAVEN_VERSION: 14-internal+0-2019-10-10-110056 UPDATE_STUB_CACHE: false Building Webkit configuration /Release/ into /Users/shadzic/jfx/modules/javafx.web/build/mac module: project ':apps' (buildModule=NO) module: project ':base' (buildModule=YES) module: project ':controls' (buildModule=YES) module: project ':fxml' (buildModule=YES) module: project ':graphics' (buildModule=YES) module: project ':media' (buildModule=YES) module: project ':swing' (buildModule=YES) module: project ':swt' (buildModule=NO) module: project ':systemTests' (buildModule=NO) module: project ':web' (buildModule=YES) > Task :web:compileJava Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. > Task :web:compileShimsJava Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. > Task :web:compileTestJava Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. > Task :systemTests:compileTestJava Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. > Task :systemTests:test test.javafx.scene.web.HTMLEditorTest > checkStyleWithCSS FAILED java.lang.NullPointerException at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleWithCSS$7(HTMLEditorTest.java:192) test.javafx.scene.web.HTMLEditorTest > checkStyleProperty FAILED java.lang.NullPointerException at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleProperty$11(HTMLEditorTest.java:266) 3 tests completed, 2 failed, 1 skipped > Task :systemTests:test FAILED PR: https://git.openjdk.java.net/jfx/pull/12 From nlisker at openjdk.org Thu Oct 10 10:17:40 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 10 Oct 2019 10:17:40 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: <4hsE1hfajesoXAoWt6zP3vYIWRmzv8lhYwZ8_6q2EWE=.3f839cba-abc1-4fc1-b3b9-6caaef89945f@github.com> On Wed, 9 Oct 2019 15:49:21 GMT, Nir Lisker wrote: > On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java line 170: > >> 169: TableColumnHeader columnHeader = tableHeader.getColumnHeaderFor(column); >> 170: if(columnHeader != null){ >> 171: columnHeader.resizeColumnToFitContent(-1); > > Space after `if` and before `{`. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > >> 607: protected void resizeColumnToFitContent(int maxRows) { >> 608: TableColumnBase tc = getTableColumn(); >> 609: if (!tc.isResizable()) return; > > Here's my suggestion (mind the max character length per line): > > Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells. >

> Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 618: > >> 617: } >> 618: >> 619: private void resizeColumnToFitContent(TableView tv, TableColumn tc, TableViewSkinBase tableSkin, int maxRows) { > > I think we put a space when casting, like `(TableView) control`. Not sure if it is a rule. > > Since you are adding new API you will need to file a CSR once the API review id done. > > ---------------- > > Disapproved by nlisker (Committer). I don't mind either way, but I think that you're right, the header is not technically a cell. PR: https://git.openjdk.java.net/jfx/pull/6 From kevin.rushforth at oracle.com Thu Oct 10 12:10:35 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Oct 2019 05:10:35 -0700 Subject: Problem of compilation of OpenJFX In-Reply-To: References: <39119d10-5785-27b4-5c33-9110357079c3@oracle.com> Message-ID: I don't see anything in your log that would explain the failure. What is the exact command to gradle that you are using? One thing to try is to use gradlew to run the exact version of gradle (5.3) that we use in production and do all of our testing with. Also, using the --info option might be helpful to provide more diagnostics. Finally, I recommend cleaning your repo with "git clean -fdx" to remove all partial build files: $ git clean -fdx $ bash gradlew --info -- Kevin On 10/9/2019 11:02 PM, Vincent MOLLIERE wrote: > Here the log of the gradle with the task compileJslcJava : > https://paste.ubuntu.com/p/5ZqZZJBSPF/ > Here the log of the java-compiler-args.txt : > https://paste.ubuntu.com/p/r72CMkFTHy/ > Thank you for your help > > Le mer. 9 oct. 2019 ? 17:51, Michael Ennen a ?crit : > >> Can you paste the full build log somewhere (not inline on the mailing >> list)? >> >> On Wed, Oct 9, 2019 at 7:02 AM Vincent MOLLIERE >> wrote: >> >>> Thank you for you answer but its seems its using the 4.7.2. I pasted the >>> java-compiler-args.txt of the command generating the files : >>> -source >>> 11 >>> -target >>> 11 >>> -d >>> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\classes\\java\\jslc >>> -nowarn >>> -g:source,lines,vars >>> -sourcepath >>> "" >>> -proc:none >>> -s >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\generated\\sources\\annotationProcessor\\java\\jslc >>> -XDuseUnsharedTable=true >>> -classpath >>> >>> C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4\\4.7.2\\34fc363424d3b060b660f84974a82d6bdc7ebe0c\\antlr4-4.7.2-complete.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr4-runtime\\4.7.2\\e27d8ab4f984f9d186f54da984a6ab1cccac755e\\antlr4-runtime-4.7.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\ST4\\4.1\\467d508be07a542ad0a68ffcaed2d561c5fb2e0c\\ST4-4.1.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.antlr\\antlr-runtime\\3.5.2\\cd9cd41361c155f3af0f653009dcecb08d8b4afd\\antlr-runtime-3.5.2.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.abego.treelayout\\org.abego.treelayout.core\\1.0.3\\457216e8e6578099ae63667bb1e4439235892028\\org.abego.treelayout.core-1.0.3.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\org.glassfish\\javax.json\\1.0.4\\3178f73569fd7a1e5ffc464e680f7a8cc784b85a\\javax.json-1.0.4.jar;C:\\Users\\LambdaUser\\.gradle\\caches\\modules-2\\files-2.1\\com.ibm.icu\\icu4j\\61.1\\28d33b5e44e72edcc66a5da7a34a42147f38d987\\icu4j-61.1.jar >>> -XDignore.symbol.file >>> -encoding >>> UTF-8 >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\ES2Backend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\GLSLBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\HLSLBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\hw\\SLBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\prism\\PrismBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWCallScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWFuncImpls.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\java\\JSWTreeScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MECallScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\MEFuncImpls.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\me\\METreeScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEBackend.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSECallScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSEFuncImpls.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\backend\\sw\\sse\\SSETreeScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\JSLC.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BaseType.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\BinaryOpType.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\CoreSymbols.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\FuncImpl.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Function.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Param.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Precision.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Qualifier.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\SymbolTable.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Type.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\UnaryOpType.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\model\\Variable.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\ThrowingErrorListener.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ArrayAccessExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BinaryExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\BreakStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CallExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\CompoundStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ContinueStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DeclStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DiscardStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\DoWhileStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Expr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExprStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ExtDecl.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FieldSelectExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ForStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\FuncDef.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\GlueBlock.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\JSLVisitor.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\LiteralExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ParenExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ProgramUnit.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\ReturnStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\SelectStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Stmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\Tree.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeMaker.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeScanner.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\TreeVisitor.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\UnaryExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VarDecl.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VariableExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\VectorCtorExpr.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\src\\jslc\\java\\com\\sun\\scenario\\effect\\compiler\\tree\\WhileStmt.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLBaseListener.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLLexer.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLListener.java >>> >>> D:\\Git\\jfx\\modules\\javafx.graphics\\build\\gensrc\\antlr\\com\\sun\\scenario\\effect\\compiler\\JSLParser.java >>> >>> What do you think about it ? >>> >>> Le mer. 9 oct. 2019 ? 15:20, Kevin Rushforth >>> a >>> ?crit : >>> >>>> This class is generated by antlr during the build: >>>> >>>> >>>> >>> modules/javafx.graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler/JSLBaseVisitor.java >>>> You may be using an old 3.x version of anltlr, although the build >>>> should download the latest antlr4 for you. Make sure that you have a >>>> clean repo with no leftovers from an older build. >>>> >>>> -- Kevin >>>> >>>> On 10/9/2019 2:06 AM, Vincent MOLLIERE wrote: >>>>> Hello, >>>>> I'm trying to build the latest version of OpenJFX on Windows and I >>> have a >>>>> compilation problem in JSLVisitor, it cannot find the >>>>> import com.sun.scenario.effect.compiler.JSLBaseVisitor and neither do >>> I. >>>>> Where this file can be found/generated ? >>>>> Thank you in advance for your help ! >>>> >> >> -- >> Michael Ennen >> From kcr at openjdk.org Thu Oct 10 12:19:18 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 10 Oct 2019 12:19:18 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: Message-ID: On Thu, 10 Oct 2019 09:12:57 GMT, Hadzic Samir wrote: > On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth wrote: > >> On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir wrote: >> >>> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: >>> >>>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: >>>> >>>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >>>>> >>>>> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>> >>>>> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 >>>> >>>> @Maxoudela please edit the title as follows: >>>> >>>> 1. Remove the space before the `:` (that extra space is why jcheck failed) >>>> 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. >>>> >>>> As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: >>>> >>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >>> >>> Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. >>> >>> I'll try to add a test asap, thanks for the pointer. >> >>> I'm sorry for posting the Pull request like that >> >> No problem. I mainly wanted to make sure that you knew why the RFR wasn't sent. As for the note about the title matching, the contributing guidelines don't mention that and I now realize that they should -- I'll add that along with some other improvements I'll be making. >> >>> I'll try to add a test asap, thanks for the pointer. >> >> Great, thanks. > > Hum I do not succeed in running the existing test either. Here is my log. Apparently, the tests are failing because the WebView is null and not initialized. Do you have any clue of what I've been doing wrong? > > Should I try to update my gradle version and JDK version maybe? > gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest > Starting a Gradle Daemon (subsequent builds will be faster) > >> Configure project : > MACOSX_MIN_VERSION = 10.9 > MACOSX_SDK_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk > ***************************************************************** > Unsupported gradle version 4.8 in use. > Only version 5.3 is supported. Use this version at your own risk > ***************************************************************** > gradle.gradleVersion: 4.8 > OS_NAME: mac os x > OS_ARCH: x86_64 > JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home > JDK_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home > java.runtime.version: 11.0.1+13 > java version: 11.0.1 > java build number: 13 > jdk.runtime.version: 11.0.1+13 > jdk version: 11.0.1 > jdk build number: 13 > minimum jdk version: 11 > minimum jdk build number: 28 > XCODE version: Xcode10.1-MacOSX10.14+1.0 > cmake version: 3.13.3 > ninja version: 1.8.2 > ant version: 1.10.5 > HAS_JAVAFX_MODULES: false > STUB_RUNTIME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home > CONF: Debug > NUM_COMPILE_THREADS: 1 > COMPILE_TARGETS: mac > COMPILE_FLAGS_FILES: buildSrc/mac.gradle > HUDSON_JOB_NAME: not_hudson > HUDSON_BUILD_NUMBER: 0000 > PROMOTED_BUILD_NUMBER: 0 > PRODUCT_NAME: OpenJFX > RELEASE_VERSION: 14 > RELEASE_SUFFIX: -internal > RELEASE_VERSION_SHORT: 14-internal > RELEASE_VERSION_LONG: 14-internal+0-2019-10-10-110056 > RELEASE_VERSION_PADDED: 14.0.0.0 > MAVEN_VERSION: 14-internal+0-2019-10-10-110056 > UPDATE_STUB_CACHE: false > Building Webkit configuration /Release/ into /Users/shadzic/jfx/modules/javafx.web/build/mac > module: project ':apps' (buildModule=NO) > module: project ':base' (buildModule=YES) > module: project ':controls' (buildModule=YES) > module: project ':fxml' (buildModule=YES) > module: project ':graphics' (buildModule=YES) > module: project ':media' (buildModule=YES) > module: project ':swing' (buildModule=YES) > module: project ':swt' (buildModule=NO) > module: project ':systemTests' (buildModule=NO) > module: project ':web' (buildModule=YES) > >> Task :web:compileJava > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > >> Task :web:compileShimsJava > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > >> Task :web:compileTestJava > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > >> Task :systemTests:compileTestJava > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > >> Task :systemTests:test > > test.javafx.scene.web.HTMLEditorTest > checkStyleWithCSS FAILED > java.lang.NullPointerException > at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleWithCSS$7(HTMLEditorTest.java:192) > > test.javafx.scene.web.HTMLEditorTest > checkStyleProperty FAILED > java.lang.NullPointerException > at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleProperty$11(HTMLEditorTest.java:266) > > 3 tests completed, 2 failed, 1 skipped > >> Task :systemTests:test FAILED The test failure is almost certainly due to not having the native WebKit libraries. Two options: 1. You can build WebKit yourself (it's fairly painless on Mac) by running gradle with `-PCOMPILE_WEBKIT=true` 2. You can download libjfxwebkit.dylib from the openjfx14+1 EA build and put it in `../caches/modular-sdk/modules_libs/javafx.web/libjfxwebkit.dylib` PR: https://git.openjdk.java.net/jfx/pull/12 From nlisker at gmail.com Thu Oct 10 12:40:29 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 10 Oct 2019 15:40:29 +0300 Subject: Skara transition: openjdk/jfx GitHub repo is ready to accept pull requests In-Reply-To: <05e95501-11bc-90b1-ef06-4655598dbcb3@oracle.com> References: <9c45fca9-bae7-4d64-6ada-151914d8fda4@oracle.com> <05e95501-11bc-90b1-ef06-4655598dbcb3@oracle.com> Message-ID: Hi Kevin, A few questions and comments: 1. I'm getting double notifications from threads I'm subscribed to - one from GitHub and one from the bot, including notifications on my own comments. The Skara bot doesn't need to notify me on threads I'm subscribed to. 2. Are the hg files like hgignore and hgtags still needed in the GitHub Skara repo? 3. Is there a plan for the bot to be CSR-aware? For example, add to the checklist the CSR status when applicable? 4. I updated the build instructions page on the Wiki to remove the Mercurial requirements and update the Git tools and repo address. The page could use a cleanup for the sections "Before you start" and anything below and including "Testing with JDK 9 or JDK 10". 5. Not directly Skara related, but I could not find where the rule that OpenJFX is compatible with JDK N and N-1 is stated. I see that the section "Contributing to the OpenJFX codebase" in Contributing.md lists JDK 11 as the minimum, but doesn't it apply to users of the library too? - Nir On Wed, Oct 2, 2019 at 4:52 PM Kevin Rushforth wrote: > The openjdk/jfx repo is now open and accepting pull requests. Refer to > the links in the included message below for more information. > > One thing to note: there is not yet a CI job hooked up to the repo. > Contributors, Committers, and Reviewers need to take this into account > when testing. > > Please report any problems that you run into by replying to this thread. > > Thanks. > > -- Kevin > > > On 10/1/2019 9:13 AM, Kevin Rushforth wrote: > > As announced in this message [1], we are transitioning the official > > openjfx mainline repo from Mercurial (hosted on hg.openjdk.java.net) > > to GIT (hosted on github.com). Effective immediately, the HG > > openjfx/jfx-dev/rt [2] repo is frozen. No more pushes to this repo > > will be accepted. Similarly, no more pull requests will be accepted > > against the GitHub javafxports/openjdk-jfx [3] sandbox repo. > > > > I have one final push to HG which will add the .jcheck/conf file > > needed by Skara [4]. I will do some sanity testing, and then the HG > > repo will be made read-only. > > > > I will send an announcement tomorrow morning when the new GitHub > > openjdk/jfx [5] repo is open for accepting pull requests. In the mean > > time, you can fork and clone the new repo as indicated here [6] to > > prepare for this. > > > > Let me know if you have any questions. > > > > -- Kevin > > > > [1] > > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt > > [3] https://github.com/javafxports/openjdk-jfx > > [4] https://bugs.openjdk.java.net/browse/JDK-8231310 > > [5] https://github.com/openjdk/jfx > > [6] > > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html > > From shadzic at openjdk.org Thu Oct 10 14:56:19 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 10 Oct 2019 14:56:19 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: Message-ID: <5sc2TcVxXD92jtPsDF4L5BvUSDrPDI-_Uwv_DRdonDo=.6ad0a745-e683-4ade-8080-644718a47fca@github.com> On Thu, 10 Oct 2019 12:19:18 GMT, Kevin Rushforth wrote: > On Thu, 10 Oct 2019 09:12:57 GMT, Hadzic Samir wrote: > >> On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth wrote: >> >>> On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir wrote: >>> >>>> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: >>>> >>>>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: >>>>> >>>>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >>>>>> >>>>>> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>>> >>>>>> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>>> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 >>>>> >>>>> @Maxoudela please edit the title as follows: >>>>> >>>>> 1. Remove the space before the `:` (that extra space is why jcheck failed) >>>>> 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. >>>>> >>>>> As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: >>>>> >>>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >>>> >>>> Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. >>>> >>>> I'll try to add a test asap, thanks for the pointer. >>> >>>> I'm sorry for posting the Pull request like that >>> >>> No problem. I mainly wanted to make sure that you knew why the RFR wasn't sent. As for the note about the title matching, the contributing guidelines don't mention that and I now realize that they should -- I'll add that along with some other improvements I'll be making. >>> >>>> I'll try to add a test asap, thanks for the pointer. >>> >>> Great, thanks. >> >> Hum I do not succeed in running the existing test either. Here is my log. Apparently, the tests are failing because the WebView is null and not initialized. Do you have any clue of what I've been doing wrong? >> >> Should I try to update my gradle version and JDK version maybe? >> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >> Starting a Gradle Daemon (subsequent builds will be faster) >> >>> Configure project : >> MACOSX_MIN_VERSION = 10.9 >> MACOSX_SDK_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk >> ***************************************************************** >> Unsupported gradle version 4.8 in use. >> Only version 5.3 is supported. Use this version at your own risk >> ***************************************************************** >> gradle.gradleVersion: 4.8 >> OS_NAME: mac os x >> OS_ARCH: x86_64 >> JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >> JDK_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >> java.runtime.version: 11.0.1+13 >> java version: 11.0.1 >> java build number: 13 >> jdk.runtime.version: 11.0.1+13 >> jdk version: 11.0.1 >> jdk build number: 13 >> minimum jdk version: 11 >> minimum jdk build number: 28 >> XCODE version: Xcode10.1-MacOSX10.14+1.0 >> cmake version: 3.13.3 >> ninja version: 1.8.2 >> ant version: 1.10.5 >> HAS_JAVAFX_MODULES: false >> STUB_RUNTIME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >> CONF: Debug >> NUM_COMPILE_THREADS: 1 >> COMPILE_TARGETS: mac >> COMPILE_FLAGS_FILES: buildSrc/mac.gradle >> HUDSON_JOB_NAME: not_hudson >> HUDSON_BUILD_NUMBER: 0000 >> PROMOTED_BUILD_NUMBER: 0 >> PRODUCT_NAME: OpenJFX >> RELEASE_VERSION: 14 >> RELEASE_SUFFIX: -internal >> RELEASE_VERSION_SHORT: 14-internal >> RELEASE_VERSION_LONG: 14-internal+0-2019-10-10-110056 >> RELEASE_VERSION_PADDED: 14.0.0.0 >> MAVEN_VERSION: 14-internal+0-2019-10-10-110056 >> UPDATE_STUB_CACHE: false >> Building Webkit configuration /Release/ into /Users/shadzic/jfx/modules/javafx.web/build/mac >> module: project ':apps' (buildModule=NO) >> module: project ':base' (buildModule=YES) >> module: project ':controls' (buildModule=YES) >> module: project ':fxml' (buildModule=YES) >> module: project ':graphics' (buildModule=YES) >> module: project ':media' (buildModule=YES) >> module: project ':swing' (buildModule=YES) >> module: project ':swt' (buildModule=NO) >> module: project ':systemTests' (buildModule=NO) >> module: project ':web' (buildModule=YES) >> >>> Task :web:compileJava >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> >>> Task :web:compileShimsJava >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> >>> Task :web:compileTestJava >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> >>> Task :systemTests:compileTestJava >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> >>> Task :systemTests:test >> >> test.javafx.scene.web.HTMLEditorTest > checkStyleWithCSS FAILED >> java.lang.NullPointerException >> at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleWithCSS$7(HTMLEditorTest.java:192) >> >> test.javafx.scene.web.HTMLEditorTest > checkStyleProperty FAILED >> java.lang.NullPointerException >> at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleProperty$11(HTMLEditorTest.java:266) >> >> 3 tests completed, 2 failed, 1 skipped >> >>> Task :systemTests:test FAILED > > The test failure is almost certainly due to not having the native WebKit libraries. Two options: > > 1. You can build WebKit yourself (it's fairly painless on Mac) by running gradle with `-PCOMPILE_WEBKIT=true` > 2. You can download libjfxwebkit.dylib from the openjfx14+1 EA build and put it in `../caches/modular-sdk/modules_libs/javafx.web/libjfxwebkit.dylib` Allright, I've been able to build the WebKit. I am now trying to add my test. I took some snippets from MiscellaneousTest and add my method to HTMLEditorTest: /** * @test * @bug 8230231 * FIXME */ @Test public void checkFontFamily() throws Exception { final FontFaceTestHelper fontFaceHelper = new FontFaceTestHelper("src/test/resources/test/javafx/scene/web/Ahem.ttf"); final CountDownLatch editorStateLatch = new CountDownLatch(1); final AtomicReference result = new AtomicReference<>(); Util.runAndWait(() -> { webView.getEngine().loadContent("\n" + "Toto Tutu\n" + "\n", "text/html"); final JSObject window = (JSObject) webView.getEngine().executeScript("window"); assertNotNull(window); assertEquals("undefined", window.getMember("fontFaceHelper")); window.setMember("fontFaceHelper", fontFaceHelper); assertTrue(window.getMember("fontFaceHelper") instanceof FontFaceTestHelper); // Create font-face object from byte[] webView.getEngine().executeScript( "var byteArray = new Uint8Array(fontFaceHelper.ttfFileContent);\n" + "var arrayBuffer = byteArray.buffer;\n" + "window.fontFace1 = new FontFace('WebFont test', arrayBuffer, {});" ); webView.getEngine().executeScript("document.execCommand('selectAll', false, 'true');"); assertEquals("loaded", webView.getEngine().executeScript("fontFace1.status")); // Add font-face to Document, so that it could be usable on styles //webView.getEngine().executeScript( // "document.fonts.add(fontFace1);\n" + // "document.getElementById('probe1').style.fontFamily = 'WebFont test';\n" //); // webView.getEngine().getLoadWorker().stateProperty(). // addListener((observable, oldValue, newValue) -> { // if (newValue == SUCCEEDED) { // htmlEditor.requestFocus(); // } // }); assertNotNull(fontFamilyComboBox); assertFalse(fontFamilyComboBox.getItems().isEmpty()); String theChosenOne = null; for(String fontFamily: fontFamilyComboBox.getItems()){ if(fontFamily.contains(" ")){ theChosenOne = fontFamily; break; } } assertNotNull(theChosenOne); //Select the font fontFamilyComboBox.getSelectionModel().select(theChosenOne); assertEquals(theChosenOne, fontFamilyComboBox.getSelectionModel().getSelectedItem()); webView.getEngine().executeScript("document.execCommand('selectAll', false, 'true');"); assertEquals(theChosenOne, fontFamilyComboBox.getSelectionModel().getSelectedItem()); editorStateLatch.countDown(); }); assertTrue("Timeout when waiting for focus change ", Util.await(editorStateLatch)); } where fontFamilyComboBox is retrieved like that : fontFamilyComboBox = (ComboBox) htmlEditor.lookup(".font-menu-button"); assertNotNull(fontFamilyComboBox); This idea is to add a Font family with a space in it, then apply it on the text. But I'm struggling to select a text portion, apply the font, then select elsewhere, and select back the text to demonstrate that the ComboBox is not updated. I tried to trigger some selectAll command but it's not working. If anyone has some ideas, I'm all ears. PR: https://git.openjdk.java.net/jfx/pull/12 From fastegal at openjdk.org Thu Oct 10 15:02:10 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 10 Oct 2019 15:02:10 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 15:49:21 GMT, Nir Lisker wrote: > On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java line 170: > >> 169: TableColumnHeader columnHeader = tableHeader.getColumnHeaderFor(column); >> 170: if(columnHeader != null){ >> 171: columnHeader.resizeColumnToFitContent(-1); > > Space after `if` and before `{`. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > >> 607: protected void resizeColumnToFitContent(int maxRows) { >> 608: TableColumnBase tc = getTableColumn(); >> 609: if (!tc.isResizable()) return; > > Here's my suggestion (mind the max character length per line): > > Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells. >

> Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 618: > >> 617: } >> 618: >> 619: private void resizeColumnToFitContent(TableView tv, TableColumn tc, TableViewSkinBase tableSkin, int maxRows) { > > I think we put a space when casting, like `(TableView) control`. Not sure if it is a rule. > > Since you are adding new API you will need to file a CSR once the API review id done. > > ---------------- > > Disapproved by nlisker (Committer). > > > Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. > good, IMO :) Are there any tests guaranteeing that new behaviour is the same as old behaviour? PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Oct 10 15:07:49 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 10 Oct 2019 15:07:49 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 15:49:21 GMT, Nir Lisker wrote: > On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java line 170: > >> 169: TableColumnHeader columnHeader = tableHeader.getColumnHeaderFor(column); >> 170: if(columnHeader != null){ >> 171: columnHeader.resizeColumnToFitContent(-1); > > Space after `if` and before `{`. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > >> 607: protected void resizeColumnToFitContent(int maxRows) { >> 608: TableColumnBase tc = getTableColumn(); >> 609: if (!tc.isResizable()) return; > > Here's my suggestion (mind the max character length per line): > > Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells. >

> Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 618: > >> 617: } >> 618: >> 619: private void resizeColumnToFitContent(TableView tv, TableColumn tc, TableViewSkinBase tableSkin, int maxRows) { > > I think we put a space when casting, like `(TableView) control`. Not sure if it is a rule. > > Since you are adding new API you will need to file a CSR once the API review id done. > > ---------------- > > Disapproved by nlisker (Committer). > Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells. >

> Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). > ``` still would prefer to emphasize a bit more that the sizing you describe in the second sentence is just some implementation (could be implied from the second paragraph, though). How about: The resulting column width for this implementation is the ... PR: https://git.openjdk.java.net/jfx/pull/6 From kevin.rushforth at oracle.com Thu Oct 10 17:03:11 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Oct 2019 10:03:11 -0700 Subject: Skara transition: openjdk/jfx GitHub repo is ready to accept pull requests In-Reply-To: References: <9c45fca9-bae7-4d64-6ada-151914d8fda4@oracle.com> <05e95501-11bc-90b1-ef06-4655598dbcb3@oracle.com> Message-ID: <59b72ff1-0efe-fc0d-6e5c-3dea9646da1c@oracle.com> 1. The Skara bot sends email to the openjfx-dev mailing list as a reply to the RFR. Yes, this will lead to duplicate email for those on the mailing list who are following the PR thread. I can't think of any way to avoid this. 2. We don't need .hgignore any longer needed, but .hgtags has useful historical data, so I wouldn't want to delete it. At some point we could get rid of .hgignore as a cleanup task, but there is no hurry. 3. No plan that I am aware of, but it's an interesting question. I don't know whether it would be feasible to have the Skara tooling enforce this, but even if it were, identifying those changes that need a CSR would still be a manual step. I would note that the bot also doesn't know which PRs need a second reviewer, nor can it tell when all of the outstanding concerns have been addressed. The bot does a baseline level of checking, but ultimately it up to the Reviewer(s) and Committer to ensure that a PR has met the criteria for integrating it. 4. Thanks for the update. As you say, the page could use some further cleanup. 5. The only place I know of where we stated the general rule that OpenJFX N is compatible with JDK N-1 or later is on the mailing list in this thread [1]. And yes, the minimum version applies to running as well as building. As of OpenJFX 13, the minimum is still JDK 11: we use JDK 12 as the boot JDK to build openjfx13, and run javac with "-source 11 -target 11". I am not aware of anything at this time that would motivate us to bump the minimum to JDK 12 or JDK 13, but that's always a possibility. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022534.html On 10/10/2019 5:40 AM, Nir Lisker wrote: > Hi Kevin, > > A few questions?and comments: > > 1. I'm getting double notifications from threads I'm subscribed to - > one from GitHub and one from the bot, including notifications on my > own comments. The Skara bot doesn't need to notify me on threads I'm > subscribed to. > 2. Are the hg files like hgignore and hgtags still needed in the > GitHub Skara repo? > 3. Is there a plan for the bot to be CSR-aware? For example, add to > the checklist the CSR status when applicable? > 4. I updated the build instructions page on the Wiki to remove the > Mercurial requirements and update the Git tools and repo address. The > page could use a cleanup for the sections "Before you start" and > anything below and including "Testing with JDK 9 or JDK 10". > 5. Not directly Skara related, but I could not find where the rule > that OpenJFX is compatible with JDK N and N-1 is stated. I see that > the section "Contributing to the OpenJFX codebase" in Contributing.md > lists JDK 11 as the minimum, but doesn't it apply to users of the > library too? > > - Nir > > > On Wed, Oct 2, 2019 at 4:52 PM Kevin Rushforth > > wrote: > > The openjdk/jfx repo is now open and accepting pull requests. > Refer to > the links in the included message below for more information. > > One thing to note: there is not yet a CI job hooked up to the repo. > Contributors, Committers, and Reviewers need to take this into > account > when testing. > > Please report any problems that you run into by replying to this > thread. > > Thanks. > > -- Kevin > > > On 10/1/2019 9:13 AM, Kevin Rushforth wrote: > > As announced in this message [1], we are transitioning the official > > openjfx mainline repo from Mercurial (hosted on > hg.openjdk.java.net ) > > to GIT (hosted on github.com ). Effective > immediately, the HG > > openjfx/jfx-dev/rt [2] repo is frozen. No more pushes to this repo > > will be accepted. Similarly, no more pull requests will be accepted > > against the GitHub javafxports/openjdk-jfx [3] sandbox repo. > > > > I have one final push to HG which will add the .jcheck/conf file > > needed by Skara [4]. I will do some sanity testing, and then the HG > > repo will be made read-only. > > > > I will send an announcement tomorrow morning when the new GitHub > > openjdk/jfx [5] repo is open for accepting pull requests. In the > mean > > time, you can fork and clone the new repo as indicated here [6] to > > prepare for this. > > > > Let me know if you have any questions. > > > > -- Kevin > > > > [1] > > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt > > [3] https://github.com/javafxports/openjdk-jfx > > [4] https://bugs.openjdk.java.net/browse/JDK-8231310 > > [5] https://github.com/openjdk/jfx > > [6] > > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html > From arajkumar at openjdk.org Fri Oct 11 05:52:33 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Fri, 11 Oct 2019 05:52:33 GMT Subject: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing Message-ID: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> 8232158: [macOS] Fallback to command line tools if xcode is missing ---------------- Commits: - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing Changes: https://git.openjdk.java.net/jfx/pull/13/files Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 PR: https://git.openjdk.java.net/jfx/pull/13 From arajkumar at openjdk.org Fri Oct 11 06:07:14 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Fri, 11 Oct 2019 06:07:14 GMT Subject: RFR: 8211308: Support HTTP/2 in WebView Message-ID: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. Reference: [1] https://openjdk.java.net/groups/net/httpclient/intro.html [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers #### Task List - [x] simple GET requests - [x] Runtime setting to fallback to legacy client - [ ] Runtime settings to use *only* HTTP/1.1 - [x] sync requests - [x] Error Handling & Propagation - [x] POST with form data - [x] AccessController association for HttpClient.sendAsync / send - [x] Redirection - [ ] Check for possibilities to write unit tests - [ ] Sync request handling from WebCore java platform layer - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool - [x] gzip, deflate encoding support #### HTTP/2 Test pages - http://www.http2demo.io - https://http2.akamai.com/demo - https://http2.golang.org - https://google.com #### Redirection Test - https://www.httpwatch.com/httpgallery/redirection/#showExample7 More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. ---------------- Commits: - 1798a661: 8211308: Support HTTP/2 in WebView Changes: https://git.openjdk.java.net/jfx/pull/14/files Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod Patch: https://git.openjdk.java.net/jfx/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 PR: https://git.openjdk.java.net/jfx/pull/14 From arajkumar at openjdk.org Fri Oct 11 06:08:11 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Fri, 11 Oct 2019 06:08:11 GMT Subject: [Rev 01] RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> Message-ID: <6xAHz6EiuaGs_7KDPIYkt_A-t6gY8F1Al81kCTtqz7U=.63226b14-60c4-4bc0-b7fc-42d596ab0394@github.com> The pull request has been updated with additional changes. ---------------- Added commits: - 9b1f7286: 8232158: [macOS] Fallback to command line tools if xcode is missing Changes: - all: https://git.openjdk.java.net/jfx/pull/13/files - new: https://git.openjdk.java.net/jfx/pull/13/files/063d2f38..9b1f7286 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/13/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/13/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 PR: https://git.openjdk.java.net/jfx/pull/13 From arajkumar at openjdk.org Fri Oct 11 06:18:38 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Fri, 11 Oct 2019 06:18:38 GMT Subject: RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> Message-ID: <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: > The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. > > Reference: > [1] https://openjdk.java.net/groups/net/httpclient/intro.html > [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html > > Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, > > [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient > [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 > [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers > > #### Task List > - [x] simple GET requests > - [x] Runtime setting to fallback to legacy client > - [ ] Runtime settings to use *only* HTTP/1.1 > - [x] sync requests > - [x] Error Handling & Propagation > - [x] POST with form data > - [x] AccessController association for HttpClient.sendAsync / send > - [x] Redirection > - [ ] Check for possibilities to write unit tests > - [ ] Sync request handling from WebCore java platform layer > - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool > - [x] gzip, deflate encoding support > > #### HTTP/2 Test pages > - http://www.http2demo.io > - https://http2.akamai.com/demo > - https://http2.golang.org > - https://google.com > > #### Redirection Test > - https://www.httpwatch.com/httpgallery/redirection/#showExample7 > > More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. > > ---------------- > > Commits: > - 1798a661: 8211308: Support HTTP/2 in WebView > > Changes: https://git.openjdk.java.net/jfx/pull/14/files > Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 > Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod > Patch: https://git.openjdk.java.net/jfx/pull/14.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. PR: https://git.openjdk.java.net/jfx/pull/14 From jvos at openjdk.org Fri Oct 11 06:42:30 2019 From: jvos at openjdk.org (Johan Vos) Date: Fri, 11 Oct 2019 06:42:30 GMT Subject: [Approved] RFR: 8226754: FX build fails using gradle 5.6+ or 6 In-Reply-To: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> References: <1hZYruHDLofatLgNnJqWpWpWQdVYORy_yrAy2QKJ69o=.c6640112-6e77-48df-9352-4eb60c04776a@github.com> Message-ID: On Tue, 8 Oct 2019 13:54:22 GMT, Kevin Rushforth wrote: > JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) > > As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). > > The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). > > The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. > > The changes are as follows: > > 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x > 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` > 3. Specify no metadata for ivy repositories > 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir > 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) > > I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. > > ---------------- > > Commits: > - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 > > Changes: https://git.openjdk.java.net/jfx/pull/9/files > Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 > Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/9.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 Works on Linux/Mac/Windows ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/9 From jvos at openjdk.org Fri Oct 11 06:44:09 2019 From: jvos at openjdk.org (Johan Vos) Date: Fri, 11 Oct 2019 06:44:09 GMT Subject: RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> Message-ID: On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar wrote: > On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: > >> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. >> >> Reference: >> [1] https://openjdk.java.net/groups/net/httpclient/intro.html >> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html >> >> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, >> >> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient >> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 >> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers >> >> #### Task List >> - [x] simple GET requests >> - [x] Runtime setting to fallback to legacy client >> - [ ] Runtime settings to use *only* HTTP/1.1 >> - [x] sync requests >> - [x] Error Handling & Propagation >> - [x] POST with form data >> - [x] AccessController association for HttpClient.sendAsync / send >> - [x] Redirection >> - [ ] Check for possibilities to write unit tests >> - [ ] Sync request handling from WebCore java platform layer >> - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool >> - [x] gzip, deflate encoding support >> >> #### HTTP/2 Test pages >> - http://www.http2demo.io >> - https://http2.akamai.com/demo >> - https://http2.golang.org >> - https://google.com >> >> #### Redirection Test >> - https://www.httpwatch.com/httpgallery/redirection/#showExample7 >> >> More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. >> >> ---------------- >> >> Commits: >> - 1798a661: 8211308: Support HTTP/2 in WebView >> >> Changes: https://git.openjdk.java.net/jfx/pull/14/files >> Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 >> Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod >> Patch: https://git.openjdk.java.net/jfx/pull/14.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 > > Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. Good work. Should the title be prefixed with WIP until it's ready for review, so that Skara will send the RFR when it is ready for review? PR: https://git.openjdk.java.net/jfx/pull/14 From arajkumar at openjdk.org Fri Oct 11 07:01:48 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Fri, 11 Oct 2019 07:01:48 GMT Subject: RFR: WIP: 8211308: Support HTTP/2 in WebView In-Reply-To: References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> Message-ID: On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos wrote: > On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar wrote: > >> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: >> >>> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. >>> >>> Reference: >>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html >>> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html >>> >>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, >>> >>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient >>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 >>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers >>> >>> #### Task List >>> - [x] simple GET requests >>> - [x] Runtime setting to fallback to legacy client >>> - [ ] Runtime settings to use *only* HTTP/1.1 >>> - [x] sync requests >>> - [x] Error Handling & Propagation >>> - [x] POST with form data >>> - [x] AccessController association for HttpClient.sendAsync / send >>> - [x] Redirection >>> - [ ] Check for possibilities to write unit tests >>> - [ ] Sync request handling from WebCore java platform layer >>> - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool >>> - [x] gzip, deflate encoding support >>> >>> #### HTTP/2 Test pages >>> - http://www.http2demo.io >>> - https://http2.akamai.com/demo >>> - https://http2.golang.org >>> - https://google.com >>> >>> #### Redirection Test >>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7 >>> >>> More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. >>> >>> ---------------- >>> >>> Commits: >>> - 1798a661: 8211308: Support HTTP/2 in WebView >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/14/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 >>> Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/14.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 >> >> Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. > > Good work. Should the title be prefixed with WIP until it's ready for review, so that Skara will send the RFR when it is ready for review? I was wondering why @skara had sent the RFR when the PR is still in draft stage. Actually @skara should consider the "Draft" attribute associated with the PR. PR: https://git.openjdk.java.net/jfx/pull/14 From rwestberg at openjdk.org Fri Oct 11 11:21:08 2019 From: rwestberg at openjdk.org (Robin Westberg) Date: Fri, 11 Oct 2019 11:21:08 GMT Subject: RFR: WIP: 8211308: Support HTTP/2 in WebView In-Reply-To: References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> Message-ID: <8NVPSfkk9SAl3JCFggl9QGzSP1QvJfajNR9qJUjfhuk=.cc58a9f9-1141-4618-a16a-06f9ca757cf5@github.com> On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar wrote: > On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos wrote: > >> On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar wrote: >> >>> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: >>> >>>> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. >>>> >>>> Reference: >>>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html >>>> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html >>>> >>>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, >>>> >>>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient >>>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 >>>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers >>>> >>>> #### Task List >>>> - [x] simple GET requests >>>> - [x] Runtime setting to fallback to legacy client >>>> - [ ] Runtime settings to use *only* HTTP/1.1 >>>> - [x] sync requests >>>> - [x] Error Handling & Propagation >>>> - [x] POST with form data >>>> - [x] AccessController association for HttpClient.sendAsync / send >>>> - [x] Redirection >>>> - [ ] Check for possibilities to write unit tests >>>> - [ ] Sync request handling from WebCore java platform layer >>>> - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool >>>> - [x] gzip, deflate encoding support >>>> >>>> #### HTTP/2 Test pages >>>> - http://www.http2demo.io >>>> - https://http2.akamai.com/demo >>>> - https://http2.golang.org >>>> - https://google.com >>>> >>>> #### Redirection Test >>>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7 >>>> >>>> More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 1798a661: 8211308: Support HTTP/2 in WebView >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/14/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 >>>> Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/14.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 >>> >>> Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. >> >> Good work. Should the title be prefixed with WIP until it's ready for review, so that Skara will send the RFR when it is ready for review? > > I was wondering why @skara had sent the RFR when the PR is still in draft stage. Actually @skara should consider the "Draft" attribute associated with the PR. Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to track this. PR: https://git.openjdk.java.net/jfx/pull/14 From shadzic at openjdk.org Fri Oct 11 13:59:39 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Fri, 11 Oct 2019 13:59:39 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 15:49:21 GMT, Nir Lisker wrote: > On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java line 170: > >> 169: TableColumnHeader columnHeader = tableHeader.getColumnHeaderFor(column); >> 170: if(columnHeader != null){ >> 171: columnHeader.resizeColumnToFitContent(-1); > > Space after `if` and before `{`. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: > >> 607: protected void resizeColumnToFitContent(int maxRows) { >> 608: TableColumnBase tc = getTableColumn(); >> 609: if (!tc.isResizable()) return; > > Here's my suggestion (mind the max character length per line): > > Resizes this {@code TableColumnHeader}'s column to fit the width of its content. The resulting column width is the maximum of the preferred width of the header cell and the preferred width of the first {@code maxRow} cells. >

> Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum width etc.). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 618: > >> 617: } >> 618: >> 619: private void resizeColumnToFitContent(TableView tv, TableColumn tc, TableViewSkinBase tableSkin, int maxRows) { > > I think we put a space when casting, like `(TableView) control`. Not sure if it is a rule. > > Since you are adding new API you will need to file a CSR once the API review id done. > > ---------------- > > Disapproved by nlisker (Committer). I wouldn't know if there are enough tests on that part. I know I added one. PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Fri Oct 11 15:57:24 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Fri, 11 Oct 2019 15:57:24 GMT Subject: [Rev 03] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 1f1f7c44: Javadoc update upon review for tableColumnHeader Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new: https://git.openjdk.java.net/jfx/pull/6/files/49abc7c7..1f1f7c44 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/6/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.02-03 Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at swingempire.de Mon Oct 14 13:28:29 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 14 Oct 2019 15:28:29 +0200 Subject: Parameterized test not compiling Message-ID: <20191014152829.Horde.7OOldXq2ndAxAusH0cHnaw1@webmail.df.eu> compiles fine in Eclipse, throws when compiling in cygwin with gradle :controls:test The test class (excerpt): @RunWith(Parameterized.class) public abstract class DefaultCancelButtonTest { private ButtonType buttonType; private boolean consume; private boolean registerAfterShowing; @Parameterized.Parameters(name= "{index}: Button {0}, consuming {1}, registerAfterShowing {2} " ) public static Collection data() { Object[][] data = new Object[][] { // buttonType, consuming, registerAfterShowing {new ButtonType(ButtonState.DEFAULT), true, true}, {new ButtonType(ButtonState.DEFAULT), true, false}, {new ButtonType(ButtonState.DEFAULT), false, true}, {new ButtonType(ButtonState.DEFAULT), false, false}, {new ButtonType(ButtonState.CANCEL), true, true}, {new ButtonType(ButtonState.CANCEL), true, false}, {new ButtonType(ButtonState.CANCEL), false, true}, {new ButtonType(ButtonState.CANCEL), false, false}, }; return Arrays.asList(data); } public DefaultCancelButtonTest(ButtonType buttonType, boolean consume, boolean registerAfterShowing) { this.buttonType = buttonType; this.consume = consume; this.registerAfterShowing = registerAfterShowing; } } the error: C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.controls\src\test\java\test\javafx\scene\control\DefaultCancelButtonTest.java:172: error: cannot find symbol @Parameterized.Parameters(name= "{index}: Button {0}, consuming {1}, registerAfterShowing {2} " ) ^ symbol: method name() location: @interface Parameters Any idea what's wrong? From jvos at openjdk.org Tue Oct 15 11:01:05 2019 From: jvos at openjdk.org (Johan Vos) Date: Tue, 15 Oct 2019 11:01:05 GMT Subject: [Approved] RFR: 8218640: Update ICU4C to version 64.2 In-Reply-To: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> References: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> Message-ID: On Wed, 9 Oct 2019 13:25:54 GMT, Arun Joseph wrote: > We currently use ICU4C version 62.1. We should update to the latest stable version 64.2. > http://site.icu-project.org/home > > ---------------- > > Commits: > - b56b720e: 8218640: Update ICU4C to version 64.2 > > Changes: https://git.openjdk.java.net/jfx/pull/10/files > Webrev: https://webrevs.openjdk.java.net/jfx/10/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8218640 > Stats: 41065 lines in 430 files changed: 23684 ins; 7205 del; 10176 mod > Patch: https://git.openjdk.java.net/jfx/pull/10.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/10/head:pull/10 Builds clean on Mac/Linux/Win ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/10 From fastegal at swingempire.de Tue Oct 15 11:37:06 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 15 Oct 2019 13:37:06 +0200 Subject: Parameterized test not compiling In-Reply-To: <20191014152829.Horde.7OOldXq2ndAxAusH0cHnaw1@webmail.df.eu> References: <20191014152829.Horde.7OOldXq2ndAxAusH0cHnaw1@webmail.df.eu> Message-ID: <20191015133706.Horde.tbbWQh9XaRXnoBnBCF41IA1@webmail.df.eu> Zitat von Jeanette Winzenburg : okay, probably found the reason: dependencies { testCompile group: "junit", name: "junit", version: "4.8.2" if (BUILD_CLOSED && DO_JCOV) { testCompile name: "jcov" } } the version is too old, name parameter was introduced in 4.11. Any plans to update? For now, I will comment the name (which makes failing tests quite unreadable, but can't be helped, a test for a fixed bug will not fail :) > compiles fine in Eclipse, throws when compiling in cygwin with > gradle :controls:test > > The test class (excerpt): > > @RunWith(Parameterized.class) > public abstract class DefaultCancelButtonTest { > > private ButtonType buttonType; > private boolean consume; > private boolean registerAfterShowing; > > @Parameterized.Parameters(name= "{index}: Button {0}, consuming > {1}, registerAfterShowing {2} " ) > public static Collection data() { > Object[][] data = new Object[][] { > // buttonType, consuming, registerAfterShowing > {new ButtonType(ButtonState.DEFAULT), true, true}, > {new ButtonType(ButtonState.DEFAULT), true, false}, > {new ButtonType(ButtonState.DEFAULT), false, true}, > {new ButtonType(ButtonState.DEFAULT), false, false}, > {new ButtonType(ButtonState.CANCEL), true, true}, > {new ButtonType(ButtonState.CANCEL), true, false}, > {new ButtonType(ButtonState.CANCEL), false, true}, > {new ButtonType(ButtonState.CANCEL), false, false}, > }; > return Arrays.asList(data); > } > > public DefaultCancelButtonTest(ButtonType buttonType, boolean consume, > boolean registerAfterShowing) { > this.buttonType = buttonType; > this.consume = consume; > this.registerAfterShowing = registerAfterShowing; > } > > } > > the error: > > C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.controls\src\test\java\test\javafx\scene\control\DefaultCancelButtonTest.java:172: error: cannot find > symbol > @Parameterized.Parameters(name= "{index}: Button {0}, consuming > {1}, registerAfterShowing {2} " ) > ^ > symbol: method name() > location: @interface Parameters > > Any idea what's wrong? From fastegal at swingempire.de Tue Oct 15 11:48:11 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 15 Oct 2019 13:48:11 +0200 Subject: Unexpected: abstract test classes are run ... Message-ID: <20191015134811.Horde.uoy6MiaaXwcoHDg6v0lFSg1@webmail.df.eu> .. with gradle :controls:test Maybe related to the outdated version (4.8.2 of junit) as well as the problem with missing name property (of Parameterized? Don't know, though. The workaround seems to be to @Ignore abstract tests - descendants are run as expected. From kevin.rushforth at oracle.com Tue Oct 15 11:54:05 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Oct 2019 04:54:05 -0700 Subject: Unexpected: abstract test classes are run ... In-Reply-To: <20191015134811.Horde.uoy6MiaaXwcoHDg6v0lFSg1@webmail.df.eu> References: <20191015134811.Horde.uoy6MiaaXwcoHDg6v0lFSg1@webmail.df.eu> Message-ID: Our convention, which is codified in build.gradle (but not documented well), is that the name of any concrete unit test class must end with exactly `Test`. Similarly, the name of any abstract super class or utility class should not end with `Test`. It's a little clunky, but dates back to the very early port of JavaFX build to gradle. Or are you seeing something else? As for the version of junit, we could consider updating to a newer version (it would need us to do a third-party approval), if there were enough benefit. It would be behind a few other things for openjfx14... -- Kevin On 10/15/2019 4:48 AM, Jeanette Winzenburg wrote: > > .. with gradle :controls:test > > Maybe related to the outdated version (4.8.2 of junit) as well as the > problem with missing name property (of Parameterized? Don't know, though. > > The workaround seems to be to @Ignore abstract tests - descendants are > run as expected. > From fastegal at swingempire.de Tue Oct 15 12:17:19 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 15 Oct 2019 14:17:19 +0200 Subject: Unexpected: abstract test classes are run ... In-Reply-To: References: <20191015134811.Horde.uoy6MiaaXwcoHDg6v0lFSg1@webmail.df.eu> Message-ID: <20191015141719.Horde.xmn4FoWRJQdi7rJ5r5LESg6@webmail.df.eu> Zitat von Kevin Rushforth : > Our convention, which is codified in build.gradle (but not > documented well), is that the name of any concrete unit test class > must end with exactly `Test`. Similarly, the name of any abstract > super class or utility class should not end with `Test`. It's a > little clunky, but dates back to the very early port of JavaFX build > to gradle. > ahh ... faintly remember those days, think we used the same/similar convention in SwingX :) > Or are you seeing something else? > no - works with renaming, thanks > As for the version of junit, we could consider updating to a newer > version (it would need us to do a third-party approval), if there > were enough benefit. It would be behind a few other things for > openjfx14... > if there are other niceties (apart from the name parameter in parameterized tests) not available in 4.8.2, I will stumble across them, I always do sooner or later

> -- Kevin > > On 10/15/2019 4:48 AM, Jeanette Winzenburg wrote: >> >> .. with gradle :controls:test >> >> Maybe related to the outdated version (4.8.2 of junit) as well as >> the problem with missing name property (of Parameterized? Don't >> know, though. >> >> The workaround seems to be to @Ignore abstract tests - descendants >> are run as expected. >> From john at status6.com Tue Oct 15 16:03:53 2019 From: john at status6.com (John Neffenger) Date: Tue, 15 Oct 2019 09:03:53 -0700 Subject: Unexpected: abstract test classes are run ... In-Reply-To: <20191015141719.Horde.xmn4FoWRJQdi7rJ5r5LESg6@webmail.df.eu> References: <20191015134811.Horde.uoy6MiaaXwcoHDg6v0lFSg1@webmail.df.eu> <20191015141719.Horde.xmn4FoWRJQdi7rJ5r5LESg6@webmail.df.eu> Message-ID: <23fece71-b52b-e000-b932-5342afc3ad99@status6.com> On 10/15/19 5:17 AM, Jeanette Winzenburg wrote: > if there are other niceties (apart from the name parameter in > parameterized tests) not available in 4.8.2, I will stumble across them, > I always do sooner or later

One other nicety is a big performance improvement in comparing primitive arrays found in the later versions of JUnit 4. New unit tests 12 times slower under Gradle (solved) http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-February/023114.html John From kevin.rushforth at oracle.com Tue Oct 15 16:40:32 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Oct 2019 09:40:32 -0700 Subject: [14] RFR: Request to sync October 2019 CPU changes into jfx Message-ID: <6e3170bf-d0de-f1b5-fcda-a210a5bcb712@oracle.com> Johan and Phil, I request approval to sync changes from to the just-released October 2019 CPU release into 'jfx'. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/64aaeb8...bada612 NOTE: Since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly rather than via a pull request. -- Kevin From kevin.rushforth at oracle.com Tue Oct 15 16:43:52 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Oct 2019 09:43:52 -0700 Subject: [11][13] RFR: Request to backport October 2019 CPU changes Message-ID: <135916bc-48a7-7c97-3e8c-50b445ff3da1@oracle.com> Hi Johan, I request approval to backport the changes from the just-released April 2019 CPU to 11-dev and 13-dev. https://cr.openjdk.java.net/~kcr/cpu-1910-sync/11-dev/webrev/ https://cr.openjdk.java.net/~kcr/cpu-1910-sync/13-dev/webrev/ Each is a straight backport (patch applies cleanly) of the one FX fix that went into the October CPU. Thanks. -- Kevin From kevin.rushforth at oracle.com Tue Oct 15 16:44:56 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Oct 2019 09:44:56 -0700 Subject: [11][13] RFR: Request to backport October 2019 CPU changes In-Reply-To: <135916bc-48a7-7c97-3e8c-50b445ff3da1@oracle.com> References: <135916bc-48a7-7c97-3e8c-50b445ff3da1@oracle.com> Message-ID: <32444616-991f-4bde-60d8-91c33912732c@oracle.com> > I request approval to backport the changes from the just-released April 2019 CPU to 11-dev and 13-dev. Typo: that should be October 2019 CPU On 10/15/2019 9:43 AM, Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released > April 2019 CPU to 11-dev and 13-dev. > > https://cr.openjdk.java.net/~kcr/cpu-1910-sync/11-dev/webrev/ > https://cr.openjdk.java.net/~kcr/cpu-1910-sync/13-dev/webrev/ > > Each is a straight backport (patch applies cleanly) of the one FX fix > that went into the October CPU. > > Thanks. > > -- Kevin > From philip.race at oracle.com Tue Oct 15 17:30:35 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2019 10:30:35 -0700 Subject: [14] RFR: Request to sync October 2019 CPU changes into jfx In-Reply-To: <6e3170bf-d0de-f1b5-fcda-a210a5bcb712@oracle.com> References: <6e3170bf-d0de-f1b5-fcda-a210a5bcb712@oracle.com> Message-ID: Approved. -phil On 10/15/19 9:40 AM, Kevin Rushforth wrote: > Johan and Phil, > > I request approval to sync changes from to the just-released October > 2019 CPU release into 'jfx'. Here is the aggregate set of changes for > the fixes: > > https://github.com/kevinrushforth/jfx/compare/64aaeb8...bada612 > > NOTE: Since this is an integration of already-reviewed fixes into the > jfx repo, I will push it directly rather than via a pull request. > > -- Kevin > From philip.race at oracle.com Tue Oct 15 17:31:33 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2019 10:31:33 -0700 Subject: [11][13] RFR: Request to backport October 2019 CPU changes In-Reply-To: <32444616-991f-4bde-60d8-91c33912732c@oracle.com> References: <135916bc-48a7-7c97-3e8c-50b445ff3da1@oracle.com> <32444616-991f-4bde-60d8-91c33912732c@oracle.com> Message-ID: Approved. -phil. On 10/15/19 9:44 AM, Kevin Rushforth wrote: > > I request approval to backport the changes from the just-released > April 2019 CPU to 11-dev and 13-dev. > > Typo: that should be October 2019 CPU > > On 10/15/2019 9:43 AM, Kevin Rushforth wrote: >> Hi Johan, >> >> I request approval to backport the changes from the just-released >> April 2019 CPU to 11-dev and 13-dev. >> >> https://cr.openjdk.java.net/~kcr/cpu-1910-sync/11-dev/webrev/ >> https://cr.openjdk.java.net/~kcr/cpu-1910-sync/13-dev/webrev/ >> >> Each is a straight backport (patch applies cleanly) of the one FX fix >> that went into the October CPU. >> >> Thanks. >> >> -- Kevin >> > From ghb at openjdk.org Tue Oct 15 17:42:39 2019 From: ghb at openjdk.org (Guru Hb) Date: Tue, 15 Oct 2019 17:42:39 GMT Subject: [Integrated] RFR: 8218640: Update ICU4C to version 64.2 In-Reply-To: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> References: <0XMlFwr_aSLv25IM9n6B1ASSO3Wl3N6SGznRTH1NiyQ=.a759c11c-f2de-413f-a74c-e0006ad15b7e@github.com> Message-ID: <9c1b35fa-22e0-49cf-a40e-54164f533fa1@openjdk.org> Changeset: b6e53f4f Author: Arun Joseph Committer: Guru Hb Date: 2019-10-15 17:41:33 +0000 URL: https://git.openjdk.java.net/jfx/commit/b6e53f4f 8218640: Update ICU4C to version 64.2 Reviewed-by: kcr, ghb, jvos ! modules/javafx.web/src/main/legal/icu_web.md ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/CMakeLists.txt ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/LICENSE - modules/javafx.web/src/main/native/Source/ThirdParty/icu/java/data/icudt62l.zip + modules/javafx.web/src/main/native/Source/ThirdParty/icu/java/data/icudt64l.zip ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/bmpset.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/brkeng.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/bytesinkutil.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/bytesinkutil.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/bytestriebuilder.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/capi_helper.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/characterproperties.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/charstr.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/charstr.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/cmemory.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/common.rc ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/common.vcxproj ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/common.vcxproj.filters ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/common_uwp.vcxproj ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/dictbe.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/dictionarydata.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/edits.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/hash.h - modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/listformatter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/loadednormalizer2impl.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/localebuilder.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/localsvc.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locavailable.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locdispnames.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locdspnm.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locid.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/loclikely.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locmap.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locmap.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locresdata.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/locutil.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/mutex.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/norm2_nfc_data.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/normalizer2.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/normalizer2impl.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/normalizer2impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/normlzr.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/patternprops.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/patternprops.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/propname_data.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/putil.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/putilimp.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbi.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbi_cache.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbi_cache.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbicst.pl ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbirb.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbirpt.txt ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbiscan.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbiscan.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbitblb.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/rbbitblb.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/resbund.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/serv.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/servls.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/servnotf.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/sharedobject.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/simpleformatter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/static_unicode_sets.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/static_unicode_sets.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/stringtriebuilder.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uassert.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ubidi.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ubidi_props_data.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ubidiln.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ubiditransform.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ubidiwrt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucase.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucase_props_data.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uchar.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uchar_props_data.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucln_cmn.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucln_cmn.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv2022.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv_bld.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv_ct.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv_u16.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv_u32.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnv_u8.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnvhz.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnvmbcs.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucnvsel.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucol_swp.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucptrie.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucptrie_impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ucurr.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/udata.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/udataswp.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uhash.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uinvchar.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uinvchar.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ulayout_props.h - modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ulistformatter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uloc.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uloc_keytype.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uloc_tag.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ulocimp.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/umapfile.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/umapfile.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/umutablecptrie.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/umutex.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/umutex.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unames.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/brkiter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/bytestream.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/casemap.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/char16ptr.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/docmain.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/dtintrv.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/edits.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/enumset.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/filteredbrk.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/icuplug.h - modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/listformatter.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/localebuilder.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/localpointer.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/locdspnm.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/locid.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/messagepattern.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/normalizer2.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/parsepos.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/platform.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ptypes.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/rbbi.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/simpleformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/stringoptions.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/stringtriebuilder.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ubidi.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ubiditransform.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uchar.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ucnv.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uconfig.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ucpmap.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ucptrie.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ucurr.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uenum.h - modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ulistformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/umachine.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/umutablecptrie.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uniset.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/unistr.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uobject.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/urename.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ures.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uscript.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uset.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/usprep.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/ustring.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/utext.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/utf16.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/utf8.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/utypes.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/uvernum.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unifiedcache.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unifiedcache.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uniset.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uniset_closure.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uniset_props.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unistr.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uobject.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uprops.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uprops.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uresbund.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uresdata.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uresimp.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uscript.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uscript_props.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uset.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/usetiter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ushape.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/usprep.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ustr_cnv.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ustr_titlecase_brkiter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/ustrcase.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utext.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrace.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrie.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrie2.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrie2.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrie2_builder.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrie2_impl.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/utrie_swap.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uts46.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uvector.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uvector.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uvectr32.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/uvectr64.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/wintz.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/wintz.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/alphaindex.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/anytrans.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/astro.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/brktrans.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/calendar.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/chnsecal.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/coll.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/collationbuilder.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/collationdatabuilder.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/collationfcd.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/collationkeys.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/collationruleparser.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/csdetect.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/csrmbcs.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/csrsbcs.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/currfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/currfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/currpinf.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/currunit.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/datefmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/dcfmtsym.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/decNumberLocal.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/decimfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion-bignum-dtoa.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion-bignum.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion-bignum.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion-cached-powers.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion-ieee.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion-utils.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/double-conversion.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/dtfmtsym.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/dtitvfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/dtitvinf.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/dtptngen.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/dtptngen_impl.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/erarules.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/erarules.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/fmtable.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/formattedval_impl.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/formattedval_iterimpl.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/formattedval_sbimpl.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/formattedvalue.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/fphdlimp.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/fphdlimp.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/fpositer.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/gender.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/gregocal.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/gregoimp.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/i18n.rc ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/i18n.vcxproj ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/i18n.vcxproj.filters ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/i18n_uwp.vcxproj ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/indiancal.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/indiancal.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/islamcal.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/japancal.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/japancal.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/listformatter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/measfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/measunit.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/msgfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/nfrule.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/nfrule.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_affixutils.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_affixutils.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_asformat.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_capi.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_compact.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_decimalquantity.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_decimalquantity.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_decimfmtprops.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_decimfmtprops.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_fluent.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_formatimpl.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_formatimpl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_grouping.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_integerwidth.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_longnames.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_longnames.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_mapper.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_mapper.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_microprops.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_modifiers.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_modifiers.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_multiplier.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_multiplier.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_output.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_padding.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_patternmodifier.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_patternmodifier.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_patternstring.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_patternstring.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_rounding.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_roundingutils.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_scientific.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_scientific.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_skeletons.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_skeletons.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_stringbuilder.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_stringbuilder.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_types.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_utils.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_utils.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/number_utypes.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_affixes.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_affixes.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_currency.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_impl.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_parsednumber.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_scientific.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_symbols.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numparse_types.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numrange_fluent.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numrange_impl.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numrange_impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numsys.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/numsys_impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/olsontz.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/plurfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/plurrule.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/plurrule_impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/quantityformatter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/quantityformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rbnf.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rbt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rbt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rbt_pars.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rbtz.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/regexcmp.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/regexcst.txt ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/region.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/reldatefmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/reldtfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/reldtfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rematch.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/rulebasedcollator.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/scriptset.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/scriptset.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/shareddateformatsymbols.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/simpletz.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/smpdtfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/timezone.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tmunit.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tmutfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/translit.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/transreg.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tridpars.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tzfmt.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tzgnames.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tzgnames.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tznames.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/tznames_impl.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/ucln_in.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/ucol_res.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/udat.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/udateintervalformat.cpp + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/ulistformatter.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/ulocdata.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/umsg.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/alphaindex.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/calendar.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/coll.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/compactdecimalformat.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/currpinf.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/currunit.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/datefmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/dcfmtsym.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/decimfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/dtitvfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/dtitvinf.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/dtptngen.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/fmtable.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/formattedvalue.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/gender.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/listformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/measfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/measunit.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/msgfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/nounit.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/numberformatter.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/numberrangeformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/numfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/numsys.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/plurfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/plurrule.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/rbnf.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/regex.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/region.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/reldatefmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/smpdtfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/timezone.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/translit.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/tzfmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/ucal.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/ucol.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/udat.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/udateintervalformat.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/udatpg.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/uformattedvalue.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/ugender.h + modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/ulistformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/unum.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/unumberformatter.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/unumsys.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/upluralrules.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/uregex.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/ureldatefmt.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/usearch.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/unicode/uspoof.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/upluralrules.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/uregex.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/usearch.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/uspoof.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/uspoof_conf.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/uspoof_impl.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/uspoof_impl.h ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/vtzone.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/i18n/zonemeta.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/filestrm.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/filetools.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/package.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/pkg_genc.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/pkg_gencmn.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/swapimpl.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/toolutil.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/toolutil.vcxproj ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/ucbuf.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/ucmstate.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/udbgutil.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/unewdata.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/writesrc.cpp ! modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/tools/toolutil/writesrc.h From philip.race at oracle.com Tue Oct 15 19:17:38 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2019 12:17:38 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> Message-ID: Hi, I've looked over this and I don't see any issues - meaning gotchas. It just provides a way to over-ride the hard-coded 8, whether using a Text node directly or a TextFlow. Two observations of what one might call limitations 1) This is a rendering time property, which is controlled by the program. A document containing tabs saved and re-rendered somewhere else won't be helped. 2) This just provides API on the scene graph node types, not any of the UI controls which use Text nodes. Something like a CSS property may be the way to go if you wanted that. Text has a nested class StyleableProperties for CSS properties with which it plays nice : font, underline, strikethrough, text-alignment So creating an fx-tabWidth (or similar name) CSS property could be propagated through to there in a similar way. -phil. On 9/30/19 9:48 AM, Scott Palmer wrote: > Okay, current work relocated to a clone of the new official Git repo. > My initial implementation is here: > https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f > > I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? > > I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. > > Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. > > Scott > >> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >> >> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >> >> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >> >> Regards, >> >> Scott >> >> >>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>> >>> Thanks Kevin. >>> >>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>> >>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>> >>> Cheers, >>> >>> Scott >>> >>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>> >>>> Hi Scott, >>>> >>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>> >>>> -- Kevin >>>> >>>> >>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>> >>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>> PrismTextLayout implements the new setTabWidth API. >>>>> >>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>> >>>>> What?s the next step? >>>>> >>>>> Regards, >>>>> >>>>> Scott From sverre.moe at gmail.com Wed Oct 16 10:04:56 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 16 Oct 2019 12:04:56 +0200 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: A comment on the JDK-8231644 issue was added by Jeanette Winzenburg https://bugs.openjdk.java.net/browse/JDK-8231644 > hmm .. no testing done but: the data object looks pathological - it's always problematic to have nodes as data (even though technically possible). That will explode with the known glitches with graphics/disclosureNode in treeTableRow I would like to know more about what you are saying here: 1) That OurDataObject and AlsoOurDataObject as data model/type to TreeTableView is pathological? 2) "Having nodes as data". Are you referring to using a Label node in the Column CellValueFactory? column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>( new OurDataObjectLabel(param.getValue().getValue()))); Instead of using: column.setCellValueFactory(new TreeItemPropertyValueFactory<>("name")); The reason we are using OurDataObjectLabel, is because we want to style a specific type of data determined by AlsoOurDataObject. 3) What known glitches? /Sverre From fastegal at swingempire.de Wed Oct 16 10:51:58 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 16 Oct 2019 12:51:58 +0200 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: <20191016125158.Horde._fMw0jIvL6DFyFSJW68wUA1@webmail.df.eu> Zitat von Sverre Moe : > A comment on the JDK-8231644 issue was added by Jeanette Winzenburg > https://bugs.openjdk.java.net/browse/JDK-8231644 > >> hmm .. no testing done but: the data object looks pathological - it's > always problematic to have nodes as data (even though technically > possible). That will explode with the known glitches with > graphics/disclosureNode in treeTableRow > > I would like to know more about what you are saying here: > > 1) That OurDataObject and AlsoOurDataObject as data model/type to > TreeTableView is pathological? > > 2) "Having nodes as data". Are you referring to using a Label node in the > Column CellValueFactory? > column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>( > new OurDataObjectLabel(param.getValue().getValue()))); > exactly, _class OurDataObjectLabel extends Label_ is a terrible mixing of data with view - simply don't, they should be separated for a reason .. > Instead of using: > column.setCellValueFactory(new TreeItemPropertyValueFactory<>("name")); > > The reason we are using OurDataObjectLabel, is because we want to style a > specific type of data determined by AlsoOurDataObject. > suboptimal approach: instead let a custom cell style itself based on content > 3) What known glitches? there are a bunch of bugs (don't have references handy, sry) - search the bug parade for Tree/Table/Cell andTree/TableRow From fastegal at openjdk.org Wed Oct 16 13:07:45 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 16 Oct 2019 13:07:45 GMT Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists Message-ID: This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759 The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix. There are additional/changed tests to verify the fix. All old tests are passing. ---------------- Commits: - 93556393: Fix: VK_ENTER not consumed by TextField when default Button exists Changes: https://git.openjdk.java.net/jfx/pull/15/files Webrev: https://webrevs.openjdk.java.net/jfx/15/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8207759 Stats: 553 lines in 8 files changed: 528 ins; 20 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15 PR: https://git.openjdk.java.net/jfx/pull/15 From kcr at openjdk.org Wed Oct 16 13:09:35 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Oct 2019 13:09:35 GMT Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists In-Reply-To: References: Message-ID: On Wed, 16 Oct 2019 13:07:45 GMT, Jeanette Winzenburg wrote: > This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759 > > The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix. > > There are additional/changed tests to verify the fix. All old tests are passing. > > ---------------- > > Commits: > - 93556393: Fix: VK_ENTER not consumed by TextField when default Button exists > > Changes: https://git.openjdk.java.net/jfx/pull/15/files > Webrev: https://webrevs.openjdk.java.net/jfx/15/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8207759 > Stats: 553 lines in 8 files changed: 528 ins; 20 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/15.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15 @aghaisas can you review this as well? PR: https://git.openjdk.java.net/jfx/pull/15 From johan.vos at gluonhq.com Wed Oct 16 13:12:04 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 16 Oct 2019 15:12:04 +0200 Subject: [11][13] RFR: Request to backport October 2019 CPU changes In-Reply-To: <135916bc-48a7-7c97-3e8c-50b445ff3da1@oracle.com> References: <135916bc-48a7-7c97-3e8c-50b445ff3da1@oracle.com> Message-ID: +1 On Tue, Oct 15, 2019 at 6:43 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released April > 2019 CPU to 11-dev and 13-dev. > > https://cr.openjdk.java.net/~kcr/cpu-1910-sync/11-dev/webrev/ > https://cr.openjdk.java.net/~kcr/cpu-1910-sync/13-dev/webrev/ > > Each is a straight backport (patch applies cleanly) of the one FX fix > that went into the October CPU. > > Thanks. > > -- Kevin > > From johan.vos at gluonhq.com Wed Oct 16 13:12:46 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 16 Oct 2019 15:12:46 +0200 Subject: [14] RFR: Request to sync October 2019 CPU changes into jfx In-Reply-To: <6e3170bf-d0de-f1b5-fcda-a210a5bcb712@oracle.com> References: <6e3170bf-d0de-f1b5-fcda-a210a5bcb712@oracle.com> Message-ID: +1 On Tue, Oct 15, 2019 at 6:42 PM Kevin Rushforth wrote: > Johan and Phil, > > I request approval to sync changes from to the just-released October > 2019 CPU release into 'jfx'. Here is the aggregate set of changes for > the fixes: > > https://github.com/kevinrushforth/jfx/compare/64aaeb8...bada612 > > NOTE: Since this is an integration of already-reviewed fixes into the > jfx repo, I will push it directly rather than via a pull request. > > -- Kevin > > From johan.vos at gluonhq.com Wed Oct 16 14:24:02 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 16 Oct 2019 16:24:02 +0200 Subject: RFR: 8232377: Change JavaFX release version in 11-dev to 11.0.5 Message-ID: Please review the webrev for bumpding the JavaFX release version for 11-dev to 11.0.5 [1], available at [ 2] Thanks, - Johan [1] https://bugs.openjdk.java.net/browse/JDK-8232377 [2] http://cr.openjdk.java.net/~jvos/8232377/webrev.00/ From kevin.rushforth at oracle.com Wed Oct 16 14:34:04 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2019 07:34:04 -0700 Subject: RFR: 8232377: Change JavaFX release version in 11-dev to 11.0.5 In-Reply-To: References: Message-ID: <1e59bd1d-2c7c-0690-7ebc-e7ed591fda76@oracle.com> +1 On 10/16/2019 7:24 AM, Johan Vos wrote: > Please review the webrev for bumpding the JavaFX release version for 11-dev > to 11.0.5 [1], available at [ > 2] > > Thanks, > > - Johan > > [1] https://bugs.openjdk.java.net/browse/JDK-8232377 > [2] http://cr.openjdk.java.net/~jvos/8232377/webrev.00/ From johan.vos at gluonhq.com Wed Oct 16 14:42:30 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 16 Oct 2019 16:42:30 +0200 Subject: RFR: 8232378: change JavaFX release version in 13-dev to 13.0.1 Message-ID: Please review http://cr.openjdk.java.net/~jvos/8232378/webrev.00/ which fixes https://bugs.openjdk.java.net/browse/JDK-8232378 Thanks, - Johan From arajkumar at openjdk.org Wed Oct 16 15:21:55 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Wed, 16 Oct 2019 15:21:55 GMT Subject: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> Message-ID: On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar wrote: > 8232158: [macOS] Fallback to command line tools if xcode is missing > > ---------------- > > Commits: > - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing > > Changes: https://git.openjdk.java.net/jfx/pull/13/files > Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 > Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/13.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 @kevinrushforth Am I missing anything here which prevents the review process? PR: https://git.openjdk.java.net/jfx/pull/13 From kevin.rushforth at oracle.com Wed Oct 16 15:26:47 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2019 08:26:47 -0700 Subject: RFR: 8232378: change JavaFX release version in 13-dev to 13.0.1 In-Reply-To: References: Message-ID: <31f5ad4b-5ab3-406e-155e-52b9c4e507dd@oracle.com> +1 On 10/16/2019 7:42 AM, Johan Vos wrote: > Please review http://cr.openjdk.java.net/~jvos/8232378/webrev.00/ which > fixes https://bugs.openjdk.java.net/browse/JDK-8232378 > > Thanks, > > - Johan From kcr at openjdk.org Wed Oct 16 15:29:05 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Oct 2019 15:29:05 GMT Subject: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> Message-ID: <_-WBqk_gDuD7wVko2GF-shlL0LOAinb75E3pBl-R3Ds=.6dc11b87-6d1a-435e-9b37-d51183ddfbac@github.com> On Wed, 16 Oct 2019 15:21:55 GMT, Arunprasad Rajkumar wrote: > On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar wrote: > >> 8232158: [macOS] Fallback to command line tools if xcode is missing >> >> ---------------- >> >> Commits: >> - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing >> >> Changes: https://git.openjdk.java.net/jfx/pull/13/files >> Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 >> Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod >> Patch: https://git.openjdk.java.net/jfx/pull/13.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 > > @kevinrushforth Am I missing anything here which prevents the review process? No, I have just been swamped the last few days. It's on my list to review. Sorry for the delay. PR: https://git.openjdk.java.net/jfx/pull/13 From arajkumar at openjdk.org Wed Oct 16 15:54:54 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Wed, 16 Oct 2019 15:54:54 GMT Subject: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: <_-WBqk_gDuD7wVko2GF-shlL0LOAinb75E3pBl-R3Ds=.6dc11b87-6d1a-435e-9b37-d51183ddfbac@github.com> References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> <_-WBqk_gDuD7wVko2GF-shlL0LOAinb75E3pBl-R3Ds=.6dc11b87-6d1a-435e-9b37-d51183ddfbac@github.com> Message-ID: On Wed, 16 Oct 2019 15:29:05 GMT, Kevin Rushforth wrote: > On Wed, 16 Oct 2019 15:21:55 GMT, Arunprasad Rajkumar wrote: > >> On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar wrote: >> >>> 8232158: [macOS] Fallback to command line tools if xcode is missing >>> >>> ---------------- >>> >>> Commits: >>> - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/13/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 >>> Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/13.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 >> >> @kevinrushforth Am I missing anything here which prevents the review process? > > No, I have just been swamped the last few days. It's on my list to review. Sorry for the delay. Thanks @kevin. PR: https://git.openjdk.java.net/jfx/pull/13 From arajkumar at openjdk.org Wed Oct 16 17:57:58 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Wed, 16 Oct 2019 17:57:58 GMT Subject: [Rev 01] RFR: WIP: 8211308: Support HTTP/2 in WebView In-Reply-To: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 1832c2db: Incorporate fixes provided by @kcr Changes: - all: https://git.openjdk.java.net/jfx/pull/14/files - new: https://git.openjdk.java.net/jfx/pull/14/files/1798a661..1832c2db Webrevs: - full: https://webrevs.openjdk.java.net/jfx/14/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/14/webrev.00-01 Stats: 13 lines in 2 files changed: 5 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 PR: https://git.openjdk.java.net/jfx/pull/14 From arajkumar at openjdk.org Wed Oct 16 17:58:32 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Wed, 16 Oct 2019 17:58:32 GMT Subject: RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: <8NVPSfkk9SAl3JCFggl9QGzSP1QvJfajNR9qJUjfhuk=.cc58a9f9-1141-4618-a16a-06f9ca757cf5@github.com> References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> <8NVPSfkk9SAl3JCFggl9QGzSP1QvJfajNR9qJUjfhuk=.cc58a9f9-1141-4618-a16a-06f9ca757cf5@github.com> Message-ID: On Fri, 11 Oct 2019 11:21:08 GMT, Robin Westberg wrote: > On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar wrote: > >> On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos wrote: >> >>> On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar wrote: >>> >>>> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: >>>> >>>>> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. >>>>> >>>>> Reference: >>>>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html >>>>> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html >>>>> >>>>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, >>>>> >>>>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient >>>>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 >>>>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers >>>>> >>>>> #### Task List >>>>> - [x] simple GET requests >>>>> - [x] Runtime setting to fallback to legacy client >>>>> - [ ] Runtime settings to use *only* HTTP/1.1 >>>>> - [x] sync requests >>>>> - [x] Error Handling & Propagation >>>>> - [x] POST with form data >>>>> - [x] AccessController association for HttpClient.sendAsync / send >>>>> - [x] Redirection >>>>> - [ ] Check for possibilities to write unit tests >>>>> - [ ] Sync request handling from WebCore java platform layer >>>>> - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool >>>>> - [x] gzip, deflate encoding support >>>>> >>>>> #### HTTP/2 Test pages >>>>> - http://www.http2demo.io >>>>> - https://http2.akamai.com/demo >>>>> - https://http2.golang.org >>>>> - https://google.com >>>>> >>>>> #### Redirection Test >>>>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7 >>>>> >>>>> More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 1798a661: 8211308: Support HTTP/2 in WebView >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/14/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 >>>>> Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/14.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 >>>> >>>> Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. >>> >>> Good work. Should the title be prefixed with WIP until it's ready for review, so that Skara will send the RFR when it is ready for review? >> >> I was wondering why @skara had sent the RFR when the PR is still in draft stage. Actually @skara should consider the "Draft" attribute associated with the PR. > > Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to track this. @jfx team, now it is ready for a fresh review :) PR: https://git.openjdk.java.net/jfx/pull/14 From kcr at openjdk.org Wed Oct 16 18:10:00 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Oct 2019 18:10:00 GMT Subject: RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> <8NVPSfkk9SAl3JCFggl9QGzSP1QvJfajNR9qJUjfhuk=.cc58a9f9-1141-4618-a16a-06f9ca757cf5@github.com> Message-ID: On Wed, 16 Oct 2019 17:58:32 GMT, Arunprasad Rajkumar wrote: > On Fri, 11 Oct 2019 11:21:08 GMT, Robin Westberg wrote: > >> On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar wrote: >> >>> On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos wrote: >>> >>>> On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar wrote: >>>> >>>>> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: >>>>> >>>>>> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. >>>>>> >>>>>> Reference: >>>>>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html >>>>>> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html >>>>>> >>>>>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, >>>>>> >>>>>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient >>>>>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 >>>>>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers >>>>>> >>>>>> #### Task List >>>>>> - [x] simple GET requests >>>>>> - [x] Runtime setting to fallback to legacy client >>>>>> - [ ] Runtime settings to use *only* HTTP/1.1 >>>>>> - [x] sync requests >>>>>> - [x] Error Handling & Propagation >>>>>> - [x] POST with form data >>>>>> - [x] AccessController association for HttpClient.sendAsync / send >>>>>> - [x] Redirection >>>>>> - [ ] Check for possibilities to write unit tests >>>>>> - [ ] Sync request handling from WebCore java platform layer >>>>>> - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool >>>>>> - [x] gzip, deflate encoding support >>>>>> >>>>>> #### HTTP/2 Test pages >>>>>> - http://www.http2demo.io >>>>>> - https://http2.akamai.com/demo >>>>>> - https://http2.golang.org >>>>>> - https://google.com >>>>>> >>>>>> #### Redirection Test >>>>>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7 >>>>>> >>>>>> More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - 1798a661: 8211308: Support HTTP/2 in WebView >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/14/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 >>>>>> Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/14.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 >>>>> >>>>> Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. >>>> >>>> Good work. Should the title be prefixed with WIP until it's ready for review, so that Skara will send the RFR when it is ready for review? >>> >>> I was wondering why @skara had sent the RFR when the PR is still in draft stage. Actually @skara should consider the "Draft" attribute associated with the PR. >> >> Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to track this. > > @jfx team, now it is ready for a fresh review :) @guruhb please also review this. PR: https://git.openjdk.java.net/jfx/pull/14 From kcr at openjdk.org Wed Oct 16 21:43:15 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Oct 2019 21:43:15 GMT Subject: RFR: 8211308: Support HTTP/2 in WebView In-Reply-To: References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com> <65bbKoZ_BZBJfqlOBT6Eb15Tl64ugDNqQxJLWlW4YgE=.c139b834-251d-41c3-bfb6-4bc36bb83bef@github.com> <8NVPSfkk9SAl3JCFggl9QGzSP1QvJfajNR9qJUjfhuk=.cc58a9f9-1141-4618-a16a-06f9ca757cf5@github.com> Message-ID: On Wed, 16 Oct 2019 18:10:00 GMT, Kevin Rushforth wrote: > On Wed, 16 Oct 2019 17:58:32 GMT, Arunprasad Rajkumar wrote: > >> On Fri, 11 Oct 2019 11:21:08 GMT, Robin Westberg wrote: >> >>> On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar wrote: >>> >>>> On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos wrote: >>>> >>>>> On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar wrote: >>>>> >>>>>> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar wrote: >>>>>> >>>>>>> The goal of this enhancement is to use new [HttpClient APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html) available from JDK 11. >>>>>>> >>>>>>> Reference: >>>>>>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html >>>>>>> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html >>>>>>> >>>>>>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work correctly due to the dependency on following issues, >>>>>>> >>>>>>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to connect to https://google.com using java.net.HttpClient >>>>>>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 responses with Content-Length:0 >>>>>>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) java.net.http HTTP client should allow specifying Origin and Referer headers >>>>>>> >>>>>>> #### Task List >>>>>>> - [x] simple GET requests >>>>>>> - [x] Runtime setting to fallback to legacy client >>>>>>> - [ ] Runtime settings to use *only* HTTP/1.1 >>>>>>> - [x] sync requests >>>>>>> - [x] Error Handling & Propagation >>>>>>> - [x] POST with form data >>>>>>> - [x] AccessController association for HttpClient.sendAsync / send >>>>>>> - [x] Redirection >>>>>>> - [ ] Check for possibilities to write unit tests >>>>>>> - [ ] Sync request handling from WebCore java platform layer >>>>>>> - [x] Make use of singleton instance of direct ByteBuffer instead of using allocator pool >>>>>>> - [x] gzip, deflate encoding support >>>>>>> >>>>>>> #### HTTP/2 Test pages >>>>>>> - http://www.http2demo.io >>>>>>> - https://http2.akamai.com/demo >>>>>>> - https://http2.golang.org >>>>>>> - https://google.com >>>>>>> >>>>>>> #### Redirection Test >>>>>>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7 >>>>>>> >>>>>>> More details are available at https://github.com/javafxports/openjdk-jfx/pull/247. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - 1798a661: 8211308: Support HTTP/2 in WebView >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/14/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211308 >>>>>>> Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/14.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14 >>>>>> >>>>>> Still few changes need to be done as [suggested by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613) @kevinrushforth. >>>>> >>>>> Good work. Should the title be prefixed with WIP until it's ready for review, so that Skara will send the RFR when it is ready for review? >>>> >>>> I was wondering why @skara had sent the RFR when the PR is still in draft stage. Actually @skara should consider the "Draft" attribute associated with the PR. >>> >>> Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to track this. >> >> @jfx team, now it is ready for a fresh review :) > > @guruhb please also review this. I note that this change needs two reviewers (so should not be integrated until there are two approved reviews). PR: https://git.openjdk.java.net/jfx/pull/14 From sebastian.stenzel at gmail.com Wed Oct 16 21:52:59 2019 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 16 Oct 2019 23:52:59 +0200 Subject: Change Priority of JDK-8231513 Message-ID: <10428363-9E95-4161-B1FB-73695A291A26@gmail.com> I would like to ask whether it doesn't make sense to give this issue a little more attention than P4: https://bugs.openjdk.java.net/browse/JDK-8231513 Essentially, as Kevin Rushforth confirmed in the Ticket, any JavaFX application will trigger a warning on the latest stable macOS release that it is requesting permissions to an API to receive key events. I want to stress that denying this permission will not impair the functionality of any JavaFX controls in any way. Nevertheless this warning lets any JavaFX application appear as a malware. This is especially worrying for productivity apps used in enterprise environments. The only thing downstream developers can do atm is fingerpointing at JavaFX, which harms its spread as a UI frameworks for cross platform dev. I suggest to solve this earlier than with openjfx-14, since it will affect any JavaFX app for any macOS Catalina user. See related discussions: - https://forums.developer.apple.com/thread/123797 - https://stackoverflow.com/questions/58094615/javafx-tornadofx-cause-keystroke-receiving-prompt-on-macos-10-15-catalina From mvfranz at gmail.com Thu Oct 17 03:47:10 2019 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 16 Oct 2019 23:47:10 -0400 Subject: Building OpenJFX on clean install of CentOS 7 Message-ID: Hi, I did a clean install of CentOS 7, updated, added the necessary tools and then cloned the repo and ran the default build. I get the following errors: /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:598:1: error: unused parameter ?event? [-Werror=unused-parameter] glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, GdkCursor *cursor) { ^ /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:628:1: error: unused parameter ?event? [-Werror=unused-parameter] glass_gdk_master_pointer_ungrab(GdkEvent *event) { ^ cc1plus: all warnings being treated as errors > Task :graphics:ccLinuxGlassGlassgtk2 FAILED Is this expected? I have not found any documentation specifing the minimum version of gcc/g++ and wonder if I need to upgrade? I am using g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39). Also, other native code in the build are treating the unused-parameter as a warning. Why is this module different? /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-font/pango.c:429:26: warning: unused parameter ?that? [-Wunused-parameter] (JNIEnv *env, jclass that, jlong arg0) Here are the detailed steps I followed: 0. sudo yum update 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant gcc-c++ libstdc++-static 2. sudo alternatives --config java - specify Java 11 3. git clone https://github.com/openjdk/jfx.git 4. cd jfx 5. bash ./gradelw Any suggestions is appreciated. Michael From amnojeeuw at gmail.com Thu Oct 17 10:08:57 2019 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Thu, 17 Oct 2019 06:08:57 -0400 Subject: The thing about JAR files Message-ID: <88615797-7f37-e68b-84e4-649785688357@gmail.com> Has anyone notices that the JAR files produced, eclipse in my case, in javafx 12+ applications do not run with an error that reads java -jar app.jar Error Javafx runtime components are missing, and are required to run this application. It seems that it is quit common, since there are so many entries regarding this problem on the net. Well, any help would be nice. -- This email has been checked for viruses by AVG. https://www.avg.com From sproket at videotron.ca Thu Oct 17 10:43:44 2019 From: sproket at videotron.ca (Dan Howard) Date: Thu, 17 Oct 2019 06:43:44 -0400 Subject: The thing about JAR files In-Reply-To: References: Message-ID: <6b8ac4e0-026a-a334-a36b-2ab30b1c60fb@videotron.ca> Check here https://stackoverflow.com/questions/56771832/java-12-and-javafx-12-create-runnable-jar-and-custom-jre On 10/17/2019 6:08 AM, AmnoJeeuw wrote: > Has anyone notices that the JAR files produced, eclipse in my case, in > javafx 12+ applications do not run with an error that reads > java -jar app.jar > > Error Javafx runtime components are missing, and are required to run > this application. > > It seems that it is quit common, since there are so many entries > regarding this problem on the net. > > Well, any help would be nice. > > From sproket at videotron.ca Thu Oct 17 10:45:23 2019 From: sproket at videotron.ca (Dan Howard) Date: Thu, 17 Oct 2019 06:45:23 -0400 Subject: Change Priority of JDK-8231513 In-Reply-To: References: Message-ID: <99086d6e-6e4a-5d04-2a9d-53386e1c9196@videotron.ca> Yes. Please! I was looking at this a while ago but I'm not familiar enough with the source to see where the problem lies. On 10/16/2019 5:52 PM, Sebastian Stenzel wrote: > I would like to ask whether it doesn't make sense to give this issue a little more attention than P4: > > https://bugs.openjdk.java.net/browse/JDK-8231513 > > Essentially, as Kevin Rushforth confirmed in the Ticket, any JavaFX application will trigger a warning on the latest stable macOS release that it is requesting permissions to an API to receive key events. > > I want to stress that denying this permission will not impair the functionality of any JavaFX controls in any way. > > Nevertheless this warning lets any JavaFX application appear as a malware. This is especially worrying for productivity apps used in enterprise environments. The only thing downstream developers can do atm is fingerpointing at JavaFX, which harms its spread as a UI frameworks for cross platform dev. > > I suggest to solve this earlier than with openjfx-14, since it will affect any JavaFX app for any macOS Catalina user. > > See related discussions: > - https://forums.developer.apple.com/thread/123797 > - https://stackoverflow.com/questions/58094615/javafx-tornadofx-cause-keystroke-receiving-prompt-on-macos-10-15-catalina > > From swpalmer at gmail.com Thu Oct 17 11:16:59 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Oct 2019 07:16:59 -0400 Subject: The thing about JAR files In-Reply-To: <88615797-7f37-e68b-84e4-649785688357@gmail.com> References: <88615797-7f37-e68b-84e4-649785688357@gmail.com> Message-ID: <4D9A70C5-040A-42D2-A58E-D4686D47DEBE@gmail.com> What?s in the jar manifest? How did you create the Java 12 runtime? Scott > On Oct 17, 2019, at 6:09 AM, AmnoJeeuw wrote: > > ?Has anyone notices that the JAR files produced, eclipse in my case, in javafx 12+ applications do not run with an error that reads > java -jar app.jar > > Error Javafx runtime components are missing, and are required to run this application. > > It seems that it is quit common, since there are so many entries regarding this problem on the net. > > Well, any help would be nice. > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > From kevin.rushforth at oracle.com Thu Oct 17 11:44:14 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 04:44:14 -0700 Subject: Change Priority of JDK-8231513 In-Reply-To: <99086d6e-6e4a-5d04-2a9d-53386e1c9196@videotron.ca> References: <99086d6e-6e4a-5d04-2a9d-53386e1c9196@videotron.ca> Message-ID: I just raised the priority to P3. It hits every JavaFX application the first time you move the mouse into the window. It's already targeted to openjfx14, but if anyone has time to take a look at this, a contribution would be welcome. -- Kevin On 10/17/2019 3:45 AM, Dan Howard wrote: > Yes. Please! I was looking at this a while ago but I'm not familiar > enough with the source to see where the problem lies. > > On 10/16/2019 5:52 PM, Sebastian Stenzel wrote: >> I would like to ask whether it doesn't make sense to give this issue >> a little more attention than P4: >> >> https://bugs.openjdk.java.net/browse/JDK-8231513 >> >> Essentially, as Kevin Rushforth confirmed in the Ticket, any JavaFX >> application will trigger a warning on the latest stable macOS release >> that it is requesting permissions to an API to receive key events. >> >> I want to stress that denying this permission will not impair the >> functionality of any JavaFX controls in any way. >> >> Nevertheless this warning lets any JavaFX application appear as a >> malware. This is especially worrying for productivity apps used in >> enterprise environments. The only thing downstream developers can do >> atm is fingerpointing at JavaFX, which harms its spread as a UI >> frameworks for cross platform dev. >> >> I suggest to solve this earlier than with openjfx-14, since it will >> affect any JavaFX app for any macOS Catalina user. >> >> See related discussions: >> - https://forums.developer.apple.com/thread/123797 >> - >> https://stackoverflow.com/questions/58094615/javafx-tornadofx-cause-keystroke-receiving-prompt-on-macos-10-15-catalina >> >> From fastegal at swingempire.de Thu Oct 17 11:52:49 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 17 Oct 2019 13:52:49 +0200 Subject: Refire event while it is delivered is evil - always?! Message-ID: <20191017135249.Horde.bOu2guvMYKcu01bJoH3xPQ7@webmail.df.eu> While fixing https://bugs.openjdk.java.net/browse/JDK-8207759 it turned out that the underlying reason for the bug was a broken event dispatch sequence introduced by behavior.forwardToParent. Which is a call to parent.fireEvent with the event that was received. This builds a nested chain and delivers the event to all handlers in that new chain - down and up again - _before_ the current chain is completed. Consequently, the consuming singleton handler for the same event is notified _after_ the scene-level handlers (in particular the accelerators) have seen and handled it. Looks like it happens for any control (not only for a TextField as in the referenced issue, nor only for controls with a FakeFocusTextField which refire while processing keyEvents), as the example below demonstrates. My current understanding of event dispatch is, that a chain has a life-cycle consisting of separate (?) states: - building the chain from eventTargets - delivering the event along the dispatchers in the chain There's a contract for dispatch sequence (like capturing/bubbling phase, dispatch from specialized to super event types and other rules). That can be guaranteed as long as chain building and event delivering are separate phases, it seems to break down if they are mixed (there are other issues with a similar/same underlying reason, f.i. in all controls with a FakeFocusTextField). Now the questions: - is there any specification about not mixing the life-cycle states? if so, where? - or is there a way to safely re-fire an event at the moment of receiving it? - or maybe I got it all wrong, if so please guide me :) -- Cheers, Jeanette The example: public class NestedEventDispatchChain extends Application { private KeyCode key = DIGIT1; private Parent createContent() { Button button = new Button("the evil button!"); // re-firing handler button.addEventHandler(KEY_PRESSED, e -> { if (key == e.getCode()) { System.out.println("before refire " + e); button.getParent().fireEvent(e); System.out.println("after refire " + e); } }); // consuming singleton handler button.setOnKeyPressed(e -> { if (key == e.getCode()) { e.consume(); System.out.println("consumed in singleton " + e.getCode()); } }); BorderPane content = new BorderPane(button); return content; } @Override public void start(Stage stage) throws Exception { Scene scene = new Scene(createContent()); // accelerator that shouldn't be triggered because singleton handler consumed scene.getAccelerators().put(KeyCombination.keyCombination(key.getName()), () -> { System.out.println("accelerator triggered for " + key); }); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } From sebastian.stenzel at gmail.com Thu Oct 17 11:53:41 2019 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 17 Oct 2019 13:53:41 +0200 Subject: Change Priority of JDK-8231513 In-Reply-To: References: <99086d6e-6e4a-5d04-2a9d-53386e1c9196@videotron.ca> Message-ID: <08EFFAE9-1B29-4156-925A-5E4D95D2F9E3@gmail.com> I found another software with this problem, claiming that switching from "Event Tapping" to "Global Event Monitoring" helped fixing the issue: https://www.irradiatedsoftware.com/help/cinch/ Quote: "A new "Input Monitoring" permission was added in macOS 10.15 Catalina which detects apps using an Event Tap (even if just for mouse events) and pops up this warning." In JavaFX, we're using Event Tapping, too. Maybe this is the root cause: https://github.com/openjdk/jfx/blob/jdk-11+14/modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m#L189-L193 > Am 17.10.2019 um 13:44:14 schrieb Kevin Rushforth : > > I just raised the priority to P3. It hits every JavaFX application the first time you move the mouse into the window. It's already targeted to openjfx14, but if anyone has time to take a look at this, a contribution would be welcome. > > -- Kevin > > > On 10/17/2019 3:45 AM, Dan Howard wrote: >> Yes. Please! I was looking at this a while ago but I'm not familiar enough with the source to see where the problem lies. >> >> On 10/16/2019 5:52 PM, Sebastian Stenzel wrote: >>> I would like to ask whether it doesn't make sense to give this issue a little more attention than P4: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8231513 >>> >>> Essentially, as Kevin Rushforth confirmed in the Ticket, any JavaFX application will trigger a warning on the latest stable macOS release that it is requesting permissions to an API to receive key events. >>> >>> I want to stress that denying this permission will not impair the functionality of any JavaFX controls in any way. >>> >>> Nevertheless this warning lets any JavaFX application appear as a malware. This is especially worrying for productivity apps used in enterprise environments. The only thing downstream developers can do atm is fingerpointing at JavaFX, which harms its spread as a UI frameworks for cross platform dev. >>> >>> I suggest to solve this earlier than with openjfx-14, since it will affect any JavaFX app for any macOS Catalina user. >>> >>> See related discussions: >>> - https://forums.developer.apple.com/thread/123797 >>> - https://stackoverflow.com/questions/58094615/javafx-tornadofx-cause-keystroke-receiving-prompt-on-macos-10-15-catalina >>> >>> > From r.lichtenberger at gmail.com Thu Oct 17 12:48:39 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 17 Oct 2019 14:48:39 +0200 Subject: Cannot protect copying of synchronizedObservableMap Message-ID: I've just stumbled upon a devious detail in javafx.collections.FXCollections.SynchronizedObservableMap. Although it almost looks like a twin of Collections.synchronizedMap it does not allow to protect copying or iterating over it the way Collections.synchronizedMap does. Example program: import java.util.Collections; import java.util.HashMap; import java.util.Map; import java.util.Random; import javafx.collections.FXCollections; public class SyncMap { public static void main(String[] args) { Random rnd = new Random(); Map m = Collections.synchronizedMap(new HashMap()); // Map m = FXCollections.synchronizedObservableMap(FXCollections.observableHashMap()); Thread t = new Thread(() -> { while (true) { m.put(rnd.nextInt(1000), rnd.nextInt()); } }); t.setDaemon(true); t.start(); Map c = null; for (int i = 0; i < 100000; i ++) { synchronized(m) { c = new HashMap<>(m); } } System.out.println(c); } } Using Collections.synchronizedMap this works, because we synchronize on m. If using FXCollections.synchronizedObservableMap this throws ConcurrentModificationException. The reason is that SynchronizedObservableMap(ObservableMap map) { this(map, new Object()); } SynchronizedObservableMap uses a new Object as mutex instead of itself as seen in SynchronizedMap(Map m) { this.m = Objects.requireNonNull(m); mutex = this; } Questions: * Is this considered a bug / a possible enhancement? Should there at least be a warning against this possible pitfall? * Do we need synchronizedObservable-Stuff in FXCollections at all? This seems one of the cases where JavaFX contains classes/functionality that are part of the JDK itself. I can file an issue, if there is consensus about the issue. From kevin.rushforth at oracle.com Thu Oct 17 13:00:55 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 06:00:55 -0700 Subject: Building OpenJFX on clean install of CentOS 7 In-Reply-To: References: Message-ID: The current toolchain for building JavaFX is gcc 8.2. As long as you don't build WebKit, it will still build with gcc 5.4. I just tried it on an Oracle Linux 7 machine with gcc 4.9.1 (which is what we used to use a couple years ago), and the build fails for me with the same error. Looks like you will need a newer gcc. -- Kevin On 10/16/2019 8:47 PM, Michael Franz wrote: > Hi, > > I did a clean install of CentOS 7, updated, added the necessary tools and > then cloned the repo and ran the default build. I get the following errors: > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:598:1: > error: unused parameter ?event? [-Werror=unused-parameter] > glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, > GdkCursor *cursor) { > ^ > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:628:1: > error: unused parameter ?event? [-Werror=unused-parameter] > glass_gdk_master_pointer_ungrab(GdkEvent *event) { > ^ > cc1plus: all warnings being treated as errors > >> Task :graphics:ccLinuxGlassGlassgtk2 FAILED > Is this expected? I have not found any documentation specifing the minimum > version of gcc/g++ and wonder if I need to upgrade? I am using g++ (GCC) > 4.8.5 20150623 (Red Hat 4.8.5-39). Also, other native code in the build > are treating the unused-parameter as a warning. Why is this module > different? > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-font/pango.c:429:26: > warning: unused parameter ?that? [-Wunused-parameter] > (JNIEnv *env, jclass that, jlong arg0) > > > Here are the detailed steps I followed: > 0. sudo yum update > 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel > pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant gcc-c++ > libstdc++-static > 2. sudo alternatives --config java > - specify Java 11 > 3. git clone https://github.com/openjdk/jfx.git > 4. cd jfx > 5. bash ./gradelw > > Any suggestions is appreciated. > > Michael From kevin.rushforth at oracle.com Thu Oct 17 13:26:36 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 06:26:36 -0700 Subject: Cannot protect copying of synchronizedObservableMap In-Reply-To: References: Message-ID: <4464ea4e-8dde-a74a-60bc-e664ce8d4311@oracle.com> Hi Robert, 1. Is the behavior of SynchronizedObservableMap a bug, where it uses a new mutex and doesn't synchronize on itself a bug? I'd say yes, this is a bug. Clearly the class is meant to mimic the corresponding Collections class with observability added. The fact that it then doesn't synchronize in the same way, and that this difference makes the class not thread-safe seems to defeat the entire purpose of having a synchronized flavor of ObservableMap. So go ahead and file a bug. 2. Do we need SynchronizedObservableMap at all? If we want a map that is both synchronized and observable, then yes. In any case, I don't see any value in trying to eliminate it from the API (e.g., through deprecation --> deprecation for removal --> removal). -- Kevin On 10/17/2019 5:48 AM, Robert Lichtenberger wrote: > I've just stumbled upon a devious detail in > javafx.collections.FXCollections.SynchronizedObservableMap. Although > it almost looks like a twin of Collections.synchronizedMap it does not > allow to protect copying or iterating over it the way > Collections.synchronizedMap does. > > Example program: > import java.util.Collections; > import java.util.HashMap; > import java.util.Map; > import java.util.Random; > import javafx.collections.FXCollections; > > public class SyncMap { > public static void main(String[] args) { > Random rnd = new Random(); > Map m = Collections.synchronizedMap(new > HashMap()); > // Map m = > FXCollections.synchronizedObservableMap(FXCollections.observableHashMap()); > Thread t = new Thread(() -> { > while (true) { > m.put(rnd.nextInt(1000), rnd.nextInt()); > } > }); > t.setDaemon(true); > t.start(); > Map c = null; > for (int i = 0; i < 100000; i ++) { > synchronized(m) { > c = new HashMap<>(m); > } > } > System.out.println(c); > } > } > > Using Collections.synchronizedMap this works, because we synchronize on m. > If using FXCollections.synchronizedObservableMap this throws > ConcurrentModificationException. The reason is that > SynchronizedObservableMap(ObservableMap map) { > this(map, new Object()); > } > SynchronizedObservableMap uses a new Object as mutex instead of itself as > seen in > SynchronizedMap(Map m) { > this.m = Objects.requireNonNull(m); > mutex = this; > } > > Questions: > * Is this considered a bug / a possible enhancement? Should there at least > be a warning against this possible pitfall? > * Do we need synchronizedObservable-Stuff in FXCollections at all? This > seems one of the cases where JavaFX contains classes/functionality that are > part of the JDK itself. > > I can file an issue, if there is consensus about the issue. From r.lichtenberger at gmail.com Thu Oct 17 14:18:22 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 17 Oct 2019 16:18:22 +0200 Subject: Cannot protect copying of synchronizedObservableMap In-Reply-To: <4464ea4e-8dde-a74a-60bc-e664ce8d4311@oracle.com> References: <4464ea4e-8dde-a74a-60bc-e664ce8d4311@oracle.com> Message-ID: > > If we want a map that is both synchronized and observable, then yes. In > any case, I don't see any value in trying to eliminate it from the API > (e.g., through deprecation --> deprecation for removal --> removal). One could do this: protected Map criteriaLock = Collections.synchronizedMap(new HashMap()); protected ObservableMap criteria = FXCollections.observableMap(criteriaLock); and then: Map params; synchronized (criteriaLock) { // #91157: lock synchronized map to prevent ConcurrentModificationException params = new HashMap<>(getCriteria()); } i.e. use a synchronized "inner" map and make it observable. But I admit this is a bit clumsy since you can no longer synchronize on your "real" map and have to keep the inner map around for synchronizing. I filed https://bugs.openjdk.java.net/browse/JDK-8232524 Am Do., 17. Okt. 2019 um 15:51 Uhr schrieb Kevin Rushforth < kevin.rushforth at oracle.com>: > Hi Robert, > > 1. Is the behavior of SynchronizedObservableMap a bug, where it uses a > new mutex and doesn't synchronize on itself a bug? > > I'd say yes, this is a bug. Clearly the class is meant to mimic the > corresponding Collections class with observability added. The fact that > it then doesn't synchronize in the same way, and that this difference > makes the class not thread-safe seems to defeat the entire purpose of > having a synchronized flavor of ObservableMap. So go ahead and file a bug. > > 2. Do we need SynchronizedObservableMap at all? > > If we want a map that is both synchronized and observable, then yes. In > any case, I don't see any value in trying to eliminate it from the API > (e.g., through deprecation --> deprecation for removal --> removal). > > -- Kevin > > > On 10/17/2019 5:48 AM, Robert Lichtenberger wrote: > > I've just stumbled upon a devious detail in > > javafx.collections.FXCollections.SynchronizedObservableMap. > Although > > it almost looks like a twin of Collections.synchronizedMap it does not > > allow to protect copying or iterating over it the way > > Collections.synchronizedMap does. > > > > Example program: > > import java.util.Collections; > > import java.util.HashMap; > > import java.util.Map; > > import java.util.Random; > > import javafx.collections.FXCollections; > > > > public class SyncMap { > > public static void main(String[] args) { > > Random rnd = new Random(); > > Map m = Collections.synchronizedMap(new > > HashMap()); > > // Map m = > > > FXCollections.synchronizedObservableMap(FXCollections.observableHashMap()); > > Thread t = new Thread(() -> { > > while (true) { > > m.put(rnd.nextInt(1000), rnd.nextInt()); > > } > > }); > > t.setDaemon(true); > > t.start(); > > Map c = null; > > for (int i = 0; i < 100000; i ++) { > > synchronized(m) { > > c = new HashMap<>(m); > > } > > } > > System.out.println(c); > > } > > } > > > > Using Collections.synchronizedMap this works, because we synchronize on > m. > > If using FXCollections.synchronizedObservableMap this throws > > ConcurrentModificationException. The reason is that > > SynchronizedObservableMap(ObservableMap map) { > > this(map, new Object()); > > } > > SynchronizedObservableMap uses a new Object as mutex instead of itself as > > seen in > > SynchronizedMap(Map m) { > > this.m = Objects.requireNonNull(m); > > mutex = this; > > } > > > > Questions: > > * Is this considered a bug / a possible enhancement? Should there at > least > > be a warning against this possible pitfall? > > * Do we need synchronizedObservable-Stuff in FXCollections at all? This > > seems one of the cases where JavaFX contains classes/functionality that > are > > part of the JDK itself. > > > > I can file an issue, if there is consensus about the issue. > > From johan.vos at gluonhq.com Thu Oct 17 14:23:06 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 17 Oct 2019 16:23:06 +0200 Subject: Building OpenJFX on clean install of CentOS 7 In-Reply-To: References: Message-ID: I heard similar reports from developers trying to build with gcc 4.x. We might benefit from an assert early in the build. On Thu, Oct 17, 2019 at 3:16 PM Kevin Rushforth wrote: > The current toolchain for building JavaFX is gcc 8.2. As long as you > don't build WebKit, it will still build with gcc 5.4. > > I just tried it on an Oracle Linux 7 machine with gcc 4.9.1 (which is > what we used to use a couple years ago), and the build fails for me with > the same error. Looks like you will need a newer gcc. > > -- Kevin > > > On 10/16/2019 8:47 PM, Michael Franz wrote: > > Hi, > > > > I did a clean install of CentOS 7, updated, added the necessary tools and > > then cloned the repo and ran the default build. I get the following > errors: > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:598:1: > > error: unused parameter ?event? [-Werror=unused-parameter] > > glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, > > GdkCursor *cursor) { > > ^ > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:628:1: > > error: unused parameter ?event? [-Werror=unused-parameter] > > glass_gdk_master_pointer_ungrab(GdkEvent *event) { > > ^ > > cc1plus: all warnings being treated as errors > > > >> Task :graphics:ccLinuxGlassGlassgtk2 FAILED > > Is this expected? I have not found any documentation specifing the > minimum > > version of gcc/g++ and wonder if I need to upgrade? I am using g++ (GCC) > > 4.8.5 20150623 (Red Hat 4.8.5-39). Also, other native code in the build > > are treating the unused-parameter as a warning. Why is this module > > different? > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-font/pango.c:429:26: > > warning: unused parameter ?that? [-Wunused-parameter] > > (JNIEnv *env, jclass that, jlong arg0) > > > > > > Here are the detailed steps I followed: > > 0. sudo yum update > > 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel > > pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant > gcc-c++ > > libstdc++-static > > 2. sudo alternatives --config java > > - specify Java 11 > > 3. git clone https://github.com/openjdk/jfx.git > > 4. cd jfx > > 5. bash ./gradelw > > > > Any suggestions is appreciated. > > > > Michael > > From kcr at openjdk.org Thu Oct 17 15:28:31 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 17 Oct 2019 15:28:31 GMT Subject: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() In-Reply-To: <0YJvd4XIwHfRAuOVa3jtcjFVOhDVvaq94-fi6HKRKqY=.42af4fb5-cc1b-42eb-9fad-b9409971a9ca@github.com> References: <0YJvd4XIwHfRAuOVa3jtcjFVOhDVvaq94-fi6HKRKqY=.42af4fb5-cc1b-42eb-9fad-b9409971a9ca@github.com> Message-ID: On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka wrote: > On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka wrote: > >> Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call. >> This patch fixes the problem by submitting the UI work (including the call to the SecondaryLoop.exit() method) before entering the secondary loop. >> >> [1] https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4 >> >> ---------------- >> >> Commits: >> - 9483ccde: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() >> >> Changes: https://git.openjdk.java.net/jfx/pull/16/files >> Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 >> Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/16.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16 > > @kevinrushforth I believe you should be able to move forward with the review of this PR now as I've filed a bug report for the problem and signed the OCA as required. (As I did not know I needed to have my github account associated with the OCA, I did not include it in my details. I've asked Dalibor Topic from the Java SE PM team to help me have that fixed or get in touch with you to confirm my signing of the OCA.) @mruzicka once Dalibor connects your OCA with your GitHub account, this review will be able to proceed. PR: https://git.openjdk.java.net/jfx/pull/16 From github.com+562920+mruzicka at openjdk.org Thu Oct 17 15:28:30 2019 From: github.com+562920+mruzicka at openjdk.org (mruzicka) Date: Thu, 17 Oct 2019 15:28:30 GMT Subject: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() In-Reply-To: References: Message-ID: <0YJvd4XIwHfRAuOVa3jtcjFVOhDVvaq94-fi6HKRKqY=.42af4fb5-cc1b-42eb-9fad-b9409971a9ca@github.com> On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka wrote: > Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call. > This patch fixes the problem by submitting the UI work (including the call to the SecondaryLoop.exit() method) before entering the secondary loop. > > [1] https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4 > > ---------------- > > Commits: > - 9483ccde: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() > > Changes: https://git.openjdk.java.net/jfx/pull/16/files > Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 > Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/16.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16 @kevinrushforth I believe you should be able to move forward with the review of this PR now as I've filed a bug report for the problem and signed the OCA as required. (As I did not know I needed to have my github account associated with the OCA, I did not include it in my details. I've asked Dalibor Topic from the Java SE PM team to help me have that fixed or get in touch with you to confirm my signing of the OCA.) PR: https://git.openjdk.java.net/jfx/pull/16 From github.com+562920+mruzicka at openjdk.org Thu Oct 17 15:28:28 2019 From: github.com+562920+mruzicka at openjdk.org (mruzicka) Date: Thu, 17 Oct 2019 15:28:28 GMT Subject: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() Message-ID: Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call. This patch fixes the problem by submitting the UI work (including the call to the SecondaryLoop.exit() method) before entering the secondary loop. [1] https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4 ---------------- Commits: - 9483ccde: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() Changes: https://git.openjdk.java.net/jfx/pull/16/files Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16 PR: https://git.openjdk.java.net/jfx/pull/16 From kevin.rushforth at oracle.com Thu Oct 17 16:12:28 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 09:12:28 -0700 Subject: Building OpenJFX on clean install of CentOS 7 In-Reply-To: References: Message-ID: <29c19bff-98bc-0aa8-1487-e63ba27704cb@oracle.com> Yeah, this would be helpful. I'm pretty sure we've had requests for checking other dependencies (like missing packages, etc). Failing fast with an explicit error message is almost always better than wasting time tracking down strange build failures. -- Kevin On 10/17/2019 7:23 AM, Johan Vos wrote: > I heard similar reports from developers trying to build with gcc 4.x. > We might benefit from an assert early in the build. > > On Thu, Oct 17, 2019 at 3:16 PM Kevin Rushforth > > wrote: > > The current toolchain for building JavaFX is gcc 8.2. As long as you > don't build WebKit, it will still build with gcc 5.4. > > I just tried it on an Oracle Linux 7 machine with gcc 4.9.1 (which is > what we used to use a couple years ago), and the build fails for > me with > the same error. Looks like you will need a newer gcc. > > -- Kevin > > > On 10/16/2019 8:47 PM, Michael Franz wrote: > > Hi, > > > > I did a clean install of CentOS 7, updated, added the necessary > tools and > > then cloned the repo and ran the default build.? I get the > following errors: > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:598:1: > > error: unused parameter ?event? [-Werror=unused-parameter] > >? ?glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, > > GdkCursor *cursor) { > >? ?^ > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:628:1: > > error: unused parameter ?event? [-Werror=unused-parameter] > >? ?glass_gdk_master_pointer_ungrab(GdkEvent *event) { > >? ?^ > > cc1plus: all warnings being treated as errors > > > >> Task :graphics:ccLinuxGlassGlassgtk2 FAILED > > Is this expected?? I have not found any documentation specifing > the minimum > > version of gcc/g++ and wonder if I need to upgrade? I am using > g++ (GCC) > > 4.8.5 20150623 (Red Hat 4.8.5-39).? Also, other native code in > the build > > are treating the unused-parameter as a warning.? Why is this module > > different? > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-font/pango.c:429:26: > > warning: unused parameter ?that? [-Wunused-parameter] > >? ? ? ?(JNIEnv *env, jclass that, jlong arg0) > > > > > > Here are the detailed steps I followed: > > 0. sudo yum update > > 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel > > pango-devel freetype-devel libXtst-devel java-11-openjdk-devel > ant gcc-c++ > > libstdc++-static > > 2. sudo alternatives --config java > >? ? - specify Java 11 > > 3. git clone https://github.com/openjdk/jfx.git > > 4. cd jfx > > 5. bash ./gradelw > > > > Any suggestions is appreciated. > > > > Michael > From philip.race at oracle.com Thu Oct 17 16:45:19 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 09:45:19 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> Message-ID: <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> Hi, Some more points which I thought about but for whatever reason did not pen .. First one minor thing: tabWidth is an OK name, but it does not conjure up that the value you specify isn't a width in pixels but the number of discrete space characters to use. FWIW CSS calls it tab-size. But CSS then supports pixels and ems .. that complicates matters a lot. https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size Thee rest is mostly to do with "legal or sensible values" You have : ??????? if (spaces < 0) ??????????? spaces = 0; since negative values are not something we want to support! But I think instead of clamping you could "ignore", any out of range value. This is practiced elsewhere in FX where illegal values are ignored rather than throwing an exception, although it might be that clamping is quite common in range cases. The follow on to that is that what is a sensible maximum value. Currently we have int which is more than we need. For that matter so is short. I think we should have a documented and enforced sensible maximum. Perhaps it could be "8" meaning we only support reducing tab width as I don't know if anyone really wants to increase it. CSS doesn't have a limit that I can see but if we are already only supporting it described as number of spaces, we can have this other limitation too. If you think 8 is too small, then maybe 16 ? Also remember we can compatibly relax it later but we can't compatibly tighten it. -phil. On 10/15/19 12:17 PM, Phil Race wrote: > Hi, > > I've looked over this and I don't see any issues - meaning gotchas. > It just provides a way to over-ride the hard-coded 8, > whether using a Text node directly or a TextFlow. > > Two observations of what one might call limitations > 1) This is a rendering time property, which is controlled by the program. > A document containing tabs saved and re-rendered somewhere else > won't be helped. > > 2) This just provides API on the scene graph node types, not any of > the UI controls > which use Text nodes. Something like a CSS property may be the way to > go if > you wanted that. > Text has a nested class StyleableProperties for CSS properties with > which it > plays nice : font, underline, strikethrough, text-alignment > > So creating an fx-tabWidth (or similar name) CSS property could be > propagated > through to there in a similar way. > > -phil. > > > On 9/30/19 9:48 AM, Scott Palmer wrote: >> Okay, current work relocated to a clone of the new official Git repo. >> My initial implementation is here: >> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >> >> >> >> I would submit it as a pull request but that seems premature since >> there hasn?t been any real discussion of challenges I?ve overlooked.? >> All I have are the famous last words, ?It works for me.? >> >> I saw in the archives a concern about tab width vs tab stops. For >> some reason I didn?t get the email.? Anyway, I don?t think arbitrary >> tab stop positions, at different intervals that is, are what was >> asked for.? That certainly would require a significantly different >> implementation. >> >> Would love to keep some momentum going on this before I become busy >> with other things and won?t have time for it. >> >> Scott >> >>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>> >>> My current work is here >>> https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>> >>> >>> >>> While writing a unit test I realized that the StubToolkit isn?t >>> really running the Prism layout code, so I?m not sure how that gets >>> tested.? I made it work with StubTextLayout for now. >>> >>> Regards, >>> >>> Scott >>> >>> >>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer >>> > wrote: >>>> >>>> Thanks Kevin. >>>> >>>> My current implementation appears to be working for TextFlow and >>>> Text, with the TextFlow overriding the tabWidth of the child Text >>>> nodes.? This seems to work out naturally from the way TextFlow >>>> overrides the TextLayout instance used by the Text node. >>>> >>>> If there are tricky corner-cases that I?m missing, I guess figuring >>>> out all the cases it will need to handle is part of this >>>> discussion.? It didn?t seem to be that challenging so far, so >>>> perhaps I am missing something (hopefully not).? I wrote a small >>>> test app to visually see that things were working as I expected.? I >>>> have not yet written the unit tests. >>>> >>>> Cheers, >>>> >>>> Scott >>>> >>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >>>>> > >>>>> wrote: >>>>> >>>>> Hi Scott, >>>>> >>>>> I'm sure Phil will have more comments on this. While the API seems >>>>> simple enough on the surface, I suspect that this will be a >>>>> challenging feature to implement correctly for all of the cases it >>>>> will need to handle. It would need careful review and testing as >>>>> well. My only comment on the API itself is that if we do accept >>>>> this feature, it should probably go on both Text and TextFlow, and >>>>> be one of the attributes of Text that is ignored / overridden when >>>>> a Text node is in a TextFlow. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>> I would like to implement this feature, being able to adjust the >>>>>> tab size in a TextFlow or Text node (JDK-8130738 >>>>>> >>>>> >). It involves >>>>>> new public API, so I want to start a discussion about it here.? >>>>>> (My motivation is that RichTextFX suggests an entirely >>>>>> unacceptable workaround of substituting actual spaces when the >>>>>> tab character is typed and cites the lack of this API.) >>>>>> >>>>>> I?ve already jumped the gun and taken a crack at an >>>>>> implementation.? It is currently incomplete as I was just poking >>>>>> around to see if it was going to be easy enough to not take up >>>>>> too much of my time.? It boils down to: >>>>>> TextFlow and Text get a new property for tab width, an integer >>>>>> representing the number of spaces taken by a tab. (The value is >>>>>> only used to initialize the tab width for the TextLayout when >>>>>> needed.) >>>>>> TextLayout interface gets a new method:? boolean setTabWidth(int >>>>>> spaces) >>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>> >>>>>> I?m not sure that the Text node needs this new property.? I >>>>>> figured it would be rarely used on that class, so I had >>>>>> implemented it via an added property in the private >>>>>> TextAttributes class.? Maybe it isn?t needed at all. >>>>>> >>>>>> What?s the next step? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Scott > From swpalmer at gmail.com Thu Oct 17 17:40:39 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Oct 2019 13:40:39 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> Message-ID: <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> Hi Phil, Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) // Two tab-related properties public void setTabSize(int size); // defaults to 8 public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font If we did the above, I would consider adding this for convenience: public void setTabWidth(int size, TabUnits units); As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. Regards, Scott > On Oct 17, 2019, at 12:45 PM, Phil Race wrote: > > Hi, > > Some more points which I thought about but for whatever reason did not pen .. > > First one minor thing: tabWidth is an OK name, but it does not > conjure up that the value you specify isn't a width in pixels but the > number of discrete space characters to use. FWIW CSS calls it tab-size. > But CSS then supports pixels and ems .. that complicates matters a lot. > > https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size > > Thee rest is mostly to do with "legal or sensible values" > > You have : > if (spaces < 0) > spaces = 0; > > since negative values are not something we want to support! > But I think instead of clamping you could "ignore", any out of range value. > This is practiced elsewhere in FX where illegal values are ignored rather than > throwing an exception, although it might be that clamping is quite common > in range cases. > > The follow on to that is that what is a sensible maximum value. > Currently we have int which is more than we need. For that matter so is short. > I think we should have a documented and enforced sensible maximum. > Perhaps it could be "8" meaning we only support reducing tab width as I > don't know if anyone really wants to increase it. > CSS doesn't have a limit that I can see but if we are already only supporting > it described as number of spaces, we can have this other limitation too. > If you think 8 is too small, then maybe 16 ? > Also remember we can compatibly relax it later but we can't compatibly tighten it. > > > -phil. > > On 10/15/19 12:17 PM, Phil Race wrote: >> Hi, >> >> I've looked over this and I don't see any issues - meaning gotchas. >> It just provides a way to over-ride the hard-coded 8, >> whether using a Text node directly or a TextFlow. >> >> Two observations of what one might call limitations >> 1) This is a rendering time property, which is controlled by the program. >> A document containing tabs saved and re-rendered somewhere else >> won't be helped. >> >> 2) This just provides API on the scene graph node types, not any of the UI controls >> which use Text nodes. Something like a CSS property may be the way to go if >> you wanted that. >> Text has a nested class StyleableProperties for CSS properties with which it >> plays nice : font, underline, strikethrough, text-alignment >> >> So creating an fx-tabWidth (or similar name) CSS property could be propagated >> through to there in a similar way. >> >> -phil. >> >> >> On 9/30/19 9:48 AM, Scott Palmer wrote: >>> Okay, current work relocated to a clone of the new official Git repo. >>> My initial implementation is here: >>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>> >>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>> >>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>> >>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>> >>> Scott >>> >>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>> >>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>> >>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>> >>>> Regards, >>>> >>>> Scott >>>> >>>> >>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>> >>>>> Thanks Kevin. >>>>> >>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>> >>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>> >>>>> Cheers, >>>>> >>>>> Scott >>>>> >>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>> >>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>> >>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>> >>>>>>> What?s the next step? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Scott >> > From kevin.rushforth at oracle.com Thu Oct 17 18:16:01 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 11:16:01 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> Message-ID: <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you suggest. I'm not sure it's needed, though, so that would be another reason not to do it now. It's probably best to have the type of tabSize be double rather than int. We do this for most attributes to leave the door open for fractional values. I don't know why anyone would want a tab that was 5.7 spaces, but if we ever were to add a tabUnits property, I could easily see wanting fractional values for some units. -- Kevin On 10/17/2019 10:40 AM, Scott Palmer wrote: > Hi Phil, > > Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. > > David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) > Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) > > // Two tab-related properties > public void setTabSize(int size); // defaults to 8 > public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font > > If we did the above, I would consider adding this for convenience: > public void setTabWidth(int size, TabUnits units); > > As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. > > Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. > > > Regards, > > Scott > > >> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >> >> Hi, >> >> Some more points which I thought about but for whatever reason did not pen .. >> >> First one minor thing: tabWidth is an OK name, but it does not >> conjure up that the value you specify isn't a width in pixels but the >> number of discrete space characters to use. FWIW CSS calls it tab-size. >> But CSS then supports pixels and ems .. that complicates matters a lot. >> >> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >> >> Thee rest is mostly to do with "legal or sensible values" >> >> You have : >> if (spaces < 0) >> spaces = 0; >> >> since negative values are not something we want to support! >> But I think instead of clamping you could "ignore", any out of range value. >> This is practiced elsewhere in FX where illegal values are ignored rather than >> throwing an exception, although it might be that clamping is quite common >> in range cases. >> >> The follow on to that is that what is a sensible maximum value. >> Currently we have int which is more than we need. For that matter so is short. >> I think we should have a documented and enforced sensible maximum. >> Perhaps it could be "8" meaning we only support reducing tab width as I >> don't know if anyone really wants to increase it. >> CSS doesn't have a limit that I can see but if we are already only supporting >> it described as number of spaces, we can have this other limitation too. >> If you think 8 is too small, then maybe 16 ? >> Also remember we can compatibly relax it later but we can't compatibly tighten it. >> >> >> -phil. >> >> On 10/15/19 12:17 PM, Phil Race wrote: >>> Hi, >>> >>> I've looked over this and I don't see any issues - meaning gotchas. >>> It just provides a way to over-ride the hard-coded 8, >>> whether using a Text node directly or a TextFlow. >>> >>> Two observations of what one might call limitations >>> 1) This is a rendering time property, which is controlled by the program. >>> A document containing tabs saved and re-rendered somewhere else >>> won't be helped. >>> >>> 2) This just provides API on the scene graph node types, not any of the UI controls >>> which use Text nodes. Something like a CSS property may be the way to go if >>> you wanted that. >>> Text has a nested class StyleableProperties for CSS properties with which it >>> plays nice : font, underline, strikethrough, text-alignment >>> >>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>> through to there in a similar way. >>> >>> -phil. >>> >>> >>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>> Okay, current work relocated to a clone of the new official Git repo. >>>> My initial implementation is here: >>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>> >>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>> >>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>> >>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>> >>>> Scott >>>> >>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>> >>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>> >>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>> >>>>> Regards, >>>>> >>>>> Scott >>>>> >>>>> >>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>> >>>>>> Thanks Kevin. >>>>>> >>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>> >>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>> >>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>> >>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>> >>>>>>>> What?s the next step? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Scott From swpalmer at gmail.com Thu Oct 17 18:22:33 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Oct 2019 14:22:33 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> Message-ID: So do we go ahead and implement tabSize without the CSS support? I?m not sure the CSS property should be added before unit issues are worked out, as I think the units would be expected in the CSS context. E.g. CSS implicitly adds ?px? if no unit is specified. If our tabSize units are spaces, that breaks. Scott > On Oct 17, 2019, at 2:16 PM, Kevin Rushforth wrote: > > It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you suggest. I'm not sure it's needed, though, so that would be another reason not to do it now. > > It's probably best to have the type of tabSize be double rather than int. We do this for most attributes to leave the door open for fractional values. I don't know why anyone would want a tab that was 5.7 spaces, but if we ever were to add a tabUnits property, I could easily see wanting fractional values for some units. > > -- Kevin > > On 10/17/2019 10:40 AM, Scott Palmer wrote: >> Hi Phil, >> >> Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. >> >> David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) >> Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) >> >> // Two tab-related properties >> public void setTabSize(int size); // defaults to 8 >> public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font >> >> If we did the above, I would consider adding this for convenience: >> public void setTabWidth(int size, TabUnits units); >> >> As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. >> >> Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. >> >> >> Regards, >> >> Scott >> >> >>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>> >>> Hi, >>> >>> Some more points which I thought about but for whatever reason did not pen .. >>> >>> First one minor thing: tabWidth is an OK name, but it does not >>> conjure up that the value you specify isn't a width in pixels but the >>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>> But CSS then supports pixels and ems .. that complicates matters a lot. >>> >>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>> >>> Thee rest is mostly to do with "legal or sensible values" >>> >>> You have : >>> if (spaces < 0) >>> spaces = 0; >>> >>> since negative values are not something we want to support! >>> But I think instead of clamping you could "ignore", any out of range value. >>> This is practiced elsewhere in FX where illegal values are ignored rather than >>> throwing an exception, although it might be that clamping is quite common >>> in range cases. >>> >>> The follow on to that is that what is a sensible maximum value. >>> Currently we have int which is more than we need. For that matter so is short. >>> I think we should have a documented and enforced sensible maximum. >>> Perhaps it could be "8" meaning we only support reducing tab width as I >>> don't know if anyone really wants to increase it. >>> CSS doesn't have a limit that I can see but if we are already only supporting >>> it described as number of spaces, we can have this other limitation too. >>> If you think 8 is too small, then maybe 16 ? >>> Also remember we can compatibly relax it later but we can't compatibly tighten it. >>> >>> >>> -phil. >>> >>> On 10/15/19 12:17 PM, Phil Race wrote: >>>> Hi, >>>> >>>> I've looked over this and I don't see any issues - meaning gotchas. >>>> It just provides a way to over-ride the hard-coded 8, >>>> whether using a Text node directly or a TextFlow. >>>> >>>> Two observations of what one might call limitations >>>> 1) This is a rendering time property, which is controlled by the program. >>>> A document containing tabs saved and re-rendered somewhere else >>>> won't be helped. >>>> >>>> 2) This just provides API on the scene graph node types, not any of the UI controls >>>> which use Text nodes. Something like a CSS property may be the way to go if >>>> you wanted that. >>>> Text has a nested class StyleableProperties for CSS properties with which it >>>> plays nice : font, underline, strikethrough, text-alignment >>>> >>>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>>> through to there in a similar way. >>>> >>>> -phil. >>>> >>>> >>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>> My initial implementation is here: >>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>> >>>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>>> >>>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>>> >>>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>>> >>>>> Scott >>>>> >>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>>> >>>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>> >>>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>>> >>>>>>> Thanks Kevin. >>>>>>> >>>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>>> >>>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>>> >>>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>> >>>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>> >>>>>>>>> What?s the next step? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Scott > From kevin.rushforth at oracle.com Thu Oct 17 18:25:21 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 11:25:21 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> Message-ID: That's a good question. It feels a bit incomplete without CSS support, but might be good enough for most uses. I'd be interested in what other developers think. -- Kevin On 10/17/2019 11:22 AM, Scott Palmer wrote: > So do we go ahead and implement tabSize without the CSS support? I?m not sure the CSS property should be added before unit issues are worked out, as I think the units would be expected in the CSS context. E.g. CSS implicitly adds ?px? if no unit is specified. If our tabSize units are spaces, that breaks. > > Scott > >> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth wrote: >> >> It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you suggest. I'm not sure it's needed, though, so that would be another reason not to do it now. >> >> It's probably best to have the type of tabSize be double rather than int. We do this for most attributes to leave the door open for fractional values. I don't know why anyone would want a tab that was 5.7 spaces, but if we ever were to add a tabUnits property, I could easily see wanting fractional values for some units. >> >> -- Kevin >> >> On 10/17/2019 10:40 AM, Scott Palmer wrote: >>> Hi Phil, >>> >>> Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. >>> >>> David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) >>> Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) >>> >>> // Two tab-related properties >>> public void setTabSize(int size); // defaults to 8 >>> public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font >>> >>> If we did the above, I would consider adding this for convenience: >>> public void setTabWidth(int size, TabUnits units); >>> >>> As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. >>> >>> Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. >>> >>> >>> Regards, >>> >>> Scott >>> >>> >>>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>>> >>>> Hi, >>>> >>>> Some more points which I thought about but for whatever reason did not pen .. >>>> >>>> First one minor thing: tabWidth is an OK name, but it does not >>>> conjure up that the value you specify isn't a width in pixels but the >>>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>>> But CSS then supports pixels and ems .. that complicates matters a lot. >>>> >>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>>> >>>> Thee rest is mostly to do with "legal or sensible values" >>>> >>>> You have : >>>> if (spaces < 0) >>>> spaces = 0; >>>> >>>> since negative values are not something we want to support! >>>> But I think instead of clamping you could "ignore", any out of range value. >>>> This is practiced elsewhere in FX where illegal values are ignored rather than >>>> throwing an exception, although it might be that clamping is quite common >>>> in range cases. >>>> >>>> The follow on to that is that what is a sensible maximum value. >>>> Currently we have int which is more than we need. For that matter so is short. >>>> I think we should have a documented and enforced sensible maximum. >>>> Perhaps it could be "8" meaning we only support reducing tab width as I >>>> don't know if anyone really wants to increase it. >>>> CSS doesn't have a limit that I can see but if we are already only supporting >>>> it described as number of spaces, we can have this other limitation too. >>>> If you think 8 is too small, then maybe 16 ? >>>> Also remember we can compatibly relax it later but we can't compatibly tighten it. >>>> >>>> >>>> -phil. >>>> >>>> On 10/15/19 12:17 PM, Phil Race wrote: >>>>> Hi, >>>>> >>>>> I've looked over this and I don't see any issues - meaning gotchas. >>>>> It just provides a way to over-ride the hard-coded 8, >>>>> whether using a Text node directly or a TextFlow. >>>>> >>>>> Two observations of what one might call limitations >>>>> 1) This is a rendering time property, which is controlled by the program. >>>>> A document containing tabs saved and re-rendered somewhere else >>>>> won't be helped. >>>>> >>>>> 2) This just provides API on the scene graph node types, not any of the UI controls >>>>> which use Text nodes. Something like a CSS property may be the way to go if >>>>> you wanted that. >>>>> Text has a nested class StyleableProperties for CSS properties with which it >>>>> plays nice : font, underline, strikethrough, text-alignment >>>>> >>>>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>>>> through to there in a similar way. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>>> My initial implementation is here: >>>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>>> >>>>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>>>> >>>>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>>>> >>>>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>>>> >>>>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>>> >>>>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>>>> >>>>>>>> Thanks Kevin. >>>>>>>> >>>>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>>>> >>>>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>>>> >>>>>>>>> Hi Scott, >>>>>>>>> >>>>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>>>> >>>>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>>> >>>>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>>> >>>>>>>>>> What?s the next step? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Scott From philip.race at oracle.com Thu Oct 17 18:25:16 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 11:25:16 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> Message-ID: <6bec850b-8c5e-5d7f-247f-95f041c15cea@oracle.com> Hi, As I wrote, adding units complicates things. We would have two linked properties in what you have below and one modifies the interpretation of the other. If we expose the number of spaces integer property today, I think we'd have to add the units as a separate property, but it might be that this is what you'd want anyway unless right now, today you add some new TabSize class which includes both and perhaps today would support only "spaces" or "ems" or something as the only value of the enum of sizes. FWIW I assumed that CSS is using "ems" as an explicit name for the default if you don't specify units. With TabSize there you could later add "pixels". But I am not sure it is really worth supporting pixels but I raised it because we should have the discussion up front to know if we have a way to add it later if it is needed. If we aren't limiting the value, I see no reason to use short, since any value > 100 or thereabouts pretty much means " line break", or "clip" if there's no line breaking. However I still prefer a sensible maximum. Kevin noted off-line that clamping isn't completely off-base for ranges. -phil. On 10/17/19 10:40 AM, Scott Palmer wrote: > Hi Phil, > > Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. > > David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) > Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) > > // Two tab-related properties > public void setTabSize(int size); // defaults to 8 > public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font > > If we did the above, I would consider adding this for convenience: > public void setTabWidth(int size, TabUnits units); > > As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. > > Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. > > > Regards, > > Scott > > >> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >> >> Hi, >> >> Some more points which I thought about but for whatever reason did not pen .. >> >> First one minor thing: tabWidth is an OK name, but it does not >> conjure up that the value you specify isn't a width in pixels but the >> number of discrete space characters to use. FWIW CSS calls it tab-size. >> But CSS then supports pixels and ems .. that complicates matters a lot. >> >> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >> >> Thee rest is mostly to do with "legal or sensible values" >> >> You have : >> if (spaces < 0) >> spaces = 0; >> >> since negative values are not something we want to support! >> But I think instead of clamping you could "ignore", any out of range value. >> This is practiced elsewhere in FX where illegal values are ignored rather than >> throwing an exception, although it might be that clamping is quite common >> in range cases. >> >> The follow on to that is that what is a sensible maximum value. >> Currently we have int which is more than we need. For that matter so is short. >> I think we should have a documented and enforced sensible maximum. >> Perhaps it could be "8" meaning we only support reducing tab width as I >> don't know if anyone really wants to increase it. >> CSS doesn't have a limit that I can see but if we are already only supporting >> it described as number of spaces, we can have this other limitation too. >> If you think 8 is too small, then maybe 16 ? >> Also remember we can compatibly relax it later but we can't compatibly tighten it. >> >> >> -phil. >> >> On 10/15/19 12:17 PM, Phil Race wrote: >>> Hi, >>> >>> I've looked over this and I don't see any issues - meaning gotchas. >>> It just provides a way to over-ride the hard-coded 8, >>> whether using a Text node directly or a TextFlow. >>> >>> Two observations of what one might call limitations >>> 1) This is a rendering time property, which is controlled by the program. >>> A document containing tabs saved and re-rendered somewhere else >>> won't be helped. >>> >>> 2) This just provides API on the scene graph node types, not any of the UI controls >>> which use Text nodes. Something like a CSS property may be the way to go if >>> you wanted that. >>> Text has a nested class StyleableProperties for CSS properties with which it >>> plays nice : font, underline, strikethrough, text-alignment >>> >>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>> through to there in a similar way. >>> >>> -phil. >>> >>> >>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>> Okay, current work relocated to a clone of the new official Git repo. >>>> My initial implementation is here: >>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>> >>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>> >>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>> >>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>> >>>> Scott >>>> >>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>> >>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>> >>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>> >>>>> Regards, >>>>> >>>>> Scott >>>>> >>>>> >>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>> >>>>>> Thanks Kevin. >>>>>> >>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>> >>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>> >>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>> >>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>> >>>>>>>> What?s the next step? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Scott From philip.race at oracle.com Thu Oct 17 18:26:12 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 11:26:12 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> Message-ID: <5f7cf98f-6034-6190-652e-31b59d67cc70@oracle.com> On 10/17/19 11:16 AM, Kevin Rushforth wrote: > It might make sense to just add the tabSize property now, and later > consider adding a tabUnits property in the future if needed. By > default, having the units be "number of spaces in the current font" is > what makes the most sense, so before we could add tabUnits we would > need to extend it as you suggest. I'm not sure it's needed, though, so > that would be another reason not to do it now. > > It's probably best to have the type of tabSize be double rather than > int. We do this for most attributes to leave the door open for > fractional values. I don't know why anyone would want a tab that was > 5.7 spaces, but if we ever were to add a tabUnits property, I could > easily see wanting fractional values for some units. In a fixed width font that would seem bizarre. And I think fixed width fonts are the main case when you *want* tabs. This is another reason why I don't think we should do pixels ... -phil. > > -- Kevin > > On 10/17/2019 10:40 AM, Scott Palmer wrote: >> Hi Phil, >> >> Thanks for taking a look.? I was going to get back to this soon to >> attempt adding the CSS property as you mention in your previous >> email.? I considered tabSize as a name as well.? I don?t have a >> preference if we leave things as representing tabs as a number of >> spaces.? But it wouldn?t be too difficult to support units, making it >> mostly compatible with CSS rules.? The way I envision that is having >> two properties, tabSize and tabUnit. >> >> David mentioned javafx.css.SizeUnits? I looked quickly at the java >> docs for it, and it?s basically undocumented .? So I went to >> https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS >> unit like ?ems? but meaning the width of a space in the current >> font.? The problem with that is it would leave out the possibility to >> set the tab width to anything relative to the current implementation >> of 8 spaces. (In hindsight it should have been implemented based on >> ?ems?, which for a fixed width font as typically used in a code >> editor would be the same as 8 spaces anyway) >> Do we add something to SizeUnits so we can work around this? e.g. >> ?fxsp?? (FX-space - fx prefix to avoid a potential collision with any >> future official CSS units) >> >> // Two tab-related properties >> public void setTabSize(int size); // defaults to 8 >> public void setTabUnits(SizeUnits units); // ?? no unit for width of >> space in current font >> >> If we did the above, I would consider adding this for convenience: >> public void setTabWidth(int size, TabUnits units); >> >> As far as setting a range, I?m not sure there is any worthwhile >> benefit to enforcing a maximum.? If we want to store the value in a >> short instead of an int to potentially save a couple bytes, sure.? >> Otherwise, if someone wants to set tabs to be 20 spaces or 100, why >> should we prevent it?? If there isn't a performance or memory impact, >> I wouldn?t enforce a maximum. >> >> Ignoring any out of range values rather than clamping seems fine to >> me as well.? I was thinking of what happens if the value was bound to >> another value that strayed out of range. Clamping would get you as >> close as possible to the bound value, rather than stuck at the >> previously observed value.? I just guessed that would be preferred, >> but if ignoring is more consistent with other values, then I agree it >> makes sense.? As long as the behaviour is documented, I can?t think >> of any significant downside either way. >> >> >> Regards, >> >> Scott >> >> >>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>> >>> Hi, >>> >>> Some more points which I thought about but for whatever reason did >>> not pen .. >>> >>> First one minor thing: tabWidth is an OK name, but it does not >>> conjure up that the value you specify isn't a width in pixels but the >>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>> But CSS then supports pixels and ems .. that complicates matters a lot. >>> >>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>> >>> Thee rest is mostly to do with "legal or sensible values" >>> >>> You have : >>> ???????? if (spaces < 0) >>> ???????????? spaces = 0; >>> >>> since negative values are not something we want to support! >>> But I think instead of clamping you could "ignore", any out of range >>> value. >>> This is practiced elsewhere in FX where illegal values are ignored >>> rather than >>> throwing an exception, although it might be that clamping is quite >>> common >>> in range cases. >>> >>> The follow on to that is that what is a sensible maximum value. >>> Currently we have int which is more than we need. For that matter so >>> is short. >>> I think we should have a documented and enforced sensible maximum. >>> Perhaps it could be "8" meaning we only support reducing tab width as I >>> don't know if anyone really wants to increase it. >>> CSS doesn't have a limit that I can see but if we are already only >>> supporting >>> it described as number of spaces, we can have this other limitation >>> too. >>> If you think 8 is too small, then maybe 16 ? >>> Also remember we can compatibly relax it later but we can't >>> compatibly tighten it. >>> >>> >>> -phil. >>> >>> On 10/15/19 12:17 PM, Phil Race wrote: >>>> Hi, >>>> >>>> I've looked over this and I don't see any issues - meaning gotchas. >>>> It just provides a way to over-ride the hard-coded 8, >>>> whether using a Text node directly or a TextFlow. >>>> >>>> Two observations of what one might call limitations >>>> 1) This is a rendering time property, which is controlled by the >>>> program. >>>> A document containing tabs saved and re-rendered somewhere else >>>> won't be helped. >>>> >>>> 2) This just provides API on the scene graph node types, not any of >>>> the UI controls >>>> which use Text nodes. Something like a CSS property may be the way >>>> to go if >>>> you wanted that. >>>> Text has a nested class StyleableProperties for CSS properties with >>>> which it >>>> plays nice : font, underline, strikethrough, text-alignment >>>> >>>> So creating an fx-tabWidth (or similar name) CSS property could be >>>> propagated >>>> through to there in a similar way. >>>> >>>> -phil. >>>> >>>> >>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>> My initial implementation is here: >>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>> >>>>> >>>>> >>>>> I would submit it as a pull request but that seems premature since >>>>> there hasn?t been any real discussion of challenges I?ve >>>>> overlooked.? All I have are the famous last words, ?It works for me.? >>>>> >>>>> I saw in the archives a concern about tab width vs tab stops. For >>>>> some reason I didn?t get the email.? Anyway, I don?t think >>>>> arbitrary tab stop positions, at different intervals that is, are >>>>> what was asked for.? That certainly would require a significantly >>>>> different implementation. >>>>> >>>>> Would love to keep some momentum going on this before I become >>>>> busy with other things and won?t have time for it. >>>>> >>>>> Scott >>>>> >>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer >>>>>> wrote: >>>>>> >>>>>> My current work is here >>>>>> https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>> >>>>>> >>>>>> >>>>>> While writing a unit test I realized that the StubToolkit isn?t >>>>>> really running the Prism layout code, so I?m not sure how that >>>>>> gets tested.? I made it work with StubTextLayout for now. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer >>>>>> > wrote: >>>>>>> >>>>>>> Thanks Kevin. >>>>>>> >>>>>>> My current implementation appears to be working for TextFlow and >>>>>>> Text, with the TextFlow overriding the tabWidth of the child >>>>>>> Text nodes.? This seems to work out naturally from the way >>>>>>> TextFlow overrides the TextLayout instance used by the Text node. >>>>>>> >>>>>>> If there are tricky corner-cases that I?m missing, I guess >>>>>>> figuring out all the cases it will need to handle is part of >>>>>>> this discussion.? It didn?t seem to be that challenging so far, >>>>>>> so perhaps I am missing something (hopefully not).? I wrote a >>>>>>> small test app to visually see that things were working as I >>>>>>> expected.? I have not yet written the unit tests. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> I'm sure Phil will have more comments on this. While the API >>>>>>>> seems simple enough on the surface, I suspect that this will be >>>>>>>> a challenging feature to implement correctly for all of the >>>>>>>> cases it will need to handle. It would need careful review and >>>>>>>> testing as well. My only comment on the API itself is that if >>>>>>>> we do accept this feature, it should probably go on both Text >>>>>>>> and TextFlow, and be one of the attributes of Text that is >>>>>>>> ignored / overridden when a Text node is in a TextFlow. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>> I would like to implement this feature, being able to adjust >>>>>>>>> the tab size in a TextFlow or Text node (JDK-8130738 >>>>>>>>> >>>>>>>> >). It >>>>>>>>> involves new public API, so I want to start a discussion about >>>>>>>>> it here.? (My motivation is that RichTextFX suggests an >>>>>>>>> entirely unacceptable workaround of substituting actual spaces >>>>>>>>> when the tab character is typed and cites the lack of this API.) >>>>>>>>> >>>>>>>>> I?ve already jumped the gun and taken a crack at an >>>>>>>>> implementation.? It is currently incomplete as I was just >>>>>>>>> poking around to see if it was going to be easy enough to not >>>>>>>>> take up too much of my time.? It boils down to: >>>>>>>>> TextFlow and Text get a new property for tab width, an integer >>>>>>>>> representing the number of spaces taken by a tab. (The value >>>>>>>>> is only used to initialize the tab width for the TextLayout >>>>>>>>> when needed.) >>>>>>>>> TextLayout interface gets a new method:? boolean >>>>>>>>> setTabWidth(int spaces) >>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>> >>>>>>>>> I?m not sure that the Text node needs this new property.? I >>>>>>>>> figured it would be rarely used on that class, so I had >>>>>>>>> implemented it via an added property in the private >>>>>>>>> TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>> >>>>>>>>> What?s the next step? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Scott > From philip.race at oracle.com Thu Oct 17 18:32:43 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 11:32:43 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> Message-ID: Really ? It defaults to pixels ? Is that just inherited as being the default CSS unit ? Is that FX's implementation Hmm. A bit of reading about web CSS says that strictly anything without an explicit unit should be ignored. The only exception is zero, where it doesn't matter. Eg see : https://stackoverflow.com/questions/7907749/default-unit-for-font-size Although I am sure there are more authoratative? sources than that. -phil. On 10/17/19 11:22 AM, Scott Palmer wrote: > So do we go ahead and implement tabSize without the CSS support? I?m not sure the CSS property should be added before unit issues are worked out, as I think the units would be expected in the CSS context. E.g. CSS implicitly adds ?px? if no unit is specified. If our tabSize units are spaces, that breaks. > > Scott > >> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth wrote: >> >> It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you suggest. I'm not sure it's needed, though, so that would be another reason not to do it now. >> >> It's probably best to have the type of tabSize be double rather than int. We do this for most attributes to leave the door open for fractional values. I don't know why anyone would want a tab that was 5.7 spaces, but if we ever were to add a tabUnits property, I could easily see wanting fractional values for some units. >> >> -- Kevin >> >> On 10/17/2019 10:40 AM, Scott Palmer wrote: >>> Hi Phil, >>> >>> Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. >>> >>> David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) >>> Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) >>> >>> // Two tab-related properties >>> public void setTabSize(int size); // defaults to 8 >>> public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font >>> >>> If we did the above, I would consider adding this for convenience: >>> public void setTabWidth(int size, TabUnits units); >>> >>> As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. >>> >>> Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. >>> >>> >>> Regards, >>> >>> Scott >>> >>> >>>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>>> >>>> Hi, >>>> >>>> Some more points which I thought about but for whatever reason did not pen .. >>>> >>>> First one minor thing: tabWidth is an OK name, but it does not >>>> conjure up that the value you specify isn't a width in pixels but the >>>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>>> But CSS then supports pixels and ems .. that complicates matters a lot. >>>> >>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>>> >>>> Thee rest is mostly to do with "legal or sensible values" >>>> >>>> You have : >>>> if (spaces < 0) >>>> spaces = 0; >>>> >>>> since negative values are not something we want to support! >>>> But I think instead of clamping you could "ignore", any out of range value. >>>> This is practiced elsewhere in FX where illegal values are ignored rather than >>>> throwing an exception, although it might be that clamping is quite common >>>> in range cases. >>>> >>>> The follow on to that is that what is a sensible maximum value. >>>> Currently we have int which is more than we need. For that matter so is short. >>>> I think we should have a documented and enforced sensible maximum. >>>> Perhaps it could be "8" meaning we only support reducing tab width as I >>>> don't know if anyone really wants to increase it. >>>> CSS doesn't have a limit that I can see but if we are already only supporting >>>> it described as number of spaces, we can have this other limitation too. >>>> If you think 8 is too small, then maybe 16 ? >>>> Also remember we can compatibly relax it later but we can't compatibly tighten it. >>>> >>>> >>>> -phil. >>>> >>>> On 10/15/19 12:17 PM, Phil Race wrote: >>>>> Hi, >>>>> >>>>> I've looked over this and I don't see any issues - meaning gotchas. >>>>> It just provides a way to over-ride the hard-coded 8, >>>>> whether using a Text node directly or a TextFlow. >>>>> >>>>> Two observations of what one might call limitations >>>>> 1) This is a rendering time property, which is controlled by the program. >>>>> A document containing tabs saved and re-rendered somewhere else >>>>> won't be helped. >>>>> >>>>> 2) This just provides API on the scene graph node types, not any of the UI controls >>>>> which use Text nodes. Something like a CSS property may be the way to go if >>>>> you wanted that. >>>>> Text has a nested class StyleableProperties for CSS properties with which it >>>>> plays nice : font, underline, strikethrough, text-alignment >>>>> >>>>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>>>> through to there in a similar way. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>>> My initial implementation is here: >>>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>>> >>>>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>>>> >>>>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>>>> >>>>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>>>> >>>>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>>> >>>>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>>>> >>>>>>>> Thanks Kevin. >>>>>>>> >>>>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>>>> >>>>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>>>> >>>>>>>>> Hi Scott, >>>>>>>>> >>>>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>>>> >>>>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>>> >>>>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>>> >>>>>>>>>> What?s the next step? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Scott From philip.race at oracle.com Thu Oct 17 18:51:36 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 11:51:36 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <6bec850b-8c5e-5d7f-247f-95f041c15cea@oracle.com> Message-ID: Hi, Thanks for that. It also neatly solves the units problem. I think it means we can just support the same and not go out of our way to make provision for pixels. -phil. On 10/17/19 11:46 AM, David Grieve wrote: > FWIW, w3c spec for tab-size is https://drafts.csswg.org/css-text-3/#propdef-tab-size > In this spec, the value of 'tab-size' is a (or length -which no browsers support). For all intents and purposes, indicates a number of spaces. > >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Phil Race >> Sent: Thursday, October 17, 2019 2:25 PM >> To: Scott Palmer >> Cc: openjfx-dev at openjdk.java.net Mailing >> Subject: Re: JDK-8130738 TextFlow's tab width is static >> >> Hi, >> >> As I wrote, adding units complicates things. >> We would have two linked properties in what you have below and one >> modifies the interpretation of the other. >> >> If we expose the number of spaces integer property today, I think we'd have >> to add the units as a separate property, but it might be that this is what you'd >> want anyway unless right now, today you add some new TabSize class which >> includes both and perhaps today would support only "spaces" or "ems" or >> something as the only value of the enum of sizes. >> FWIW I assumed that CSS is using "ems" as an explicit name for the default if >> you don't specify units. >> >> With TabSize there you could later add "pixels". >> But I am not sure it is really worth supporting pixels but I raised it because >> we should have the discussion up front to know if we have a way to add it >> later if it is needed. >> >> If we aren't limiting the value, I see no reason to use short, since any value > >> 100 or thereabouts pretty much means " line break", or "clip" if there's no >> line breaking. >> >> However I still prefer a sensible maximum. >> >> Kevin noted off-line that clamping isn't completely off-base for ranges. >> >> -phil. >> >> On 10/17/19 10:40 AM, Scott Palmer wrote: >>> Hi Phil, >>> >>> Thanks for taking a look. I was going to get back to this soon to attempt >> adding the CSS property as you mention in your previous email. I considered >> tabSize as a name as well. I don?t have a preference if we leave things as >> representing tabs as a number of spaces. But it wouldn?t be too difficult to >> support units, making it mostly compatible with CSS rules. The way I envision >> that is having two properties, tabSize and tabUnit. >>> David mentioned javafx.css.SizeUnits? I looked quickly at the java >>> docs for it, and it?s basically undocumented . So I went to >>> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> . >>> w3.org%2FTR%2Fcss-values- >> 3%2F%23lengths&data=02%7C01%7CDavid.Griev >> e%40microsoft.com%7Cec03031ecb6c484da76008d7533002ce%7C72f988bf8 >> 6f141a >> f91ab2d7cd011db47%7C1%7C0%7C637069337978947508&sdata=li0kW >> L1C1hNRA >>> In0C5ehMIHz6WD%2B%2F3F1xgRH%2Fl9Piv4%3D&reserved=0 and I >> see there >>> is no CSS unit like ?ems? but meaning the width of a space in the >>> current font. The problem with that is it would leave out the >>> possibility to set the tab width to anything relative to the current >>> implementation of 8 spaces. (In hindsight it should have been >>> implemented based on ?ems?, which for a fixed width font as typically >>> used in a code editor would be the same as 8 spaces anyway) Do we add >>> something to SizeUnits so we can work around this? e.g. ?fxsp? >>> (FX-space - fx prefix to avoid a potential collision with any future >>> official CSS units) >>> >>> // Two tab-related properties >>> public void setTabSize(int size); // defaults to 8 public void >>> setTabUnits(SizeUnits units); // ?? no unit for width of space in >>> current font >>> >>> If we did the above, I would consider adding this for convenience: >>> public void setTabWidth(int size, TabUnits units); >>> >>> As far as setting a range, I?m not sure there is any worthwhile benefit to >> enforcing a maximum. If we want to store the value in a short instead of an >> int to potentially save a couple bytes, sure. Otherwise, if someone wants to >> set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a >> performance or memory impact, I wouldn?t enforce a maximum. >>> Ignoring any out of range values rather than clamping seems fine to me as >> well. I was thinking of what happens if the value was bound to another value >> that strayed out of range. Clamping would get you as close as possible to the >> bound value, rather than stuck at the previously observed value. I just >> guessed that would be preferred, but if ignoring is more consistent with >> other values, then I agree it makes sense. As long as the behaviour is >> documented, I can?t think of any significant downside either way. >>> >>> Regards, >>> >>> Scott >>> >>> >>>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>>> >>>> Hi, >>>> >>>> Some more points which I thought about but for whatever reason did not >> pen .. >>>> First one minor thing: tabWidth is an OK name, but it does not >>>> conjure up that the value you specify isn't a width in pixels but the >>>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>>> But CSS then supports pixels and ems .. that complicates matters a lot. >>>> >>>> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdev >>>> eloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FCSS%2Ftab- >> size&data=02% >> 7C01%7CDavid.Grieve%40microsoft.com%7Cec03031ecb6c484da76008d7533 >> 002c >> e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6370693379789475 >> 08& >> ;sdata=UGYGSC%2F1S85T1XPBcsaUhHp1s4gmDYOKrcjQxaPdi0M%3D&r >> eserved= >>>> 0 >>>> >>>> Thee rest is mostly to do with "legal or sensible values" >>>> >>>> You have : >>>> if (spaces < 0) >>>> spaces = 0; >>>> >>>> since negative values are not something we want to support! >>>> But I think instead of clamping you could "ignore", any out of range value. >>>> This is practiced elsewhere in FX where illegal values are ignored >>>> rather than throwing an exception, although it might be that clamping >>>> is quite common in range cases. >>>> >>>> The follow on to that is that what is a sensible maximum value. >>>> Currently we have int which is more than we need. For that matter so is >> short. >>>> I think we should have a documented and enforced sensible maximum. >>>> Perhaps it could be "8" meaning we only support reducing tab width as >>>> I don't know if anyone really wants to increase it. >>>> CSS doesn't have a limit that I can see but if we are already only >>>> supporting it described as number of spaces, we can have this other >> limitation too. >>>> If you think 8 is too small, then maybe 16 ? >>>> Also remember we can compatibly relax it later but we can't compatibly >> tighten it. >>>> >>>> -phil. >>>> >>>> On 10/15/19 12:17 PM, Phil Race wrote: >>>>> Hi, >>>>> >>>>> I've looked over this and I don't see any issues - meaning gotchas. >>>>> It just provides a way to over-ride the hard-coded 8, whether using >>>>> a Text node directly or a TextFlow. >>>>> >>>>> Two observations of what one might call limitations >>>>> 1) This is a rendering time property, which is controlled by the program. >>>>> A document containing tabs saved and re-rendered somewhere else >>>>> won't be helped. >>>>> >>>>> 2) This just provides API on the scene graph node types, not any of >>>>> the UI controls which use Text nodes. Something like a CSS property >>>>> may be the way to go if you wanted that. >>>>> Text has a nested class StyleableProperties for CSS properties with >>>>> which it plays nice : font, underline, strikethrough, text-alignment >>>>> >>>>> So creating an fx-tabWidth (or similar name) CSS property could be >>>>> propagated through to there in a similar way. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>>> My initial implementation is here: >>>>>> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg >> ithub.com%2Fswpalmer%2Fjfx%2Fcommit%2Fcc6193451bf8a693093f3ded5d >> cbe >> 47af2fcbe8f&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cec0 >> 30 >> 31ecb6c484da76008d7533002ce%7C72f988bf86f141af91ab2d7cd011db47%7 >> C1% >> 7C0%7C637069337978947508&sdata=LcefWjPpbrsy5tOSVZx%2FL56saH >> 3L%2 >>>>>> FeeqgHp%2Ftbg4gFY%3D&reserved=0 >>>>>> >> > github.com%2Fswpalmer%2Fjfx%2Fcommit%2Fcc6193451bf8a693093f3ded5 >> dcb >> e47af2fcbe8f&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cec >> 03 >> 031ecb6c484da76008d7533002ce%7C72f988bf86f141af91ab2d7cd011db47% >> 7C1 >> %7C0%7C637069337978947508&sdata=LcefWjPpbrsy5tOSVZx%2FL56sa >> H3L% >>>>>> 2FeeqgHp%2Ftbg4gFY%3D&reserved=0> >>>>>> >>>>>> I would submit it as a pull request but that seems premature since >> there hasn?t been any real discussion of challenges I?ve overlooked. All I >> have are the famous last words, ?It works for me.? >>>>>> I saw in the archives a concern about tab width vs tab stops. For some >> reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop >> positions, at different intervals that is, are what was asked for. That certainly >> would require a significantly different implementation. >>>>>> Would love to keep some momentum going on this before I become >> busy with other things and won?t have time for it. >>>>>> Scott >>>>>> >>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer >> wrote: >>>>>>> My current work is here >>>>>>> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>>>> github.com%2Fjavafxports%2Fopenjdk- >> jfx%2Fcompare%2Fdevelop...swpal >>>>>>> mer%3Ajdk- >> 8130738%3Fexpand%3D1&data=02%7C01%7CDavid.Grieve%40m >> icrosoft.com%7Cec03031ecb6c484da76008d7533002ce%7C72f988bf86f141af >> 91ab2d7cd011db47%7C1%7C0%7C637069337978947508&sdata=BbNzTf >> l7Ai >>>>>>> J16Lg3GD%2FpflnxJ5EllT93W0CNv62gdWw%3D&reserved=0 >>>>>>> >> >>>>>> Fgithub.com%2Fjavafxports%2Fopenjdk- >> jfx%2Fcompare%2Fdevelop...swpa >>>>>>> lmer%3Ajdk- >> 8130738%3Fexpand%3D1&data=02%7C01%7CDavid.Grieve%40 >> microsoft.com%7Cec03031ecb6c484da76008d7533002ce%7C72f988bf86f141 >> a >> f91ab2d7cd011db47%7C1%7C0%7C637069337978947508&sdata=BbNzT >> fl7A >>>>>>> iJ16Lg3GD%2FpflnxJ5EllT93W0CNv62gdWw%3D&reserved=0> >>>>>>> >>>>>>> While writing a unit test I realized that the StubToolkit isn?t really >> running the Prism layout code, so I?m not sure how that gets tested. I made >> it work with StubTextLayout for now. >>>>>>> Regards, >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > > wrote: >>>>>>>> Thanks Kevin. >>>>>>>> >>>>>>>> My current implementation appears to be working for TextFlow and >> Text, with the TextFlow overriding the tabWidth of the child Text nodes. This >> seems to work out naturally from the way TextFlow overrides the TextLayout >> instance used by the Text node. >>>>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out >> all the cases it will need to handle is part of this discussion. It didn?t seem to >> be that challenging so far, so perhaps I am missing something (hopefully >> not). I wrote a small test app to visually see that things were working as I >> expected. I have not yet written the unit tests. >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >> > wrote: >>>>>>>>> Hi Scott, >>>>>>>>> >>>>>>>>> I'm sure Phil will have more comments on this. While the API seems >> simple enough on the surface, I suspect that this will be a challenging feature >> to implement correctly for all of the cases it will need to handle. It would >> need careful review and testing as well. My only comment on the API itself is >> that if we do accept this feature, it should probably go on both Text and >> TextFlow, and be one of the attributes of Text that is ignored / overridden >> when a Text node is in a TextFlow. >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>>> I would like to implement this feature, being able to adjust >>>>>>>>>> the tab size in a TextFlow or Text node (JDK-8130738 >>>>>>>>>> >> >>>>>>>>> F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK- >> 8130738&data=02%7C >> 01%7CDavid.Grieve%40microsoft.com%7Cec03031ecb6c484da76008d7533 >> 002ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637069337978 >> 947508&sdata=bD3fdm4cbXVppm7F7hced9HDRt8WXtDMiZ9%2FOyTl3o >> 8% >>>>>>>>>> 3D&reserved=0 >>>>>>>>>> >> >>>>>>>>> F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK- >> 8130738&data=02%7C >> 01%7CDavid.Grieve%40microsoft.com%7Cec03031ecb6c484da76008d7533 >> 002ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637069337978 >> 947508&sdata=bD3fdm4cbXVppm7F7hced9HDRt8WXtDMiZ9%2FOyTl3o >> 8% >>>>>>>>>> 3D&reserved=0>>). It involves new public API, so I want to >>>>>>>>>> start a discussion about it here. (My motivation is that >>>>>>>>>> RichTextFX suggests an entirely unacceptable workaround of >>>>>>>>>> substituting actual spaces when the tab character is typed and >>>>>>>>>> cites the lack of this API.) >>>>>>>>>> >>>>>>>>>> I?ve already jumped the gun and taken a crack at an >> implementation. It is currently incomplete as I was just poking around to see >> if it was going to be easy enough to not take up too much of my time. It boils >> down to: >>>>>>>>>> TextFlow and Text get a new property for tab width, an integer >>>>>>>>>> representing the number of spaces taken by a tab. (The value is >>>>>>>>>> only used to initialize the tab width for the TextLayout when >>>>>>>>>> needed.) TextLayout interface gets a new method: boolean >> setTabWidth(int spaces) TextLayout gets a new constant: >> DEFAULT_TAB_WIDTH = 8; PrismTextLayout implements the new >> setTabWidth API. >>>>>>>>>> I?m not sure that the Text node needs this new property. I figured >> it would be rarely used on that class, so I had implemented it via an added >> property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>>> What?s the next step? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Scott From swpalmer at gmail.com Thu Oct 17 19:11:33 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Oct 2019 15:11:33 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> Message-ID: <99C8989F-13AD-46D0-A004-735FFBBDBBC0@gmail.com> You?re right. Something I was reading indicated that while there was no default unit, ?px? was implicitly appended. I can?t find that now. Go figure. Everything I find now about CSS tab-size is in agreement with what David wrote. It?s a number of spaces. With units it would be a ?length? but nothing supports that. So I think it makes sense to add -fx-tab-size as a CSS property, only supporting a number with no units. Scott > On Oct 17, 2019, at 2:32 PM, Phil Race wrote: > > Really ? It defaults to pixels ? Is that just inherited as being the default CSS unit ? > Is that FX's implementation > > Hmm. A bit of reading about web CSS says that strictly anything without an explicit unit should be ignored. > The only exception is zero, where it doesn't matter. > > Eg see : https://stackoverflow.com/questions/7907749/default-unit-for-font-size > > Although I am sure there are more authoratative sources than that. > > -phil. > > On 10/17/19 11:22 AM, Scott Palmer wrote: >> So do we go ahead and implement tabSize without the CSS support? I?m not sure the CSS property should be added before unit issues are worked out, as I think the units would be expected in the CSS context. E.g. CSS implicitly adds ?px? if no unit is specified. If our tabSize units are spaces, that breaks. >> >> Scott >> >>> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth wrote: >>> >>> It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you suggest. I'm not sure it's needed, though, so that would be another reason not to do it now. >>> >>> It's probably best to have the type of tabSize be double rather than int. We do this for most attributes to leave the door open for fractional values. I don't know why anyone would want a tab that was 5.7 spaces, but if we ever were to add a tabUnits property, I could easily see wanting fractional values for some units. >>> >>> -- Kevin >>> >>> On 10/17/2019 10:40 AM, Scott Palmer wrote: >>>> Hi Phil, >>>> >>>> Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. >>>> >>>> David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) >>>> Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) >>>> >>>> // Two tab-related properties >>>> public void setTabSize(int size); // defaults to 8 >>>> public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font >>>> >>>> If we did the above, I would consider adding this for convenience: >>>> public void setTabWidth(int size, TabUnits units); >>>> >>>> As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. >>>> >>>> Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. >>>> >>>> >>>> Regards, >>>> >>>> Scott >>>> >>>> >>>>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>>>> >>>>> Hi, >>>>> >>>>> Some more points which I thought about but for whatever reason did not pen .. >>>>> >>>>> First one minor thing: tabWidth is an OK name, but it does not >>>>> conjure up that the value you specify isn't a width in pixels but the >>>>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>>>> But CSS then supports pixels and ems .. that complicates matters a lot. >>>>> >>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>>>> >>>>> Thee rest is mostly to do with "legal or sensible values" >>>>> >>>>> You have : >>>>> if (spaces < 0) >>>>> spaces = 0; >>>>> >>>>> since negative values are not something we want to support! >>>>> But I think instead of clamping you could "ignore", any out of range value. >>>>> This is practiced elsewhere in FX where illegal values are ignored rather than >>>>> throwing an exception, although it might be that clamping is quite common >>>>> in range cases. >>>>> >>>>> The follow on to that is that what is a sensible maximum value. >>>>> Currently we have int which is more than we need. For that matter so is short. >>>>> I think we should have a documented and enforced sensible maximum. >>>>> Perhaps it could be "8" meaning we only support reducing tab width as I >>>>> don't know if anyone really wants to increase it. >>>>> CSS doesn't have a limit that I can see but if we are already only supporting >>>>> it described as number of spaces, we can have this other limitation too. >>>>> If you think 8 is too small, then maybe 16 ? >>>>> Also remember we can compatibly relax it later but we can't compatibly tighten it. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 10/15/19 12:17 PM, Phil Race wrote: >>>>>> Hi, >>>>>> >>>>>> I've looked over this and I don't see any issues - meaning gotchas. >>>>>> It just provides a way to over-ride the hard-coded 8, >>>>>> whether using a Text node directly or a TextFlow. >>>>>> >>>>>> Two observations of what one might call limitations >>>>>> 1) This is a rendering time property, which is controlled by the program. >>>>>> A document containing tabs saved and re-rendered somewhere else >>>>>> won't be helped. >>>>>> >>>>>> 2) This just provides API on the scene graph node types, not any of the UI controls >>>>>> which use Text nodes. Something like a CSS property may be the way to go if >>>>>> you wanted that. >>>>>> Text has a nested class StyleableProperties for CSS properties with which it >>>>>> plays nice : font, underline, strikethrough, text-alignment >>>>>> >>>>>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>>>>> through to there in a similar way. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>>>> My initial implementation is here: >>>>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>>>> >>>>>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>>>>> >>>>>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>>>>> >>>>>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>>>>> >>>>>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>>>> >>>>>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>>>>> >>>>>>>>> Thanks Kevin. >>>>>>>>> >>>>>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>>>>> >>>>>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>>>>> >>>>>>>>>> Hi Scott, >>>>>>>>>> >>>>>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>>>>> >>>>>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>>>> >>>>>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>>>> >>>>>>>>>>> What?s the next step? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Scott > From kevin.rushforth at oracle.com Thu Oct 17 19:32:54 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Oct 2019 12:32:54 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <99C8989F-13AD-46D0-A004-735FFBBDBBC0@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> <99C8989F-13AD-46D0-A004-735FFBBDBBC0@gmail.com> Message-ID: It seems that you have a path forward then. So, there are a couple questions to answer: 1. Should the type of the property be int or double? If it really is only ever going to be a number of spaces, then int seems fine. That, along with the name of the property, would underscore the fact that no, this isn't a size where units make sense; it's a number of spaces. 2. Should the range be [1,MAXINT] or [1,16] or [1,something-else]? Once that is decided, I think clamp on use would be the most consistent with other similar properties, but that's worth checking. -- Kevin On 10/17/2019 12:11 PM, Scott Palmer wrote: > You?re right. Something I was reading indicated that while there was no default unit, ?px? was implicitly appended. I can?t find that now. Go figure. > > Everything I find now about CSS tab-size is in agreement with what David wrote. It?s a number of spaces. With units it would be a ?length? but nothing supports that. > > So I think it makes sense to add -fx-tab-size as a CSS property, only supporting a number with no units. > > Scott > > >> On Oct 17, 2019, at 2:32 PM, Phil Race wrote: >> >> Really ? It defaults to pixels ? Is that just inherited as being the default CSS unit ? >> Is that FX's implementation >> >> Hmm. A bit of reading about web CSS says that strictly anything without an explicit unit should be ignored. >> The only exception is zero, where it doesn't matter. >> >> Eg see : https://stackoverflow.com/questions/7907749/default-unit-for-font-size >> >> Although I am sure there are more authoratative sources than that. >> >> -phil. >> >> On 10/17/19 11:22 AM, Scott Palmer wrote: >>> So do we go ahead and implement tabSize without the CSS support? I?m not sure the CSS property should be added before unit issues are worked out, as I think the units would be expected in the CSS context. E.g. CSS implicitly adds ?px? if no unit is specified. If our tabSize units are spaces, that breaks. >>> >>> Scott >>> >>>> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth wrote: >>>> >>>> It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you suggest. I'm not sure it's needed, though, so that would be another reason not to do it now. >>>> >>>> It's probably best to have the type of tabSize be double rather than int. We do this for most attributes to leave the door open for fractional values. I don't know why anyone would want a tab that was 5.7 spaces, but if we ever were to add a tabUnits property, I could easily see wanting fractional values for some units. >>>> >>>> -- Kevin >>>> >>>> On 10/17/2019 10:40 AM, Scott Palmer wrote: >>>>> Hi Phil, >>>>> >>>>> Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don?t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn?t be too difficult to support units, making it mostly compatible with CSS rules. The way I envision that is having two properties, tabSize and tabUnit. >>>>> >>>>> David mentioned javafx.css.SizeUnits? I looked quickly at the java docs for it, and it?s basically undocumented . So I went to https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like ?ems? but meaning the width of a space in the current font. The problem with that is it would leave out the possibility to set the tab width to anything relative to the current implementation of 8 spaces. (In hindsight it should have been implemented based on ?ems?, which for a fixed width font as typically used in a code editor would be the same as 8 spaces anyway) >>>>> Do we add something to SizeUnits so we can work around this? e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision with any future official CSS units) >>>>> >>>>> // Two tab-related properties >>>>> public void setTabSize(int size); // defaults to 8 >>>>> public void setTabUnits(SizeUnits units); // ?? no unit for width of space in current font >>>>> >>>>> If we did the above, I would consider adding this for convenience: >>>>> public void setTabWidth(int size, TabUnits units); >>>>> >>>>> As far as setting a range, I?m not sure there is any worthwhile benefit to enforcing a maximum. If we want to store the value in a short instead of an int to potentially save a couple bytes, sure. Otherwise, if someone wants to set tabs to be 20 spaces or 100, why should we prevent it? If there isn't a performance or memory impact, I wouldn?t enforce a maximum. >>>>> >>>>> Ignoring any out of range values rather than clamping seems fine to me as well. I was thinking of what happens if the value was bound to another value that strayed out of range. Clamping would get you as close as possible to the bound value, rather than stuck at the previously observed value. I just guessed that would be preferred, but if ignoring is more consistent with other values, then I agree it makes sense. As long as the behaviour is documented, I can?t think of any significant downside either way. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Scott >>>>> >>>>> >>>>>> On Oct 17, 2019, at 12:45 PM, Phil Race wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Some more points which I thought about but for whatever reason did not pen .. >>>>>> >>>>>> First one minor thing: tabWidth is an OK name, but it does not >>>>>> conjure up that the value you specify isn't a width in pixels but the >>>>>> number of discrete space characters to use. FWIW CSS calls it tab-size. >>>>>> But CSS then supports pixels and ems .. that complicates matters a lot. >>>>>> >>>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>>>>> >>>>>> Thee rest is mostly to do with "legal or sensible values" >>>>>> >>>>>> You have : >>>>>> if (spaces < 0) >>>>>> spaces = 0; >>>>>> >>>>>> since negative values are not something we want to support! >>>>>> But I think instead of clamping you could "ignore", any out of range value. >>>>>> This is practiced elsewhere in FX where illegal values are ignored rather than >>>>>> throwing an exception, although it might be that clamping is quite common >>>>>> in range cases. >>>>>> >>>>>> The follow on to that is that what is a sensible maximum value. >>>>>> Currently we have int which is more than we need. For that matter so is short. >>>>>> I think we should have a documented and enforced sensible maximum. >>>>>> Perhaps it could be "8" meaning we only support reducing tab width as I >>>>>> don't know if anyone really wants to increase it. >>>>>> CSS doesn't have a limit that I can see but if we are already only supporting >>>>>> it described as number of spaces, we can have this other limitation too. >>>>>> If you think 8 is too small, then maybe 16 ? >>>>>> Also remember we can compatibly relax it later but we can't compatibly tighten it. >>>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 10/15/19 12:17 PM, Phil Race wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've looked over this and I don't see any issues - meaning gotchas. >>>>>>> It just provides a way to over-ride the hard-coded 8, >>>>>>> whether using a Text node directly or a TextFlow. >>>>>>> >>>>>>> Two observations of what one might call limitations >>>>>>> 1) This is a rendering time property, which is controlled by the program. >>>>>>> A document containing tabs saved and re-rendered somewhere else >>>>>>> won't be helped. >>>>>>> >>>>>>> 2) This just provides API on the scene graph node types, not any of the UI controls >>>>>>> which use Text nodes. Something like a CSS property may be the way to go if >>>>>>> you wanted that. >>>>>>> Text has a nested class StyleableProperties for CSS properties with which it >>>>>>> plays nice : font, underline, strikethrough, text-alignment >>>>>>> >>>>>>> So creating an fx-tabWidth (or similar name) CSS property could be propagated >>>>>>> through to there in a similar way. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>>>>> Okay, current work relocated to a clone of the new official Git repo. >>>>>>>> My initial implementation is here: >>>>>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>>>>> >>>>>>>> I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? >>>>>>>> >>>>>>>> I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. >>>>>>>> >>>>>>>> Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: >>>>>>>>> >>>>>>>>> My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>>>>> >>>>>>>>> While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >>>>>>>>>> >>>>>>>>>> Thanks Kevin. >>>>>>>>>> >>>>>>>>>> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >>>>>>>>>> >>>>>>>>>> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Scott, >>>>>>>>>>> >>>>>>>>>>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>>>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>>>>>>>>>> >>>>>>>>>>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>>>>>>>>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>>>>>>>>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>>>>> >>>>>>>>>>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>>>>>>>>>> >>>>>>>>>>>> What?s the next step? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Scott From philip.race at oracle.com Thu Oct 17 19:39:12 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 12:39:12 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> <99C8989F-13AD-46D0-A004-735FFBBDBBC0@gmail.com> Message-ID: <1c664471-9682-231d-aa8b-3d93a3db9d12@oracle.com> On 10/17/19 12:32 PM, Kevin Rushforth wrote: > It seems that you have a path forward then. So, there are a couple > questions to answer: > > 1. Should the type of the property be int or double? If it really is > only ever going to be a number of spaces, then int seems fine. That, > along with the name of the property, would underscore the fact that > no, this isn't a size where units make sense; it's a number of spaces. A discrete number of spaces, so int. > > 2. Should the range be [1,MAXINT] or [1,16] or [1,something-else]? > Once that is decided, I think clamp on use would be the most > consistent with other similar properties, but that's worth checking. If we go with "MAXINT" (which is not my preference), I think there'd need to be some testing of the various code paths and pipelines to be sure that various values from large, through extreme, all do something sensible, and of course, no exceptions or crashes. Various code paths means Text, TextFlow,? linewrapping or not ... complex text and simple text too. Perhaps complex text should be tested anyway, although I've been assuming that we are handling tab spacing outside of that but didn't verify it. -phil. > > -- Kevin > > > On 10/17/2019 12:11 PM, Scott Palmer wrote: >> You?re right.? Something I was reading indicated that while there was >> no default unit, ?px? was implicitly appended.? I can?t find that >> now. Go figure. >> >> Everything I find now about CSS tab-size is in agreement with what >> David wrote.? It?s a number of spaces.? With units it would be a >> ?length? but nothing supports that. >> >> So I think it makes sense to add -fx-tab-size as a CSS property, only >> supporting a number with no units. >> >> Scott >> >> >>> On Oct 17, 2019, at 2:32 PM, Phil Race wrote: >>> >>> Really ? It defaults to pixels ? Is that just inherited as being the >>> default CSS unit ? >>> Is that FX's implementation >>> >>> Hmm. A bit of reading about web CSS says that strictly anything >>> without an explicit unit should be ignored. >>> The only exception is zero, where it doesn't matter. >>> >>> Eg see : >>> https://stackoverflow.com/questions/7907749/default-unit-for-font-size >>> >>> Although I am sure there are more authoratative? sources than that. >>> >>> -phil. >>> >>> On 10/17/19 11:22 AM, Scott Palmer wrote: >>>> So do we go ahead and implement tabSize without the CSS support??? >>>> I?m not sure the CSS property should be added before unit issues >>>> are worked out, as I think the units would be expected in the CSS >>>> context. E.g. CSS implicitly adds ?px? if no unit is specified.? If >>>> our tabSize units are spaces, that breaks. >>>> >>>> Scott >>>> >>>>> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth >>>>> wrote: >>>>> >>>>> It might make sense to just add the tabSize property now, and >>>>> later consider adding a tabUnits property in the future if needed. >>>>> By default, having the units be "number of spaces in the current >>>>> font" is what makes the most sense, so before we could add >>>>> tabUnits we would need to extend it as you suggest. I'm not sure >>>>> it's needed, though, so that would be another reason not to do it >>>>> now. >>>>> >>>>> It's probably best to have the type of tabSize be double rather >>>>> than int. We do this for most attributes to leave the door open >>>>> for fractional values. I don't know why anyone would want a tab >>>>> that was 5.7 spaces, but if we ever were to add a tabUnits >>>>> property, I could easily see wanting fractional values for some >>>>> units. >>>>> >>>>> -- Kevin >>>>> >>>>> On 10/17/2019 10:40 AM, Scott Palmer wrote: >>>>>> Hi Phil, >>>>>> >>>>>> Thanks for taking a look.? I was going to get back to this soon >>>>>> to attempt adding the CSS property as you mention in your >>>>>> previous email.? I considered tabSize as a name as well.? I don?t >>>>>> have a preference if we leave things as representing tabs as a >>>>>> number of spaces.? But it wouldn?t be too difficult to support >>>>>> units, making it mostly compatible with CSS rules.? The way I >>>>>> envision that is having two properties, tabSize and tabUnit. >>>>>> >>>>>> David mentioned javafx.css.SizeUnits? I looked quickly at the >>>>>> java docs for it, and it?s basically undocumented .? So I went to >>>>>> https://www.w3.org/TR/css-values-3/#lengths and I see there is no >>>>>> CSS unit like ?ems? but meaning the width of a space in the >>>>>> current font.? The problem with that is it would leave out the >>>>>> possibility to set the tab width to anything relative to the >>>>>> current implementation of 8 spaces. (In hindsight it should have >>>>>> been implemented based on ?ems?, which for a fixed width font as >>>>>> typically used in a code editor would be the same as 8 spaces >>>>>> anyway) >>>>>> Do we add something to SizeUnits so we can work around this?? >>>>>> e.g. ?fxsp?? (FX-space - fx prefix to avoid a potential collision >>>>>> with any future official CSS units) >>>>>> >>>>>> // Two tab-related properties >>>>>> public void setTabSize(int size); // defaults to 8 >>>>>> public void setTabUnits(SizeUnits units); // ?? no unit for width >>>>>> of space in current font >>>>>> >>>>>> If we did the above, I would consider adding this for convenience: >>>>>> public void setTabWidth(int size, TabUnits units); >>>>>> >>>>>> As far as setting a range, I?m not sure there is any worthwhile >>>>>> benefit to enforcing a maximum.? If we want to store the value in >>>>>> a short instead of an int to potentially save a couple bytes, >>>>>> sure.? Otherwise, if someone wants to set tabs to be 20 spaces or >>>>>> 100, why should we prevent it?? If there isn't a performance or >>>>>> memory impact, I wouldn?t enforce a maximum. >>>>>> >>>>>> Ignoring any out of range values rather than clamping seems fine >>>>>> to me as well.? I was thinking of what happens if the value was >>>>>> bound to another value that strayed out of range. Clamping would >>>>>> get you as close as possible to the bound value, rather than >>>>>> stuck at the previously observed value.? I just guessed that >>>>>> would be preferred, but if ignoring is more consistent with other >>>>>> values, then I agree it makes sense.? As long as the behaviour is >>>>>> documented, I can?t think of any significant downside either way. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>>> On Oct 17, 2019, at 12:45 PM, Phil Race >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Some more points which I thought about but for whatever reason >>>>>>> did not pen .. >>>>>>> >>>>>>> First one minor thing: tabWidth is an OK name, but it does not >>>>>>> conjure up that the value you specify isn't a width in pixels >>>>>>> but the >>>>>>> number of discrete space characters to use. FWIW CSS calls it >>>>>>> tab-size. >>>>>>> But CSS then supports pixels and ems .. that complicates matters >>>>>>> a lot. >>>>>>> >>>>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size >>>>>>> >>>>>>> Thee rest is mostly to do with "legal or sensible values" >>>>>>> >>>>>>> You have : >>>>>>> ???????? if (spaces < 0) >>>>>>> ???????????? spaces = 0; >>>>>>> >>>>>>> since negative values are not something we want to support! >>>>>>> But I think instead of clamping you could "ignore", any out of >>>>>>> range value. >>>>>>> This is practiced elsewhere in FX where illegal values are >>>>>>> ignored rather than >>>>>>> throwing an exception, although it might be that clamping is >>>>>>> quite common >>>>>>> in range cases. >>>>>>> >>>>>>> The follow on to that is that what is a sensible maximum value. >>>>>>> Currently we have int which is more than we need. For that >>>>>>> matter so is short. >>>>>>> I think we should have a documented and enforced sensible maximum. >>>>>>> Perhaps it could be "8" meaning we only support reducing tab >>>>>>> width as I >>>>>>> don't know if anyone really wants to increase it. >>>>>>> CSS doesn't have a limit that I can see but if we are already >>>>>>> only supporting >>>>>>> it described as number of spaces, we can have this other >>>>>>> limitation too. >>>>>>> If you think 8 is too small, then maybe 16 ? >>>>>>> Also remember we can compatibly relax it later but we can't >>>>>>> compatibly tighten it. >>>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 10/15/19 12:17 PM, Phil Race wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've looked over this and I don't see any issues - meaning >>>>>>>> gotchas. >>>>>>>> It just provides a way to over-ride the hard-coded 8, >>>>>>>> whether using a Text node directly or a TextFlow. >>>>>>>> >>>>>>>> Two observations of what one might call limitations >>>>>>>> 1) This is a rendering time property, which is controlled by >>>>>>>> the program. >>>>>>>> A document containing tabs saved and re-rendered somewhere else >>>>>>>> won't be helped. >>>>>>>> >>>>>>>> 2) This just provides API on the scene graph node types, not >>>>>>>> any of the UI controls >>>>>>>> which use Text nodes. Something like a CSS property may be the >>>>>>>> way to go if >>>>>>>> you wanted that. >>>>>>>> Text has a nested class StyleableProperties for CSS properties >>>>>>>> with which it >>>>>>>> plays nice : font, underline, strikethrough, text-alignment >>>>>>>> >>>>>>>> So creating an fx-tabWidth (or similar name) CSS property could >>>>>>>> be propagated >>>>>>>> through to there in a similar way. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: >>>>>>>>> Okay, current work relocated to a clone of the new official >>>>>>>>> Git repo. >>>>>>>>> My initial implementation is here: >>>>>>>>> https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I would submit it as a pull request but that seems premature >>>>>>>>> since there hasn?t been any real discussion of challenges I?ve >>>>>>>>> overlooked.? All I have are the famous last words, ?It works >>>>>>>>> for me.? >>>>>>>>> >>>>>>>>> I saw in the archives a concern about tab width vs tab stops. >>>>>>>>> For some reason I didn?t get the email.? Anyway, I don?t think >>>>>>>>> arbitrary tab stop positions, at different intervals that is, >>>>>>>>> are what was asked for.? That certainly would require a >>>>>>>>> significantly different implementation. >>>>>>>>> >>>>>>>>> Would love to keep some momentum going on this before I become >>>>>>>>> busy with other things and won?t have time for it. >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> My current work is here >>>>>>>>>> https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> While writing a unit test I realized that the StubToolkit >>>>>>>>>> isn?t really running the Prism layout code, so I?m not sure >>>>>>>>>> how that gets tested.? I made it work with StubTextLayout for >>>>>>>>>> now. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Thanks Kevin. >>>>>>>>>>> >>>>>>>>>>> My current implementation appears to be working for TextFlow >>>>>>>>>>> and Text, with the TextFlow overriding the tabWidth of the >>>>>>>>>>> child Text nodes.? This seems to work out naturally from the >>>>>>>>>>> way TextFlow overrides the TextLayout instance used by the >>>>>>>>>>> Text node. >>>>>>>>>>> >>>>>>>>>>> If there are tricky corner-cases that I?m missing, I guess >>>>>>>>>>> figuring out all the cases it will need to handle is part of >>>>>>>>>>> this discussion.? It didn?t seem to be that challenging so >>>>>>>>>>> far, so perhaps I am missing something (hopefully not).? I >>>>>>>>>>> wrote a small test app to visually see that things were >>>>>>>>>>> working as I expected.? I have not yet written the unit tests. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Scott >>>>>>>>>>> >>>>>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Scott, >>>>>>>>>>>> >>>>>>>>>>>> I'm sure Phil will have more comments on this. While the >>>>>>>>>>>> API seems simple enough on the surface, I suspect that this >>>>>>>>>>>> will be a challenging feature to implement correctly for >>>>>>>>>>>> all of the cases it will need to handle. It would need >>>>>>>>>>>> careful review and testing as well. My only comment on the >>>>>>>>>>>> API itself is that if we do accept this feature, it should >>>>>>>>>>>> probably go on both Text and TextFlow, and be one of the >>>>>>>>>>>> attributes of Text that is ignored / overridden when a Text >>>>>>>>>>>> node is in a TextFlow. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>>>>>>>>>> I would like to implement this feature, being able to >>>>>>>>>>>>> adjust the tab size in a TextFlow or Text node >>>>>>>>>>>>> (JDK-8130738 >>>>>>>>>>>>> >>>>>>>>>>>> >). It >>>>>>>>>>>>> involves new public API, so I want to start a discussion >>>>>>>>>>>>> about it here.? (My motivation is that RichTextFX suggests >>>>>>>>>>>>> an entirely unacceptable workaround of substituting actual >>>>>>>>>>>>> spaces when the tab character is typed and cites the lack >>>>>>>>>>>>> of this API.) >>>>>>>>>>>>> >>>>>>>>>>>>> I?ve already jumped the gun and taken a crack at an >>>>>>>>>>>>> implementation.? It is currently incomplete as I was just >>>>>>>>>>>>> poking around to see if it was going to be easy enough to >>>>>>>>>>>>> not take up too much of my time.? It boils down to: >>>>>>>>>>>>> TextFlow and Text get a new property for tab width, an >>>>>>>>>>>>> integer representing the number of spaces taken by a tab. >>>>>>>>>>>>> (The value is only used to initialize the tab width for >>>>>>>>>>>>> the TextLayout when needed.) >>>>>>>>>>>>> TextLayout interface gets a new method: boolean >>>>>>>>>>>>> setTabWidth(int spaces) >>>>>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>>>>>>>>>> PrismTextLayout implements the new setTabWidth API. >>>>>>>>>>>>> >>>>>>>>>>>>> I?m not sure that the Text node needs this new property.? >>>>>>>>>>>>> I figured it would be rarely used on that class, so I had >>>>>>>>>>>>> implemented it via an added property in the private >>>>>>>>>>>>> TextAttributes class.? Maybe it isn?t needed at all. >>>>>>>>>>>>> >>>>>>>>>>>>> What?s the next step? >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Scott > From pedro.duquevieira at gmail.com Thu Oct 17 21:29:35 2019 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 17 Oct 2019 22:29:35 +0100 Subject: JDK-8130738 TextFlow's tab width is static Message-ID: Hi, Kevin asked for developers opinions on this issue, just thought I'd leave my own. Didn't have time to read the thread thoroughly enough, don't have much time at the moment to do it. Apologies for that. Just wanted to make a comment about the CSS support for this feature. I think if you add it, it would be great if it follows the CSS web spec or at least it doesn't go against it. I think there's a lot of value if we start more and more following the web css spec, it would mean a web designer could eventually transfer his skills directly to javafx or that we could use tools used in the web or that we could simply copy paste a CSS web example into JavaFX and it would just work (though we're still a bit far from that but could be a possibility in the future). There are a good deal of big companies already involved in developing web css, I'm sure they've put a lot of thought into it (not speaking of the early days of CSS which was very bad). Thanks, -- Pedro Duque Vieira - https://www.pixelduke.com From swpalmer at gmail.com Thu Oct 17 21:46:45 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 17 Oct 2019 17:46:45 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: Message-ID: I think what we?ve settled on fits CSS for the web. I agree we shouldn?t deviate from that if possible. Scott > On Oct 17, 2019, at 5:30 PM, Pedro Duque Vieira wrote: > > ?Hi, > > Kevin asked for developers opinions on this issue, just thought I'd leave > my own. > > Didn't have time to read the thread thoroughly enough, don't have much time > at the moment to do it. Apologies for that. > > Just wanted to make a comment about the CSS support for this feature. I > think if you add it, it would be great if it follows the CSS web spec or at > least it doesn't go against it. > I think there's a lot of value if we start more and more following the web > css spec, it would mean a web designer could eventually transfer his skills > directly to javafx or that we could use tools used in the web or that we > could simply copy paste a CSS web example into JavaFX and it would just > work (though we're still a bit far from that but could be a possibility in > the future). > > There are a good deal of big companies already involved in developing web > css, I'm sure they've put a lot of thought into it (not speaking of the > early days of CSS which was very bad). > > Thanks, > > -- > Pedro Duque Vieira - https://www.pixelduke.com From mvfranz at gmail.com Fri Oct 18 00:41:14 2019 From: mvfranz at gmail.com (Michael Franz) Date: Thu, 17 Oct 2019 20:41:14 -0400 Subject: Building OpenJFX on clean install of CentOS 7 In-Reply-To: References: Message-ID: Kevin, I updated my gcc to 8.2.0 using the steps here https://medium.com/@bipul.k.kuri/install-latest-gcc-on-centos-linux-release-7-6-a704a11d943d and was able to successfully build and run all the tests. thank you for the specific version, I will probably do the same exercise on CentOS 8 Michael On Thu, Oct 17, 2019 at 9:00 AM Kevin Rushforth wrote: > The current toolchain for building JavaFX is gcc 8.2. As long as you > don't build WebKit, it will still build with gcc 5.4. > > I just tried it on an Oracle Linux 7 machine with gcc 4.9.1 (which is > what we used to use a couple years ago), and the build fails for me with > the same error. Looks like you will need a newer gcc. > > -- Kevin > > > On 10/16/2019 8:47 PM, Michael Franz wrote: > > Hi, > > > > I did a clean install of CentOS 7, updated, added the necessary tools and > > then cloned the repo and ran the default build. I get the following > errors: > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:598:1: > > error: unused parameter ?event? [-Werror=unused-parameter] > > glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window, > > GdkCursor *cursor) { > > ^ > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:628:1: > > error: unused parameter ?event? [-Werror=unused-parameter] > > glass_gdk_master_pointer_ungrab(GdkEvent *event) { > > ^ > > cc1plus: all warnings being treated as errors > > > >> Task :graphics:ccLinuxGlassGlassgtk2 FAILED > > Is this expected? I have not found any documentation specifing the > minimum > > version of gcc/g++ and wonder if I need to upgrade? I am using g++ (GCC) > > 4.8.5 20150623 (Red Hat 4.8.5-39). Also, other native code in the build > > are treating the unused-parameter as a warning. Why is this module > > different? > > > /home/test00/Source/jfx/modules/javafx.graphics/src/main/native-font/pango.c:429:26: > > warning: unused parameter ?that? [-Wunused-parameter] > > (JNIEnv *env, jclass that, jlong arg0) > > > > > > Here are the detailed steps I followed: > > 0. sudo yum update > > 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel > > pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant > gcc-c++ > > libstdc++-static > > 2. sudo alternatives --config java > > - specify Java 11 > > 3. git clone https://github.com/openjdk/jfx.git > > 4. cd jfx > > 5. bash ./gradelw > > > > Any suggestions is appreciated. > > > > Michael > > From r.lichtenberger at gmail.com Fri Oct 18 06:02:12 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Fri, 18 Oct 2019 08:02:12 +0200 Subject: Using gradle mit JDK-13 Message-ID: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> In trying to provide a fix for JDK-8232524 I have begun to setup a build for JavaFX. According to [1] using JDK-13 is recommended. However, gradle is not yet ready to run on JDK-13 ([2]): [rli at rlinux jfx]$ ./gradlew clean FAILURE: Build failed with an exception. * Where: Build file '/home/rli/PWEs/jfx/buildSrc/build.gradle' * What went wrong: Could not compile build file '/home/rli/PWEs/jfx/buildSrc/build.gradle'. > startup failed: ? General error during semantic analysis: Unsupported class file major version 57 I'll now continue on JDK-12 (just like I have to in my day job) but is there any general advice on how to proceed with JDK-13? Best regards, Robert [1]https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux [2] https://github.com/gradle/gradle/issues/8681 From nlisker at gmail.com Fri Oct 18 11:56:12 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 Oct 2019 14:56:12 +0300 Subject: Using gradle mit JDK-13 In-Reply-To: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> References: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> Message-ID: Sorry, that was my mistake when I updated that page for Skara. We usually list JDK N and N-1 as compatible for JFX N and I missed that Gradle is not there yet for 13. Use JDK 12 for now. - Nir On Fri, Oct 18, 2019, 09:02 Robert Lichtenberger wrote: > In trying to provide a fix for JDK-8232524 I have begun to setup a build > for JavaFX. > > According to [1] using JDK-13 is recommended. However, gradle is not yet > ready to run on JDK-13 ([2]): > > [rli at rlinux jfx]$ ./gradlew clean > > FAILURE: Build failed with an exception. > > * Where: > > Build file '/home/rli/PWEs/jfx/buildSrc/build.gradle' > > * What went wrong: > > Could not compile build file '/home/rli/PWEs/jfx/buildSrc/build.gradle'. > > > startup failed: > > General error during semantic analysis: Unsupported class file major > version 57 > > I'll now continue on JDK-12 (just like I have to in my day job) but is > there any general advice on how to proceed with JDK-13? > > Best regards, > > Robert > > > [1] > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux > > [2] https://github.com/gradle/gradle/issues/8681 > > From johan.vos at gluonhq.com Fri Oct 18 12:54:25 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 18 Oct 2019 14:54:25 +0200 Subject: RFR: 8232597: release notes 13.0.1 Message-ID: Hi Kevin, Please review http://cr.openjdk.java.net/~jvos/8232597/webrev.01/ which fixes https://bugs.openjdk.java.net/browse/JDK-8232597 Thanks, - Johan From kevin.rushforth at oracle.com Fri Oct 18 12:57:17 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 Oct 2019 05:57:17 -0700 Subject: Using gradle mit JDK-13 In-Reply-To: References: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> Message-ID: <94489d7e-88fb-b6c5-9eb5-23df51a2e7ea@oracle.com> Correct. will need to upgrade to gradle 6 to support building with JDK 13. See JDK-8232063 [1] and JDK-8232064 [2]. The gradle team indicates that they plan to ship gradle 6 on November 1 [3]. By way of information, the current toolchain versions used by the JavaFX build are recorded in build.properties [4]. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8232063 [2] https://bugs.openjdk.java.net/browse/JDK-8232064 [3] https://github.com/gradle/gradle/milestones [4] https://github.com/openjdk/jfx/blob/master/build.properties#L75 On 10/18/2019 4:56 AM, Nir Lisker wrote: > Sorry, that was my mistake when I updated that page for Skara. We usually > list JDK N and N-1 as compatible for JFX N and I missed that Gradle is not > there yet for 13. > Use JDK 12 for now. > > - Nir > > On Fri, Oct 18, 2019, 09:02 Robert Lichtenberger > wrote: > >> In trying to provide a fix for JDK-8232524 I have begun to setup a build >> for JavaFX. >> >> According to [1] using JDK-13 is recommended. However, gradle is not yet >> ready to run on JDK-13 ([2]): >> >> [rli at rlinux jfx]$ ./gradlew clean >> >> FAILURE: Build failed with an exception. >> >> * Where: >> >> Build file '/home/rli/PWEs/jfx/buildSrc/build.gradle' >> >> * What went wrong: >> >> Could not compile build file '/home/rli/PWEs/jfx/buildSrc/build.gradle'. >> >>> startup failed: >> General error during semantic analysis: Unsupported class file major >> version 57 >> >> I'll now continue on JDK-12 (just like I have to in my day job) but is >> there any general advice on how to proceed with JDK-13? >> >> Best regards, >> >> Robert >> >> >> [1] >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux >> >> [2] https://github.com/gradle/gradle/issues/8681 >> >> From kevin.rushforth at oracle.com Fri Oct 18 13:00:52 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 Oct 2019 06:00:52 -0700 Subject: RFR: 8232597: release notes 13.0.1 In-Reply-To: References: Message-ID: <28bfa613-cbeb-29e4-ac93-0116bd78fa2c@oracle.com> +1 On 10/18/2019 5:54 AM, Johan Vos wrote: > Hi Kevin, > > Please review > http://cr.openjdk.java.net/~jvos/8232597/webrev.01/ > which fixes > https://bugs.openjdk.java.net/browse/JDK-8232597 > > Thanks, > > - Johan From nlisker at gmail.com Fri Oct 18 13:16:22 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 Oct 2019 16:16:22 +0300 Subject: Using gradle mit JDK-13 In-Reply-To: <94489d7e-88fb-b6c5-9eb5-23df51a2e7ea@oracle.com> References: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> <94489d7e-88fb-b6c5-9eb5-23df51a2e7ea@oracle.com> Message-ID: > > By way of information, the current toolchain versions used by the JavaFX > build are recorded in build.properties [4]. I referenced this file for the minimum and current Gradle versions in the Gradle section of the build instructions [1] to avoid needing to update the wiki page manually every time the version changes. I now corrected the page to say that Java 13 support is pending Gradle 6. Thanks Robert. - Nir [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle On Fri, Oct 18, 2019 at 3:57 PM Kevin Rushforth wrote: > Correct. will need to upgrade to gradle 6 to support building with JDK > 13. See JDK-8232063 [1] and JDK-8232064 [2]. The gradle team indicates > that they plan to ship gradle 6 on November 1 [3]. > > By way of information, the current toolchain versions used by the JavaFX > build are recorded in build.properties [4]. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8232063 > [2] https://bugs.openjdk.java.net/browse/JDK-8232064 > [3] https://github.com/gradle/gradle/milestones > [4] https://github.com/openjdk/jfx/blob/master/build.properties#L75 > > > On 10/18/2019 4:56 AM, Nir Lisker wrote: > > Sorry, that was my mistake when I updated that page for Skara. We usually > > list JDK N and N-1 as compatible for JFX N and I missed that Gradle is > not > > there yet for 13. > > Use JDK 12 for now. > > > > - Nir > > > > On Fri, Oct 18, 2019, 09:02 Robert Lichtenberger < > r.lichtenberger at gmail.com> > > wrote: > > > >> In trying to provide a fix for JDK-8232524 I have begun to setup a build > >> for JavaFX. > >> > >> According to [1] using JDK-13 is recommended. However, gradle is not yet > >> ready to run on JDK-13 ([2]): > >> > >> [rli at rlinux jfx]$ ./gradlew clean > >> > >> FAILURE: Build failed with an exception. > >> > >> * Where: > >> > >> Build file '/home/rli/PWEs/jfx/buildSrc/build.gradle' > >> > >> * What went wrong: > >> > >> Could not compile build file '/home/rli/PWEs/jfx/buildSrc/build.gradle'. > >> > >>> startup failed: > >> General error during semantic analysis: Unsupported class file major > >> version 57 > >> > >> I'll now continue on JDK-12 (just like I have to in my day job) but is > >> there any general advice on how to proceed with JDK-13? > >> > >> Best regards, > >> > >> Robert > >> > >> > >> [1] > >> > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux > >> > >> [2] https://github.com/gradle/gradle/issues/8681 > >> > >> > > From nlisker at gmail.com Fri Oct 18 13:23:09 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 Oct 2019 16:23:09 +0300 Subject: Using gradle mit JDK-13 In-Reply-To: References: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> <94489d7e-88fb-b6c5-9eb5-23df51a2e7ea@oracle.com> Message-ID: By the way, Gradle 6.0 RC1 is due today. It could be beneficial to test the build with it prior to the release of 6.0. On Fri, Oct 18, 2019 at 4:16 PM Nir Lisker wrote: > By way of information, the current toolchain versions used by the JavaFX >> build are recorded in build.properties [4]. > > > I referenced this file for the minimum and current Gradle versions in the > Gradle section of the build instructions [1] to avoid needing to update the > wiki page manually every time the version changes. > > I now corrected the page to say that Java 13 support is pending Gradle 6. > Thanks Robert. > > - Nir > > [1] > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > > On Fri, Oct 18, 2019 at 3:57 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Correct. will need to upgrade to gradle 6 to support building with JDK >> 13. See JDK-8232063 [1] and JDK-8232064 [2]. The gradle team indicates >> that they plan to ship gradle 6 on November 1 [3]. >> >> By way of information, the current toolchain versions used by the JavaFX >> build are recorded in build.properties [4]. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232063 >> [2] https://bugs.openjdk.java.net/browse/JDK-8232064 >> [3] https://github.com/gradle/gradle/milestones >> [4] https://github.com/openjdk/jfx/blob/master/build.properties#L75 >> >> >> On 10/18/2019 4:56 AM, Nir Lisker wrote: >> > Sorry, that was my mistake when I updated that page for Skara. We >> usually >> > list JDK N and N-1 as compatible for JFX N and I missed that Gradle is >> not >> > there yet for 13. >> > Use JDK 12 for now. >> > >> > - Nir >> > >> > On Fri, Oct 18, 2019, 09:02 Robert Lichtenberger < >> r.lichtenberger at gmail.com> >> > wrote: >> > >> >> In trying to provide a fix for JDK-8232524 I have begun to setup a >> build >> >> for JavaFX. >> >> >> >> According to [1] using JDK-13 is recommended. However, gradle is not >> yet >> >> ready to run on JDK-13 ([2]): >> >> >> >> [rli at rlinux jfx]$ ./gradlew clean >> >> >> >> FAILURE: Build failed with an exception. >> >> >> >> * Where: >> >> >> >> Build file '/home/rli/PWEs/jfx/buildSrc/build.gradle' >> >> >> >> * What went wrong: >> >> >> >> Could not compile build file >> '/home/rli/PWEs/jfx/buildSrc/build.gradle'. >> >> >> >>> startup failed: >> >> General error during semantic analysis: Unsupported class file major >> >> version 57 >> >> >> >> I'll now continue on JDK-12 (just like I have to in my day job) but is >> >> there any general advice on how to proceed with JDK-13? >> >> >> >> Best regards, >> >> >> >> Robert >> >> >> >> >> >> [1] >> >> >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux >> >> >> >> [2] https://github.com/gradle/gradle/issues/8681 >> >> >> >> >> >> From kevin.rushforth at oracle.com Fri Oct 18 14:43:19 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 Oct 2019 07:43:19 -0700 Subject: Using gradle mit JDK-13 In-Reply-To: References: <95d107fd-78aa-878e-f14c-000ae65156fc@gmail.com> <94489d7e-88fb-b6c5-9eb5-23df51a2e7ea@oracle.com> Message-ID: <594f38dd-b1d2-3912-c347-bd201b3e2cfe@oracle.com> Yes, it says that it's due today, but it originally said it was due last week, and they've been slipping it day for day. I did a fair bit of testing with a recent gradle 6.0 nightly build while working on https://bugs.openjdk.java.net/browse/JDK-8226754 so I don't anticipate any problems. -- Kevin On 10/18/2019 6:23 AM, Nir Lisker wrote: > By the way, Gradle 6.0 RC1 is due today. It could be beneficial to > test the build with it prior to the release of 6.0. > > On Fri, Oct 18, 2019 at 4:16 PM Nir Lisker > wrote: > > By way of information, the current toolchain versions used by > the JavaFX > build are recorded in build.properties [4]. > > I referenced this file for the minimum and current Gradle versions > in the Gradle section of the build instructions [1] to avoid > needing to update the wiki page manually every time the version > changes. > > I now corrected the page to say that Java 13 support is pending > Gradle 6. Thanks Robert. > > - Nir > > [1] > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > > On Fri, Oct 18, 2019 at 3:57 PM Kevin Rushforth > > > wrote: > > Correct. will need to upgrade to gradle 6 to support building > with JDK > 13. See JDK-8232063 [1] and JDK-8232064 [2]. The gradle team > indicates > that they plan to ship gradle 6 on November 1 [3]. > > By way of information, the current toolchain versions used by > the JavaFX > build are recorded in build.properties [4]. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8232063 > [2] https://bugs.openjdk.java.net/browse/JDK-8232064 > [3] https://github.com/gradle/gradle/milestones > [4] > https://github.com/openjdk/jfx/blob/master/build.properties#L75 > > > On 10/18/2019 4:56 AM, Nir Lisker wrote: > > Sorry, that was my mistake when I updated that page for > Skara. We usually > > list JDK N and N-1 as compatible for JFX N and I missed that > Gradle is not > > there yet for 13. > > Use JDK 12 for now. > > > > - Nir > > > > On Fri, Oct 18, 2019, 09:02 Robert Lichtenberger > > > > wrote: > > > >> In trying to provide a fix for JDK-8232524 I have begun to > setup a build > >> for JavaFX. > >> > >> According to [1] using JDK-13 is recommended. However, > gradle is not yet > >> ready to run on JDK-13 ([2]): > >> > >> [rli at rlinux jfx]$ ./gradlew clean > >> > >> FAILURE: Build failed with an exception. > >> > >> * Where: > >> > >> Build file '/home/rli/PWEs/jfx/buildSrc/build.gradle' > >> > >> * What went wrong: > >> > >> Could not compile build file > '/home/rli/PWEs/jfx/buildSrc/build.gradle'. > >> > >>> startup failed: > >>? ? General error during semantic analysis: Unsupported > class file major > >> version 57 > >> > >> I'll now continue on JDK-12 (just like I have to in my day > job) but is > >> there any general advice on how to proceed with JDK-13? > >> > >> Best regards, > >> > >> Robert > >> > >> > >> [1] > >> > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux > >> > >> [2] https://github.com/gradle/gradle/issues/8681 > >> > >> > From kcr at openjdk.org Sat Oct 19 15:04:27 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 19 Oct 2019 15:04:27 GMT Subject: RFR: 8232522: FX: Update copyright year in docs, readme files to 2020 Message-ID: As indicated in the JBS bug, this makes the needed change for releasing in 2020. ---------------- Commits: - 85c03ad9: 8232522: FX: Update copyright year in docs, readme files to 2020 Changes: https://git.openjdk.java.net/jfx/pull/18/files Webrev: https://webrevs.openjdk.java.net/jfx/18/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232522 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/18/head:pull/18 PR: https://git.openjdk.java.net/jfx/pull/18 From kcr at openjdk.org Sat Oct 19 15:04:29 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 19 Oct 2019 15:04:29 GMT Subject: RFR: 8232522: FX: Update copyright year in docs, readme files to 2020 In-Reply-To: References: Message-ID: On Sat, 19 Oct 2019 15:04:27 GMT, Kevin Rushforth wrote: > As indicated in the JBS bug, this makes the needed change for releasing in 2020. > > ---------------- > > Commits: > - 85c03ad9: 8232522: FX: Update copyright year in docs, readme files to 2020 > > Changes: https://git.openjdk.java.net/jfx/pull/18/files > Webrev: https://webrevs.openjdk.java.net/jfx/18/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232522 > Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/18.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/18/head:pull/18 Reviewer: @arapte PR: https://git.openjdk.java.net/jfx/pull/18 From swpalmer at gmail.com Sat Oct 19 15:50:36 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 19 Oct 2019 11:50:36 -0400 Subject: OpenJFX.io points to old repo Message-ID: The Let's do it! " link at https://openjfx.io still points to https://github.com/javafxports/openjdk-jfx instead of https://github.com/openjdk/jfx Scott From mvfranz at gmail.com Sat Oct 19 16:07:03 2019 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 19 Oct 2019 12:07:03 -0400 Subject: Building OpenJFX on clean install of CentOS 8 Message-ID: Hi, Just to report that I was able to get OpenJFX development setup on CentOS 8 using the following steps: 0. sudo yum update 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant gcc-c++ 2. sudo yum install epel-release 3. sudo yum config-manager --set-enabled PowerTools 4. sudo yum update 5. sudo yum install libstdc++-static 6. sudo alternatives --config java - specify Java 11 There are more steps than CentOS 7, however CentOS 8 has gcc 8.2.1 so there is not need to manually install. Now that my two development platforms are setup, I hope to start contributing. Michael From nlisker at gmail.com Sat Oct 19 16:11:02 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 19 Oct 2019 19:11:02 +0300 Subject: Building OpenJFX on clean install of CentOS 8 In-Reply-To: References: Message-ID: Thanks Michael. Kevin, if these are approved I can add them to the build instructions page. - Nir On Sat, Oct 19, 2019 at 7:07 PM Michael Franz wrote: > Hi, > > Just to report that I was able to get OpenJFX development setup on CentOS 8 > using the following steps: > 0. sudo yum update > 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel > pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant gcc-c++ > 2. sudo yum install epel-release > 3. sudo yum config-manager --set-enabled PowerTools > 4. sudo yum update > 5. sudo yum install libstdc++-static > 6. sudo alternatives --config java > - specify Java 11 > > There are more steps than CentOS 7, however CentOS 8 has gcc 8.2.1 so there > is not need to manually install. > > Now that my two development platforms are setup, I hope to start > contributing. > > Michael > From kevin.rushforth at oracle.com Sat Oct 19 16:26:24 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 19 Oct 2019 09:26:24 -0700 Subject: Building OpenJFX on clean install of CentOS 8 In-Reply-To: References: Message-ID: <43f382b6-6d49-4ab4-e233-ee0f906ac263@oracle.com> This looks fine to me. A couple of them might not be needed (PowerTools? epel-release? libXtst-devel? (although that probably pulls in the needed libX11 developer package)), but it seems a good list. -- Kevin On 10/19/2019 9:11 AM, Nir Lisker wrote: > Thanks Michael. > > Kevin, if these are approved I can add them to the build instructions page. > > - Nir > > On Sat, Oct 19, 2019 at 7:07 PM Michael Franz wrote: > >> Hi, >> >> Just to report that I was able to get OpenJFX development setup on CentOS 8 >> using the following steps: >> 0. sudo yum update >> 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel >> pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant gcc-c++ >> 2. sudo yum install epel-release >> 3. sudo yum config-manager --set-enabled PowerTools >> 4. sudo yum update >> 5. sudo yum install libstdc++-static >> 6. sudo alternatives --config java >> - specify Java 11 >> >> There are more steps than CentOS 7, however CentOS 8 has gcc 8.2.1 so there >> is not need to manually install. >> >> Now that my two development platforms are setup, I hope to start >> contributing. >> >> Michael >> From nlisker at gmail.com Sat Oct 19 16:38:02 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 19 Oct 2019 19:38:02 +0300 Subject: Building OpenJFX on clean install of CentOS 8 In-Reply-To: <43f382b6-6d49-4ab4-e233-ee0f906ac263@oracle.com> References: <43f382b6-6d49-4ab4-e233-ee0f906ac263@oracle.com> Message-ID: Added at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-CentOS8 On Sat, Oct 19, 2019 at 7:28 PM Kevin Rushforth wrote: > This looks fine to me. A couple of them might not be needed (PowerTools? > epel-release? libXtst-devel? (although that probably pulls in the needed > libX11 developer package)), but it seems a good list. > > -- Kevin > > > On 10/19/2019 9:11 AM, Nir Lisker wrote: > > Thanks Michael. > > > > Kevin, if these are approved I can add them to the build instructions > page. > > > > - Nir > > > > On Sat, Oct 19, 2019 at 7:07 PM Michael Franz wrote: > > > >> Hi, > >> > >> Just to report that I was able to get OpenJFX development setup on > CentOS 8 > >> using the following steps: > >> 0. sudo yum update > >> 1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel > >> pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant > gcc-c++ > >> 2. sudo yum install epel-release > >> 3. sudo yum config-manager --set-enabled PowerTools > >> 4. sudo yum update > >> 5. sudo yum install libstdc++-static > >> 6. sudo alternatives --config java > >> - specify Java 11 > >> > >> There are more steps than CentOS 7, however CentOS 8 has gcc 8.2.1 so > there > >> is not need to manually install. > >> > >> Now that my two development platforms are setup, I hope to start > >> contributing. > >> > >> Michael > >> > > From joeri at lodgon.com Mon Oct 21 08:39:41 2019 From: joeri at lodgon.com (Joeri Sykora) Date: Mon, 21 Oct 2019 10:39:41 +0200 Subject: OpenJFX.io points to old repo In-Reply-To: References: Message-ID: Hi Scott, thanks for reporting this. The link you mentioned and the link to the release notes have both been updated to point to the new repository. Kind regards, Joeri Op za 19 okt. 2019 om 17:55 schreef Scott Palmer : > The Let's do it! " link at > https://openjfx.io still points to > https://github.com/javafxports/openjdk-jfx instead of > https://github.com/openjdk/jfx > > Scott > From jvos at openjdk.org Mon Oct 21 10:03:24 2019 From: jvos at openjdk.org (Johan Vos) Date: Mon, 21 Oct 2019 10:03:24 GMT Subject: RFR: 8232687: No static JNI loader for libprism-sw Message-ID: This PR adds a JNI_OnLoad_prism_sw call to the static lib libprism_sw.a. This approach is similar to the addition of e.g. JNI_OnLoad_prism_es2 that has been done as part of https://bugs.openjdk.java.net/browse/JDK-8223760 Unless -PSTATIC_BUILD is provided when building, this patch has no impact. ---------------- Commits: - 6f31ee6b: Add JNI_OnLoad_prism_sw call to make prism-sw work with static libs Changes: https://git.openjdk.java.net/jfx/pull/19/files Webrev: https://webrevs.openjdk.java.net/jfx/19/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232687 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/19/head:pull/19 PR: https://git.openjdk.java.net/jfx/pull/19 From johan.vos at gluonhq.com Mon Oct 21 10:16:48 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 21 Oct 2019 12:16:48 +0200 Subject: Request for permission to backport fixes to jfx-11 Message-ID: Hi Kevin, I request permission to backport the following issues to the jfx-11 repository. All patches apply clean or with minor changes (e.g. build.properties must keep jfx.release.major.version to 11) Thanks, - Johan https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 on Linux https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to Visual Studio 2017 version 15.9.6 https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to Xcode 10.1 https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the versions of tools used to build FX in the repo https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web build fails on XCode 10.2 https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite to version 3.28.0 https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to 608.1 version of WebKit https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick GTK WebKit 2.24.3 changes https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies are not enabled in WebKit v608.1 https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] PlatformFileHandle type should be JGObject rather than void * https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix assertion failure on X86 32-bit when enabling CLOOP based JavaScript interpreter https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket client doesn't work in WebView https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level Stage::initOwner can crash gnome-shell or X.org server https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage sometimes shown at top-left before moving to correct position https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop no longer works with GTK3 https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer does not play some mp3 with artwork stream in mjpeg https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected VirtualFlow methods for subclassing From rlichten at openjdk.org Mon Oct 21 10:19:04 2019 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Mon, 21 Oct 2019 10:19:04 GMT Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating Message-ID: By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes. I've create test cases that fail with the current way of synchronizing on a separate object. I've removed unused constructors. ---------------- Commits: - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating - 8ecf3545: JDK-8232524 fixed. Changes: https://git.openjdk.java.net/jfx/pull/17/files Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232524 Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17 PR: https://git.openjdk.java.net/jfx/pull/17 From kcr at openjdk.org Mon Oct 21 10:19:05 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 10:19:05 GMT Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating In-Reply-To: References: Message-ID: On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger wrote: > By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes. > > I've create test cases that fail with the current way of synchronizing on a separate object. > > I've removed unused constructors. > > ---------------- > > Commits: > - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating > - 8ecf3545: JDK-8232524 fixed. > > Changes: https://git.openjdk.java.net/jfx/pull/17/files > Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232524 > Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod > Patch: https://git.openjdk.java.net/jfx/pull/17.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17 You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). PR: https://git.openjdk.java.net/jfx/pull/17 From rlichten at openjdk.org Mon Oct 21 10:19:06 2019 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Mon, 21 Oct 2019 10:19:06 GMT Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating In-Reply-To: References: Message-ID: <_uTRPbwk-forXug4_Iyzy_XmZf6dUy9ydYA7_YqjgNQ=.ab563019-ab27-4dde-a9b2-b027199e17c5@github.com> On Mon, 21 Oct 2019 10:19:05 GMT, Kevin Rushforth wrote: > On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger wrote: > >> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes. >> >> I've create test cases that fail with the current way of synchronizing on a separate object. >> >> I've removed unused constructors. >> >> ---------------- >> >> Commits: >> - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating >> - 8ecf3545: JDK-8232524 fixed. >> >> Changes: https://git.openjdk.java.net/jfx/pull/17/files >> Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8232524 >> Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod >> Patch: https://git.openjdk.java.net/jfx/pull/17.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17 > > You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. > > As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). > You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. I'm trying to setup skara tools so that I can check changes before committing in the future. > > As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). OMG, hope I didn't break things ;-) PR: https://git.openjdk.java.net/jfx/pull/17 From jvos at openjdk.org Mon Oct 21 11:10:32 2019 From: jvos at openjdk.org (Johan Vos) Date: Mon, 21 Oct 2019 11:10:32 GMT Subject: [Rev 01] RFR: 8232687: No static JNI loader for libprism-sw In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - f34a99a3: In order to leverage this on Mac, we need to add -DSTATIC_BUILD to the cc flags Changes: - all: https://git.openjdk.java.net/jfx/pull/19/files - new: https://git.openjdk.java.net/jfx/pull/19/files/6f31ee6b..f34a99a3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/19/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/19/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8232687 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/19/head:pull/19 PR: https://git.openjdk.java.net/jfx/pull/19 From johan.vos at gluonhq.com Mon Oct 21 11:26:02 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 21 Oct 2019 13:26:02 +0200 Subject: duplicate symbols in static libraries Message-ID: Hi, When creating static libraries for the native parts of JavaFX, I ran into an issue with symbols exposed in more than 1 library: checkAndClearException() is declared and used in both libjavafx_font.a and in libprism_sw.a I have a simple fix for this that adds a prefix to the symbol in the prism-sw code: https://github.com/johanvos/jfx/commit/9180a73b51f60b0c6fe6e89184c4cba88fcf1696 However, I'm not sure this is the generally agreed approach. Are there opinions/guidelines for this? - Johan From kevin.rushforth at oracle.com Mon Oct 21 12:39:54 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Oct 2019 05:39:54 -0700 Subject: Request for permission to backport fixes to jfx-11 In-Reply-To: References: Message-ID: +1 -- Kevin On 10/21/2019 3:16 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issues to the jfx-11 > repository. All patches apply clean or with minor changes (e.g. > build.properties must keep jfx.release.major.version to 11) > > Thanks, > > - Johan > > https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 on > Linux > https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to Visual Studio > 2017 version 15.9.6 > https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to Xcode 10.1 > https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the versions of > tools used to build FX in the repo > https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web build fails > on XCode 10.2 > https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite to version > 3.28.0 > https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to 608.1 version > of WebKit > https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick GTK WebKit > 2.24.3 changes > https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies are not > enabled in WebKit v608.1 > https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] > PlatformFileHandle type should be JGObject rather than void * > https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix assertion > failure on X86 32-bit when enabling CLOOP based JavaScript interpreter > https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket client doesn't > work in WebView > https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level > Stage::initOwner can crash gnome-shell or X.org server > https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage sometimes > shown at top-left before moving to correct position > https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop no longer > works with GTK3 > https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer does not > play some mp3 with artwork stream in mjpeg > https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected > VirtualFlow methods for subclassing From kevin.rushforth at oracle.com Mon Oct 21 12:54:28 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Oct 2019 05:54:28 -0700 Subject: duplicate symbols in static libraries In-Reply-To: References: Message-ID: <296ea2c2-15f4-690e-a567-13240c59d388@oracle.com> This approach seems fine to me. Worth noting is that prism-sw will be removed as part of the Pisces removal by JDK-8196079 [1], which is targeted for 14. If your proposed change helps in the mean time, then I see no problem with getting it in. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8196079 On 10/21/2019 4:26 AM, Johan Vos wrote: > Hi, > > When creating static libraries for the native parts of JavaFX, I ran into > an issue with symbols exposed in more than 1 library: > checkAndClearException() is declared and used in both libjavafx_font.a and > in libprism_sw.a > > I have a simple fix for this that adds a prefix to the symbol in the > prism-sw code: > https://github.com/johanvos/jfx/commit/9180a73b51f60b0c6fe6e89184c4cba88fcf1696 > > However, I'm not sure this is the generally agreed approach. Are there > opinions/guidelines for this? > > - Johan From rlichten at openjdk.org Mon Oct 21 15:11:31 2019 From: rlichten at openjdk.org (Robert Lichtenberger) Date: Mon, 21 Oct 2019 15:11:31 GMT Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating In-Reply-To: <_uTRPbwk-forXug4_Iyzy_XmZf6dUy9ydYA7_YqjgNQ=.ab563019-ab27-4dde-a9b2-b027199e17c5@github.com> References: <_uTRPbwk-forXug4_Iyzy_XmZf6dUy9ydYA7_YqjgNQ=.ab563019-ab27-4dde-a9b2-b027199e17c5@github.com> Message-ID: On Mon, 21 Oct 2019 10:19:06 GMT, Robert Lichtenberger wrote: > On Mon, 21 Oct 2019 10:19:05 GMT, Kevin Rushforth wrote: > >> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger wrote: >> >>> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes. >>> >>> I've create test cases that fail with the current way of synchronizing on a separate object. >>> >>> I've removed unused constructors. >>> >>> ---------------- >>> >>> Commits: >>> - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating >>> - 8ecf3545: JDK-8232524 fixed. >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/17/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8232524 >>> Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/17.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17 >> >> You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. >> >> As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). > >> You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. > > I'm trying to setup skara tools so that I can check changes before committing in the future. > >> >> As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). > > OMG, hope I didn't break things ;-) I think I have corrected the whitespace errors (I can see "All checks have passed"), is there anything else I can / should do for this pull request? PR: https://git.openjdk.java.net/jfx/pull/17 From kcr at openjdk.org Mon Oct 21 15:29:22 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 15:29:22 GMT Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating In-Reply-To: References: <_uTRPbwk-forXug4_Iyzy_XmZf6dUy9ydYA7_YqjgNQ=.ab563019-ab27-4dde-a9b2-b027199e17c5@github.com> Message-ID: On Mon, 21 Oct 2019 15:11:31 GMT, Robert Lichtenberger wrote: > On Mon, 21 Oct 2019 10:19:06 GMT, Robert Lichtenberger wrote: > >> On Mon, 21 Oct 2019 10:19:05 GMT, Kevin Rushforth wrote: >> >>> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger wrote: >>> >>>> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes. >>>> >>>> I've create test cases that fail with the current way of synchronizing on a separate object. >>>> >>>> I've removed unused constructors. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating >>>> - 8ecf3545: JDK-8232524 fixed. >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/17/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8232524 >>>> Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/17.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17 >>> >>> You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. >>> >>> As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). >> >>> You have many whitespace errors in your patch that will need to be fixed before `git jcheck` will pass. When you fix them, you can just push a new commit. >> >> I'm trying to setup skara tools so that I can check changes before committing in the future. >> >>> >>> As an aside, you have uncovered a bug in the Skara PR bot where the server-side jcheck fails to complete if there are more than 50 errors. See [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). >> >> OMG, hope I didn't break things ;-) > > I think I have corrected the whitespace errors (I can see "All checks have passed"), is there anything else I can / should do for this pull request? This is now ready to be reviewed. Nothing more for you to do until there are questions or comments that arise during the review. PR: https://git.openjdk.java.net/jfx/pull/17 From kevin.rushforth at oracle.com Mon Oct 21 15:58:29 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Oct 2019 08:58:29 -0700 Subject: duplicate symbols in static libraries In-Reply-To: <296ea2c2-15f4-690e-a567-13240c59d388@oracle.com> References: <296ea2c2-15f4-690e-a567-13240c59d388@oracle.com> Message-ID: Actually, I did a quick check and there is more than just Pisces in the native prism_sw library, so removing Pisces isn't sufficient to remove prism_sw. -- Kevin On 10/21/2019 5:54 AM, Kevin Rushforth wrote: > This approach seems fine to me. Worth noting is that prism-sw will be > removed as part of the Pisces removal by JDK-8196079 [1], which is > targeted for 14. If your proposed change helps in the mean time, then > I see no problem with getting it in. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8196079 > > On 10/21/2019 4:26 AM, Johan Vos wrote: >> Hi, >> >> When creating static libraries for the native parts of JavaFX, I ran >> into >> an issue with symbols exposed in more than 1 library: >> checkAndClearException() is declared and used in both >> libjavafx_font.a and >> in libprism_sw.a >> >> I have a simple fix for this that adds a prefix to the symbol in the >> prism-sw code: >> https://github.com/johanvos/jfx/commit/9180a73b51f60b0c6fe6e89184c4cba88fcf1696 >> >> >> However, I'm not sure this is the generally agreed approach. Are there >> opinions/guidelines for this? >> >> - Johan > From arapte at openjdk.org Mon Oct 21 16:34:57 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 21 Oct 2019 16:34:57 GMT Subject: [Approved] RFR: 8232522: FX: Update copyright year in docs, readme files to 2020 In-Reply-To: References: Message-ID: On Sat, 19 Oct 2019 15:04:27 GMT, Kevin Rushforth wrote: > As indicated in the JBS bug, this makes the needed change for releasing in 2020. > > ---------------- > > Commits: > - 85c03ad9: 8232522: FX: Update copyright year in docs, readme files to 2020 > > Changes: https://git.openjdk.java.net/jfx/pull/18/files > Webrev: https://webrevs.openjdk.java.net/jfx/18/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232522 > Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/18.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/18/head:pull/18 lgtm ---------------- Approved by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/18 From kcr at openjdk.org Mon Oct 21 16:46:21 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 16:46:21 GMT Subject: [Integrated] RFR: 8232522: FX: Update copyright year in docs, readme files to 2020 In-Reply-To: References: Message-ID: Changeset: a09a0fa5 Author: Kevin Rushforth Date: 2019-10-21 16:45:26 +0000 URL: https://git.openjdk.java.net/jfx/commit/a09a0fa5 8232522: FX: Update copyright year in docs, readme files to 2020 Reviewed-by: arapte ! build.properties ! modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html ! modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html From johan at lodgon.com Mon Oct 21 17:33:04 2019 From: johan at lodgon.com (Johan Vos) Date: Mon, 21 Oct 2019 19:33:04 +0200 Subject: duplicate symbols in static libraries In-Reply-To: References: <296ea2c2-15f4-690e-a567-13240c59d388@oracle.com> Message-ID: Hi Kevin, Marlin is already used in com.sun.prism.sw classes, so it seems to me we can just use Marlin in prism-sw (instead of Pisces), unless I'm missing something? - Johan Op ma 21 okt. 2019 om 17:59 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Actually, I did a quick check and there is more than just Pisces in the > native prism_sw library, so removing Pisces isn't sufficient to remove > prism_sw. > > -- Kevin > > > On 10/21/2019 5:54 AM, Kevin Rushforth wrote: > > This approach seems fine to me. Worth noting is that prism-sw will be > > removed as part of the Pisces removal by JDK-8196079 [1], which is > > targeted for 14. If your proposed change helps in the mean time, then > > I see no problem with getting it in. > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8196079 > > > > On 10/21/2019 4:26 AM, Johan Vos wrote: > >> Hi, > >> > >> When creating static libraries for the native parts of JavaFX, I ran > >> into > >> an issue with symbols exposed in more than 1 library: > >> checkAndClearException() is declared and used in both > >> libjavafx_font.a and > >> in libprism_sw.a > >> > >> I have a simple fix for this that adds a prefix to the symbol in the > >> prism-sw code: > >> > https://github.com/johanvos/jfx/commit/9180a73b51f60b0c6fe6e89184c4cba88fcf1696 > >> > >> > >> However, I'm not sure this is the generally agreed approach. Are there > >> opinions/guidelines for this? > >> > >> - Johan > > > > From kevin.rushforth at oracle.com Mon Oct 21 17:44:06 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Oct 2019 10:44:06 -0700 Subject: duplicate symbols in static libraries In-Reply-To: References: <296ea2c2-15f4-690e-a567-13240c59d388@oracle.com> Message-ID: <6f4ecabf-eb50-d065-6770-2b1beaba64f7@oracle.com> Removing Pisces will completely remove almost all of the native code in prism-sw (it isn't used at all by Marlin). What I meant is that the prism-sw library also contains native functions that have nothing to do with rasterization. Thus the library will still remain after the removal of Pisces, it will just be much smaller. -- Kevin On 10/21/2019 10:33 AM, Johan Vos wrote: > Hi Kevin, > > Marlin is already used in com.sun.prism.sw classes, so it seems to me > we can just use Marlin in prism-sw (instead of Pisces), unless I'm > missing something? > > - Johan > > Op ma 21 okt. 2019 om 17:59 schreef Kevin Rushforth > >: > > Actually, I did a quick check and there is more than just Pisces > in the > native prism_sw library, so removing Pisces isn't sufficient to > remove > prism_sw. > > -- Kevin > > > On 10/21/2019 5:54 AM, Kevin Rushforth wrote: > > This approach seems fine to me. Worth noting is that prism-sw > will be > > removed as part of the Pisces removal by JDK-8196079 [1], which is > > targeted for 14. If your proposed change helps in the mean time, > then > > I see no problem with getting it in. > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8196079 > > > > On 10/21/2019 4:26 AM, Johan Vos wrote: > >> Hi, > >> > >> When creating static libraries for the native parts of JavaFX, > I ran > >> into > >> an issue with symbols exposed in more than 1 library: > >> checkAndClearException() is declared and used in both > >> libjavafx_font.a and > >> in libprism_sw.a > >> > >> I have a simple fix for this that adds a prefix to the symbol > in the > >> prism-sw code: > >> > https://github.com/johanvos/jfx/commit/9180a73b51f60b0c6fe6e89184c4cba88fcf1696 > > >> > >> > >> However, I'm not sure this is the generally agreed approach. > Are there > >> opinions/guidelines for this? > >> > >> - Johan > > > From kcr at openjdk.org Mon Oct 21 20:06:39 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 20:06:39 GMT Subject: [Rev 01] RFR: 8232687: No static JNI loader for libprism-sw In-Reply-To: References: Message-ID: On Mon, 21 Oct 2019 11:10:32 GMT, Johan Vos wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - f34a99a3: In order to leverage this on Mac, we need to add -DSTATIC_BUILD to the cc flags > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/19/files > - new: https://git.openjdk.java.net/jfx/pull/19/files/6f31ee6b..f34a99a3 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/19/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/19/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8232687 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/19.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/19/head:pull/19 buildSrc/mac.gradle line 173: > 172: MAC.prism.ccFlags = ["-O3", "-DINLINE=inline", "-c", IS_STATIC_BUILD? "-DSTATIC_BUILD" : "", ccBaseFlags].flatten() > 173: MAC.prism.linker = linker > 174: MAC.prism.linkFlags = linkFlagsAlt Minor: normally we would put a space before the `?` although we are a bit more lax in the gradle files. Up to you whether you want to fix it. PR: https://git.openjdk.java.net/jfx/pull/19 From kcr at openjdk.org Mon Oct 21 20:06:40 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 20:06:40 GMT Subject: [Approved] RFR: 8232687: No static JNI loader for libprism-sw In-Reply-To: References: Message-ID: On Mon, 21 Oct 2019 10:03:24 GMT, Johan Vos wrote: > This PR adds a JNI_OnLoad_prism_sw call to the static lib libprism_sw.a. > This approach is similar to the addition of e.g. JNI_OnLoad_prism_es2 that has been done as part of https://bugs.openjdk.java.net/browse/JDK-8223760 > > Unless -PSTATIC_BUILD is provided when building, this patch has no impact. > > ---------------- > > Commits: > - 6f31ee6b: Add JNI_OnLoad_prism_sw call to make prism-sw work with static libs > > Changes: https://git.openjdk.java.net/jfx/pull/19/files > Webrev: https://webrevs.openjdk.java.net/jfx/19/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232687 > Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/19.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/19/head:pull/19 Looks good. One minor formatting comment. Approved. This one is simple enough I don't think it needs a second review. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/19 From sverre.moe at gmail.com Mon Oct 21 20:08:32 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 21 Oct 2019 22:08:32 +0200 Subject: Request for permission to backport fixes to jfx-11 In-Reply-To: References: Message-ID: Could JavaFX 11 also get backported the fix related for JDK-8193502? It might have been solved in the fix for JDK-8179073. I noticed this regression right after JDK 9 build 161. Recently also JavaFX 8 got this regression after update 181. It seems this was fixed in JavaFX 13. I asked on GitHub in #222 a while back if this could be backported. Considering that repository is now closed, I will repeat it here. Kevin Rushforth wrote: > That's a good question for @johanvos -- it seems this might be a good candidate for backport, although there is one report of a possible regression caused by this fix when using GTK 2 as reported in #475 /Sverre [1] https://bugs.openjdk.java.net/browse/JDK-8193502 [2] https://bugs.openjdk.java.net/browse/JDK-8179073 [3] https://github.com/javafxports/openjdk-jfx/pull/456 [4] https://github.com/javafxports/openjdk-jfx/issues/222 man. 21. okt. 2019 kl. 14:39 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > +1 > > -- Kevin > > On 10/21/2019 3:16 AM, Johan Vos wrote: > > Hi Kevin, > > > > I request permission to backport the following issues to the jfx-11 > > repository. All patches apply clean or with minor changes (e.g. > > build.properties must keep jfx.release.major.version to 11) > > > > Thanks, > > > > - Johan > > > > https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 on > > Linux > > https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to Visual > Studio > > 2017 version 15.9.6 > > https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to Xcode 10.1 > > https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the versions > of > > tools used to build FX in the repo > > https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web build > fails > > on XCode 10.2 > > https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite to > version > > 3.28.0 > > https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to 608.1 > version > > of WebKit > > https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick GTK > WebKit > > 2.24.3 changes > > https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies are not > > enabled in WebKit v608.1 > > https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] > > PlatformFileHandle type should be JGObject rather than void * > > https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix > assertion > > failure on X86 32-bit when enabling CLOOP based JavaScript interpreter > > https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket client > doesn't > > work in WebView > > https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level > > Stage::initOwner can crash gnome-shell or X.org server > > https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage > sometimes > > shown at top-left before moving to correct position > > https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop no longer > > works with GTK3 > > https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer does not > > play some mp3 with artwork stream in mjpeg > > https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected > > VirtualFlow methods for subclassing > > From kcr at openjdk.org Mon Oct 21 20:08:46 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 20:08:46 GMT Subject: [Approved] RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> Message-ID: On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar wrote: > 8232158: [macOS] Fallback to command line tools if xcode is missing > > ---------------- > > Commits: > - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing > > Changes: https://git.openjdk.java.net/jfx/pull/13/files > Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 > Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/13.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 Looks good. This one is simple enough I don't think it needs a second review, although @johanvos might want to review it. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/13 From kevin.rushforth at oracle.com Mon Oct 21 21:15:31 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 21 Oct 2019 14:15:31 -0700 Subject: Request for permission to backport fixes to jfx-11 In-Reply-To: References: Message-ID: <9e45e477-3f8a-5f87-2bac-d980d0dc26f8@oracle.com> > JDK-8193502 Johan can comment on whether he wants to backport it. As noted below, someone reported a regression associated with it when using gtk2, but we don't have a bug filed or a test case. > It might have been solved in the fix for JDK-8179073. Not sure what you mean since JDK-8179073 is still an open bug and thus is not a solved issue (although it might be worth re-testing after the fix for JDK-8179073). -- Kevin On 10/21/2019 1:08 PM, Sverre Moe wrote: > Could JavaFX 11 also get backported the fix related for?JDK-8193502? > It might have been solved in the fix for JDK-8179073. > > I noticed this regression right after JDK 9 build 161. Recently also > JavaFX 8 got this regression after update 181. > > It seems this was fixed in JavaFX 13. > I asked on GitHub in #222 a while back if this could be backported. > Considering that repository is now closed, I will repeat it here. > > Kevin Rushforth wrote: > >?That's a good question for @johanvos -- it seems this might be a > good candidate for backport, although there is one report of a > possible regression caused by this fix when using GTK 2 as reported in > #475 > > /Sverre > > [1] https://bugs.openjdk.java.net/browse/JDK-8193502 > [2] https://bugs.openjdk.java.net/browse/JDK-8179073 > [3] https://github.com/javafxports/openjdk-jfx/pull/456 > [4] https://github.com/javafxports/openjdk-jfx/issues/222 > > man. 21. okt. 2019 kl. 14:39 skrev Kevin Rushforth > >: > > +1 > > -- Kevin > > On 10/21/2019 3:16 AM, Johan Vos wrote: > > Hi Kevin, > > > > I request permission to backport the following issues to the jfx-11 > > repository. All patches apply clean or with minor changes (e.g. > > build.properties must keep jfx.release.major.version to 11) > > > > Thanks, > > > > - Johan > > > > https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to > gcc 8.2 on > > Linux > > https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to > Visual Studio > > 2017 version 15.9.6 > > https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to > Xcode 10.1 > > https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the > versions of > > tools used to build FX in the repo > > https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web > build fails > > on XCode 10.2 > > https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite > to version > > 3.28.0 > > https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to > 608.1 version > > of WebKit > > https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick > GTK WebKit > > 2.24.3 changes > > https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies > are not > > enabled in WebKit v608.1 > > https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] > > PlatformFileHandle type should be JGObject rather than void * > > https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix > assertion > > failure on X86 32-bit when enabling CLOOP based JavaScript > interpreter > > https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket > client doesn't > > work in WebView > > https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level > > Stage::initOwner can crash gnome-shell or X.org server > > https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage > sometimes > > shown at top-left before moving to correct position > > https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop > no longer > > works with GTK3 > > https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer > does not > > play some mp3 with artwork stream in mjpeg > > https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected > > VirtualFlow methods for subclassing > From kcr at openjdk.org Mon Oct 21 22:52:47 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Oct 2019 22:52:47 GMT Subject: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() In-Reply-To: References: <0YJvd4XIwHfRAuOVa3jtcjFVOhDVvaq94-fi6HKRKqY=.42af4fb5-cc1b-42eb-9fad-b9409971a9ca@github.com> Message-ID: On Thu, 17 Oct 2019 15:28:31 GMT, Kevin Rushforth wrote: > On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka wrote: > >> On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka wrote: >> >>> Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call. >>> This patch fixes the problem by submitting the UI work (including the call to the SecondaryLoop.exit() method) before entering the secondary loop. >>> >>> [1] https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4 >>> >>> ---------------- >>> >>> Commits: >>> - 9483ccde: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/16/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 >>> Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/16.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16 >> >> @kevinrushforth I believe you should be able to move forward with the review of this PR now as I've filed a bug report for the problem and signed the OCA as required. (As I did not know I needed to have my github account associated with the OCA, I did not include it in my details. I've asked Dalibor Topic from the Java SE PM team to help me have that fixed or get in touch with you to confirm my signing of the OCA.) > > @mruzicka once Dalibor connects your OCA with your GitHub account, this review will be able to proceed. Do you have a test program that shows the bug? Also, can you take a look at whether you could turn the test case into an automated test? PR: https://git.openjdk.java.net/jfx/pull/16 From jvos at openjdk.org Tue Oct 22 11:46:19 2019 From: jvos at openjdk.org (Johan Vos) Date: Tue, 22 Oct 2019 11:46:19 GMT Subject: [Integrated] RFR: 8232687: No static JNI loader for libprism-sw In-Reply-To: References: Message-ID: <15dfeede-39b2-48c7-a4a7-345e2f01a0ab@openjdk.org> Changeset: 2ae171a2 Author: Johan Vos Date: 2019-10-22 11:44:12 +0000 URL: https://git.openjdk.java.net/jfx/commit/2ae171a2 8232687: No static JNI loader for libprism-sw Reviewed-by: kcr ! buildSrc/mac.gradle ! modules/javafx.graphics/src/main/native-prism-sw/JNIUtil.c From johan.vos at gluonhq.com Tue Oct 22 11:47:48 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 22 Oct 2019 13:47:48 +0200 Subject: Request for permission to backport fixes to jfx-11 In-Reply-To: <9e45e477-3f8a-5f87-2bac-d980d0dc26f8@oracle.com> References: <9e45e477-3f8a-5f87-2bac-d980d0dc26f8@oracle.com> Message-ID: I'm ok with the backport, as long as the patch applies clean -- which it most likely does, as I don't think we have other changes in that file. - Johan On Mon, Oct 21, 2019 at 11:15 PM Kevin Rushforth wrote: > > JDK-8193502 > > Johan can comment on whether he wants to backport it. As noted below, > someone reported a regression associated with it when using gtk2, but we > don't have a bug filed or a test case. > > > It might have been solved in the fix for JDK-8179073. > > Not sure what you mean since JDK-8179073 is still an open bug and thus is > not a solved issue (although it might be worth re-testing after the fix for > JDK-8179073). > > -- Kevin > > > On 10/21/2019 1:08 PM, Sverre Moe wrote: > > Could JavaFX 11 also get backported the fix related for JDK-8193502? It > might have been solved in the fix for JDK-8179073. > > I noticed this regression right after JDK 9 build 161. Recently also > JavaFX 8 got this regression after update 181. > > It seems this was fixed in JavaFX 13. > I asked on GitHub in #222 a while back if this could be backported. > Considering that repository is now closed, I will repeat it here. > > Kevin Rushforth wrote: > > That's a good question for @johanvos -- it seems this might be a good > candidate for backport, although there is one report of a possible > regression caused by this fix when using GTK 2 as reported in #475 > > /Sverre > > [1] https://bugs.openjdk.java.net/browse/JDK-8193502 > [2] https://bugs.openjdk.java.net/browse/JDK-8179073 > [3] https://github.com/javafxports/openjdk-jfx/pull/456 > [4] https://github.com/javafxports/openjdk-jfx/issues/222 > > man. 21. okt. 2019 kl. 14:39 skrev Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> +1 >> >> -- Kevin >> >> On 10/21/2019 3:16 AM, Johan Vos wrote: >> > Hi Kevin, >> > >> > I request permission to backport the following issues to the jfx-11 >> > repository. All patches apply clean or with minor changes (e.g. >> > build.properties must keep jfx.release.major.version to 11) >> > >> > Thanks, >> > >> > - Johan >> > >> > https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 >> on >> > Linux >> > https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to Visual >> Studio >> > 2017 version 15.9.6 >> > https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to Xcode >> 10.1 >> > https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the versions >> of >> > tools used to build FX in the repo >> > https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web build >> fails >> > on XCode 10.2 >> > https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite to >> version >> > 3.28.0 >> > https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to 608.1 >> version >> > of WebKit >> > https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick GTK >> WebKit >> > 2.24.3 changes >> > https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies are >> not >> > enabled in WebKit v608.1 >> > https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] >> > PlatformFileHandle type should be JGObject rather than void * >> > https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix >> assertion >> > failure on X86 32-bit when enabling CLOOP based JavaScript interpreter >> > https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket client >> doesn't >> > work in WebView >> > https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level >> > Stage::initOwner can crash gnome-shell or X.org server >> > https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage >> sometimes >> > shown at top-left before moving to correct position >> > https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop no >> longer >> > works with GTK3 >> > https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer does not >> > play some mp3 with artwork stream in mjpeg >> > https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected >> > VirtualFlow methods for subclassing >> >> > From arajkumar at openjdk.org Tue Oct 22 17:57:21 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Tue, 22 Oct 2019 17:57:21 GMT Subject: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> <_-WBqk_gDuD7wVko2GF-shlL0LOAinb75E3pBl-R3Ds=.6dc11b87-6d1a-435e-9b37-d51183ddfbac@github.com> Message-ID: On Wed, 16 Oct 2019 15:54:54 GMT, Arunprasad Rajkumar wrote: > On Wed, 16 Oct 2019 15:29:05 GMT, Kevin Rushforth wrote: > >> On Wed, 16 Oct 2019 15:21:55 GMT, Arunprasad Rajkumar wrote: >> >>> On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar wrote: >>> >>>> 8232158: [macOS] Fallback to command line tools if xcode is missing >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/13/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 >>>> Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/13.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 >>> >>> @kevinrushforth Am I missing anything here which prevents the review process? >> >> No, I have just been swamped the last few days. It's on my list to review. Sorry for the delay. > > Thanks @kevin. @johanvos , Do you have any concern? In short, this fix allows developers to build jfx on mac without full Xcode install. It would be useful for CI/CD. PR: https://git.openjdk.java.net/jfx/pull/13 From jvos at openjdk.org Wed Oct 23 07:43:07 2019 From: jvos at openjdk.org (Johan Vos) Date: Wed, 23 Oct 2019 07:43:07 GMT Subject: [Approved] RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> Message-ID: On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar wrote: > 8232158: [macOS] Fallback to command line tools if xcode is missing > > ---------------- > > Commits: > - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is missing > > Changes: https://git.openjdk.java.net/jfx/pull/13/files > Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232158 > Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/13.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13 These things (retrieving locations and versions of OS-specific directories/settings and toolchains) are imho the most brittle of the whole end-to-end building. Mistakes here (e.g. wrong versions, wrong architectures) might lead to a number of almost inpredictable failures. I 100% agree the fallback is a great idea, but I am a bit worried that this change is in gradle and that we don't have tests for this. ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/13 From arajkumar at openjdk.org Wed Oct 23 08:42:20 2019 From: arajkumar at openjdk.org (Arunprasad Rajkumar) Date: Wed, 23 Oct 2019 08:42:20 GMT Subject: [Integrated] RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing In-Reply-To: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> References: <5TKMCi0Z03p1AXOPUgvO1WLY-F_VU7k8VTOIHMC30QA=.4f57face-3907-4d81-8413-6841b8ada2aa@github.com> Message-ID: <18c1f4e9-b3c5-4ba5-8c68-2f7e2ac4691c@openjdk.org> Changeset: ab6ea3b9 Author: Arunprasad Rajkumar Date: 2019-10-23 08:41:40 +0000 URL: https://git.openjdk.java.net/jfx/commit/ab6ea3b9 8232158: [macOS] Fallback to command line tools if xcode is missing Reviewed-by: kcr, jvos ! buildSrc/mac.gradle From fastegal at openjdk.org Wed Oct 23 11:32:48 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 23 Oct 2019 11:32:48 GMT Subject: RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene Message-ID: The issue is that firing keyEvents on a node that is not focusOwner might produce false green tests, please see the issue for details. fix for https://bugs.openjdk.java.net/browse/JDK-8231692 - added contructor taking the scene - changed event firing to use either the target directly or inject into scene ---------------- Commits: - aabea139: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into Changes: https://git.openjdk.java.net/jfx/pull/20/files Webrev: https://webrevs.openjdk.java.net/jfx/20/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 Stats: 263 lines in 2 files changed: 260 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 PR: https://git.openjdk.java.net/jfx/pull/20 From jvos at openjdk.org Thu Oct 24 07:43:44 2019 From: jvos at openjdk.org (Johan Vos) Date: Thu, 24 Oct 2019 07:43:44 GMT Subject: RFR: 8232929: Duplicate symbols when building static libraries Message-ID: This PR only affects native code in the prism-sw pipeline. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8232929 ---------------- Commits: - 9afeca00: Avoid name clashes when creating static libraries. Prefix exposed functions. Changes: https://git.openjdk.java.net/jfx/pull/21/files Webrev: https://webrevs.openjdk.java.net/jfx/21/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232929 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/21.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/21/head:pull/21 PR: https://git.openjdk.java.net/jfx/pull/21 From kcr at openjdk.org Thu Oct 24 12:15:11 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 24 Oct 2019 12:15:11 GMT Subject: [Approved] RFR: 8232929: Duplicate symbols when building static libraries In-Reply-To: References: Message-ID: <2MDvzLyIUrNg-x50ERAwmUzPmOebJZGHmhHbw3bgeng=.8873d3fe-d688-448a-a543-37dbdb646624@github.com> On Thu, 24 Oct 2019 07:43:44 GMT, Johan Vos wrote: > This PR only affects native code in the prism-sw pipeline. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8232929 > > ---------------- > > Commits: > - 9afeca00: Avoid name clashes when creating static libraries. Prefix exposed functions. > > Changes: https://git.openjdk.java.net/jfx/pull/21/files > Webrev: https://webrevs.openjdk.java.net/jfx/21/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232929 > Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/21.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/21/head:pull/21 +1 This seems like a simple enough fix that 1 reviewer is sufficient. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/21 From johan.vos at gluonhq.com Thu Oct 24 17:10:40 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 24 Oct 2019 19:10:40 +0200 Subject: Request for permission to backport fixes to jfx-11 In-Reply-To: References: <9e45e477-3f8a-5f87-2bac-d980d0dc26f8@oracle.com> Message-ID: Looking a bit deeper into it, it seems there are some related issues that might be caused by the same root cause, or by this fix. I'll request to backport it once we have more insight about the potential regressions. - Johan On Tue, Oct 22, 2019 at 1:47 PM Johan Vos wrote: > I'm ok with the backport, as long as the patch applies clean -- which it > most likely does, as I don't think we have other changes in that file. > > - Johan > > On Mon, Oct 21, 2019 at 11:15 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> > JDK-8193502 >> >> Johan can comment on whether he wants to backport it. As noted below, >> someone reported a regression associated with it when using gtk2, but we >> don't have a bug filed or a test case. >> >> > It might have been solved in the fix for JDK-8179073. >> >> Not sure what you mean since JDK-8179073 is still an open bug and thus is >> not a solved issue (although it might be worth re-testing after the fix for >> JDK-8179073). >> >> -- Kevin >> >> >> On 10/21/2019 1:08 PM, Sverre Moe wrote: >> >> Could JavaFX 11 also get backported the fix related for JDK-8193502? It >> might have been solved in the fix for JDK-8179073. >> >> I noticed this regression right after JDK 9 build 161. Recently also >> JavaFX 8 got this regression after update 181. >> >> It seems this was fixed in JavaFX 13. >> I asked on GitHub in #222 a while back if this could be backported. >> Considering that repository is now closed, I will repeat it here. >> >> Kevin Rushforth wrote: >> > That's a good question for @johanvos -- it seems this might be a good >> candidate for backport, although there is one report of a possible >> regression caused by this fix when using GTK 2 as reported in #475 >> >> /Sverre >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8193502 >> [2] https://bugs.openjdk.java.net/browse/JDK-8179073 >> [3] https://github.com/javafxports/openjdk-jfx/pull/456 >> [4] https://github.com/javafxports/openjdk-jfx/issues/222 >> >> man. 21. okt. 2019 kl. 14:39 skrev Kevin Rushforth < >> kevin.rushforth at oracle.com>: >> >>> +1 >>> >>> -- Kevin >>> >>> On 10/21/2019 3:16 AM, Johan Vos wrote: >>> > Hi Kevin, >>> > >>> > I request permission to backport the following issues to the jfx-11 >>> > repository. All patches apply clean or with minor changes (e.g. >>> > build.properties must keep jfx.release.major.version to 11) >>> > >>> > Thanks, >>> > >>> > - Johan >>> > >>> > https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 >>> on >>> > Linux >>> > https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to Visual >>> Studio >>> > 2017 version 15.9.6 >>> > https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to Xcode >>> 10.1 >>> > https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the >>> versions of >>> > tools used to build FX in the repo >>> > https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web build >>> fails >>> > on XCode 10.2 >>> > https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite to >>> version >>> > 3.28.0 >>> > https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to 608.1 >>> version >>> > of WebKit >>> > https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick GTK >>> WebKit >>> > 2.24.3 changes >>> > https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies are >>> not >>> > enabled in WebKit v608.1 >>> > https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] >>> > PlatformFileHandle type should be JGObject rather than void * >>> > https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix >>> assertion >>> > failure on X86 32-bit when enabling CLOOP based JavaScript interpreter >>> > https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket client >>> doesn't >>> > work in WebView >>> > https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level >>> > Stage::initOwner can crash gnome-shell or X.org server >>> > https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage >>> sometimes >>> > shown at top-left before moving to correct position >>> > https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop no >>> longer >>> > works with GTK3 >>> > https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer does >>> not >>> > play some mp3 with artwork stream in mjpeg >>> > https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected >>> > VirtualFlow methods for subclassing >>> >>> >> From swpalmer at gmail.com Thu Oct 24 17:42:23 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 24 Oct 2019 13:42:23 -0400 Subject: Build Problem on macOS with OpenJDK 13 and Gradle 6.0-rc-1 Message-ID: I?m getting this: * What went wrong: Execution failed for task ':swt:compileJava'. > Could not resolve all files for configuration ':swt:compileClasspath'. > Could not find :org.eclipse.swt.cocoa.macosx.x86_64_3.105.3.v20170228-0512:. Searched in the following locations: - https://download.eclipse.org/eclipse/updates/4.6/R-4.6.3-201703010400/plugins/ivy.xml Required by: project :swt Earlier on I see: module: project ':swt' (buildModule=NO) so I?m not even sure why :swt:compileJava is running.. but it is. This is with OpenJDK 13, and Gradle 6.0-rc-1. I know the jump to Gradle 6.0 has not been officially made yet, but I also know it is coming for the JDK 13 support. When I use OpenJDK 12 and gradlew the build mostly works. Though even with OpenJDK 12 and gradlew the tests fail: > Task :base:test test.javafx.util.converter.LocalDateTimeStringConverterTest > toString_to_fromString_testRoundtrip[0] FAILED java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' could not be parsed, unparsed text found at index 19 at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052) at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877) at javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208) at javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159) at test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131) 5222 tests completed, 1 failed, 27 skipped Regards, Scott From jvos at openjdk.org Thu Oct 24 21:31:20 2019 From: jvos at openjdk.org (Johan Vos) Date: Thu, 24 Oct 2019 21:31:20 GMT Subject: [Integrated] RFR: 8232929: Duplicate symbols when building static libraries In-Reply-To: References: Message-ID: Changeset: ac71396c Author: Johan Vos Date: 2019-10-24 21:31:08 +0000 URL: https://git.openjdk.java.net/jfx/commit/ac71396c 8232929: Duplicate symbols when building static libraries Reviewed-by: kcr ! modules/javafx.graphics/src/main/native-prism-sw/JNIUtil.c ! modules/javafx.graphics/src/main/native-prism-sw/JNIUtil.h ! modules/javafx.graphics/src/main/native-prism-sw/JPiscesRenderer.c From jpereda at openjdk.org Fri Oct 25 09:29:16 2019 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 25 Oct 2019 09:29:16 GMT Subject: RFR: 8232943: Gesture support is not initialized on iOS Message-ID: This PR only affects iOS native code. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8232943 Since the `IosGestureSupport` class is only instantiated from the native side, the proposal is to change in `ios/GlassViewDelegate.m` the use of `FindClass` in favor of `[GlassHelper ClassForName]`, in the same way as it is done in [`mac/GlassViewDelegate.m`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m#L614) to instantiate `MacGestureSupport`. ---------------- Commits: - 49f39910: Use ClassForName instead of FindClass Changes: https://git.openjdk.java.net/jfx/pull/23/files Webrev: https://webrevs.openjdk.java.net/jfx/23/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232943 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/23.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/23/head:pull/23 PR: https://git.openjdk.java.net/jfx/pull/23 From kevin.rushforth at oracle.com Fri Oct 25 15:00:00 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 25 Oct 2019 08:00:00 -0700 Subject: Build Problem on macOS with OpenJDK 13 and Gradle 6.0-rc-1 In-Reply-To: References: Message-ID: <43ecfa3a-096a-27f7-f52f-d1d059cca512@oracle.com> This is a known issue that will be fixed by JDK-8232063 [1]. I've already tested the fix, and will send a review out shortly after gradle 6 GA. I note that I initially was going to fix it as part of JDK-8226754 [2], but during the course of that review we decided to wait until the actual switch to gradle 6 since the fix relies on API that is incubating in gradle 5.x. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8232063 [2] https://bugs.openjdk.java.net/browse/JDK-8226754 On 10/24/2019 10:42 AM, Scott Palmer wrote: > I?m getting this: > > * What went wrong: > Execution failed for task ':swt:compileJava'. >> Could not resolve all files for configuration ':swt:compileClasspath'. > > Could not find :org.eclipse.swt.cocoa.macosx.x86_64_3.105.3.v20170228-0512:. > Searched in the following locations: > - https://download.eclipse.org/eclipse/updates/4.6/R-4.6.3-201703010400/plugins/ivy.xml > Required by: > project :swt > > Earlier on I see: > > module: project ':swt' (buildModule=NO) > > so I?m not even sure why :swt:compileJava is running.. but it is. > > This is with OpenJDK 13, and Gradle 6.0-rc-1. > > I know the jump to Gradle 6.0 has not been officially made yet, but I also know it is coming for the JDK 13 support. > > When I use OpenJDK 12 and gradlew the build mostly works. > > Though even with OpenJDK 12 and gradlew the tests fail: > >> Task :base:test > test.javafx.util.converter.LocalDateTimeStringConverterTest > toString_to_fromString_testRoundtrip[0] FAILED > java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' could not be parsed, unparsed text found at index 19 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877) > at javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208) > at javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159) > at test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131) > > 5222 tests completed, 1 failed, 27 skipped > > > Regards, > > Scott > > From kcr at openjdk.org Fri Oct 25 15:07:57 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 25 Oct 2019 15:07:57 GMT Subject: RFR: 8232943: Gesture support is not initialized on iOS In-Reply-To: References: Message-ID: On Fri, 25 Oct 2019 09:29:16 GMT, Jose Pereda wrote: > This PR only affects iOS native code. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8232943 > > Since the `IosGestureSupport` class is only instantiated from the native side, the proposal is to change in `ios/GlassViewDelegate.m` the use of `FindClass` in favor of `[GlassHelper ClassForName]`, in the same way as it is done in [`mac/GlassViewDelegate.m`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m#L614) to instantiate `MacGestureSupport`. > > ---------------- > > Commits: > - 49f39910: Use ClassForName instead of FindClass > > Changes: https://git.openjdk.java.net/jfx/pull/23/files > Webrev: https://webrevs.openjdk.java.net/jfx/23/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232943 > Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/23.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/23/head:pull/23 @johanvos should be able to review this. PR: https://git.openjdk.java.net/jfx/pull/23 From prr at openjdk.org Fri Oct 25 20:18:48 2019 From: prr at openjdk.org (Phil Race) Date: Fri, 25 Oct 2019 20:18:48 GMT Subject: RFR: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph Message-ID: I have added an evaluation in https://bugs.openjdk.java.net/browse/JDK-8207839 Please read that for more detail, but basically we are not properly preventing or handling cases where fontconfig causes us to overflow the byte storage used for a font "slot". ---------------- Commits: - b6c19466: Fix whitespace - e00ef992: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph Changes: https://git.openjdk.java.net/jfx/pull/24/files Webrev: https://webrevs.openjdk.java.net/jfx/24/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8189092 Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/24.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/24/head:pull/24 PR: https://git.openjdk.java.net/jfx/pull/24 From kcr at openjdk.org Fri Oct 25 23:16:41 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 25 Oct 2019 23:16:41 GMT Subject: [Approved] RFR: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph In-Reply-To: References: Message-ID: On Fri, 25 Oct 2019 20:18:48 GMT, Phil Race wrote: > I have added an evaluation in https://bugs.openjdk.java.net/browse/JDK-8207839 > Please read that for more detail, but basically we are not properly preventing or > handling cases where fontconfig causes us to overflow the byte storage used > for a font "slot". > > ---------------- > > Commits: > - b6c19466: Fix whitespace > - e00ef992: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph > > Changes: https://git.openjdk.java.net/jfx/pull/24/files > Webrev: https://webrevs.openjdk.java.net/jfx/24/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8189092 > Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/24.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/24/head:pull/24 Looks good to me. I don't think this needs a second review, although @bourgesl or @johanvos might want to weigh in. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/24 From github.com+5607073+bourgesl at openjdk.org Sat Oct 26 11:33:15 2019 From: github.com+5607073+bourgesl at openjdk.org (Laurent Bourg=?utf-8?b?w6g=?=s) Date: Sat, 26 Oct 2019 11:33:15 GMT Subject: RFR: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph In-Reply-To: References: Message-ID: On Fri, 25 Oct 2019 20:18:48 GMT, Phil Race wrote: > I have added an evaluation in https://bugs.openjdk.java.net/browse/JDK-8207839 > Please read that for more detail, but basically we are not properly preventing or > handling cases where fontconfig causes us to overflow the byte storage used > for a font "slot". > > ---------------- > > Commits: > - b6c19466: Fix whitespace > - e00ef992: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph > > Changes: https://git.openjdk.java.net/jfx/pull/24/files > Webrev: https://webrevs.openjdk.java.net/jfx/24/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8189092 > Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/24.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/24/head:pull/24 I had a quick look by curiosity as it is not my field. Explanations really make sense, thanks Phil. Bit masks & shifts look good and definitely it will make that code safer. However I wonder how to deal with more than 255 fonts (1 byte limit) as it may happen on some systems, even not reallistic. Thanks PR: https://git.openjdk.java.net/jfx/pull/24 From prr at openjdk.org Sat Oct 26 15:09:55 2019 From: prr at openjdk.org (Phil Race) Date: Sat, 26 Oct 2019 15:09:55 GMT Subject: RFR: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph In-Reply-To: References: Message-ID: On Sat, 26 Oct 2019 11:33:15 GMT, Laurent Bourg?s wrote: > On Fri, 25 Oct 2019 20:18:48 GMT, Phil Race wrote: > >> I have added an evaluation in https://bugs.openjdk.java.net/browse/JDK-8207839 >> Please read that for more detail, but basically we are not properly preventing or >> handling cases where fontconfig causes us to overflow the byte storage used >> for a font "slot". >> >> ---------------- >> >> Commits: >> - b6c19466: Fix whitespace >> - e00ef992: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph >> >> Changes: https://git.openjdk.java.net/jfx/pull/24/files >> Webrev: https://webrevs.openjdk.java.net/jfx/24/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8189092 >> Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/24.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/24/head:pull/24 > > I had a quick look by curiosity as it is not my field. Explanations really make sense, thanks Phil. > Bit masks & shifts look good and definitely it will make that code safer. > However I wonder how to deal with more than 255 fonts (1 byte limit) as it may happen on some systems, even not reallistic. > Thanks > However I wonder how to deal with more than 255 fonts (1 byte limit) as it may happen on some systems, even not reallistic. That would have to be > 255 fonts *per fontconfig font*, and we have additional filters to eliminate fonts that don't add value (at least we do now with fixing the bug in that code in fontpath_linux.c). We could rework things to use 16 bit for font slot, although that would be a bigger change and require more testing and really this is never going to be needed on Windows or Mac, just some very small number of Linux systems that are not default configs .. PR: https://git.openjdk.java.net/jfx/pull/24 From prr at openjdk.org Sat Oct 26 15:15:23 2019 From: prr at openjdk.org (Phil Race) Date: Sat, 26 Oct 2019 15:15:23 GMT Subject: [Integrated] RFR: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph In-Reply-To: References: Message-ID: <96819713-9ca3-470a-8146-44971f8157e7@openjdk.org> Changeset: 5a70b0c5 Author: Phil Race Date: 2019-10-26 15:14:47 +0000 URL: https://git.openjdk.java.net/jfx/commit/5a70b0c5 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph Reviewed-by: kcr ! modules/javafx.graphics/src/main/java/com/sun/javafx/font/CompositeGlyphMapper.java ! modules/javafx.graphics/src/main/java/com/sun/prism/impl/GlyphCache.java ! modules/javafx.graphics/src/main/native-font/fontpath_linux.c From fastegal at swingempire.de Sat Oct 26 15:16:55 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 26 Oct 2019 17:16:55 +0200 Subject: Okay to open a bug? Message-ID: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) and accidentally opened it - the child in me can't refrain from clicking buttons to see what happens ;) Having it opened, I went the whole way and assigned it to me (it's in my current line of interes anyway). Not certain if I maybe violated some procedure on the side of jbs? If so, please revert everything (except the bug, of course :) Happy weekend, Jeanette From fastegal at swingempire.de Sat Oct 26 15:18:37 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 26 Oct 2019 17:18:37 +0200 Subject: Okay to open a bug? Message-ID: <20191026171837.Horde.hQaVlnCoOTeoW6CF9KytPQ1@webmail.df.eu> the bug reference in my last message - was wrong, it's https://bugs.openjdk.java.net/browse/JDK-8233040 From fastegal at swingempire.de Sat Oct 26 15:20:11 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 26 Oct 2019 17:20:11 +0200 Subject: Okay to open a bug? In-Reply-To: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> References: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> Message-ID: <20191026172011.Horde.Wi_cV0XQLmLSrvyQ0Vw4Gw1@webmail.df.eu> argggg ... wrong bug id: https://bugs.openjdk.java.net/browse/JDK-8233040 Zitat von Jeanette Winzenburg : > Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) > and accidentally opened it - the child in me can't refrain from > clicking buttons to see what happens ;) Having it opened, I went the > whole way and assigned it to me (it's in my current line of interes > anyway). > > Not certain if I maybe violated some procedure on the side of jbs? > If so, please revert everything (except the bug, of course :) > > Happy weekend, > Jeanette From philip.race at oracle.com Sat Oct 26 16:08:19 2019 From: philip.race at oracle.com (Philip Race) Date: Sat, 26 Oct 2019 09:08:19 -0700 Subject: Okay to open a bug? In-Reply-To: <20191026172011.Horde.Wi_cV0XQLmLSrvyQ0Vw4Gw1@webmail.df.eu> References: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> <20191026172011.Horde.Wi_cV0XQLmLSrvyQ0Vw4Gw1@webmail.df.eu> Message-ID: <5DB46F73.8000202@oracle.com> I see no problem with filing a bug .. and bonus points for assigning it to yourself and triaging it. -phil. On 10/26/19, 8:20 AM, Jeanette Winzenburg wrote: > > argggg ... wrong bug id: https://bugs.openjdk.java.net/browse/JDK-8233040 > > Zitat von Jeanette Winzenburg : > >> Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) >> and accidentally opened it - the child in me can't refrain from >> clicking buttons to see what happens ;) Having it opened, I went the >> whole way and assigned it to me (it's in my current line of interes >> anyway). >> >> Not certain if I maybe violated some procedure on the side of jbs? If >> so, please revert everything (except the bug, of course :) >> >> Happy weekend, >> Jeanette > > > From nlisker at gmail.com Sat Oct 26 18:17:25 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 26 Oct 2019 21:17:25 +0300 Subject: Okay to open a bug? In-Reply-To: <5DB46F73.8000202@oracle.com> References: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> <20191026172011.Horde.Wi_cV0XQLmLSrvyQ0Vw4Gw1@webmail.df.eu> <5DB46F73.8000202@oracle.com> Message-ID: I triage and self-assign my issues by the dozens :) On Sat, Oct 26, 2019 at 7:07 PM Philip Race wrote: > I see no problem with filing a bug .. and bonus points for assigning it > to yourself and triaging it. > > -phil. > > On 10/26/19, 8:20 AM, Jeanette Winzenburg wrote: > > > > argggg ... wrong bug id: > https://bugs.openjdk.java.net/browse/JDK-8233040 > > > > Zitat von Jeanette Winzenburg : > > > >> Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) > >> and accidentally opened it - the child in me can't refrain from > >> clicking buttons to see what happens ;) Having it opened, I went the > >> whole way and assigned it to me (it's in my current line of interes > >> anyway). > >> > >> Not certain if I maybe violated some procedure on the side of jbs? If > >> so, please revert everything (except the bug, of course :) > >> > >> Happy weekend, > >> Jeanette > > > > > > > From fastegal at swingempire.de Sun Oct 27 16:20:27 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sun, 27 Oct 2019 17:20:27 +0100 Subject: Okay to open a bug? In-Reply-To: References: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> <20191026172011.Horde.Wi_cV0XQLmLSrvyQ0Vw4Gw1@webmail.df.eu> <5DB46F73.8000202@oracle.com> Message-ID: <20191027172027.Horde.cUrdwTlPT2Zw54M0RBYtGA6@webmail.df.eu> thanks :) Zitat von Nir Lisker : > I triage and self-assign my issues by the dozens :) > > On Sat, Oct 26, 2019 at 7:07 PM Philip Race wrote: > >> I see no problem with filing a bug .. and bonus points for assigning it >> to yourself and triaging it. >> >> -phil. >> >> On 10/26/19, 8:20 AM, Jeanette Winzenburg wrote: >> > >> > argggg ... wrong bug id: >> https://bugs.openjdk.java.net/browse/JDK-8233040 >> > >> > Zitat von Jeanette Winzenburg : >> > >> >> Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) >> >> and accidentally opened it - the child in me can't refrain from >> >> clicking buttons to see what happens ;) Having it opened, I went the >> >> whole way and assigned it to me (it's in my current line of interes >> >> anyway). >> >> >> >> Not certain if I maybe violated some procedure on the side of jbs? If >> >> so, please revert everything (except the bug, of course :) >> >> >> >> Happy weekend, >> >> Jeanette >> > >> > >> > >> From sproket at videotron.ca Sun Oct 27 20:51:22 2019 From: sproket at videotron.ca (Dan Howard) Date: Sun, 27 Oct 2019 16:51:22 -0400 Subject: Okay to open a bug? In-Reply-To: References: Message-ID: How do you register to file a bug? I don't see any registration link On 10/26/2019 11:18 AM, Jeanette Winzenburg wrote: > > the bug reference in my last message - was wrong, it's > https://bugs.openjdk.java.net/browse/JDK-8233040 > > From nlisker at gmail.com Sun Oct 27 20:54:51 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 27 Oct 2019 22:54:51 +0200 Subject: Okay to open a bug? In-Reply-To: References: Message-ID: If you have at least an Author role you will be given a JBS account. Otherwise, use the link https://bugs.java.com and your bug will be transferred to JBS after triage. - Nir On Sun, Oct 27, 2019 at 10:51 PM Dan Howard wrote: > How do you register to file a bug? I don't see any registration link > > On 10/26/2019 11:18 AM, Jeanette Winzenburg wrote: > > > > the bug reference in my last message - was wrong, it's > > https://bugs.openjdk.java.net/browse/JDK-8233040 > > > > > From kevin.rushforth at oracle.com Mon Oct 28 14:14:51 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 28 Oct 2019 07:14:51 -0700 Subject: Okay to open a bug? In-Reply-To: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> References: <20191026171655.Horde.ybidK9-PPs8AFi57NJE0ng1@webmail.df.eu> Message-ID: <02410b0e-25c1-ba79-f285-de51c374a4bd@oracle.com> Jo Jeanette, This is fine since it's one you expect to work on yourself. Thanks. -- Kevin On 10/26/2019 8:16 AM, Jeanette Winzenburg wrote: > > Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) > and accidentally opened it - the child in me can't refrain from > clicking buttons to see what happens ;) Having it opened, I went the > whole way and assigned it to me (it's in my current line of interes > anyway). > > Not certain if I maybe violated some procedure on the side of jbs? If > so, please revert everything (except the bug, of course :) > > Happy weekend, > Jeanette > From sproket at videotron.ca Mon Oct 28 22:55:12 2019 From: sproket at videotron.ca (Dan Howard) Date: Mon, 28 Oct 2019 18:55:12 -0400 Subject: Okay to open a bug? In-Reply-To: References: Message-ID: <0c41692d-df50-354d-95d3-fb93485c4f87@videotron.ca> Thanks. I'll follow up on it. On 10/27/2019 4:54 PM, Nir Lisker wrote: > If you have at least an Author role you will be given a JBS account. > Otherwise, use the link https://bugs.java.com and your bug will be > transferred to JBS after triage. > > - Nir > > On Sun, Oct 27, 2019 at 10:51 PM Dan Howard > wrote: > > How do you register to file a bug? I don't see any registration link > > On 10/26/2019 11:18 AM, Jeanette Winzenburg wrote: > > > > the bug reference in my last message - was wrong, it's > > https://bugs.openjdk.java.net/browse/JDK-8233040 > > > > > From jvos at openjdk.org Tue Oct 29 09:40:24 2019 From: jvos at openjdk.org (Johan Vos) Date: Tue, 29 Oct 2019 09:40:24 GMT Subject: [Approved] RFR: 8232943: Gesture support is not initialized on iOS In-Reply-To: References: Message-ID: On Fri, 25 Oct 2019 09:29:16 GMT, Jose Pereda wrote: > This PR only affects iOS native code. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8232943 > > Since the `IosGestureSupport` class is only instantiated from the native side, the proposal is to change in `ios/GlassViewDelegate.m` the use of `FindClass` in favor of `[GlassHelper ClassForName]`, in the same way as it is done in [`mac/GlassViewDelegate.m`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m#L614) to instantiate `MacGestureSupport`. > > ---------------- > > Commits: > - 49f39910: Use ClassForName instead of FindClass > > Changes: https://git.openjdk.java.net/jfx/pull/23/files > Webrev: https://webrevs.openjdk.java.net/jfx/23/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232943 > Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/23.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/23/head:pull/23 While the class should also be initialised by using (*env)->FindClass, it is more in line with other parts in the code (and other platforms) to use the GlassHelper for this. ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/23 From jvos at openjdk.org Tue Oct 29 09:53:28 2019 From: jvos at openjdk.org (Johan Vos) Date: Tue, 29 Oct 2019 09:53:28 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: > On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >> >> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >> >> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >> >> ---------------- >> >> Commits: >> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >> >> Changes: https://git.openjdk.java.net/jfx/pull/5/files >> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 > > This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. > > ---------------- > > Disapproved by kcr (Lead). Is this PR open for review now? Or will a new PR be created? PR: https://git.openjdk.java.net/jfx/pull/5 From jvos at openjdk.org Tue Oct 29 10:04:31 2019 From: jvos at openjdk.org (Johan Vos) Date: Tue, 29 Oct 2019 10:04:31 GMT Subject: [Integrated] RFR: 8232943: Gesture support is not initialized on iOS In-Reply-To: References: Message-ID: <8db709a3-488e-486d-9ca8-c6dd37431653@openjdk.org> Changeset: dca8df4e Author: Jose Pereda Committer: Johan Vos Date: 2019-10-29 10:03:54 +0000 URL: https://git.openjdk.java.net/jfx/commit/dca8df4e 8232943: Gesture support is not initialized on iOS Reviewed-by: jvos ! modules/javafx.graphics/src/main/native-glass/ios/GlassViewDelegate.m From github.com+12861109+dellgreen at openjdk.org Tue Oct 29 10:10:32 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Tue, 29 Oct 2019 10:10:32 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: <7b3FypbOegTPgE32Ab6wK_-o-RhqLEQjfUrbgDyDzQQ=.ace45171-6730-4997-9f38-567e8e114eea@github.com> On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: > On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: > >> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >> >>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>> >>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>> >>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>> >>> ---------------- >>> >>> Commits: >>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >> >> This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. >> >> ---------------- >> >> Disapproved by kcr (Lead). > > Is this PR open for review now? Or will a new PR be created? this is ready for review form my perspective. :) PR: https://git.openjdk.java.net/jfx/pull/5 From github.com+6547435+FlorianKirmaier at openjdk.org Tue Oct 29 11:27:35 2019 From: github.com+6547435+FlorianKirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 29 Oct 2019 11:27:35 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus Message-ID: Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). This fix introduced synthesized press-events, which is an unsafe fix for the problem. The pull request introduces a new fix for the problem. Instead of simulating new input-events, we set JavaFX Scene/Window to focused. We do so, by using setFocused. When the original Swing-Focus event is called slightly later, it won't have any side-effects, because calling setFocused just sets the value of a boolean property. I've now also added a unit-test for the problem. ---------------- Commits: - 314e423c: JDK-8200224 - 725e5fef: JDK-8200224 Changes: https://git.openjdk.java.net/jfx/pull/25/files Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.org Tue Oct 29 11:31:18 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 29 Oct 2019 11:31:18 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <7b3FypbOegTPgE32Ab6wK_-o-RhqLEQjfUrbgDyDzQQ=.ace45171-6730-4997-9f38-567e8e114eea@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <7b3FypbOegTPgE32Ab6wK_-o-RhqLEQjfUrbgDyDzQQ=.ace45171-6730-4997-9f38-567e8e114eea@github.com> Message-ID: On Tue, 29 Oct 2019 10:10:32 GMT, Dell Green wrote: > On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: > >> On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: >> >>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>> >>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>> >>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>> >>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>> >>> This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. >>> >>> ---------------- >>> >>> Disapproved by kcr (Lead). >> >> Is this PR open for review now? Or will a new PR be created? > > this is ready for review form my perspective. :) The Skara tooling bug in question has been fixed, so yes this is ready for review. PR: https://git.openjdk.java.net/jfx/pull/5 From shadzic at openjdk.org Tue Oct 29 13:19:27 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Tue, 29 Oct 2019 13:19:27 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Wed, 9 Oct 2019 16:01:38 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: > >> On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: >> >>> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >>> >>>> Allright, this is a fix for JDK-8207957 >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 969ebb51: Fixing TableColumnHeaderTest >>>> - 9d379619: Removing Tablecolumnbasehelper >>>> - 4fe020fc: Fix javadoc for TableColumnHeader >>>> - c422c80f: Minor modification and uni test added. >>>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>> >>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >>> >>>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>>> 600: * {@code super()}) to provide their custom algorithm. >>>> 601: * >>> >>> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) >> >> Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. >> >> I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. > > A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. Do you think this looks good now @kleopatra @nlisker ? PR: https://git.openjdk.java.net/jfx/pull/6 From nlisker at openjdk.org Tue Oct 29 14:38:10 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 29 Oct 2019 14:38:10 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 16:18:49 GMT, Kevin Rushforth wrote: > On Wed, 9 Oct 2019 16:11:49 GMT, Hadzic Samir wrote: > >> On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: >> >>> The pull request has been updated with additional changes. >>> >>> ---------------- >>> >>> Added commits: >>> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >>> >>> Changes: >>> - all: https://git.openjdk.java.net/jfx/pull/6/files >>> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >>> >>> Webrevs: >>> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >>> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >> >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: >> >>> 607: protected void resizeColumnToFitContent(int maxRows) { >>> 608: TableColumnBase tc = getTableColumn(); >>> 609: if (!tc.isResizable()) return; >> >> I have put the `since 14`, because if merged, it will be available in OpenJFX 14 right? (It was 13 before) > > Correct. The "The resulting column width for this implementation..." part might belong in an `@implSpec` section. PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Tue Oct 29 14:45:46 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 29 Oct 2019 14:45:46 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 > > A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. > The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). > This fix introduced synthesized press-events, which is an unsafe fix for the problem. > > The pull request introduces a new fix for the problem. > Instead of simulating new input-events, we set JavaFX Scene/Window to focused. > We do so, by using setFocused. > When the original Swing-Focus event is called slightly later, it won't have any side-effects, > because calling setFocused just sets the value of a boolean property. > > I've now also added a unit-test for the problem. > > ---------------- > > Commits: > - 314e423c: JDK-8200224 > - 725e5fef: JDK-8200224 > > Changes: https://git.openjdk.java.net/jfx/pull/25/files > Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 @FlorianKirmaier you still need to file a JBS issue to associate your GitHub username with your OpenJDK user ID as noted [above](#issuecomment-546883472), and per the instructions in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html) sent to openjfx-dev. PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.org Tue Oct 29 14:47:19 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 29 Oct 2019 14:47:19 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 14:45:46 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > >> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >> >> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >> >> The pull request introduces a new fix for the problem. >> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >> We do so, by using setFocused. >> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >> because calling setFocused just sets the value of a boolean property. >> >> I've now also added a unit-test for the problem. >> >> ---------------- >> >> Commits: >> - 314e423c: JDK-8200224 >> - 725e5fef: JDK-8200224 >> >> Changes: https://git.openjdk.java.net/jfx/pull/25/files >> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 > > @FlorianKirmaier you still need to file a JBS issue to associate your GitHub username with your OpenJDK user ID as noted [above](#issuecomment-546883472), and per the instructions in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html) sent to openjfx-dev. @prsadhuk please review this. I will also review it (this will need two reviewers). PR: https://git.openjdk.java.net/jfx/pull/25 From github.com+6547435+FlorianKirmaier at openjdk.org Tue Oct 29 15:48:46 2019 From: github.com+6547435+FlorianKirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 29 Oct 2019 15:48:46 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 14:47:19 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 14:45:46 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >> >>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>> >>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>> >>> The pull request introduces a new fix for the problem. >>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>> We do so, by using setFocused. >>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>> because calling setFocused just sets the value of a boolean property. >>> >>> I've now also added a unit-test for the problem. >>> >>> ---------------- >>> >>> Commits: >>> - 314e423c: JDK-8200224 >>> - 725e5fef: JDK-8200224 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >> >> @FlorianKirmaier you still need to file a JBS issue to associate your GitHub username with your OpenJDK user ID as noted [above](#issuecomment-546883472), and per the instructions in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html) sent to openjfx-dev. > > @prsadhuk please review this. I will also review it (this will need two reviewers). @kevinrushforth If created the ticket a moment ago. https://bugs.openjdk.java.net/browse/JDK-8233121 Is this okay, or is any information missing? PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.org Tue Oct 29 15:59:58 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 29 Oct 2019 15:59:58 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 15:48:46 GMT, Florian Kirmaier wrote: > On Tue, 29 Oct 2019 14:47:19 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 14:45:46 GMT, Kevin Rushforth wrote: >> >>> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >>> >>>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>>> >>>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>>> >>>> The pull request introduces a new fix for the problem. >>>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>>> We do so, by using setFocused. >>>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>>> because calling setFocused just sets the value of a boolean property. >>>> >>>> I've now also added a unit-test for the problem. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 314e423c: JDK-8200224 >>>> - 725e5fef: JDK-8200224 >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >>> >>> @FlorianKirmaier you still need to file a JBS issue to associate your GitHub username with your OpenJDK user ID as noted [above](#issuecomment-546883472), and per the instructions in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html) sent to openjfx-dev. >> >> @prsadhuk please review this. I will also review it (this will need two reviewers). > > @kevinrushforth > If created the ticket a moment ago. https://bugs.openjdk.java.net/browse/JDK-8233121 > Is this okay, or is any information missing? > https://bugs.openjdk.java.net/browse/JDK-8233121 It was created in the JDK Project rather than the SKARA project (odd...the link should have filled in the right project and component). I fixed it. PR: https://git.openjdk.java.net/jfx/pull/25 From github.com+6547435+FlorianKirmaier at openjdk.org Tue Oct 29 16:27:17 2019 From: github.com+6547435+FlorianKirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 29 Oct 2019 16:27:17 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 15:59:58 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 15:48:46 GMT, Florian Kirmaier wrote: > >> On Tue, 29 Oct 2019 14:47:19 GMT, Kevin Rushforth wrote: >> >>> On Tue, 29 Oct 2019 14:45:46 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >>>> >>>>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>>>> >>>>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>>>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>>>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>>>> >>>>> The pull request introduces a new fix for the problem. >>>>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>>>> We do so, by using setFocused. >>>>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>>>> because calling setFocused just sets the value of a boolean property. >>>>> >>>>> I've now also added a unit-test for the problem. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 314e423c: JDK-8200224 >>>>> - 725e5fef: JDK-8200224 >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>>>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >>>> >>>> @FlorianKirmaier you still need to file a JBS issue to associate your GitHub username with your OpenJDK user ID as noted [above](#issuecomment-546883472), and per the instructions in [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023558.html) sent to openjfx-dev. >>> >>> @prsadhuk please review this. I will also review it (this will need two reviewers). >> >> @kevinrushforth >> If created the ticket a moment ago. https://bugs.openjdk.java.net/browse/JDK-8233121 >> Is this okay, or is any information missing? > >> https://bugs.openjdk.java.net/browse/JDK-8233121 > > It was created in the JDK Project rather than the SKARA project (odd...the link should have filled in the right project and component). I fixed it. Great, thanks. Some more notes on the importance of this Change. A project which uses a lot of JFXPanels for small components was basically unusable because the majority of clicks were registered as a double click. This made the software basically unusable with JavaFX11. PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.org Tue Oct 29 23:05:44 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 29 Oct 2019 23:05:44 GMT Subject: RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 Message-ID: This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. The `*ext.h` header files were updated fairly recently, so those diffs are not large. Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. This reduces the number of upstream sources we need to monitor. I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. ---------------- Commits: - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 Changes: https://git.openjdk.java.net/jfx/pull/26/files Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod Patch: https://git.openjdk.java.net/jfx/pull/26.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 PR: https://git.openjdk.java.net/jfx/pull/26 From kcr at openjdk.org Tue Oct 29 23:05:46 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 29 Oct 2019 23:05:46 GMT Subject: RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote: > This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. > > The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. > > The `*ext.h` header files were updated fairly recently, so those diffs are not large. > > Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. > > This reduces the number of upstream sources we need to monitor. > > I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. > > I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. > > As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. > > ---------------- > > Commits: > - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 > > Changes: https://git.openjdk.java.net/jfx/pull/26/files > Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 > Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod > Patch: https://git.openjdk.java.net/jfx/pull/26.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 Reviewers: @prrace, @arapte, @johanvos PR: https://git.openjdk.java.net/jfx/pull/26 From serb at openjdk.org Wed Oct 30 00:43:08 2019 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Oct 2019 00:43:08 GMT Subject: RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 23:05:46 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote: > >> This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. >> >> The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. >> >> The `*ext.h` header files were updated fairly recently, so those diffs are not large. >> >> Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. >> >> This reduces the number of upstream sources we need to monitor. >> >> I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. >> >> I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. >> >> As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. >> >> ---------------- >> >> Commits: >> - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 >> >> Changes: https://git.openjdk.java.net/jfx/pull/26/files >> Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 >> Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod >> Patch: https://git.openjdk.java.net/jfx/pull/26.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 > > Reviewers: @prrace, @arapte, @johanvos Not sure but should not the license be GPL+CP in some of these files? PR: https://git.openjdk.java.net/jfx/pull/26 From prr at openjdk.org Wed Oct 30 00:45:17 2019 From: prr at openjdk.org (Phil Race) Date: Wed, 30 Oct 2019 00:45:17 GMT Subject: RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 00:43:08 GMT, Sergey Bylokhov wrote: > On Tue, 29 Oct 2019 23:05:46 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote: >> >>> This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. >>> >>> The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. >>> >>> The `*ext.h` header files were updated fairly recently, so those diffs are not large. >>> >>> Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. >>> >>> This reduces the number of upstream sources we need to monitor. >>> >>> I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. >>> >>> I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. >>> >>> As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. >>> >>> ---------------- >>> >>> Commits: >>> - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/26/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 >>> Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/26.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 >> >> Reviewers: @prrace, @arapte, @johanvos > > Not sure but should not the license be GPL+CP in some of these files? > Not sure but should not the license be GPL+CP in some of these files? It is not necessary. PR: https://git.openjdk.java.net/jfx/pull/26 From prr at openjdk.org Wed Oct 30 00:48:17 2019 From: prr at openjdk.org (Phil Race) Date: Wed, 30 Oct 2019 00:48:17 GMT Subject: [Approved] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote: > This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. > > The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. > > The `*ext.h` header files were updated fairly recently, so those diffs are not large. > > Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. > > This reduces the number of upstream sources we need to monitor. > > I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. > > I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. > > As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. > > ---------------- > > Commits: > - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 > > Changes: https://git.openjdk.java.net/jfx/pull/26/files > Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 > Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod > Patch: https://git.openjdk.java.net/jfx/pull/26.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 Approved by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/26 From github.com+24428922+arun-Joseph at openjdk.org Wed Oct 30 10:07:42 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Wed, 30 Oct 2019 10:07:42 GMT Subject: RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it Message-ID: In the HTMLEditor, when positioning the caret in a text and trying to set a font-family that has a number in it is not working. Issue: In [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp), concatenateFamilyName() function parses only identifiers. So, when a number is introduced in a font-name, it fails. Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes. A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf ---------------- Commits: - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a number in it Changes: https://git.openjdk.java.net/jfx/pull/27/files Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 PR: https://git.openjdk.java.net/jfx/pull/27 From shadzic at openjdk.org Wed Oct 30 10:27:28 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 30 Oct 2019 10:27:28 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 14:38:10 GMT, Nir Lisker wrote: > On Wed, 9 Oct 2019 16:18:49 GMT, Kevin Rushforth wrote: > >> On Wed, 9 Oct 2019 16:11:49 GMT, Hadzic Samir wrote: >> >>> On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: >>> >>>> The pull request has been updated with additional changes. >>>> >>>> ---------------- >>>> >>>> Added commits: >>>> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >>>> >>>> Changes: >>>> - all: https://git.openjdk.java.net/jfx/pull/6/files >>>> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >>>> >>>> Webrevs: >>>> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >>>> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>> >>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: >>> >>>> 607: protected void resizeColumnToFitContent(int maxRows) { >>>> 608: TableColumnBase tc = getTableColumn(); >>>> 609: if (!tc.isResizable()) return; >>> >>> I have put the `since 14`, because if merged, it will be available in OpenJFX 14 right? (It was 13 before) >> >> Correct. > > The "The resulting column width for this implementation..." part might belong in an `@implSpec` section. >From https://openjdk.java.net/jeps/8068562 > Implementation Specification. This is where the default implementation (or an overrideable implementation in a class) is specified. Interface implementors or class subclassers use the information here in order to decide whether it is sensible or necessary to override a particular method, and what behavior they can rely on if a method is called via super. So maybe the whole part beginning from "The resulting column [..]width etc.)." should be in the `@implSpec` section. PR: https://git.openjdk.java.net/jfx/pull/6 From nlisker at openjdk.org Wed Oct 30 10:36:39 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 30 Oct 2019 10:36:39 GMT Subject: [Rev 01] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 10:27:28 GMT, Hadzic Samir wrote: > On Tue, 29 Oct 2019 14:38:10 GMT, Nir Lisker wrote: > >> On Wed, 9 Oct 2019 16:18:49 GMT, Kevin Rushforth wrote: >> >>> On Wed, 9 Oct 2019 16:11:49 GMT, Hadzic Samir wrote: >>> >>>> On Wed, 9 Oct 2019 12:25:26 GMT, Hadzic Samir wrote: >>>> >>>>> The pull request has been updated with additional changes. >>>>> >>>>> ---------------- >>>>> >>>>> Added commits: >>>>> - e846e51c: Remove TableColumn argument for resizeColumnToFitContent for clarification on TableColumnHeader >>>>> >>>>> Changes: >>>>> - all: https://git.openjdk.java.net/jfx/pull/6/files >>>>> - new: https://git.openjdk.java.net/jfx/pull/6/files/969ebb51..e846e51c >>>>> >>>>> Webrevs: >>>>> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.01 >>>>> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.00-01 >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>>> Stats: 27 lines in 3 files changed: 13 ins; 1 del; 13 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>>> >>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 608: >>>> >>>>> 607: protected void resizeColumnToFitContent(int maxRows) { >>>>> 608: TableColumnBase tc = getTableColumn(); >>>>> 609: if (!tc.isResizable()) return; >>>> >>>> I have put the `since 14`, because if merged, it will be available in OpenJFX 14 right? (It was 13 before) >>> >>> Correct. >> >> The "The resulting column width for this implementation..." part might belong in an `@implSpec` section. > > From https://openjdk.java.net/jeps/8068562 > >> Implementation Specification. This is where the default implementation (or an overrideable implementation in a class) is specified. Interface implementors or class subclassers use the information here in order to decide whether it is sensible or necessary to override a particular method, and what behavior they can rely on if a method is called via super. > > So maybe the whole part beginning from "The resulting column [..]width etc.)." should be in the `@implSpec` section. Yes. PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Wed Oct 30 11:09:38 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 30 Oct 2019 11:09:38 GMT Subject: RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 10:07:42 GMT, Arun Joseph wrote: > In the HTMLEditor, when positioning the caret in a text and trying to set a font-family that has a number in it is not working. > > Issue: In [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp), concatenateFamilyName() function parses only identifiers. So, when a number is introduced in a font-name, it fails. > > Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes. > > A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf > > ---------------- > > Commits: > - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a number in it > > Changes: https://git.openjdk.java.net/jfx/pull/27/files > Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 > Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/27.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 Will this be in conflict with https://github.com/openjdk/jfx/pull/12 ? I'll look at your unit tests in order to implement one similar PR: https://git.openjdk.java.net/jfx/pull/27 From kcr at openjdk.org Wed Oct 30 13:27:32 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 30 Oct 2019 13:27:32 GMT Subject: RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 11:09:38 GMT, Hadzic Samir wrote: > On Wed, 30 Oct 2019 10:07:42 GMT, Arun Joseph wrote: > >> In the HTMLEditor, when positioning the caret in a text and trying to set a font-family that has a number in it is not working. >> >> Issue: In [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp), concatenateFamilyName() function parses only identifiers. So, when a number is introduced in a font-name, it fails. >> >> Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes. >> >> A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf >> >> ---------------- >> >> Commits: >> - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a number in it >> >> Changes: https://git.openjdk.java.net/jfx/pull/27/files >> Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 >> Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/27.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 > > Will this be in conflict with https://github.com/openjdk/jfx/pull/12 ? I'll look at your unit tests in order to implement one similar I would think that the two fixes are independent of one another, but it would be a good idea to test HTMLEditor with both patches applied. PR: https://git.openjdk.java.net/jfx/pull/27 From shadzic at openjdk.org Wed Oct 30 13:59:08 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 30 Oct 2019 13:59:08 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Wed Oct 30 14:01:58 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 30 Oct 2019 14:01:58 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/6/files > - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 > - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 611: > 610: protected void resizeColumnToFitContent(int maxRows) { > 611: TableColumnBase tc = getTableColumn(); > 612: if (!tc.isResizable()) return; @nlisker I have added it this way. The auto-format of IntelliJ wanted to put the param before the implSpec but the documentation shows an example like that : > /** > * ... API specifications ... > * > * @apiNote > * ... API notes ... > * > * @implSpec > * ... implementation specification ... > * > * @implNote > * ... implementation notes ... > * > * @param ... > * @return ... > * @throws ... > */ So I thought this was the right way, let me know if I'm mistaken PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Wed Oct 30 20:46:53 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 30 Oct 2019 20:46:53 GMT Subject: [Rev 01] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: <1lm1yopfu5TCS3g_SvJksKuYu_mTLvjeaPn5JBtUcgI=.869a211e-ea1e-451b-8cf4-830ab4d89b64@github.com> The pull request has been updated with additional changes. ---------------- Added commits: - 5686a382: Update third-party license file to remove unneeded lines Changes: - all: https://git.openjdk.java.net/jfx/pull/26/files - new: https://git.openjdk.java.net/jfx/pull/26/files/7a520adc..5686a382 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/26/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/26/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/26.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 PR: https://git.openjdk.java.net/jfx/pull/26 From prr at openjdk.org Wed Oct 30 20:49:59 2019 From: prr at openjdk.org (Phil Race) Date: Wed, 30 Oct 2019 20:49:59 GMT Subject: [Approved] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote: > This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. > > The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. > > The `*ext.h` header files were updated fairly recently, so those diffs are not large. > > Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. > > This reduces the number of upstream sources we need to monitor. > > I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. > > I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. > > As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. > > ---------------- > > Commits: > - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 > > Changes: https://git.openjdk.java.net/jfx/pull/26/files > Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 > Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod > Patch: https://git.openjdk.java.net/jfx/pull/26.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 Approved by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/26 From nlisker at openjdk.org Thu Oct 31 12:18:37 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 31 Oct 2019 12:18:37 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 14:01:58 GMT, Hadzic Samir wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 611: > >> 610: protected void resizeColumnToFitContent(int maxRows) { >> 611: TableColumnBase tc = getTableColumn(); >> 612: if (!tc.isResizable()) return; > > @nlisker I have added it this way. The auto-format of IntelliJ wanted to put the param before the implSpec but the documentation shows an example like that : > >> /** >> * ... API specifications ... >> * >> * @apiNote >> * ... API notes ... >> * >> * @implSpec >> * ... implementation specification ... >> * >> * @implNote >> * ... implementation notes ... >> * >> * @param ... >> * @return ... >> * @throws ... >> */ > > So I thought this was the right way, let me know if I'm mistaken The generated docs will have the tags in the correct order as specified in the [build.gradle](https://github.com/openjdk/jfx/blob/master/build.gradle#L3953) file regardless of the order in the source code. This is what the [JDK](http://hg.openjdk.java.net/jdk/jdk/file/tip/make/Docs.gmk#l74) also uses and appears to be the same as the example you quoted. IntelliJ's order seems to be different. I would stick to JDK's order in the source as well just for consistency. PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at swingempire.de Thu Oct 31 13:41:02 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 31 Oct 2019 14:41:02 +0100 Subject: Problem with gradle ... Message-ID: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> .. fails (gradle run from cygwin console) with: * Where: Build file 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' line: 250 * What went wrong: A problem occurred evaluating root project 'jfx-fork'. > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 which is rather clear in itself, but ... how to update? It seems to too nothing, not even list the tasks CU, Jeanette From nlisker at gmail.com Thu Oct 31 13:47:49 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 31 Oct 2019 15:47:49 +0200 Subject: Problem with gradle ... In-Reply-To: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> Message-ID: Did you run the wrapper with gradlew or just gradle? The latter uses the "global" version installed on the OS which might not be up to date (use 'gradle --version' to check). - Nir On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg wrote: > > .. fails (gradle run from cygwin console) with: > > * Where: > Build file > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > line: 250 > > * What went wrong: > A problem occurred evaluating root project 'jfx-fork'. > > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 > > which is rather clear in itself, but ... how to update? It seems to > too nothing, not even list the tasks > > CU, Jeanette > > > > From kevin.rushforth at oracle.com Thu Oct 31 13:51:18 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 31 Oct 2019 06:51:18 -0700 Subject: Problem with gradle ... In-Reply-To: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> Message-ID: <8864da0c-1d0c-6a0c-b0c1-afea35a60d00@oracle.com> If you are hitting this error, then you must have your own local installation on gradle. You can either update that local installation manually, or you can use "gradlew" which will always use the supported version of gradle: sh gradlew ... -- Kevin On 10/31/2019 6:41 AM, Jeanette Winzenburg wrote: > > .. fails (gradle run from cygwin console) with: > > * Where: > Build file > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > line: 250 > > * What went wrong: > A problem occurred evaluating root project 'jfx-fork'. >> FAIL: Gradle version too old: 4.10.2; must be at least 5.3 > > which is rather clear in itself, but ... how to update? It seems to > too nothing, not even list the tasks > > CU, Jeanette > > > From fastegal at swingempire.de Thu Oct 31 13:58:04 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 31 Oct 2019 14:58:04 +0100 Subject: Problem with gradle ... In-Reply-To: References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> Message-ID: <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> Zitat von Nir Lisker : > Did you run the wrapper with gradlew or just gradle? The latter uses the > "global" version installed on the OS which might not be up to date (use > 'gradle --version' to check). > in my cygwin console I type: gradle and get the error message .. hmm ... so, yeah seems to be global version that's out of date. Are you saying that using gradlew (*cough - how exactly?) would keep the required version up-to-date? Thanks Jeanette > - Nir > > On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg > wrote: > >> >> .. fails (gradle run from cygwin console) with: >> >> * Where: >> Build file >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >> line: 250 >> >> * What went wrong: >> A problem occurred evaluating root project 'jfx-fork'. >> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 >> >> which is rather clear in itself, but ... how to update? It seems to >> too nothing, not even list the tasks >> >> CU, Jeanette >> >> >> >> From swpalmer at gmail.com Thu Oct 31 14:00:44 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 31 Oct 2019 10:00:44 -0400 Subject: Problem with gradle ... In-Reply-To: <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> Message-ID: <181A70F2-F0E1-445A-B49F-B596877FFFFD@gmail.com> The wrapper script works just like the gradle command but uses the gradle version specified by the project. See https://docs.gradle.org/current/userguide/gradle_wrapper.html > On Oct 31, 2019, at 9:58 AM, Jeanette Winzenburg wrote: > > > Zitat von Nir Lisker : > >> Did you run the wrapper with gradlew or just gradle? The latter uses the >> "global" version installed on the OS which might not be up to date (use >> 'gradle --version' to check). >> > > > in my cygwin console I type: > > gradle > > and get the error message .. hmm ... so, yeah seems to be global version that's out of date. > > Are you saying that using gradlew (*cough - how exactly?) would keep the required version up-to-date? > > Thanks > Jeanette > >> - Nir >> >> On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg >> wrote: >> >>> >>> .. fails (gradle run from cygwin console) with: >>> >>> * Where: >>> Build file >>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >>> line: 250 >>> >>> * What went wrong: >>> A problem occurred evaluating root project 'jfx-fork'. >>> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 >>> >>> which is rather clear in itself, but ... how to update? It seems to >>> too nothing, not even list the tasks >>> >>> CU, Jeanette >>> From nlisker at gmail.com Thu Oct 31 14:03:43 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 31 Oct 2019 16:03:43 +0200 Subject: Problem with gradle ... In-Reply-To: <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> Message-ID: Yes, the wrapper will know to download the correct version. I updated the build instructions page [1] to be more specific about the wrapper recently, and there is another update coming soon due to a problem I recently encountered with the buildsrc. Run ./gradlew from the root folder of the project (or give it the full path to it if you're not in the root folder). [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle On Thu, Oct 31, 2019 at 3:58 PM Jeanette Winzenburg wrote: > > Zitat von Nir Lisker : > > > Did you run the wrapper with gradlew or just gradle? The latter uses the > > "global" version installed on the OS which might not be up to date (use > > 'gradle --version' to check). > > > > > in my cygwin console I type: > > gradle > > and get the error message .. hmm ... so, yeah seems to be global > version that's out of date. > > Are you saying that using gradlew (*cough - how exactly?) would keep > the required version up-to-date? > > Thanks > Jeanette > > > - Nir > > > > On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg < > fastegal at swingempire.de> > > wrote: > > > >> > >> .. fails (gradle run from cygwin console) with: > >> > >> * Where: > >> Build file > >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > >> line: 250 > >> > >> * What went wrong: > >> A problem occurred evaluating root project 'jfx-fork'. > >> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 > >> > >> which is rather clear in itself, but ... how to update? It seems to > >> too nothing, not even list the tasks > >> > >> CU, Jeanette > >> > >> > >> > >> > > > > From fastegal at swingempire.de Thu Oct 31 14:11:45 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 31 Oct 2019 15:11:45 +0100 Subject: Problem with gradle ... In-Reply-To: References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> Message-ID: <20191031151145.Horde.RPaOPK4G9r62FiZ5RUAW1g1@webmail.df.eu> Zitat von Nir Lisker : > Yes, the wrapper will know to download the correct version. I updated the > build instructions page [1] to be more specific about the wrapper recently, > and there is another update coming soon due to a problem I recently > encountered with the buildsrc. > > Run ./gradlew from the root folder of the project (or give it the full path > to it if you're not in the root folder). > > [1] > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > ahhh .. cool, something happens :) Thanks for the pointer, should have checked the build instructions first .. - Jeanette > On Thu, Oct 31, 2019 at 3:58 PM Jeanette Winzenburg > wrote: > >> >> Zitat von Nir Lisker : >> >> > Did you run the wrapper with gradlew or just gradle? The latter uses the >> > "global" version installed on the OS which might not be up to date (use >> > 'gradle --version' to check). >> > >> >> >> in my cygwin console I type: >> >> gradle >> >> and get the error message .. hmm ... so, yeah seems to be global >> version that's out of date. >> >> Are you saying that using gradlew (*cough - how exactly?) would keep >> the required version up-to-date? >> >> Thanks >> Jeanette >> >> > - Nir >> > >> > On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg < >> fastegal at swingempire.de> >> > wrote: >> > >> >> >> >> .. fails (gradle run from cygwin console) with: >> >> >> >> * Where: >> >> Build file >> >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >> >> line: 250 >> >> >> >> * What went wrong: >> >> A problem occurred evaluating root project 'jfx-fork'. >> >> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 >> >> >> >> which is rather clear in itself, but ... how to update? It seems to >> >> too nothing, not even list the tasks >> >> >> >> CU, Jeanette >> >> >> >> >> >> >> >> >> >> >> >> From fastegal at swingempire.de Thu Oct 31 14:24:09 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 31 Oct 2019 15:24:09 +0100 Subject: Problem with gradle ... In-Reply-To: <20191031151145.Horde.RPaOPK4G9r62FiZ5RUAW1g1@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> <20191031151145.Horde.RPaOPK4G9r62FiZ5RUAW1g1@webmail.df.eu> Message-ID: <20191031152409.Horde.dFi0U1UwAhvVysz51Je-Ow1@webmail.df.eu> okay, now build everything went fine, but get an file access error > Task :controls:test FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':controls:test'. > java.nio.file.AccessDeniedException: > C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.controls\build\reports\tests\test Afaik, there are no access restrictions anywhere on my local (win10) machine .. hmm, any ideas what happened? - Jeanette Zitat von Jeanette Winzenburg : > Zitat von Nir Lisker : > >> Yes, the wrapper will know to download the correct version. I updated the >> build instructions page [1] to be more specific about the wrapper recently, >> and there is another update coming soon due to a problem I recently >> encountered with the buildsrc. >> >> Run ./gradlew from the root folder of the project (or give it the full path >> to it if you're not in the root folder). >> >> [1] >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle >> > > ahhh .. cool, something happens :) Thanks for the pointer, should > have checked the build instructions first .. > > - Jeanette > >> On Thu, Oct 31, 2019 at 3:58 PM Jeanette Winzenburg >> >> wrote: >> >>> >>> Zitat von Nir Lisker : >>> >>>> Did you run the wrapper with gradlew or just gradle? The latter uses the >>>> "global" version installed on the OS which might not be up to date (use >>>> 'gradle --version' to check). >>>> >>> >>> >>> in my cygwin console I type: >>> >>> gradle >>> >>> and get the error message .. hmm ... so, yeah seems to be global >>> version that's out of date. >>> >>> Are you saying that using gradlew (*cough - how exactly?) would keep >>> the required version up-to-date? >>> >>> Thanks >>> Jeanette >>> >>>> - Nir >>>> >>>> On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg < >>> fastegal at swingempire.de> >>>> wrote: >>>> >>>>> >>>>> .. fails (gradle run from cygwin console) with: >>>>> >>>>> * Where: >>>>> Build file >>>>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >>>>> line: 250 >>>>> >>>>> * What went wrong: >>>>> A problem occurred evaluating root project 'jfx-fork'. >>>>> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 >>>>> >>>>> which is rather clear in itself, but ... how to update? It seems to >>>>> too nothing, not even list the tasks >>>>> >>>>> CU, Jeanette >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> From nlisker at gmail.com Thu Oct 31 14:33:11 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 31 Oct 2019 16:33:11 +0200 Subject: Problem with gradle ... In-Reply-To: <20191031152409.Horde.dFi0U1UwAhvVysz51Je-Ow1@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> <20191031151145.Horde.RPaOPK4G9r62FiZ5RUAW1g1@webmail.df.eu> <20191031152409.Horde.dFi0U1UwAhvVysz51Je-Ow1@webmail.df.eu> Message-ID: Seems like an OS level issue. I've not gotten this one yet. Could be a file lock, read-only file, user permissions config etc. On Thu, Oct 31, 2019 at 4:24 PM Jeanette Winzenburg wrote: > > okay, now build everything went fine, but get an file access error > > > Task :controls:test FAILED > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':controls:test'. > > java.nio.file.AccessDeniedException: > > > C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.controls\build\reports\tests\test > > Afaik, there are no access restrictions anywhere on my local (win10) > machine .. hmm, any ideas what happened? > > - Jeanette > > Zitat von Jeanette Winzenburg : > > > Zitat von Nir Lisker : > > > >> Yes, the wrapper will know to download the correct version. I updated > the > >> build instructions page [1] to be more specific about the wrapper > recently, > >> and there is another update coming soon due to a problem I recently > >> encountered with the buildsrc. > >> > >> Run ./gradlew from the root folder of the project (or give it the full > path > >> to it if you're not in the root folder). > >> > >> [1] > >> > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > >> > > > > ahhh .. cool, something happens :) Thanks for the pointer, should > > have checked the build instructions first .. > > > > - Jeanette > > > >> On Thu, Oct 31, 2019 at 3:58 PM Jeanette Winzenburg > >> > >> wrote: > >> > >>> > >>> Zitat von Nir Lisker : > >>> > >>>> Did you run the wrapper with gradlew or just gradle? The latter uses > the > >>>> "global" version installed on the OS which might not be up to date > (use > >>>> 'gradle --version' to check). > >>>> > >>> > >>> > >>> in my cygwin console I type: > >>> > >>> gradle > >>> > >>> and get the error message .. hmm ... so, yeah seems to be global > >>> version that's out of date. > >>> > >>> Are you saying that using gradlew (*cough - how exactly?) would keep > >>> the required version up-to-date? > >>> > >>> Thanks > >>> Jeanette > >>> > >>>> - Nir > >>>> > >>>> On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg < > >>> fastegal at swingempire.de> > >>>> wrote: > >>>> > >>>>> > >>>>> .. fails (gradle run from cygwin console) with: > >>>>> > >>>>> * Where: > >>>>> Build file > >>>>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > >>>>> line: 250 > >>>>> > >>>>> * What went wrong: > >>>>> A problem occurred evaluating root project 'jfx-fork'. > >>>>> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 > >>>>> > >>>>> which is rather clear in itself, but ... how to update? It seems to > >>>>> too nothing, not even list the tasks > >>>>> > >>>>> CU, Jeanette > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > > > From fastegal at swingempire.de Thu Oct 31 14:48:15 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 31 Oct 2019 15:48:15 +0100 Subject: Problem with gradle ... In-Reply-To: References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> <20191031151145.Horde.RPaOPK4G9r62FiZ5RUAW1g1@webmail.df.eu> <20191031152409.Horde.dFi0U1UwAhvVysz51Je-Ow1@webmail.df.eu> Message-ID: <20191031154815.Horde.8RUSPn--iNVOdD6bf6_tEw1@webmail.df.eu> Zitat von Nir Lisker : > Seems like an OS level issue. I've not gotten this one yet. Could be a file > lock, read-only file, user permissions config etc. > yeah, for some reason the folder was write-protected .. removed for now, will dig later as to why it happened in the first place. Thanks for your support! - Jeanette > On Thu, Oct 31, 2019 at 4:24 PM Jeanette Winzenburg > wrote: > >> >> okay, now build everything went fine, but get an file access error >> >> > Task :controls:test FAILED >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':controls:test'. >> > java.nio.file.AccessDeniedException: >> > >> C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.controls\build\reports\tests\test >> >> Afaik, there are no access restrictions anywhere on my local (win10) >> machine .. hmm, any ideas what happened? >> >> - Jeanette >> >> Zitat von Jeanette Winzenburg : >> >> > Zitat von Nir Lisker : >> > >> >> Yes, the wrapper will know to download the correct version. I updated >> the >> >> build instructions page [1] to be more specific about the wrapper >> recently, >> >> and there is another update coming soon due to a problem I recently >> >> encountered with the buildsrc. >> >> >> >> Run ./gradlew from the root folder of the project (or give it the full >> path >> >> to it if you're not in the root folder). >> >> >> >> [1] >> >> >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle >> >> >> > >> > ahhh .. cool, something happens :) Thanks for the pointer, should >> > have checked the build instructions first .. >> > >> > - Jeanette >> > >> >> On Thu, Oct 31, 2019 at 3:58 PM Jeanette Winzenburg >> >> >> >> wrote: >> >> >> >>> >> >>> Zitat von Nir Lisker : >> >>> >> >>>> Did you run the wrapper with gradlew or just gradle? The latter uses >> the >> >>>> "global" version installed on the OS which might not be up to date >> (use >> >>>> 'gradle --version' to check). >> >>>> >> >>> >> >>> >> >>> in my cygwin console I type: >> >>> >> >>> gradle >> >>> >> >>> and get the error message .. hmm ... so, yeah seems to be global >> >>> version that's out of date. >> >>> >> >>> Are you saying that using gradlew (*cough - how exactly?) would keep >> >>> the required version up-to-date? >> >>> >> >>> Thanks >> >>> Jeanette >> >>> >> >>>> - Nir >> >>>> >> >>>> On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg < >> >>> fastegal at swingempire.de> >> >>>> wrote: >> >>>> >> >>>>> >> >>>>> .. fails (gradle run from cygwin console) with: >> >>>>> >> >>>>> * Where: >> >>>>> Build file >> >>>>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >> >>>>> line: 250 >> >>>>> >> >>>>> * What went wrong: >> >>>>> A problem occurred evaluating root project 'jfx-fork'. >> >>>>> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 >> >>>>> >> >>>>> which is rather clear in itself, but ... how to update? It seems to >> >>>>> too nothing, not even list the tasks >> >>>>> >> >>>>> CU, Jeanette >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> From fastegal at openjdk.org Thu Oct 31 15:04:35 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 31 Oct 2019 15:04:35 GMT Subject: RFR: 8233040: Fix: ComboBoxPopupControl - remove eventFilter for F4 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8233040 The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. ---------------- Commits: - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 Changes: https://git.openjdk.java.net/jfx/pull/28/files Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx/pull/28 From nlisker at gmail.com Thu Oct 31 15:11:27 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 31 Oct 2019 17:11:27 +0200 Subject: Problem with gradle ... In-Reply-To: <20191031154815.Horde.8RUSPn--iNVOdD6bf6_tEw1@webmail.df.eu> References: <20191031144102.Horde.bAIg3HrDE4EQ8L5niqJ-1A9@webmail.df.eu> <20191031145804.Horde.DUjwuPTzAIxD-ZAQ1D3s9Q5@webmail.df.eu> <20191031151145.Horde.RPaOPK4G9r62FiZ5RUAW1g1@webmail.df.eu> <20191031152409.Horde.dFi0U1UwAhvVysz51Je-Ow1@webmail.df.eu> <20191031154815.Horde.8RUSPn--iNVOdD6bf6_tEw1@webmail.df.eu> Message-ID: I think Eclipse sometimes causes folders to be marked as read-only (can't find the reference). I had issues where I couldn't rebuild because the modules\javafx.base folder was read-only for some reason and I had to delete is manually. It would reoccur seemingly randomly. On Thu, Oct 31, 2019 at 4:48 PM Jeanette Winzenburg wrote: > > Zitat von Nir Lisker : > > > Seems like an OS level issue. I've not gotten this one yet. Could be a > file > > lock, read-only file, user permissions config etc. > > > > yeah, for some reason the folder was write-protected .. removed for > now, will dig later as to why it happened in the first place. > > Thanks for your support! > > - Jeanette > > > > On Thu, Oct 31, 2019 at 4:24 PM Jeanette Winzenburg < > fastegal at swingempire.de> > > wrote: > > > >> > >> okay, now build everything went fine, but get an file access error > >> > >> > Task :controls:test FAILED > >> > >> FAILURE: Build failed with an exception. > >> > >> * What went wrong: > >> Execution failed for task ':controls:test'. > >> > java.nio.file.AccessDeniedException: > >> > > >> > C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.controls\build\reports\tests\test > >> > >> Afaik, there are no access restrictions anywhere on my local (win10) > >> machine .. hmm, any ideas what happened? > >> > >> - Jeanette > >> > >> Zitat von Jeanette Winzenburg : > >> > >> > Zitat von Nir Lisker : > >> > > >> >> Yes, the wrapper will know to download the correct version. I updated > >> the > >> >> build instructions page [1] to be more specific about the wrapper > >> recently, > >> >> and there is another update coming soon due to a problem I recently > >> >> encountered with the buildsrc. > >> >> > >> >> Run ./gradlew from the root folder of the project (or give it the > full > >> path > >> >> to it if you're not in the root folder). > >> >> > >> >> [1] > >> >> > >> > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > >> >> > >> > > >> > ahhh .. cool, something happens :) Thanks for the pointer, should > >> > have checked the build instructions first .. > >> > > >> > - Jeanette > >> > > >> >> On Thu, Oct 31, 2019 at 3:58 PM Jeanette Winzenburg > >> >> > >> >> wrote: > >> >> > >> >>> > >> >>> Zitat von Nir Lisker : > >> >>> > >> >>>> Did you run the wrapper with gradlew or just gradle? The latter > uses > >> the > >> >>>> "global" version installed on the OS which might not be up to date > >> (use > >> >>>> 'gradle --version' to check). > >> >>>> > >> >>> > >> >>> > >> >>> in my cygwin console I type: > >> >>> > >> >>> gradle > >> >>> > >> >>> and get the error message .. hmm ... so, yeah seems to be global > >> >>> version that's out of date. > >> >>> > >> >>> Are you saying that using gradlew (*cough - how exactly?) would keep > >> >>> the required version up-to-date? > >> >>> > >> >>> Thanks > >> >>> Jeanette > >> >>> > >> >>>> - Nir > >> >>>> > >> >>>> On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg < > >> >>> fastegal at swingempire.de> > >> >>>> wrote: > >> >>>> > >> >>>>> > >> >>>>> .. fails (gradle run from cygwin console) with: > >> >>>>> > >> >>>>> * Where: > >> >>>>> Build file > >> >>>>> > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > >> >>>>> line: 250 > >> >>>>> > >> >>>>> * What went wrong: > >> >>>>> A problem occurred evaluating root project 'jfx-fork'. > >> >>>>> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3 > >> >>>>> > >> >>>>> which is rather clear in itself, but ... how to update? It seems > to > >> >>>>> too nothing, not even list the tasks > >> >>>>> > >> >>>>> CU, Jeanette > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>> > >> >>> > >> >>> > >> >>> > >> > >> > >> > >> > > > > From kcr at openjdk.org Thu Oct 31 19:40:25 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 31 Oct 2019 19:40:25 GMT Subject: RFR: 8233338: FX javadoc headings are out of sequence Message-ID: As indicated in [JDK-8233338](https://bugs.openjdk.java.net/browse/JDK-8233338), this fixes all of our javadoc HTML headings to conform with the rule that all HTML heading tags in class documents must start with `

` and be nested correctly (i.e., no skipping levels). See [JDK-8219801](https://bugs.openjdk.java.net/browse/JDK-8219801) and [JDK-8220379](https://bugs.openjdk.java.net/browse/JDK-8220379). We have a few places where we are using `

` tags and several more where we are using `

`. As a result, the build of FX docs via `gradle javadoc` fails with JDK 13. We had one `

` heading that wasn't supposed to be nested with the previous `

` heading, so I made both of the `

` to reflect this. This fix can go in at any time, but must be done before we can switch the boot JDK to 13 in [JDK-8232064](https://bugs.openjdk.java.net/browse/JDK-8232064), else the build will fail. ---------------- Commits: - c5d8372a: 8233338: FX javadoc headings are out of sequence Changes: https://git.openjdk.java.net/jfx/pull/29/files Webrev: https://webrevs.openjdk.java.net/jfx/29/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233338 Stats: 69 lines in 26 files changed: 0 ins; 0 del; 69 mod Patch: https://git.openjdk.java.net/jfx/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/29/head:pull/29 PR: https://git.openjdk.java.net/jfx/pull/29 From kcr at openjdk.org Thu Oct 31 21:20:55 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 31 Oct 2019 21:20:55 GMT Subject: RFR: 8233040: Fix: ComboBoxPopupControl - remove eventFilter for F4 In-Reply-To: References: Message-ID: On Thu, 31 Oct 2019 15:04:35 GMT, Jeanette Winzenburg wrote: > https://bugs.openjdk.java.net/browse/JDK-8233040 > > The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. > > The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. > > ---------------- > > Commits: > - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 > > Changes: https://git.openjdk.java.net/jfx/pull/28/files > Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 > Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/28.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 The PR title should match the bug title, so: 8233040: ComboBoxPopupControl: remove eventFilter for F4 @aghaisas can you review this, and also comment on whether you feel it needs a second reviewer (probably not unless you find something during the review that invites a more careful review). PR: https://git.openjdk.java.net/jfx/pull/28 From kcr at openjdk.org Thu Oct 31 21:21:47 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 31 Oct 2019 21:21:47 GMT Subject: RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: On Wed, 23 Oct 2019 11:32:48 GMT, Jeanette Winzenburg wrote: > The issue is that firing keyEvents on a node that is not focusOwner might produce false green tests, please see the issue for details. > > fix for https://bugs.openjdk.java.net/browse/JDK-8231692 > - added contructor taking the scene > - changed event firing to use either the target directly or inject into > scene > > ---------------- > > Commits: > - aabea139: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into > > Changes: https://git.openjdk.java.net/jfx/pull/20/files > Webrev: https://webrevs.openjdk.java.net/jfx/20/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 > Stats: 263 lines in 2 files changed: 260 ins; 2 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/20.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 @aghaisas can you review this? A single reviewer will be sufficient. PR: https://git.openjdk.java.net/jfx/pull/20 From kcr at openjdk.org Thu Oct 31 21:22:18 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 31 Oct 2019 21:22:18 GMT Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists In-Reply-To: References: Message-ID: On Wed, 16 Oct 2019 13:09:35 GMT, Kevin Rushforth wrote: > On Wed, 16 Oct 2019 13:07:45 GMT, Jeanette Winzenburg wrote: > >> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759 >> >> The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix. >> >> There are additional/changed tests to verify the fix. All old tests are passing. >> >> ---------------- >> >> Commits: >> - 93556393: Fix: VK_ENTER not consumed by TextField when default Button exists >> >> Changes: https://git.openjdk.java.net/jfx/pull/15/files >> Webrev: https://webrevs.openjdk.java.net/jfx/15/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207759 >> Stats: 553 lines in 8 files changed: 528 ins; 20 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/15.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15 > > @aghaisas can you review this as well? This will need two reviewers. PR: https://git.openjdk.java.net/jfx/pull/15 From nlisker at gmail.com Thu Oct 31 21:25:33 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 31 Oct 2019 23:25:33 +0200 Subject: Missing package com.sun.javafx.runtime Message-ID: Hi, Eclipse reports an error on javafx.base/src/main/java/module-info.java line 79: The package com.sun.javafx.runtime does not exist or is empty. Indeed I can't find the package [1]. How is the build passing? Or am I missing something? - Nir [1] https://github.com/openjdk/jfx/tree/master/modules/javafx.base/src/main/java/com/sun/javafx From kevin.rushforth at oracle.com Thu Oct 31 21:30:02 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 31 Oct 2019 14:30:02 -0700 Subject: Missing package com.sun.javafx.runtime In-Reply-To: References: Message-ID: This package has a single class that is generated at build time. Run "gradle sdk" and you should see it here: modules/javafx.base/build/gensrc/java/com/sun/javafx/runtime/VersionInfo.java -- Kevin On 10/31/2019 2:25 PM, Nir Lisker wrote: > Hi, > > Eclipse reports an error on javafx.base/src/main/java/module-info.java line > 79: > > The package com.sun.javafx.runtime does not exist or is empty. > > Indeed I can't find the package [1]. > > How is the build passing? Or am I missing something? > > - Nir > > [1] > https://github.com/openjdk/jfx/tree/master/modules/javafx.base/src/main/java/com/sun/javafx