Re: Re: Can't load fxml on Macos
What is fxml set to? Could maybe be a “classpath” type issue where it’s looking on the classpath and can’t find it. Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On October 20, 2020 at 8:56:52 AM CDT, Davide Perini > mailto:perini.dav...@dpsoftware.org)> wrote: > I'm creating my binary file using JPackage but I don't signed the binary. > can this be the problem. > > why a simple line like this > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + > Constants.FXML)); > > return null if it works on WIndows and Linux? > > Thanks > Davide > > > > > > Il 20/10/2020 15:54, Dirk Lemmermann ha scritto: > > I worked with JavaFX on MacOS since 2013 and except for issues related to > > font rendering I never got the impression that MacOS is the black sheep. I > > also happen to know that many of the developers that are working on JavaFX > > use MacOS. > > > > Dirk > > > > > On Oct 20, 2020, at 12:28 PM, Davide Perini > > (mailto:perini.dav...@dpsoftware.org)> wrote: > > > > > > Hi all, > > > this code works well on both Windows and Linux running Java 15 on JavaFX > > > 15. > > > > > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml > > > + Constants.FXML)); return fxmlLoader.load(); > > > > > > > > > It doesn't work on Macos returning a nullpointer exception. > > > > > > Any idea? Why Macos is always the black sheep? > > > > > > Thanks > > > Davide >
RFR: 8252596: [TESTBUG] WebPageShim::paint is not thread-safe
Issue: Tests using `WebPageShim::paint` fails around 1/10 times. Fix: Execute `WebPageShim::paint` in the render thread using `PrismInvoker`. Ran tests over 100 times, no failures. Used the initial unit test in the PR for [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990). - Commit messages: - 8252596: [TESTBUG] WebPageShim::paint is not thread-safe Changes: https://git.openjdk.java.net/jfx/pull/327/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=327=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252596 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/327.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/327/head:pull/327 PR: https://git.openjdk.java.net/jfx/pull/327
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Wed, 21 Oct 2020 07:01:46 GMT, Frederic Thevenet wrote: >>> >>> >>> The visual representation corresponds with digits, so there can be tests >>> that check if the numbers are what we expect them to be. >>> It's good that this is not windows-only, so that it can be tackled on linux >>> as well. But what is not clear to me: does this require a physical HiDPI >>> screen, or is setting the scale factor manually good enough to reproduce >>> the bug? >> >> The issue will appear consistently as long as the conditions I listed are >> met, regardless of the actual number of pixels the physical screen can >> display. >> For instance you'll see the problem, if you apply a 125% scaling on 1080p >> screen (a common configuration on 13'' laptops). >> Also, it will occur regardless of whether the scaling is applied at the OS >> level and picked up by javafx or if it is only set for a single application >> using the `glass.xxx.uiScale` property. > > Hello, > Did anyone get a chance to look into this? > Thanks! Not yet. I took a quick look, and this is helpful in pointing out where the problem is, but I don't know whether it is the right solution to simply round the transform values when rendering the cache to the screen. - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* [v2]
On Wed, 21 Oct 2020 08:23:25 GMT, Ambarish Rapte wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JDK-8255002 - review fixes > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java > line 73: > >> 71: * - (2nd order) CssMetaData_isSettable returns true for thing in >> their default state >> 72: * - (2nd order) CssMetaData_isSettable returns false for things >> manually specified >> 73: * - (3rd order) impl_cssKeys includes all the public properties > > I could not find a match for `impl_cssKeys`. Should it be considered in this > fix ? either find a match and correct this comment or remove if it does not > exist anymore. I don't have strong preference on this, I leave it to you. I was in two minds whether to clean up these 3 commented references to "impl_". Now, I have corrected two commented references where I could find the closest equivalents and deleted the third commented reference. - PR: https://git.openjdk.java.net/jfx/pull/326
Re: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_* [v2]
> It is a test cleanup work. > > Issue : > Many unit tests in javafx.controls module have incorrect naming that use text > "impl_" in names and comments. > The test code correctly avoids using impl_* methods (as they were removed in > JDK 9), but test names still have "impl_" in them. > > Fix : > These tests are renamed by replacing impl_* with appropriate css method. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: JDK-8255002 - review fixes - Changes: - all: https://git.openjdk.java.net/jfx/pull/326/files - new: https://git.openjdk.java.net/jfx/pull/326/files/18c35fa9..9e6849b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=326=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=326=00-01 Stats: 17 lines in 3 files changed: 0 ins; 15 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/326.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/326/head:pull/326 PR: https://git.openjdk.java.net/jfx/pull/326
Re: RFR: 8255002: Many javafx.controls unit tests have incorrect name containing impl_*
On Tue, 20 Oct 2020 12:18:10 GMT, Ajit Ghaisas wrote: > It is a test cleanup work. > > Issue : > Many unit tests in javafx.controls module have incorrect naming that use text > "impl_" in names and comments. > The test code correctly avoids using impl_* methods (as they were removed in > JDK 9), but test names still have "impl_" in them. > > Fix : > These tests are renamed by replacing impl_* with appropriate css method. I found two other instances where impl_ methods are referred. 1. A comment in file:MiscellaneousTests.java Line#65, refers to `Scene#impl_initPeer()`. I think now it should `Scene#initPeer()`. 2. A commented test in File VirtualFlowTest.java Line#852 refers to `cell.impl_getCSSFlags()`. All the instances are commented. Please take a look if these were missed. I don't have any preference on handling these, so I leave it to you. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTest.java line 73: > 71: * - (2nd order) CssMetaData_isSettable returns true for thing in > their default state > 72: * - (2nd order) CssMetaData_isSettable returns false for things > manually specified > 73: * - (3rd order) impl_cssKeys includes all the public properties I could not find a match for `impl_cssKeys`. Should it be considered in this fix ? either find a match and correct this comment or remove if it does not exist anymore. I don't have strong preference on this, I leave it to you. - PR: https://git.openjdk.java.net/jfx/pull/326
Re: Can't load fxml on Macos
With so little information nobody will be able to answer your question and I am pretty sure that not macOS is the black sheep here. Such questions are also better posted on Stackoverflow and not here on the OpenJFX development mailing list. Michael Am 20.10.20 um 12:28 schrieb Davide Perini: Hi all, this code works well on both Windows and Linux running Java 15 on JavaFX 15. FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return fxmlLoader.load(); It doesn't work on Macos returning a nullpointer exception. Any idea? Why Macos is always the black sheep? Thanks Davide
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Fri, 25 Sep 2020 09:32:46 GMT, Frederic Thevenet wrote: >> The visual representation corresponds with digits, so there can be tests >> that check if the numbers are what we expect >> them to be. It's good that this is not windows-only, so that it can be >> tackled on linux as well. But what is not clear >> to me: does this require a physical HiDPI screen, or is setting the scale >> factor manually good enough to reproduce the >> bug? > >> >> >> The visual representation corresponds with digits, so there can be tests >> that check if the numbers are what we expect >> them to be. It's good that this is not windows-only, so that it can be >> tackled on linux as well. But what is not clear >> to me: does this require a physical HiDPI screen, or is setting the scale >> factor manually good enough to reproduce the >> bug? > > The issue will appear consistently as long as the conditions I listed are > met, regardless of the actual number of > pixels the physical screen can display. For instance you'll see the problem, > if you apply a 125% scaling on 1080p > screen (a common configuration on 13'' laptops). Also, it will occur > regardless of whether the scaling is applied at > the OS level and picked up by javafx or if it is only set for a single > application using the `glass.xxx.uiScale` > property. Hello, Did anyone get a chance to look into this? Thanks! - PR: https://git.openjdk.java.net/jfx/pull/308
