On Thu, 3 Oct 2024 16:33:12 GMT, Andy Goryachev wrote:
> > or perhaps indeed something with traversal policies would need to be
> > created by the user to solve this on a case by case basis. It will be hard
> > to always do the expected thing with a control as generic as ScrollPane.
>
> I play
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 Thu, 3 Oct 2024 15:55:55 GMT, Andy Goryachev 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
On Thu, 3 Oct 2024 19:54:58 GMT, Andy Goryachev wrote:
>> It's an interesting suggestion, but it is not needed. `javac` will already
>> deduplicate these.
>>
>> You can even verify that this is the case. Use `javap` to decompile the
>> class file with `javap -c `. In there, `invokedynamic`
On Thu, 3 Oct 2024 19:40:43 GMT, John Hendrikx wrote:
>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java
>> line 88:
>>
>>> 86:
>>> 87: new InputMap.KeyMapping(new KeyBinding(HOME), e ->
>>> verticalHome(), this::isNotFocused),
>
On Tue, 14 May 2024 22:29:18 GMT, Martin Fox wrote:
>> On Linux getKeyCodeForChar does not consult the current keyboard layout. For
>> example, it assumes the “+” character is on KeyCode.PLUS even on layouts
>> which don’t generate KeyCode.PLUS. The result is that most
>> KeyCharacterCombinati
On Thu, 3 Oct 2024 06:23:06 GMT, Michael Strauß wrote:
> Running `gradle wrapper --gradle-version 8.10.2
> --gradle-distribution-sha256-sum
> 31c55713e40233a8303827ceb42ca48a47267a0ad4bab9177123121e71524c26` on my
> Windows machine changes `gradlew` and `gradlew.bat` as follows:
This is not o
On Wed, 2 Oct 2024 18:12:35 GMT, Martin Fox wrote:
> I agree that the current ScrollPane implementation is wrong. Traversal is an
> accessibility issue so it’s imperative that we don’t block the traversal
> keys. We can’t expect custom controls to work around the ScrollPane's faulty
> behavior
On Thu, 3 Oct 2024 08:24:18 GMT, Ambarish Rapte wrote:
>> Running `gradle wrapper --gradle-version 8.10.2
>> --gradle-distribution-sha256-sum
>> 31c55713e40233a8303827ceb42ca48a47267a0ad4bab9177123121e71524c26` on my
>> Windows machine changes `gradlew` and `gradlew.bat` as follows:
>>
>>
>>
On Wed, 2 Oct 2024 21:00:55 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`,
On Wed, 2 Oct 2024 21:12:07 GMT, Andy Goryachev wrote:
> I played a bit more with your example. Your CustomButtonSkin is weird as it
> does not place the original button in the scene graph, not sure if that's
> important.
I think there is a misunderstanding. The `CustomButton` **is** part of
On Wed, 2 Oct 2024 09:06:17 GMT, Lukasz Kostyra wrote:
> I have an issue in IMETest with the new patch. This does not happen on
> master, so I suspect it's a regression.
>
> I tried typing with polish keyboard and it seems like it does not pick up the
> special characters which use diacritical
> 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`.
>
> [Screencast from 17-09-2023
> 21:59:04.webm](https://github.com/openj
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`.
>>
When creating a Scene, a `DrawableInfo` is allocated with `malloc`. When scene
changes, this is called on `WindowStage.java`:
`QuantumRenderer.getInstance().disposePresentable(painter.presentable); //
latched on RT`
But the underlying `DrawableInfo` is never freed.
I also think this should b
On Tue, 1 Oct 2024 17:37:15 GMT, Thiago Milczarek Sayao
wrote:
> When creating a Scene, a `DrawableInfo` is allocated with `malloc`. When
> scene changes, this is called on `WindowStage.java`:
>
> `QuantumRenderer.getInstance().disposePresentable(painter.presentable); //
> latched on RT`
>
On Tue, 1 Oct 2024 19:16:06 GMT, Andy Goryachev wrote:
>> Incubating a new feature - rich text control, **RichTextArea**, intended to
>> bridge the functional gap with Swing and its StyledEditorKit/JEditorPane.
>> The main design goal is to provide a control that is complete enough to be
>> us
On Tue, 1 Oct 2024 17:37:15 GMT, Thiago Milczarek Sayao
wrote:
> When creating a Scene, a `DrawableInfo` is allocated with `malloc`. When
> scene changes, this is called on `WindowStage.java`:
>
> `QuantumRenderer.getInstance().disposePresentable(painter.presentable); //
> latched on RT`
>
On Thu, 3 Oct 2024 09:35:51 GMT, Lukasz Kostyra wrote:
> Contrary to issue description, the problem was not because we referenced a
> texture after it was freed, but we referenced an RTT that we just tried to
> allocate and failed to do so because of lack of space in Prism's vram pool.
> In ca
On Thu, 3 Oct 2024 14:26:23 GMT, Ambarish Rapte wrote:
> I observed an NPE with RichTextAreaDemoApp:
I can't reproduce this...
Are you on mac or windows? Are you testing the latest code (can you tell me
the git commit hash?)
Also, could you take a screenshot when this happens, I'd like to see
On Thu, 3 Oct 2024 09:35:51 GMT, Lukasz Kostyra wrote:
> Contrary to issue description, the problem was not because we referenced a
> texture after it was freed, but we referenced an RTT that we just tried to
> allocate and failed to do so because of lack of space in Prism's vram pool.
> In ca
On Thu, 3 Oct 2024 13:26:38 GMT, John Hendrikx wrote:
> or perhaps indeed something with traversal policies would need to be created
> by the user to solve this on a case by case basis. It will be hard to always
> do the expected thing with a control as generic as ScrollPane.
I played with you
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 Tue, 1 Oct 2024 17:37:15 GMT, Thiago Milczarek Sayao
wrote:
> When creating a Scene, a `DrawableInfo` is allocated with `malloc`. When
> scene changes, this is called on `WindowStage.java`:
>
> `QuantumRenderer.getInstance().disposePresentable(painter.presentable); //
> latched on RT`
>
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
Contrary to issue description, the problem was not because we referenced a
texture after it was freed, but we referenced an RTT that we just tried to
allocate and failed to do so because of lack of space in Prism's vram pool. In
case of attached `WebViewAnimationTest.java` test app, the problem
26 matches
Mail list logo
