lila icon indicating copy to clipboard operation
lila copied to clipboard

Analysis/study page keyboard input

Open brollin opened this issue 2 years ago • 6 comments

Let's add the keyboardMove input to the analysis and study page. Not sure that the normal location directly under the board is best, but I implemented it there for the time being:

image

brollin avatar Apr 02 '24 10:04 brollin

I'm really pumped about this. Especially if you're interested in adding voice after! It's been requested several times. Variants may be tricky.

jonbgamble avatar Apr 02 '24 15:04 jonbgamble

Totally! Hoping to get voice in there right after. And I also have expectations of bug reports with both given the complexity of analysis+study+variants O_O

brollin avatar Apr 03 '24 01:04 brollin

Okay it seems to be wired up correctly, ~with only one very questionable bit of hackery~ (fixed now). As for placement, now that we have something to look at maybe we can collectively decide where it should go. There are some outstanding styling issues that I didn't want to spend to much time on in case we decided on a different location.

brollin avatar Apr 06 '24 02:04 brollin

Now the styling issues aren't as egregious, but with 2 or 3 columns in a crazyhouse study chapter with the keyboard move off, there is a little extra margin. Leaving a note for myself more than anything. Lots to keep track of with all of the possible edge cases.

brollin avatar Apr 09 '24 08:04 brollin

I like it. I did notice these areas where the various keyboard event handlers need to be deconflicted:

  • up and down arrow dont navigate the fork control when the keyboard move box has focus
  • hitting tab when the keymove box is focused puts you into a never never land where all navigation keystrokes are discarded. enter won't focus again, clicking the board won't either. you must shift tab, click back to the keymove, or click the movelist to get out of it.
  • hitting tab or escape on keymove should probably focus movelist so that any keyboard controls that conflict with keymove intercepts can still be issued.

jonbgamble avatar Apr 13 '24 13:04 jonbgamble

Good catches. I fixed the up and down arrow behavior in 1a4004b.

It turns out that the computer evaluation toggle was the next thing in the tab order, and when it is focused, or any input element for that matter, mousetrap key bindings are not respected. I solved this two ways:

  • I changed the tab order in 06b84be such that the keyboard input was after all of the right hand side tools (ceval, move list, controls, etc) in the tab order. Now, the under board is focused after the keyboard input.
  • I allowed toggling the computer evaluation via enter in 7f4517e, only when it is focused. Now if that element happens to be focused and enter is pressed, something happens at least. Since it is an input, it will still be swallowing lots of other key presses (like the arrows).

I tried to move the keyboard input such that the next thing in the tab order would be the move list, but the move list is in the middle of renderTools, and the keyboard input is rendered alongside those tools. Basically the hierarchy doesn't easily allow that. Open to changing the tab order around more if desired.

brollin avatar Apr 14 '24 07:04 brollin

It's looking a bit wrong on /analysis 258x685_2024-05-01

Also I couldn't get it to appear on a game analysis page?

ornicar avatar May 01 '24 14:05 ornicar

Should we put it up on lichess.dev or testy and let some power users see how well it integrates with the existing keyboard navigation?

jonbgamble avatar May 01 '24 15:05 jonbgamble

yes, it's on lichess.dev now

ornicar avatar May 02 '24 05:05 ornicar

Just catching back up, I can look into why it isn't on the analysis page anymore as well as the styling.

How should I log into lichess.dev? Is there a preexisting user I can use or some way to register? Attempting to register doesn't send me an email at the moment.

brollin avatar May 02 '24 09:05 brollin

Turns out there is an error when rendering the keyboard input before the underboard, but it displays fine after it (and in other positions in the vdom children array). Not sure why that error is happening, the message isn't making much sense to me: Uncaught DOMException: Node.insertBefore: Child to insert before is not a child of this node

brollin avatar May 02 '24 09:05 brollin

Okay I think it's in a better state now for testing

brollin avatar May 02 '24 10:05 brollin

Uncaught DOMException: Node.insertBefore: Child to insert before is not a child of this node

This error usually means something changed the dom that snabbdom manages.

ornicar avatar May 02 '24 14:05 ornicar

Deployed to lichess.dev!

ornicar avatar May 02 '24 14:05 ornicar

ready to go?

ornicar avatar May 03 '24 09:05 ornicar

I think so! I'll keep my eyes out for any bug reports.

brollin avatar May 03 '24 10:05 brollin