fillPath() and fillRect() functions in
[GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp)
use Image::drawPattern() for applying patterns as fill. But drawPattern()
doesn't use
I was mulling over why if it is so easy we didn't do it and I suspect
(haven't checked, and so long ago I can't remember off hand) that
this code needed to run on top of the old Java 2D pipeline (wrongly
called the Swing pipeline). And 2D did not and does not provide
this functionality either.
On Wed, 15 Apr 2020 10:52:26 GMT, Ambarish Rapte wrote:
>> `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()`
>> which holds the `SelectionModel` from being
>> GCed. Fix is to add and remove the listener when a `SelectionModel` is
>> changed.
>> If the fix looks good, We
Sadly no one is working on it.
It probably is not that hard to do, the weight should be in the OS/2 table
-phil
On 4/22/20, 3:26 PM, Tom Schindl wrote:
Hi Kevin / Phil,
I'd like to start working on JDK-8090423 but before I start investing
time I wanted to make sure nobody is working on that
Hi Kevin / Phil,
I'd like to start working on JDK-8090423 but before I start investing
time I wanted to make sure nobody is working on that and if you have any
input, ideas already how to address that problem help me not wasting time.
Tom
This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not
change the default compiler, which
remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be
proposed in a future PR using a new bug ID,
and isn't planned until after the JDK updates their compiler.
On Wed, 22 Apr 2020 18:46:29 GMT, Kevin Rushforth wrote:
> This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not
> change the default compiler, which
> remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be
> proposed in a future PR using a new bug
On Wed, 22 Apr 2020 18:07:53 GMT, Kevin Rushforth wrote:
>> This PR will allow javafx.web unit tests to run to completion and pass on
>> Windows with Visual Studio 2019.
>>
>> Two of the WebKit tests load the native WebKit library without initializing
>> the JavaFX runtime. This will lead to
This PR will allow javafx.web unit tests to run to completion and pass on
Windows with Visual Studio 2019.
Two of the WebKit tests load the native WebKit library without initializing the
JavaFX runtime. This will lead to test
failures and will hang the test run if those tests are run before the
yes I do but I think this is by nature:
a) you use CSS so only after the first CSS-Pass the color could be set
appropriately, this CSS pass could happen after the Native-Window is
shown
=> you can mitigate that a bit using
root.setBackground(new Background(new
On Wed, 22 Apr 2020 18:07:09 GMT, Kevin Rushforth wrote:
> This PR will allow javafx.web unit tests to run to completion and pass on
> Windows with Visual Studio 2019.
>
> Two of the WebKit tests load the native WebKit library without initializing
> the JavaFX runtime. This will lead to test
Hi Kevin,
as I am not able to file a CSR with the issue you suggested to come up with a
draft, so here it goes:
Summary
===
Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if
the script engine
implements the javax.script.Compilable interface to
Hi everyone,
is it just me or did something change in the launch behaviour of JavaFX
applications? It seems we are back to the old “grey box” bug of Swing where the
window would appear first before filling its content. I noticed the same (but
white) effect now for my JavaFX apps, especially
On Wed, 22 Apr 2020 15:52:11 GMT, Jeanette Winzenburg
wrote:
> `ListViewBehavior` already has change listener attached to
> `selectionModelProperty`, waiting for us to re-use it
Hi @abhinayagarwal, Thanks for the suggestion. This sound good to me too. I
shall make this change in next commit.
On Wed, 22 Apr 2020 12:46:03 GMT, Ajit Ghaisas wrote:
>> This is a solution for 8242548. There was zero test coverage, so I added a
>> few tests for this as well.
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java
> line 426:
>
>> 425:
>> 426:
On Wed, 22 Apr 2020 06:43:31 GMT, Abhinay Agarwal
wrote:
> Don't you think that all the changes in `ListViewSkin` can be moved to
> `ListViewBehavior`? All that we do in the skin
> class is to call `ListViewBehavior#updateSelectionModeKeyMapping`, which
> smells like feature envy.
> Moreover,
On Wed, 22 Apr 2020 12:51:54 GMT, Ajit Ghaisas wrote:
>> This is a solution for 8242548. There was zero test coverage, so I added a
>> few tests for this as well.
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java
> line 427:
>
>> 426: height +=
On 4/22/20 6:39 am, Sebastian Stenzel wrote:
Judging from the comments in the aforementioned issues it doesn't seem like we
can expect anything to change on AWT side. This is why it has often been
requested to create an alternative using JavaFX. [2] That said, it has always
been postponed.
Hi all,
I don't think I have to mention that java.awt.TrayIcon is a pretty outdated API
with an especially bad implementation [1] on Linux that is only just kept alive
at the mercy of distribution devs and in many cases SystemTray.isSupported()
returns false despite there being a tray.
On Wed, 22 Apr 2020 00:08:05 GMT, Kevin Rushforth wrote:
>> ### Cause
>>
>> `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly.
>> This causes
>> `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start
>> the animation not from the end, depending
On Sun, 12 Apr 2020 21:21:07 GMT, John Hendrikx wrote:
> This is a solution for 8242548. There was zero test coverage, so I added a
> few tests for this as well.
modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java
line 426:
> 425:
> 426: height +=
Hi Ajit,
Thanks for writing this up. I think we are clear on what should happen
for IntegerSpinnerValueFactory and ListSpinnerValueFactory. To answer
your two questions, I'll take the second one first:
2. Do we really care about negative values in no of steps OR
amountToStepBy?
I am asking
On Mon, 13 Apr 2020 06:59:08 GMT, Ajit Ghaisas wrote:
> Issue : https://bugs.openjdk.java.net/browse/JDK-8193286
>
> Root Cause :
> Incorrect implementation.
> Current implementation of int wrapValue(int,int,int) in Spinner.java works
> well if min is 0.
> Hence this implementation works with
On Fri, 17 Apr 2020 12:58:00 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8241840
>> Some code cleanups
>
> Changes requested by arapte (Reviewer).
I don't think the class
> Closed focused Stages are not collected with Monocle
>
> This commit adds a unit-test and a fix for collecting focused closed stages.
>
> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the
On Wed, 22 Apr 2020 09:06:09 GMT, Jeanette Winzenburg
wrote:
>> I checked and there is a case that (mostly) works today that will break with
>> your proposed fix. I left a couple inline
>> comments.
>> I wonder if it is better to wait and fix it completely in
>>
Jeanette and Kevin,
Thanks for taking a look at this in detail.
Regarding DoubleSpinnerValueFactory -
The wraparound behavior is incorrect with DoubleSpinnerValueFactory as well.
If amountToStepBy is lesser than max-min, once we try to increment from max, we
just clamp to min and start
> Closed focused Stages are not collected with Monocle
>
> This commit adds a unit-test and a fix for collecting focused closed stages.
>
> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the
On Fri, 17 Apr 2020 12:06:05 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8241840
>> Some code cleanups
>
>
> Closed focused Stages are not collected with Monocle
>
> This commit adds a unit-test and a fix for collecting focused closed stages.
>
> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the
On Fri, 17 Apr 2020 12:50:50 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8241840
>> Some code cleanups
>
> tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line
On Thu, 16 Apr 2020 18:56:21 GMT, Ambarish Rapte wrote:
>> This version doesn't work for me.
>> With this change, I get the following error:
>> test.javafx.stage.FocusedWindowTest > testLeak FAILED
>> junit.framework.AssertionFailedError: Exceeded timeout limit of 1
>> msec
>>
On Tue, 21 Apr 2020 23:34:07 GMT, Kevin Rushforth wrote:
>
> I wonder if it is better to wait and fix it completely in
> [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553).
good idea - do it correctly once and for all :)
-
PR:
On Sat, 11 Apr 2020 09:53:46 GMT, Ambarish Rapte wrote:
> The issue occurs because the key events are consumed by the `ListView` in
> `Popup`, which displays the items.
> This is a regression of
> [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change
> aadded several
>
34 matches
Mail list logo
