It depends on how many there are and how similar they are. If there
isn't much similarity, then one issue per control is probably fine (and
may be best). If there is a lot of similar patterns then some grouping
will help cut down on the number of reviews (and the associated testing).
Ambarish
Hi guys,
Sorry to barge in on the conversation but I think I have some comments that
might add to the conversation.
Sometime ago someone reported this bug in the JMetro issue tracker:
https://github.com/JFXtras/jfxtras-styles/issues/144 (it's a hobby project,
a JavaFX theme, I've been working
This upgrades the version of gradle used to build JavaFX to 6.3. The minimum
version of gradle is not changed by the
proposed fix, and remains at 5.3.
I have run done a full build and test with gradle 6.3 on all three platforms.
There are no new failures.
This will enable building JavaFX using
On Wed, 25 Mar 2020 21:20:37 GMT, Kevin Rushforth wrote:
> This upgrades the version of gradle used to build JavaFX to 6.3. The minimum
> version of gradle is not changed by the
> proposed fix, and remains at 5.3.
> I have run done a full build and test with gradle 6.3 on all three platforms.
On Wed, 25 Mar 2020 19:05:42 GMT, Rony G. Flatscher
wrote:
>> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV
>
> Rony G. Flatscher has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove jcheck whitespace
> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV
Rony G. Flatscher has updated the pull request incrementally with one
additional commit since the last revision:
Remove jcheck whitespace error.
-
Changes:
- all:
> …9: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV
Rony G. Flatscher has updated the pull request incrementally with one
additional commit since the last revision:
Applying the changes according to the review.
-
Changes:
- all:
On Wed, 25 Mar 2020 18:12:41 GMT, Arun Joseph wrote:
>> This bug can be reproduced when the screen resolution is at 125%, 150% and
>> 175% for Windows, which correpsonds to
>> `pixelScale` values of 1.25, 1.5 and 1.75, respectively.
>> Issue: The rectangle inside canvas is rendered on
> This bug can be reproduced when the screen resolution is at 125%, 150% and
> 175% for Windows, which correpsonds to
> `pixelScale` values of 1.25, 1.5 and 1.75, respectively.
> Issue: The rectangle inside canvas is rendered on `pixelScale` while the
> borders are rendered on
With the help from a paid fx support channel, we're making headway with
this. The main help was disabling the recommended software option. At
time of writing this, I recommend this warning/detail is added to the wiki:
https://wiki.openjdk.java.net/display/OpenJFX/Monocle
Quoting:
> *If you
I realized I didn't answer the "how to test" part of it. The only thing
I can think of is running all of the existing tests, including the
systemTests and any other manual tests that use the object in question,
with a limited heap size to make GC more likely to happen. There might
be
Here are my quick thoughts on the things to watch out for when
converting a (strong) listener to a WeakListener, but I would love to
hear from others.
The main thing you need to do is make sure that the listener doesn't go
out of scope, and thus become subject to garbage collection, too soon.
While working on a memory leak for ChoiceBoxSelection
(https://bugs.openjdk.java.net/browse/JDK-8241455) I wrote a test
covering the same issue in other controls with selection- and
focusModels (the latter if available). Turned out it fails for
- TreeView selection- and focusModel
-
Currently, there are two open pull requests (#147 and #148) for fixing
memory leaks in controls/skin with the same comment from Kevin:
"Using a WeakListener is certainly easier, but runs the risk of the
listener being removed too early and not cleaning up after itself."
Looks like I
14 matches
Mail list logo
