Re: Add method to save a JavaFX image to file without the use of SwingFXUtils?

2021-05-04 Thread John Neffenger
On 5/4/21 5:08 AM, Frank Delporte wrote: I researched this topic for a few hours, but didn't manage to find a good approach to save a JavaFX Image. For what it's worth, I ran 224 benchmarks to find the fastest method to go in the other direction: read in an image using AWT and convert it to

Integrated: 8264010: Add Gradle dependency verification

2021-05-03 Thread John Neffenger
On Tue, 23 Mar 2021 05:32:04 GMT, John Neffenger wrote: > This pull request adds dependency verification to the Gradle builds of JavaFX > on Linux, macOS, and Windows. It is the third of three changes that close the > gaps in the JavaFX build security: > > * [JDK-8262236][1]: C

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v4]

2021-04-29 Thread John Neffenger
ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH [v2]

2021-04-29 Thread John Neffenger
n-attacks-like-solarwinds > [3]: https://tests.reproducible-builds.org/debian/reproducible.html > [4]: https://reproducible-builds.org/specs/source-date-epoch/ > [5]: > https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion > [6]: https://reprodu

Re: RFR: 8264010: Add Gradle dependency verification [v5]

2021-04-29 Thread John Neffenger
enjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: > https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system

Re: RFR: 8264010: Add Gradle dependency verification [v4]

2021-04-29 Thread John Neffenger
On Tue, 27 Apr 2021 21:19:26 GMT, Kevin Rushforth wrote: > Here are the two additional internal downloads for the new versions of the > gcc-10.3 and vs2019-16.9.3 download Thanks, Kevin. I'll assume those replace the older versions shown in the excerpt below, and I'll remove them. Let me know

Re: Monocle, headless isolated from embedded

2021-04-26 Thread John Neffenger
On 4/21/21 12:06 PM, Johan Vos wrote: However, I don't think Monocle is ready at this moment to be bundled with the desktop releases. Serious question: Why not? If we do move the Headless Platform out of Monocle, we should consider bringing its VNC Platform subclass along as well. John

Re: RFR: 8264010: Add Gradle dependency verification [v4]

2021-04-17 Thread John Neffenger
On Sat, 17 Apr 2021 23:17:04 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of >> JavaFX on Linux, macOS, and Windows. It is the third of three changes that >> close the gaps in the JavaFX build security: >> >>

Re: RFR: 8264010: Add Gradle dependency verification [v4]

2021-04-17 Thread John Neffenger
enjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: > https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]

2021-04-17 Thread John Neffenger
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]

2021-04-14 Thread John Neffenger
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-04-14 Thread John Neffenger
On Sat, 27 Mar 2021 18:49:32 GMT, Bernhard M. Wiedemann wrote: > Sorted output still complies with that API, though. Well, that's true. I hadn't thought of it that way. I have tried twice and failed to [add you as a contributor](https://github.com/openjdk/jfx/pull/422#issuecomment-806317783)

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-04-14 Thread John Neffenger
On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann wrote: > Allow to override buildDate with `SOURCE_DATE_EPOCH` > in order to make builds reproducible. > See https://reproducible-builds.org/ for why this is good > and https://reproducible-builds.org/specs/source-date-epoch/ > for the

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-04-14 Thread John Neffenger
On Sat, 27 Mar 2021 03:34:11 GMT, Bernhard M. Wiedemann wrote: > Now the interesting question is, if it is possible to change `listFiles` to > always return deterministic output ... Yes, that would be interesting, if `listFiles()` were defined by the Gradle build tool. I think it originates,

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-04-14 Thread John Neffenger
On Tue, 9 Mar 2021 03:11:48 GMT, Bernhard M. Wiedemann wrote: > When linking shared libraries, ensure that .o files are listed in > deterministic order - i.e. `sort(glob(*.c))` and check if individual .c or .o > files vary between builds. Wow, that tip was priceless! Thank you, Bernhard. It

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-04-14 Thread John Neffenger
On Wed, 15 Apr 2020 02:35:44 GMT, Bernhard M. Wiedemann wrote: > I am currently low on time and my Java-foo is not that great, so I was hoping > that someone would pick it up. @bmwiedemann Thank you for getting this important change started. If you can finish this pull request, I'll follow

Re: RFR: 8264010: Add Gradle dependency verification [v3]

2021-04-13 Thread John Neffenger
On Wed, 14 Apr 2021 04:32:29 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of >> JavaFX on Linux, macOS, and Windows. It is the third of three changes that >> close the gaps in the JavaFX build security: >> >>

Re: RFR: 8264010: Add Gradle dependency verification [v3]

2021-04-13 Thread John Neffenger
enjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: > https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system

Re: RFR: 8264010: Add Gradle dependency verification [v2]

2021-04-12 Thread John Neffenger
On Wed, 24 Mar 2021 19:45:55 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of >> JavaFX on Linux, macOS, and Windows. It is the third of three changes that >> close the gaps in the JavaFX build security: >> >>

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]

2021-04-12 Thread John Neffenger
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: &

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2]

2021-04-04 Thread John Neffenger
On Sat, 3 Apr 2021 01:49:47 GMT, John Neffenger wrote: >>> Silly question, is the difference with Windows just the nature of the >>> native support on each platform (Unix based vs Windows) and libraries used >>> as part of that? >> >> That's a good qu

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]

2021-04-04 Thread John Neffenger
and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2]

2021-04-02 Thread John Neffenger
On Fri, 2 Apr 2021 17:45:38 GMT, John Neffenger wrote: >> Media makefiles look fine. > >> Silly question, is the difference with Windows just the nature of the native >> support on each platform (Unix based vs Windows) and libraries used as part >> of that? >

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2]

2021-04-02 Thread John Neffenger
On Thu, 1 Apr 2021 23:21:55 GMT, Alexander Matveev wrote: >> John Neffenger has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Include media shared libraries for Windows >> >> Enable reproducib

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-04-01 Thread John Neffenger
On Thu, 1 Apr 2021 19:38:18 GMT, Bernhard M. Wiedemann wrote: > IMHO, it would make sense to merge any clear improvement of the status-quo > and debug+fix more in a later PR. I agree that we will have to draw the line somewhere, but right now I'm down to just one file on one operating system

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2]

2021-04-01 Thread John Neffenger
and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-04-01 Thread John Neffenger
On Wed, 31 Mar 2021 13:59:12 GMT, Kevin Rushforth wrote: >>> I think there might be a Skara bug. >> >> No, no bug. Sorry about that. I just don't know how GitHub works. >> :frowning_face: The pre-submit tests ran two days ago when I pushed the >> branch to GitHub, so by the time I submitted

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-04-01 Thread John Neffenger
On Wed, 31 Mar 2021 23:08:38 GMT, John Neffenger wrote: >> I recommend trying this with the following gradle flags, to match the >> settings for production builds: >> >> -PCONF=Release -PPROMOTED_BUILD_NUMBER=NNN -PHUDSON_BUILD_NUMBER=MMM >> -PHUDSON_JOB_

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-03-31 Thread John Neffenger
On Wed, 31 Mar 2021 13:59:12 GMT, Kevin Rushforth wrote: > I recommend trying this with the following gradle flags, to match the > settings for production builds: Thanks, Kevin. Good news so far. I'm posting the Linux results while I run the macOS and Windows builds. Linux I ran the

Re: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3

2021-03-30 Thread John Neffenger
On Thu, 25 Mar 2021 22:58:57 GMT, Kevin Rushforth wrote: > Build fails on my system with `FAIL: WINSDK_DIR not defined` @palexdev I hit that error, too. You may have already found this, but you can work around the problem by using the sample [`windows_tools.properties`][1] file on the

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-03-30 Thread John Neffenger
On Tue, 30 Mar 2021 16:30:25 GMT, John Neffenger wrote: > I think there might be a Skara bug. No, no bug. Sorry about that. I just don't know how GitHub works. :frowning_face: The pre-submit tests ran two days ago when I pushed the branch to GitHub, so by the time I submitted the pull requ

Re: E-mail addresses at openjdk.org

2021-03-30 Thread John Neffenger
On 3/25/21 4:12 AM, Kevin Rushforth wrote: Until then, adding the email address as an unverified additional email address in your GitHub profile is the way to go. And the first GitHub user to claim the address wins! There are a large number of unclaimed commits in our repository that are up

Re: issues on javafxports/openjdk-jfx

2021-03-30 Thread John Neffenger
On 3/28/21 5:24 AM, Johan Vos wrote: I'm still in favor of closing it though. It would be nice if there were a way in GitHub to close the repository to new issues but keep the old ones public and editable. For example, I'm still getting good information on the old closed issues, even as

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-03-30 Thread John Neffenger
On Thu, 25 Mar 2021 02:35:24 GMT, John Neffenger wrote: >>> @jgneff Could not parse `bmwiedemann` as a valid contributor. >> >> You might retry the "contributor" command with the `@` before their GitHub >> username (I'm not 100% sure that wil

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-03-30 Thread John Neffenger
On Tue, 30 Mar 2021 16:20:21 GMT, John Neffenger wrote: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, > and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For > example, the following commands create a reproducible build: >

RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

2021-03-30 Thread John Neffenger
This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) $ bash gradlew sdk jmods

Re: RFR: 8264010: Add Gradle dependency verification

2021-03-25 Thread John Neffenger
On Wed, 24 Mar 2021 19:50:11 GMT, John Neffenger wrote: > Are all of them actually needed? Just to follow up on that question, all of them are in fact downloaded during the build, at least. I removed the Gradle directory `$HOME/.gradle` and ran the build as follows. Then I compared the l

E-mail addresses at openjdk.org

2021-03-24 Thread John Neffenger
I noticed that my last commit used the address jgn...@openjdk.org instead of the address I normally use to create and sign commits. GitHub didn't recognize the commit as mine until I added the address to my account. Do the openjdk.org addresses receive e-mail? If not, do we just leave the

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-03-24 Thread John Neffenger
On Wed, 24 Mar 2021 23:39:21 GMT, Kevin Rushforth wrote: > You might retry the "contributor" command with the `@` before their GitHub > username. Thanks. I'll try that now. I checked and Bernhard is on the list of "OCAs submitted prior to 2021," but not on the OpenJDK Census list, in case

Re: RFR: 8264010: Add Gradle dependency verification

2021-03-24 Thread John Neffenger
On Wed, 24 Mar 2021 19:55:20 GMT, Kevin Rushforth wrote: > I don't yet know to handle this ... Would any of the following options work? 1. If you're using your own supplemental closed Gradle build file, create your own supplemental closed Gradle verification file, too. Before the internal

Re: RFR: 8264010: Add Gradle dependency verification

2021-03-24 Thread John Neffenger
On Tue, 23 Mar 2021 12:07:48 GMT, Kevin Rushforth wrote: >> This pull request adds dependency verification to the Gradle builds of >> JavaFX on Linux, macOS, and Windows. It is the third of three changes that >> close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure

Re: RFR: 8264010: Add Gradle dependency verification [v2]

2021-03-24 Thread John Neffenger
se/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: > https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf > [6]: https

Integrated: 8264061: LocalDateTimeStringConverterTest fails in Canada

2021-03-23 Thread John Neffenger
On Tue, 23 Mar 2021 18:24:40 GMT, John Neffenger wrote: > As the comment in the test case mentions, "Tests require that default locale > is en_US." The default locale is required by the objects created in the > static method `implementations`, marked with t

RFR: 8264061: LocalDateTimeStringConverterTest fails in Canada

2021-03-23 Thread John Neffenger
As the comment in the test case mentions, "Tests require that default locale is en_US." The default locale is required by the objects created in the static method `implementations`, marked with the JUnit annotation `@Parameterized.Parameters`. So the static method `initDefaultLocale`, marked

Re: Not really a nice comment but a real issue?

2021-03-23 Thread John Neffenger
On 3/23/21 12:34 AM, Johan Vos wrote: * bug-report system: I'm all in to find a more accessible way, keeping into account that would require work being done by the community (hence, us) for converting issues into high-quality JBS issues. I have two GitHub Issue Templates that gather the same

Re: Not really a nice comment but a real issue?

2021-03-23 Thread John Neffenger
On 3/22/21 3:27 PM, Philip Race wrote: I am informed that, for no reason given, the corporate IT folks will not allow attachment upload. Thank you for looking into it, Phil. It's good at least to have a definitive answer. I brought this up on the mailing list three years ago, too: Re: More

RFR: 8264010: Add Gradle dependency verification

2021-03-22 Thread John Neffenger
This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: * [JDK-8262236][1]: Configure Gradle checksum verification * [JDK-8263204][2]: Add Gradle Wrapper

Re: Not really a nice comment but a real issue?

2021-03-19 Thread John Neffenger
On 3/19/21 12:37 PM, Philip Race wrote: I'm surprised credit is considered important It took me weeks to figure out some bugs and create a good report, all done as a volunteer in my spare time. Credit is my only compensation. I went as far as sneaking my name into the source code comments

Re: Not really a nice comment but a real issue?

2021-03-19 Thread John Neffenger
On 3/19/21 11:05 AM, Philip Race wrote: If this was important to him I don't understand why just a blog post and not a bug report .. If I had to guess, it might be because, in the age of GitHub, this is not what people expect when they try to report a bug: Report a Bug or Request a Feature

RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

2021-03-09 Thread John Neffenger
This is a continuation of the [pull request][1] started by @bmwiedemann in January 2020. After this change is integrated, I can follow up immediately with additional pull requests that get us much closer to providing fully reproducible builds. Motivation The only conclusive way to verify

Integrated: 8263204: Add Gradle Wrapper Validation Action

2021-03-09 Thread John Neffenger
On Mon, 8 Mar 2021 20:34:05 GMT, John Neffenger wrote: > See the [Gradle Wrapper Validation > Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for > details on this pull request. I'll test the changes with the following > sequence of commits: > > 1

Re: RFR: 8263204: Add Gradle Wrapper Validation Action

2021-03-08 Thread John Neffenger
On Mon, 8 Mar 2021 22:37:10 GMT, John Neffenger wrote: >> If it isn't too hard to make the running of the other three jobs dependent >> on the wrapper validation job, that would be good, as long as the validation >> job is fast. The other three still need to run in parall

Re: RFR: 8263204: Add Gradle Wrapper Validation Action [v4]

2021-03-08 Thread John Neffenger
e, which should go > undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, > which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the > original Gradle 4.8 Wrapper. John Neffenger has updat

Re: RFR: 8263204: Add Gradle Wrapper Validation Action

2021-03-08 Thread John Neffenger
On Mon, 8 Mar 2021 22:13:09 GMT, Kevin Rushforth wrote: >> Thanks, Kevin. I'll merge the two workflow files. >> >> The test results aren't what I expected: >> >>

Re: RFR: 8263204: Add Gradle Wrapper Validation Action [v3]

2021-03-08 Thread John Neffenger
e, which should go > undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, > which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the > original Gradle 4.8 Wrapper. John Neffenger has updat

Re: RFR: 8263204: Add Gradle Wrapper Validation Action

2021-03-08 Thread John Neffenger
On Mon, 8 Mar 2021 21:44:03 GMT, Kevin Rushforth wrote: >> So far, so good. The tampered file was not detected: >> >> ![all-checks-have-passed](https://user-images.githubusercontent.com/1413266/110383521-411ab200-8011-11eb-88ee-27102e0b6d81.png) >> >> The next commit will add the Official

Re: RFR: 8263204: Add Gradle Wrapper Validation Action

2021-03-08 Thread John Neffenger
On Mon, 8 Mar 2021 20:38:09 GMT, Kevin Rushforth wrote: >> See the [Gradle Wrapper Validation >> Action](https://github.com/marketplace/actions/gradle-wrapper-validation) >> for details on this pull request. I'll test the changes with the following >> sequence of commits: >> >> 1. This

Re: RFR: 8263204: Add Gradle Wrapper Validation Action [v2]

2021-03-08 Thread John Neffenger
e, which should go > undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, > which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the > original Gradle 4.8 Wrapper. John Neffenger has updat

RFR: 8263204: Add Gradle Wrapper Validation Action

2021-03-08 Thread John Neffenger
See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. 2.

Re: font color fringes on macOS, not a priority?

2021-02-26 Thread John Neffenger
On 2/26/21 6:56 AM, Rob Nikander wrote: I wonder if I can get a dev setup with a quick edit-compile-run cycle, or if the compile step takes a long time. The builds for macOS are taking just over 11 minutes on GitHub. To speed that up, I do my development in a project with only the JavaFX

Re: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen

2021-02-26 Thread John Neffenger
On Fri, 26 Feb 2021 13:58:01 GMT, Johan Vos wrote: > What is the expected behavior? I think that's why I never raised the issue. I let the bug train me to avoid it! For better or for worse, I think the only answer to your question is whatever Android and iOS do. After playing around with the

Re: font color fringes on macOS, not a priority?

2021-02-25 Thread John Neffenger
On 2/25/21 6:18 AM, Rob Nikander wrote: The way that bug is titled (“non-retina”) makes me wonder: do people realize that this is effecting even retina screens on macOS? I updated the bug report to remove the "on non-retina" in the title, along with magnified details of the four original

Re: font color fringes on macOS, not a priority?

2021-02-25 Thread John Neffenger
On 2/25/21 6:18 AM, Rob Nikander wrote: The way that bug is titled (“non-retina”) makes me wonder: do people realize that this is effecting even retina screens on macOS? Yeah, font bugs like this are frustrating. Both JavaFX[1] and the JDK[2] had the same problem on Linux for years. It can

Integrated: 8262236: Configure Gradle checksum verification

2021-02-23 Thread John Neffenger
On Tue, 23 Feb 2021 17:25:47 GMT, John Neffenger wrote: > The recent supply-chain attacks in the news are making me nervous!  > > The Gradle 6.3 distribution is the only software on my OpenJFX build system > that doesn't come from an Ubuntu package or a GitHub repository.

Re: RFR: 8262236: Configure Gradle checksum verification

2021-02-23 Thread John Neffenger
On Tue, 23 Feb 2021 19:04:47 GMT, Kevin Rushforth wrote: > My reading of it > [here](https://github.com/marketplace/actions/gradle-wrapper-validation#add-to-an-existing-workflow) > is that we would add this action as a step to our workflow script, which is > in >

Re: RFR: 8262236: Configure Gradle checksum verification

2021-02-23 Thread John Neffenger
On Tue, 23 Feb 2021 17:48:08 GMT, Kevin Rushforth wrote: > > We might also consider adding the [Gradle Wrapper > > Validation](https://github.com/marketplace/actions/gradle-wrapper-validation) > > GitHub Action to the OpenJFX repository. > > Feel free to file a bug and create a PR, if you are

Re: RFR: 8262236: Configure Gradle checksum verification

2021-02-23 Thread John Neffenger
On Tue, 23 Feb 2021 17:45:53 GMT, Kevin Rushforth wrote: > I presume that just adding the checksum will enable the validation? It does in my tests. See the section "Steps to Reproduce" in the bug report for details. It would be nice to see a message that the distribution was validated

RFR: 8262236: Configure Gradle checksum verification

2021-02-23 Thread John Neffenger
The recent supply-chain attacks in the news are making me nervous!  The Gradle 6.3 distribution is the only software on my OpenJFX build system that doesn't come from an Ubuntu package or a GitHub repository. Ubuntu uses digital signatures to authenticate each package, and Git uses a secure

Re: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen

2021-02-20 Thread John Neffenger
On Sat, 20 Feb 2021 07:41:02 GMT, Alexander Scherbatiy wrote: >> In case it helps, I reproduced the problem on a Kobo Touch e-reader with an >> e-paper display. The expected result isn't explicit in the bug report, so >> just to confirm, there should be no button action events received at all

Re: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen

2021-02-19 Thread John Neffenger
On Fri, 19 Feb 2021 20:37:46 GMT, Kevin Rushforth wrote: >> May be it has sense to add a drag event handler (which disarms the >> corresponding button) to ButtonBehavior only if javafx.platform is set to >> monocle to localize the fix only for Monocle? Or add a separate property and >> set it

Integrated: 8201568: zForce touchscreen input device fails when closed and immediately reopened

2020-12-14 Thread John Neffenger
On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). This pull request has now been integrated. Changeset: ebb59e9f Author: John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/com

Integrated: 8256012: Fix build of Monocle for Linux

2020-12-11 Thread John Neffenger
On Sat, 7 Nov 2020 23:13:48 GMT, John Neffenger wrote: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro > `__USE_GNU` before including the header file `dlfcn.h`. T

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2]

2020-12-11 Thread John Neffenger
On Tue, 29 Sep 2020 19:47:54 GMT, John Neffenger wrote: >> I don't have access to a Pi right now, so I can't test this (I'll be able to >> test in about 10 days from now though) > > @johanvos, would you mind approving this pull request again? It looks as if > the *rea

Re: RFR: 8256012: Fix build of Monocle for Linux [v3]

2020-12-11 Thread John Neffenger
mation in the following two > Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 John Neffenger has updated the pull request incrementally

Re: RFR: 8256012: Fix build of Monocle for Linux [v2]

2020-12-11 Thread John Neffenger
mation in the following two > Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 John Neffenger has updated the pull request with a new tar

Re: RFR: 8256012: Fix build of Monocle for Linux

2020-11-26 Thread John Neffenger
On Tue, 24 Nov 2020 21:18:03 GMT, Johan Vos wrote: > I don't see any harm in this PR, but I wonder which toolchains are still not > having `RTLD_NEXT` without specifying GNU_SOURCE. Thanks, Johan. I've been following the instructions in the [OpenJFX Wiki][1]. I use the GCC cross-compiler

RFR: 8256012: Fix build of Monocle for Linux

2020-11-07 Thread John Neffenger
This pull request fixes the error when building embedded JavaFX for Linux. The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the

Re: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6]

2020-11-05 Thread John Neffenger
On Thu, 5 Nov 2020 20:33:05 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional >> commit since the last revision: >> >> change invocation of getEGLDisplayHandle into getEglDisplayHandle >> Conditionally add dlfcn > > Marked as reviewed

Re: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6]

2020-11-05 Thread John Neffenger
On Thu, 5 Nov 2020 18:16:58 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional >> commit since the last revision: >> >> change invocation of getEGLDisplayHandle into getEglDisplayHandle >> Conditionally add dlfcn > > Marked as reviewed by

Re: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4]

2020-11-04 Thread John Neffenger
On Wed, 4 Nov 2020 16:14:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The >> low-level specific details about how the EGL calls should be constructed are >> left out, and a native interface (egl_ext.h) is created that can be mapped >> to

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2]

2020-09-29 Thread John Neffenger
On Mon, 21 Sep 2020 18:34:29 GMT, John Neffenger wrote: >> Based on my notes below, I believe this change is safe for any Linux input >> device driver because the driver shouldn't >> receive the intermediate *open* and *close* calls at all. >> Nonetheless, it would

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2]

2020-09-25 Thread John Neffenger
> Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additio

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

2020-09-21 Thread John Neffenger
On Mon, 29 Jun 2020 18:49:33 GMT, John Neffenger wrote: > Nonetheless, it would be reassuring if someone could try [this > change](https://github.com/openjdk/jfx/pull/258/files) > just once on a mainstream device, such as the Raspberry Pi with a touchscreen > LCD panel. I

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

2020-07-27 Thread John Neffenger
On Mon, 27 Jul 2020 14:26:44 GMT, Tor (torbuntu) wrote: > Is there somewhere I can find an embedded aarch64 version? If I had a PinePhone, I would try to get the 32-bit *armhf* build of JavaFX working. That's the one you build with `gradle -PCOMPILE_TARGETS=armv6hf sdk jmod`. You may need to

[jfx15] Integrated: 8248381: Create a daemon thread for MonocleTimer

2020-07-21 Thread John Neffenger
On Fri, 26 Jun 2020 03:50:02 GMT, John Neffenger wrote: > Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). This pull request has now been integrated. Changeset: 5f60ea5d Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/

[jfx15] Integrated: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

2020-07-10 Thread John Neffenger
On Fri, 26 Jun 2020 03:47:55 GMT, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). This pull request has now been integrated. Changeset: d67c47fd Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

2020-07-09 Thread John Neffenger
On Wed, 1 Jul 2020 12:10:23 GMT, Johan Vos wrote: > I don't have access to a Pi right now, so I can't test this (I'll be able to > test in about 10 days from now though) Thank you, Johan. If you have the time, that would be great. Otherwise, merging this for early-access builds of JavaFX 16

Re: [jfx15] RFR: 8248381: Create a daemon thread for MonocleTimer

2020-07-02 Thread John Neffenger
On Thu, 2 Jul 2020 23:46:40 GMT, Kevin Rushforth wrote: > Given that this is a regression introduced in JavaFX 14, this fix seems like > a good candidate for JavaFX 15 ... Actually, this is a regression introduced in JavaFX 15, so we have the chance to fix it before it's ever released. > Go

Integrated: 8201570: Get two bytes for the Linux input event type, not four

2020-07-02 Thread John Neffenger
On Sat, 27 Jun 2020 00:12:41 GMT, John Neffenger wrote: > Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). This pull request has now been integrated. Changeset: 126637f5 Author: John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/com

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]

2020-06-30 Thread John Neffenger
On Tue, 30 Jun 2020 06:05:08 GMT, John Neffenger wrote: >> At first glance the fix looks fine (aside from the `assert` statements that >> need to be removed). It will also need to >> be tested using the SW pipeline on all platforms. > >> It will also need to be t

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]

2020-06-30 Thread John Neffenger
> Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Remove assert statements - Changes: - all: https://git.openjdk.java.net/jfx/pull/255/fi

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

2020-06-30 Thread John Neffenger
On Sat, 27 Jun 2020 15:37:52 GMT, Kevin Rushforth wrote: > It will also need to be tested using the SW pipeline on all platforms. Thanks for the reminder. I managed to build JavaFX on Windows and macOS today, so I'll test this pull request on those platforms in addition to Linux desktop and

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

2020-06-29 Thread John Neffenger
The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Mon, 29 Jun 2020 11:26:50 GMT, Johan Vos wrote:

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

2020-06-27 Thread John Neffenger
The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Sat, 27 Jun 2020 15:36:01 GMT, Kevin Rushforth

Re: RFR: 8248381: Create a daemon thread for MonocleTimer [v2]

2020-06-27 Thread John Neffenger
> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Remove POOL_SIZE constant - Changes: - all: https://git.openjdk.java.net/jfx/pull/256/fi

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

2020-06-27 Thread John Neffenger
The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Sat, 27 Jun 2020 19:40:53 GMT, John Neffenger

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

2020-06-27 Thread John Neffenger
On Sat, 27 Jun 2020 19:37:01 GMT, Kevin Rushforth wrote: > OK, that seems fine then. I'll take a closer look and then finish my review. Actually, I think you may be right, though. Sorry for replying before looking into it. I now think the `ScheduledThreadPoolExecutor` should be shut down, but

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

2020-06-27 Thread John Neffenger
The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Sat, 27 Jun 2020 16:14:36 GMT, Kevin Rushforth

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

2020-06-27 Thread John Neffenger
On Sat, 27 Jun 2020 14:34:09 GMT, Johan Vos wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleTimer.java > line 38: > >> 37: private static final String THREAD_NAME = "Monocle Timer";

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

2020-06-26 Thread John Neffenger
On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). I thought I could avoid fixing this bug simply by waiting a few years, but the old devices from 2012 and 2013 where the problem occurs are still supported and st

  1   2   >