when switching between applications, key presses bleed

[nnako]

When switching between applications (in JigsawWM done using e.g. <WIN> + <J> or <WIN> + <K>), there should not be any "bleeding" of keypresses into the new application. No acidentally transferred keypresses to an unintended application.

Using JigsawWM, after switching between applications, I get e.g. k characters inside the editor of the new application, which must stem from the previous <CTRL> + <K> to switch applications.

[klesh]

Hi, @nnako Which version of JigsawWM and Windows were you using? I can not reproduce it on my Win11+ main branch. Would you like to try the Install from Github repo under the https://github.com/klesh/JigsawWM#installation section and see if it works?

[nnako]

Hi @klesh , thanks for your quick answer.

I am using

• Windows 10 (10.0-19045 Build 19045)
• current development version of JigsawWM (latest commit from last week)

I cloned your repo and did an pip install --editable . to be able to work directly on the source myself. I would think, this provides an environment as described in the install section. Do you want me to exactly reproduce another setting? From here, I have been using examples/wm.pyw

[klesh]

Hi, @nnako , I think there is a bug somewhere, you may try the following step to turn on the debugging log to investigate what went wrong:

1. Launch the PowerShell
2. type $env:DEBUG=true and hit enter
3. type py .\examples\jigsaw.pyw to run the app and you should be seeing a logs printed on the console.

[nnako]

Hi @klesh , I get the following output in PowerShell after issuing the command python .\examples\jigsaw.pyw:

Traceback (most recent call last):
  File "C:\Users\...\APP__JigsawWM\examples\jigsaw.pyw", line 3, in <module>
    from services import *
  File "C:\Users\...\APP__JigsawWM\examples\services.pyw", line 17, in <module>
    daemon.register(SyncthingService)
  File "C:\Users\...\APP__JigsawWM\src\jigsawwm\daemon.py", line 255, in register
    job.launch()
  File "C:\Users\...\APP__JigsawWM\src\jigsawwm\daemon.py", line 78, in launch
    self.start()
  File "C:\Users\...\APP__JigsawWM\src\jigsawwm\daemon.py", line 151, in start
    log_file = open(self.log_path, "a+" if self.log_append_only else "w+")
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Programs\\syncthing-windows-amd64-v1.23.2\\syncthing.log'

when having issued the command, at first, the mouse reacts only at 4 Hz (about 250 milliseconds). but after some seconds, mouse operation seems normal again. when switching windows, nothing happens within the PowerShell console window. Should I rather try the wm example?

[klesh]

@nnako Oh, I forget that jigsaw.pyw would try to bring up synching. yup, you should use wm.pyw instead.

[nnako]

Hi @klesh , here you see the console outputs:

PS C:\Users\...\APP__JigsawWM> .\_venv\Scripts\Activate.ps1
(_venv) PS C:\Users\...\APP__JigsawWM> $env:DEBUG=true
(_venv) PS C:\Users\...\APP__JigsawWM> python .\examples\wm.pyw
new monitor state
418 360 700 144
showing splash
active window 66894
active window 1508950
active window 67480
active window 721882
active window 459708
active window 66894
active window 1508950
active window 67480
active window 721882
active window 459708
active window 66894
active window 1508950
active window 67480
active window 721882
active window 459708
active window 66894
active window 1508950
active window 67480
active window 721882
active window 459708
...

what I did on the keyboard was something like:

• pressing <CTRL> + <J> and <CTRL> + <K> repeatedly to see full-screen applications change
• occasional pressing of "ordinary" keys within the neovim application

---

the video shows the 1st issue regarding the "bleeding" into new applications:

keys_bleeding_into_new_application_window__rf32.mp4

[nnako]

Hi @klesh . Your last edits on the main branch seemed to have caused the "bleeding" to stop. Great. Thanks for your efforts. So, now, when changing application windows, the new applications start with a cleared buffer after pressing the first character. Seems solved.

Could you re-open #4 instead? That issue is still unresolved.