On Wed, 2 Oct 2024 17:09:59 GMT, Ambarish Rapte wrote:
> Update the boot JDK to version 23.
>
> Since Gradle 8.9 does not support JDK 23, it is necessary to upgrade Gradle
> to the latest release, version 8.10.2, which supports JDK 23.
> It is advised to upgrade directly to Gradle 8.10.2 rathe
On Wed, 2 Oct 2024 23:15:41 GMT, Kevin Rushforth wrote:
> Doing this will ensure that gradlew and gradlew.bat are up-to-date with the
> latest version, which is not the case for this PR.
On a Mac machine, I had executed the command: `sh gradlew wrapper
--gradle-version 8.10.2`
It makes two cha
On Wed, 2 Oct 2024 18:52:36 GMT, Michael Strauß wrote:
> Gradle should be upgraded with the `wrapper` task (see [Upgrading your build
> from Gradle 8.x to the
> latest](https://docs.gradle.org/current/userguide/upgrading_version_8.html)):
>
> ```
> gradle wrapper --gradle-version 8.10.2
> ```
On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote:
> This change modifies `ScrollPaneBehavior` to only consume keys that are
> targetted at it. As `KeyEvent`s are in almost all cases only intended for
> the targetted node (as visually that's where the user expects the keyboard
> input to
On Wed, 2 Oct 2024 21:00:55 GMT, Martin Fox wrote:
> Whatever behavior we want the way it's implemented in JavaFX at the moment is
> wrong.
I changed my mind and I agree with you and John that this change makes sense.
> BTW, I'm not optimistic that we can find some combination of modifiers +
On Wed, 2 Oct 2024 02:25:26 GMT, John Hendrikx wrote:
> you're saying that you think it is okay that setting a Skin suddenly makes
> your control malfunction
No, I am not saying that.
I played a bit more with your example. Your CustomButtonSkin is weird as it
does not place the original butt
On Wed, 2 Oct 2024 20:12:00 GMT, Andy Goryachev wrote:
> > Focus either lies on the node that owns the ScrollPane (like a TableView)
> > or one of the nodes inside the ScrollPane but not on the ScrollPane itself.
>
> this seems to be incorrect: unless you set `mouseTransparent`, ScrollPane can
On Wed, 2 Oct 2024 18:12:35 GMT, Martin Fox wrote:
> Focus either lies on the node that owns the ScrollPane (like a TableView) or
> one of the nodes inside the ScrollPane but not on the ScrollPane itself.
this seems to be incorrect: unless you set `mouseTransparent`, ScrollPane can
be focused
On Wed, 2 Oct 2024 17:09:59 GMT, Ambarish Rapte wrote:
> Update the boot JDK to version 23.
>
> Since Gradle 8.9 does not support JDK 23, it is necessary to upgrade Gradle
> to the latest release, version 8.10.2, which supports JDK 23.
> It is advised to upgrade directly to Gradle 8.10.2 rathe
On Wed, 2 Oct 2024 18:12:35 GMT, Martin Fox wrote:
> I can’t think of an instance where a ScrollPane receives focus.
when there is a non-interactive content inside (such as image or a label).
they you *do* want to handle arrow keys to scroll.
-
PR Comment: https://git.openjdk.org/j
On Mon, 30 Sep 2024 16:30:49 GMT, Martin Fox wrote:
> The glass code on Windows does its own dead key processing so at certain
> points it must clear the dead key state that the OS is maintaining. It does
> this by simulating a SPACE key press but this only works reliably if the
> SPACE key is
On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote:
> This change modifies `ScrollPaneBehavior` to only consume keys that are
> targetted at it. As `KeyEvent`s are in almost all cases only intended for
> the targetted node (as visually that's where the user expects the keyboard
> input to
On Wed, 2 Oct 2024 17:09:59 GMT, Ambarish Rapte wrote:
> Update the boot JDK to version 23.
>
> Since Gradle 8.9 does not support JDK 23, it is necessary to upgrade Gradle
> to the latest release, version 8.10.2, which supports JDK 23.
> It is advised to upgrade directly to Gradle 8.10.2 rathe
On Wed, 2 Oct 2024 17:27:43 GMT, Andy Goryachev wrote:
>> All fields of `BackgroundPosition` are already final. Same for `BorderImage`
>> and `BorderStroke`.
>
> sorry, I meant make them `private`
Yes, that's a sensible change.
-
PR Review Comment: https://git.openjdk.org/jfx/pull
On Wed, 2 Oct 2024 17:50:32 GMT, Michael Strauß wrote:
>> Backgrounds and borders are comprised of immutable and final types. The
>> following types are marked with the `final` modifier:
>>
>> * Background
>> * BackgroundFill
>> * BackgroundImage
>> * BackgroundSize
>> * Border
>> * BorderWidth
> Backgrounds and borders are comprised of immutable and final types. The
> following types are marked with the `final` modifier:
>
> * Background
> * BackgroundFill
> * BackgroundImage
> * BackgroundSize
> * Border
> * BorderWidths
>
> The following types are not marked with the `final` modifie
On Wed, 2 Oct 2024 17:09:59 GMT, Ambarish Rapte wrote:
> Update the boot JDK to version 23.
>
> Since Gradle 8.9 does not support JDK 23, it is necessary to upgrade Gradle
> to the latest release, version 8.10.2, which supports JDK 23.
> It is advised to upgrade directly to Gradle 8.10.2 rathe
> Public APIs for focus traversal and the focus traversal policy:
>
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md
>
> This work is loosely based on the patch
> https://cr.openjdk.org/~jgiles/8061673/
Andy Goryachev has updated the pull request wit
On Wed, 2 Oct 2024 17:23:11 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java
>> line 55:
>>
>>> 53: * @since JavaFX 8.0
>>> 54: */
>>> 55: public final class BackgroundPosition implements
>>> Interpolatable {
>>
>> should we als
On Wed, 2 Oct 2024 14:43:33 GMT, Andy Goryachev wrote:
>> Backgrounds and borders are comprised of immutable and final types. The
>> following types are marked with the `final` modifier:
>>
>> * Background
>> * BackgroundFill
>> * BackgroundImage
>> * BackgroundSize
>> * Border
>> * BorderWidth
Update the boot JDK to version 23.
Since Gradle 8.9 does not support JDK 23, it is necessary to upgrade Gradle to
the latest release, version 8.10.2, which supports JDK 23.
It is advised to upgrade directly to Gradle 8.10.2 rather than 8.10. refer to
[the release notes](https://docs.gradle.org/
I suspect people who are using SecurityManager with JavaFX are still
on java8.
Very likely.
-- Kevin
On 10/2/2024 7:58 AM, Andy Goryachev wrote:
Good riddance! I suspect people who are using SecurityManager with
JavaFX are still on java8.
-andy
*From: *openjfx-dev on behalf of Kevin
It's more an evolving realization that there is little benefit to the
OpenJFX community to force JavaFX to be tied to an LTS release of the
JDK, and a cost to doing so (both in additional testing, opportunity
cost of using new features, etc). LTS releases are about stability and
support; if an
On Tue, 1 Oct 2024 20:17:52 GMT, Martin Fox wrote:
>> The glass code on Windows does its own dead key processing so at certain
>> points it must clear the dead key state that the OS is maintaining. It does
>> this by simulating a SPACE key press but this only works reliably if the
>> SPACE key
I was advocated to bump to JDK 22 last year, with FFM as a main reason to
replace sun.misc.Unsafe [1], so of course I endorse this. The main rebuttal
was that companies prefer to use LTS versions (although any distributor can
declare any version as LTS), so I wonder if these considerations still t
Good riddance! I suspect people who are using SecurityManager with JavaFX are
still on java8.
-andy
From: openjfx-dev on behalf of Kevin Rushforth
Date: Wednesday, October 2, 2024 at 07:46
To: openjfx-dev
Subject: Proposal: Remove support for running JavaFX with the security manager
The J
On Tue, 1 Oct 2024 21:46:21 GMT, Michael Strauß wrote:
> Backgrounds and borders are comprised of immutable and final types. The
> following types are marked with the `final` modifier:
>
> * Background
> * BackgroundFill
> * BackgroundImage
> * BackgroundSize
> * Border
> * BorderWidths
>
> Th
The Java Security Manager was deprecated for removal in JDK 17 by JEP
411 [1]. The next step in the evolution of removing the security manager
is to permanently disable it as proposed by candidate JEP 486 [2]. Once
this is done, System::getSecurityManager will unconditionally return
null, Syste
All,
Even though we build JavaFX 24 binaries with JDK 22 (and soon will build
with JDK 23) as the boot JDK, the latest version of JavaFX still runs
with JDK 21, although it isn't tested with older JDK versions. In order
for JavaFX to be able to use newer JDK features, such as FFM (Panama),
we
On Wed, 21 Aug 2024 09:58:53 GMT, Thiago Milczarek Sayao
wrote:
>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>>
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative
>> positioning on `InputMethodRequest`.
>>
On Sun, 25 Aug 2024 20:59:43 GMT, Thiago Milczarek Sayao
wrote:
>> Wayland implementation will require EGL.
>>
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails,
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>>
>>
>> See:
>> [Switching th
I think you might be right. I see that you created a Draft PR. Can you
also file a bug?
-- Kevin
On 9/27/2024 2:07 PM, Thiago Milczarek Sayão wrote:
Hi,
Pardon me If I'm bothering with nonsense, but I really think there's a
leak, mainly because DrawableInfo is never freed (I did not find an
On Tue, 1 Oct 2024 20:17:52 GMT, Martin Fox wrote:
>> The glass code on Windows does its own dead key processing so at certain
>> points it must clear the dead key state that the OS is maintaining. It does
>> this by simulating a SPACE key press but this only works reliably if the
>> SPACE key
On Tue, 1 Oct 2024 20:17:52 GMT, Martin Fox wrote:
>> The glass code on Windows does its own dead key processing so at certain
>> points it must clear the dead key state that the OS is maintaining. It does
>> this by simulating a SPACE key press but this only works reliably if the
>> SPACE key
On Tue, 1 Oct 2024 23:04:40 GMT, Michael Strauß wrote:
> > There might be a very narrow use case (like debugging) when developer might
> > need to extend to supply a custom `toString()` or some other method.
> > From a high level design standpoint, I do agree with making these classes
> > final
On Fri, 27 Sep 2024 13:07:15 GMT, Kevin Rushforth wrote:
>> This PR modifies the header and footer of the javadoc-generated API docs to
>> add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and
>> also to make it clear which build number the docs refer to. This matches was
>
On Thu, 26 Sep 2024 21:33:10 GMT, Kevin Rushforth wrote:
> This PR modifies the header and footer of the javadoc-generated API docs to
> add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and
> also to make it clear which build number the docs refer to. This matches was
> th
On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote:
> This change modifies `ScrollPaneBehavior` to only consume keys that are
> targetted at it. As `KeyEvent`s are in almost all cases only intended for
> the targetted node (as visually that's where the user expects the keyboard
> input to
Hi,
I am encountering an issue with vertical scroll bar visibility when I set
the height of a TableView to some fixed height. The vertical scroll bar is
always visible.
I am trying to give enough space(height) so that the vertical scroll bar is
not visible, but looks like this only works after so
On Wed, 21 Aug 2024 09:58:53 GMT, Thiago Milczarek Sayao
wrote:
>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>>
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative
>> positioning on `InputMethodRequest`.
>>
40 matches
Mail list logo
