Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(v2) Fix textinputs example #1176

Merged
merged 1 commit into from
Oct 15, 2024

Conversation

dogwaterdev1
Copy link

@dogwaterdev1 dogwaterdev1 commented Oct 4, 2024

Fix summary:

This should fix the textinputs example, as the code is using KeyMsg. KeyMsg seems to have an issue with the v2 alpha where it appears that both KeyPressMsg and KeyReleaseMsg may be unintentionally being called sequentionally within KeyMsg. Just using one or the other should solve the issue for this (or at least be a temporary workaround). This issue also likely exists within other examples and may Need to be looked at separately.

Specific Details on the Issue(s) Noticed

Specs/OS Information

  • Windows 11 Home 10.0.22631
  • VSCode Powershell Instance 1.20.11781.0 (this is technical just an integrated vscode instance)
  • VSCode Git bash instance 5.2.26(1)-release
  • Windows Terminal 1.20.11781.0 (this is also technically a powershell instance I believe)
  • Running a standard querty keyboard layout
    • Result of (Get-Culture).KeyboardLayoutID in powershell: 1033
    • Output from System Information related to Keyboard layout: image

Context
During the process of developing a client side, terminal implementation of a game client in bubbletea, I happened to notice that after migrating from v1/main release to v.2.0.0 that my nested models and general input were now skipping/taking two inputs:

(I could only cycle between Email and Submit in this photo)
image

After fiddling with this for a while (And nearly giving up), I tried a couple of other terminals. I noticed that in Windows Terminal, that there was a slight delay in between key presses that looked very deterministic as to when I pressed the key. Then I briefly recalled this section in the v2 alpha release notes (https://github.com/charmbracelet/bubbletea/releases/tag/v2.0.0-alpha.1):
image

My theory then became that at least on 1 complete keyboard press (at least within my environment), that because it's matching on both possible instances (and that people are slow in comparison to an action that's being performed); that within Update, KeyMsg was matching on both possible inputs (as was noted) and running each time a full key stroke is hit. I assume this functionality was not intended, and that KeyPress was met as an Either Or operation and not an Either AND. That, or there has to be something within the Runtime that is triggering both events to catch on KeyPress, causing this weird loop of Update being called twice.

This makes the fix (at least workaround) relatively simple in that you either need to use KeyPressMsg or KeyReleaseMsg instead of switching on KeyMsg.

There is also a separate bug that was noticed was that these weird escape characters seemed to appear when running the standalone windows terminal (I can also write this up as a separate bug if needed)
Standalone Windows Terminal:
image
changed spots on subsequent attempts:
image

I can open up a separate issue(s) for deeper investigation into both of these problems/bugs if needed as well.. Just depends on how much you want to break them down:

  1. KeyPress causing 2x actions on a "full" key stroke
  2. Weird windows escape character key looking stuff

This should fix the textinputs example, as the code is using KeyMsg. KeyMsg seems to have an issue with the v2
alpha where it appears that both KeyPressMsg and KeyReleaseMsg may be unintentionally being called sequentionally.
Just using one or the other should solve the issue for this. This issue also likely exists within other examples and may
Need to be looked at separately.

No PR/Issue Tag atm
@aymanbagabas
Copy link
Member

Thank you, @dogwaterdev1, for sending this PR and reporting these bugs.

There is also a separate bug that was noticed was that these weird escape characters seemed to appear when running the standalone windows terminal (I can also write this up as a separate bug if needed)

I can open up a separate issue(s) for deeper investigation into both of these problems/bugs if needed as well.. Just depends on how much you want to break them down:

Yes, could you please open up a separate issue for this one? Could you try #1163 and see if it changes anything?

@dogwaterdev1
Copy link
Author

Yes, could you please open up a separate issue for this one? Could you try #1163 and see if it changes anything?

@aymanbagabas you got it dude, I'll check it out at some point here. Thank you, let me know if you need anything else

@aymanbagabas aymanbagabas merged commit e8f7e58 into charmbracelet:v2-exp Oct 15, 2024
10 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working v2 windows
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants