'Caret animation'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Caret animation
From:       John Hendrikx <john.hendrikx () gmail ! com>
Date:       2023-12-27 5:53:56
Message-ID: 32eab062-6703-b23d-78d7-eab25a4813f4 () gmail ! com
[Download RAW message or body]

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


[Attachment #3 (text/html)]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>In light of a possible future Behavior API, I took a close look
      at the "complicated" behaviors surrounding TextFields and
      TextAreas.</p>
    <p>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:</p>
    <p>    <b>when the caret moves, animation should be reset</b></p>
    <p> 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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>I've created this ticket to address this:
      <a class="moz-txt-link-freetext" \
href="https://bugs.openjdk.org/browse/JDK-8322748">https://bugs.openjdk.org/browse/JDK-8322748</a></p>
  <p>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...<br>
    </p>
    <p>--John<br>
    </p>
    <p><br>
    </p>
  </body>
</html>



[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic