On Thu, 22 Dec 2022 00:13:03 GMT, Kevin Rushforth wrote:
> Apple has changed the behavior for applications that are built using the
> macOS SDK 13 (which is what XCode 14 uses), such that passing in a null
> tracking rect to `NSView::removeTrackingRect` will cause now cause a crash.
> This has
On Wed, 21 Dec 2022 10:58:50 GMT, Karthik P K wrote:
> When Text width was more than TextField width, condition to update
> `textTranslateX` was not getting satisfied as calculated value was negative.
> Hence the text was getting aligned to previous `textTranslateX` value.
>
> Added else block
On Thu, 22 Dec 2022 00:13:03 GMT, Kevin Rushforth wrote:
> Apple has changed the behavior for applications that are built using the
> macOS SDK 13 (which is what XCode 14 uses), such that passing in a null
> tracking rect to `NSView::removeTrackingRect` will cause now cause a crash.
> This has
On Thu, 22 Dec 2022 00:44:24 GMT, Thiago Milczarek Sayao
wrote:
>> This cleans size and positioning code, reducing special cases, code
>> complexity and size.
>>
>> Changes:
>>
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
>> sizes. It does not assume any si
> This cleans size and positioning code, reducing special cases, code
> complexity and size.
>
> Changes:
>
> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
> sizes. It does not assume any size because it varies - it does cache because
> it's unlikely to vary on t
Thanks for the additional info. I can reproduce this on macOS 13.1
(Ventura). In my testing earlier today, I only saw it when switching in
and out of full screen mode. I checked my settings and “Automatically
hide and show the menu bar” was set to “In Full Screen Only”, so what I
was seeing is
On Tue, 20 Dec 2022 01:43:11 GMT, Thiago Milczarek Sayao
wrote:
>> This cleans size and positioning code, reducing special cases, code
>> complexity and size.
>>
>> Changes:
>>
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
>> sizes. It does not assume any si
As it turns out, it is the version of Xcode / macOS SDK that was used
the compile the JDK that matters, regardless of what we use to compile
JavaFX. That makes this is a more serious bug than initially thought.
I can reproduce it, and have sent a pull request for review:
https://github.com/ope
On Thu, 22 Dec 2022 00:13:03 GMT, Kevin Rushforth wrote:
> Apple has changed the behavior for applications that are built using the
> macOS SDK 13 (which is what XCode 14 uses), such that passing in a null
> tracking rect to `NSView::removeTrackingRect` will cause now cause a crash.
> This has
Apple has changed the behavior for applications that are built using the macOS
SDK 13 (which is what XCode 14 uses), such that passing in a null tracking rect
to `NSView::removeTrackingRect` will cause now cause a crash. This has exposed
a latent bug in the JavaFX macOS glass code that removes t
On Tue, 20 Dec 2022 17:49:13 GMT, Johan Vos wrote:
>> When recalculating sizes, we often don't want the current index and/or
>> offset to change.
>>
>> Allow to fix the index/offset when doing recalculations.
>>
>> Fix JDK-8298728
>
> Johan Vos has updated the pull request incrementally with o
On Wed, 21 Dec 2022 10:58:50 GMT, Karthik P K wrote:
> When Text width was more than TextField width, condition to update
> `textTranslateX` was not getting satisfied as calculated value was negative.
> Hence the text was getting aligned to previous `textTranslateX` value.
>
> Added else block
On Wed, 21 Dec 2022 10:58:50 GMT, Karthik P K wrote:
> When Text width was more than TextField width, condition to update
> `textTranslateX` was not getting satisfied as calculated value was negative.
> Hence the text was getting aligned to previous `textTranslateX` value.
>
> Added else block
On Tue, 20 Dec 2022 01:43:11 GMT, Thiago Milczarek Sayao
wrote:
>> This cleans size and positioning code, reducing special cases, code
>> complexity and size.
>>
>> Changes:
>>
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
>> sizes. It does not assume any si
On Tue, 20 Dec 2022 01:43:11 GMT, Thiago Milczarek Sayao
wrote:
>> This cleans size and positioning code, reducing special cases, code
>> complexity and size.
>>
>> Changes:
>>
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
>> sizes. It does not assume any si
On Tue, 20 Dec 2022 08:42:10 GMT, Ambarish Rapte wrote:
> Updating boot JDK to 19.0.1.
> Gradle 7.3 is not compatible with JDK 19.0.1 hence updated the gradle minimum
> version as well.
This pull request has now been integrated.
Changeset: 1d9e2afc
Author:Ambarish Rapte
URL:
https:
On Wed, 21 Dec 2022 05:45:12 GMT, Ambarish Rapte wrote:
>> Updating boot JDK to 19.0.1.
>> Gradle 7.3 is not compatible with JDK 19.0.1 hence updated the gradle
>> minimum version as well.
>
> Ambarish Rapte has updated the pull request incrementally with one additional
> commit since the last
As Johan said, the JavaFX releases are currently built with Xcode 12.4,
so JDK-8296654 isn't directly relevant, unless it doesn't fully describe
the problem. If you are seeing a crash on macOS 13 Ventura with the
downloaded JavaFX SDK (built with Xcode 12.4), that would be a much more
serious b
On Mon, 19 Dec 2022 15:50:19 GMT, Lukasz Kostyra wrote:
> Creating a not-displayed node and then modifying its contents caused JFX to
> not consume its old dirty region and thus not update it. When such node was
> displayed, its old dirty region was used for drawing, which in some cases
> (ex.
> This PR was previously discussed on #905.
>
> The approach is to grab the keyboard focus so the window that originated the
> drag will keep it.
>
> I did some cleanup on grabbing related functions as well.
>
> `gdk_keyboard_focus()` is deprecated, so is `gdk_device*` functions in favor
> of
On Wed, 21 Dec 2022 05:45:12 GMT, Ambarish Rapte wrote:
>> Updating boot JDK to 19.0.1.
>> Gradle 7.3 is not compatible with JDK 19.0.1 hence updated the gradle
>> minimum version as well.
>
> Ambarish Rapte has updated the pull request incrementally with one additional
> commit since the last
On Wed, 21 Dec 2022 00:42:15 GMT, Thiago Milczarek Sayao
wrote:
>> This PR was previously discussed on #905.
>>
>> The approach is to grab the keyboard focus so the window that originated the
>> drag will keep it.
>>
>> I did some cleanup on grabbing related functions as well.
>>
>> `gdk_ke
When Text width was more than TextField width, condition to update
`textTranslateX` was not getting satisfied as calculated value was negative.
Hence the text was getting aligned to previous `textTranslateX` value.
Added else block to update the `textTranslateX` value when calculated value is
n
There will be a new JavaFX 19 release with the security patches for 2023Q1
(scheduled Jan 17).
Typically, those maintenance releases contain a few selected backports from
the head version.
However, in this case it seems unlikely to me as JDK-8296654 is not
resolved.
Once resolved, that is something
Will JavaFX 19 release an updated version?
We have received a lot of feedback about program crashes on the macOS.
These crashes should be caused by JDK-8296654.
Because our program needs to be compatible with Java 11~16, it cannot be
updated to JavaFX 20.
It would be great if we could fix this pro
25 matches
Mail list logo
