> This proposed change does the following:
>
> - Ports DND target to use GTK reducing code size and adding extra text /
> image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward
On Fri, 10 Jan 2020 00:37:58 GMT, Kevin Rushforth wrote:
>> The private field `lastPlayFinished` is responsible for 2 cases where an
>> animation in `STOPPED` status does not play after `play()` is called if the
>> rate is negative:
>>
>> 1. When the animation is created, it is `STOPPED` and
On Wed, 8 Jan 2020 23:52:07 GMT, Nir Lisker wrote:
> The private field `lastPlayFinished` is responsible for 2 cases where an
> animation in `STOPPED` status does not play after `play()` is called if the
> rate is negative:
>
> 1. When the animation is created, it is `STOPPED` and
On Thu, 9 Jan 2020 18:00:19 GMT, Nir Lisker wrote:
>> The error was for the cases of 2 and 3 lights (I was testing 1) and should
>> be fixed now. My fault with copy-paste... that's why we use loops, but I
>> guess this is some optimization for the es2 pipeline. I wonder if it's
>> really
On Sat, 4 Jan 2020 18:22:29 GMT, Nir Lisker wrote:
>> Right. This needs to talk about pixels. Perhaps there is a way to make it
>> more clear that we are talking about pixels that are part of a rendered
>> Shape3D, but I don't have a good suggestion right now.
>
> Maybe
>
> A light source
On Thu, 9 Jan 2020 16:20:19 GMT, Ambarish Rapte wrote:
>> I also looked at the code and don't see any mismatches (including those
>> called from the `ACQUIRE_SURFACE` macro). I suppose you could restore the
>> call, but since we are in a disposer thread throwing an exception doesn't
>> seem
On Fri, 3 Jan 2020 23:02:56 GMT, Nir Lisker wrote:
>>> I still need to test your sample app on Mac.
>>
>> I get the error with your sample app. It fails on Mac or Linux (Ubuntu
>> 16.04) with the same error as I reported above.
>
> The error was for the cases of 2 and 3 lights (I was testing
On Fri, 3 Jan 2020 23:50:29 GMT, Kevin Rushforth wrote:
>> Hi Johan, I did miss to verify this angle.
>> But have checked the code now and can confirm that, in a given function for
>> all possible calls to `setMemErrorFlag()` there exists a call to
>> `readAndClearMemErrorFlag()` in the same
On Thu, 9 Jan 2020 02:39:09 GMT, Kevin Rushforth wrote:
> JDK-8236733](https://bugs.openjdk.java.net/browse/JDK-8236733).
>
> Bump the release version to 15. As noted in the JBS issue, I will wait until
> right after the `jfx14` fork to integrate this.
Looks good to me.
-
Marked
Hi,
I must be doing something completely wrong or there is a major bug in
JavaFX-DnD from Java-8 upwards to JavaFX-14-ea.
If you run the attached application on OS-X the and press the CMD-key
while dragging you get null for the getTransferMode() inside DragOver
and you don't get a DragDropped
Possible workarounds would be to use Control.setSkin instead of -fx-skin, or to
bind the skin property after it has been set to something other than the
default. CSS should not mess with a bound property.
> -Original Message-
> From: openjfx-dev On Behalf Of
> Adam Granger
> Sent:
Greetings,
I realise this is now legacy for most people but we still widely use
JavaFX 8.
I appear to have discovered a memory leak when skin is changed
The constructor
com.sun.javafx.scene.control.skin.BehaviorSkinBase.BehaviorSkinBase
adds an event listener
12 matches
Mail list logo
