blinking caret initially not visible

[hwaite]

Upon receiving focus, CodeArea does not immediately display cursor. It seems that StyledTextAreaVisual.caretVisible's initial state is false? Usability would be enhanced if caret were displayed faster. Otherwise, user is left wondering which control is truly active.

[TomasMikula]

You are right. When the area does not have focus, the value of caretVisible is false. When it receives focus, caretVisible switches to alternating every 500ms between false and true. There are actually two problems currently: 1. the alternating starts only after the first 500ms; and 2. the alternating starts at false. As a result, it takes 1 second until the caret is first displayed.

It is trivial to fix 2. (all it takes is to change one boolean value in the source code), getting the visual feedback down to 500ms. Fixing 1. is less trivial to do without increasing the complexity of the code. The cleanest solution would be if there was a version of ReactFX's EventStreams.ticks(Duration) that emitted the first tick immediately.

[hwaite]

It would also be nice if timer were reset with each keystroke. If user types quickly enough, caret should never disappear.

[TomasMikula]

You are right again.

[JordanMartinez]

Those EventStreams have now been written. A new ReactFX release needs to be made. Then we'd need to update the gradle file to use that new release. Then we can update the code in the (now skinless) StyledTextArea.

[JordanMartinez]

So... I'm having trouble implementing this feature...

One issue is that the AccumulatingEventStream returned from accumulate() needs to be "restarted" when ticks gets restarted:

EventStream<?> ticks = restartableTicks0(duration, keyTyped);
ticks.accumulate(false, (b, x) -> !b);

After so many seconds, the events emitted so far are: "true, false, true, false, true." The last event in this sequence is true. Now, let's say the user types a key at this point. ticks will restart itself and immediately emit a tick. accumulate() will then return false (do not show the caret).
If it could reset itself upon an impulse stream's event, so that the initial value was false again, then it would return true (show the caret) every time the user types a key. Since ticks' timer restarts, the next value (false) wouldn't be emitted until duration amount of time passes (simulating the caret blink).

Although I'm very sure there's a better way to write this (or maybe a new EventStream class that needs to be written), I was able to get this to work with the following code (ugly in my opinion):

// caret visibility code:
EventStream<KeyEvent> keyTyped = EventStreams.eventsOf(this, KeyEvent.KEY_TYPED);

caretVisible = EventStreams.valuesOf(blinkCaret)
    .flatMap(blink -> blink
        ? booleanPulse(Duration.ofMillis(500), keyTyped)
        : EventStreams.valuesOf(Val.constant(false)))
                .toBinding(false);

// boolean pulse code
private static EventStream<Boolean> booleanPulse(Duration duration, EventStream<?> impulse) {
    EventStream<?> ticks = EventStreams.restartableTicks0(duration, impulse);
    EventStream<Boolean> forceCaretVisiblity = impulse.map(x -> true);

    EventStream<?> pulses = EventStreams.merge(ticks, forceCaretVisiblity);

    // pulses will emit 2 events when key is typed.
    // the first returns false (setting up the next one)
    // the second one (null) will invert the original value to true.
    return pulses.accumulate(false, (b, x) -> {
       if (x != null) {
           System.out.println("returning false");
           return false;
       } else {
           System.out.println("returning " + !b);
           return !b;
       }
    });
}

Another issue relates to the impulse that is used to restart ticks.
When I use keyTyped, then the caret will continue to show when I press and hold a regular key (letter, digit, Backspace).
However, if I press and hold an arrow key to navigate throughout the area, the stream will only emit one KeyEvent as soon as I press it and no more after that. Thus, the caret will return to its blinking state rather than an always-on state as I navigate through the area.

[TomasMikula]

So in dd5eda7 I did kind of the same thing as you, but using a state machine combinator, with two input streams, typing and ticks, causing state transitions.

[JordanMartinez]

Huh... I didn't even know about the StateMachine class...
Cool, it's done.

[TomasMikula]

Yeah, this one was easier to explain in code than in words.

One thing worth noting is that there is already an event stream at hand that emits an event when caret or text has been manipulated, namely caretDirty, so that makes your problem with keyTyped go away.

And then the multi-input state machine (which is basically a generalization of accumulate to multiple inputs) lets you define the state transition for each input separately, so you don't have to merge two streams into one and then in accumulate reconstruct the information which input stream the event came from. I had a short blog post about the state machine, but there is not much more to it than you can already see from this example.

The snippet you posted depends on ReactFX implementation details in two ways:

1. It assumes that restartableTicks0 emits nulls. Which it in fact does, but the type EventStream<?> does not say anything about the type of objects it emits.
2. It assumes that when restartableTicks0 stream is restarted, the initial tick is not emitted immediately from within the restart impulse handler, but at some ε later, which again is the case because of how we (i.e. you ;)) implemented restartableTicks0 (the initial tick, although at timeframe 0, is still emitted asynchronously from an animation), but that fact is not part of the "specification".

[JordanMartinez]

Yeah, that's a better way to write it then.
The blog post explained the terminology I otherwise didn't understand. Thanks for posting that.

[JordanMartinez]

Edit: I encountered an error that was due to a mistake in my project's build.gradle file. Any previous comments I had here were deleted due to no longer being relevant.