On Wed, 12 Feb 2020 20:34:55 GMT, Kevin Rushforth wrote:
>> I have indeed let this bug on the side. I would like to investigate but my
>> time is limited these days. Especially that
>> my patch is apparently creating another issue. I will try to give it another
>> shot in the upcoming week. But
Hi All,
I just wanted to send a "thank you!" to all the JavaFX devs for your work on
JavaFX and most especially, adding shared memory to JavaFX’s PixelBuffer.
(https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html)
The “tl;dr” is that I now have a JavaFX-based video player t
Hi Kevin,
1. In the goals you mention "Update to gtk3 (it was originally a port
from gtk2)" I presume that this preserves compatibility with older gtk2
libraries as well?
Yes it works and was tested with gtk2. It has version checks for each API that
changed since version 2. One thing that I may
On Thu, 2 Apr 2020 12:58:11 GMT, Ambarish Rapte wrote:
>> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which
>> results in leaking the `ButtonSkin` itself when
>> the `Button`'s skin is changed to a new `ButtonSkin`. Using a
>> `WeakChangeListener` instead of `ChangeListener
On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8230809
>
> Root Cause :
> Turned out to be a simpler issue than thought.
> Atomicity check was missed while updating toolbar state (which in turn
> updates styles).
>
> Fix :
> Added the miss
On Mon, 6 Apr 2020 16:14:41 GMT, Ambarish Rapte wrote:
> This is a simple fix similar to
> [JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372).
> The NPE can occur if a MOUSE_DRAGGED is received by tab header without
> receiving MOUSE_PRESSED.
> The fix also corrects a typo error. `
On Sun, 5 Apr 2020 10:19:07 GMT, Johan Vos wrote:
> Fix the code that integrates TextField/TextArea with the android keyboard
>
> Fix for #8242163
Similar question as for the IOS keyboard issue: The newly moved
`TextAreaSkinAndroid ` and `TextFieldSkinAndroid`
classes will become part of the p
On Sun, 5 Apr 2020 14:09:32 GMT, Johan Vos wrote:
> Use JavaFX controls for TextField and TextArea instead of the native iOS ones
> This fixes JDK-8242167
The new `TextAreaSkinIos` and `TextFieldSkinIos ` classes will become part of
the public API for IOS, since they are in
the `javafx.scene.co
Hi Thiago,
Nice summary!
As I mentioned offline, I am generally supportive of this, since I know
how fragile the existing Linux Glass implementation is. Unsurprisingly,
this has effectively turned into a rewrite of the Linux GTK glass port.
It's going to need a very thorough review, including
Hi Jesper,
Welcome to OpenJFX.
Yes, it's a fine idea to say hello, so that 's taken care of. I presume
you have read the CONTRIBUTING guidelines (since you sent the OCA you
probably have)? [1]
Since your OCA has been sent, you can file a PR any time. It won't be
marked as ready for review u
Hi,
I happened to fall over this issue:
https://bugs.openjdk.java.net/browse/JDK-8198402
while reading another jfx PR.
I have a shot at a fix:
https://github.com/openjdk/jfx/compare/master...jskov:toggleGroupSync-JDK-8198402
But I was not entirely sure if just submitting a PR without saying
This is a simple fix similar to
[JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372).
The NPE can occur if a MOUSE_DRAGGED is received by tab header without
receiving MOUSE_PRESSED.
The fix also corrects a typo error. `perfromDrag()` to `performDrag()`
-
Commit messages:
On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote:
> As noted in the JBS issue, this bug is a result of a deliberate change by
> Apple that affects applications (in this case
> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two
> methods that we are relying on,
>
On Mon, 6 Apr 2020 12:28:21 GMT, Ambarish Rapte wrote:
>> As noted in the JBS issue, this bug is a result of a deliberate change by
>> Apple that affects applications (in this case
>> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two
>> methods that we are relying on,
On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote:
> As noted in the JBS issue, this bug is a result of a deliberate change by
> Apple that affects applications (in this case
> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two
> methods that we are relying on,
>
On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote:
> As noted in the JBS issue, this bug is a result of a deliberate change by
> Apple that affects applications (in this case
> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two
> methods that we are relying on,
>
CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time
CLoop::execute() is called. For web native
threads which has a default stack size of 320 KB, a Stack Overflow Error is
raised just after two calls to execute()
function. While 64-bit windows has a default stack size of 1
17 matches
Mail list logo
