Re: RFR: 8256184: Openjfx build broken (Eclipse)

2020-11-20 Thread Jeanette Winzenburg
On Fri, 20 Nov 2020 16:22:32 GMT, Kevin Rushforth wrote: > > > I don't mind either way. If we want to proceed, I'm OK with either of: > > 1. Accept the PR as-is and file a follow-up issue > > 2. Add the change proposed by @nlisker and list him as a co-contributor > (in which case he

Re: RFR: 8256184: Openjfx build broken (Eclipse)

2020-11-20 Thread Kevin Rushforth
On Fri, 20 Nov 2020 15:44:57 GMT, Johan Vos wrote: >> Yes, but that's a problem of no reviewers. If I submit it myself then there >> will also be no one to review. @kevinrushforth What do we do? I think that >> previously when I updated the Eclipse files, there's wasn't a thorough >> review.

Re: RFR: 8256184: Openjfx build broken (Eclipse)

2020-11-20 Thread Johan Vos
On Fri, 20 Nov 2020 15:26:15 GMT, Nir Lisker wrote: >> The change looks reasonable to me, but since I don't use Eclipse it would be >> better for someone who does to review. >> @nlisker can you review this? > > Yes, but that's a problem of no reviewers. If I submit it myself then there > will

Re: RFR: 8256184: Openjfx build broken (Eclipse)

2020-11-20 Thread Nir Lisker
On Thu, 12 Nov 2020 13:50:41 GMT, Kevin Rushforth wrote: >> Issue was broken build in Eclipse after fix of >> [JDK-8244297](https://bugs.openjdk.java.net/browse/JDK-8244297): >> >> - the new memory test class requires jdk.management/java.management >> - users of the test class (in controls)

Re: RFR: 8256184: Openjfx build broken (Eclipse)

2020-11-20 Thread Jeanette Winzenburg
On Fri, 20 Nov 2020 14:40:08 GMT, Nir Lisker wrote: >> okay, so will simply unassign the issue and leave the PR open for someone >> else to complete - thanks for your input :) > > @kleopatra You can just add the line I gave in the .classpath file, there's > no need for any setup. We can be

Re: RFR: 8256184: Openjfx build broken (Eclipse)

2020-11-20 Thread Nir Lisker
On Tue, 17 Nov 2020 11:29:02 GMT, Jeanette Winzenburg wrote: >>> Plus this extra effort would only fix the current usage of memorybuddy, >>> leaving future inclusions in the other modules still broken. >> >> I think that this is fine. When future uses occur they should be accompanied >> by

Re: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2]

2020-11-20 Thread Kevin Rushforth
On Fri, 20 Nov 2020 11:30:18 GMT, Jose Pereda wrote: >> As commented in the [JBS >> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI >> scale 1.0 is used to perform initial calculations of preferred sizes of the >> scene, even if the scale has already a different value

Re: compile errors around JMemoryBuddy

2020-11-20 Thread Kevin Rushforth
Yes, that seems best. Can you also add a comment to the JBS bug to that effect? That way if someone else wants to pick it back up they'll have a clear pointer to the old PR. Thanks. -- Kevin On 11/20/2020 2:50 AM, Jeanette Winzenburg wrote: Kevin, had taken it, created a PR

Re: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2]

2020-11-20 Thread Jose Pereda
On Thu, 19 Nov 2020 02:12:05 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use assertTrue instead of try-catch > > tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java line 83:

Re: RFR: 8199592: Control labels truncated at certain DPI scaling levels [v2]

2020-11-20 Thread Jose Pereda
> As commented in the [JBS > issue](https://bugs.openjdk.java.net/browse/JDK-8199592), the default UI > scale 1.0 is used to perform initial calculations of preferred sizes of the > scene, even if the scale has already a different value (i.e 175%). As a > workaround, calling

Re: compile errors around JMemoryBuddy

2020-11-20 Thread Jeanette Winzenburg
Kevin, had taken it, created a PR https://github.com/openjdk/jfx/pull/352 with the suggested changes. In review it turned out to be not enough to cover its current usage, tests need it as well. Doing it completely would require to setup all fx modules (and tests) in my local Eclipse

Re: RFR: 8256649: Parameterized tests must not use instances as parameters

2020-11-20 Thread Jeanette Winzenburg
On Thu, 19 Nov 2020 23:38:33 GMT, Kevin Rushforth wrote: > > > Parameters should be immutable would have been a far better bug title :) > to avoid this. Each test runs in its own instance, but if a test stores a > reference to a parameter and then modifies it, that modification will leak >

Integrated: 8256649: Parameterized tests must not use instances as parameters

2020-11-20 Thread Jeanette Winzenburg
On Thu, 19 Nov 2020 15:13:49 GMT, Jeanette Winzenburg wrote: > the issue was an (my ;) overzealous refactoring when introducing support for > cross-control testing for memory leaks on switching skins. > > Fixed by > - using control class as parameter > - instantiate the control at setup time