I agree - this makes sense.
-andy
From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx
<john.hendr...@gmail.com>
Date: Tuesday, December 26, 2023 at 21:54
To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>
Subject: Caret animation
In light of a possible future Behavior API, I took a close look at the
"complicated" behaviors surrounding TextFields and TextAreas.
One thing that came out of this is that caret animation is controlled by the
behaviors by looking at key presses and keys typed. It is a very convoluted way
of doing this as there is a much simpler rule that governs caret animation:
when the caret moves, animation should be reset
This is how controls do it in browsers and on Windows, and it makes much more
sense. The caret only needs highlighting when it actually changed position, and
can remain animated when it doesn't.
This also means that caret blinking can simply be a concern of the Skin, as it
can listen for caret position changes. This also makes more sense. Replacing
the Behavior but keeping the same Skin should not break caret blinking.
Currently, the behaviors will wrap all possible key pressed/typed events to
stop the blinking, but it gets it wrong in many situations (when the caret
didn't actually move, or when a key press was not consumed or didn't do
anything, or using keypad navigation which "forgets" to wrap it in the
start/stop animation logic). It feels like a big hack when there is such an
obvious alternative.
I've created this ticket to address this:
https://bugs.openjdk.org/browse/JDK-8322748
One of the immediate benefits (aside from solving all caret animation bugs) is
probably a memory reduction as it removes a wrapper around every key press/type
mapping...
--John
