kitti3 not opening kitty window

[Deleted user]

Until yesterday, this had been working so I suspect some upgrade broke kitti3. I strongly suspect it's related to a python upgrade, because I had to do that for something else in the morning.

Behavior

• kitty itself works fine -- I can open windows as usual
• Triggering kitti from the i3 hotkey doesn't do anything
• There are no errors in .xsession-errors
• If I replace nop and make it an exec I just end up with a bunch of kitti3 instances -- one for every time I press MOD1+n.
• I've tried with compiz both enabled and disabled
• I've confirmed that $mod+n is bound exactly once in the .i3/config, and that's to kitti3
• I tried to fix it with pip install --force-reinstall --upgrade kitti3 --user
• I changed the i3 exec to exec_always to make sure kitti3 is executed on i3 restart, and confirmed via ps that i3 is, indeed, executing the kitti3 command.
• Killing the i3 kitti3 and running kitti3 from the command line, kitti3 executes and does nothing as expected (since it doesn't fork). ^z + bg to fork and background it, and then:
• a second call to kitti3 from the command line also does nothing (triggers no exposure of a window). It, too, just hangs there with no errors.

I don't know if kitti3 is doing something clever with i3 sockets and so testing from the command line is not valid; if so, any other pointers on how to debug this would be appreciated.

Environment

• i3-gaps 4.17.1
• arch linux, up-to-date as of last night. The problem started prior to the system upgrade.
• kitty 0.14.6 created by Kovid Goyal
• kitti3 0.2.4
• python 3.7.4

➜  ~ grep kitti3 .i3/config
bindsym $mod+n nop /home/ser/.local/bin/kitti3
exec --no-startup-id "/home/ser/.local/bin/kitti3 -p right -s 1.0 0.6"

[LandingEllipse]

Hi @serussell,

Thanks for your detailed issue report. At first glance the issue seems to be a misunderstanding regarding how Kitti3 is triggered by keybinds. The bindsym is a nop on purpose, as the Kitti3 instance is listening to key events over the i3 socket based IPC API, and even nop binds trigger events. The string immediately following nop is actually used as the instance ID for Kitti3, to allow for multiple instances to run concurrently. Judging by your .i3/config, this is where the misunderstanding lies, in that you seem to have assumed the path to Kitti3 should be included on this line.

I believe replacing the bindsym line in your config with the stock one from the documentation should fix the issue, that is: bindsym $mod+n nop kitti3. kitti3 here being the default instance name, which on second thought maybe should be changed to avoid confusion in the future (the way keybinds are handled are already a bit on the fringe...)

I don't know how this worked before for you if this is how your config has always been; let me know if this sorts it out and if not we can dig a bit deeper (I'm on Arch as well so should be possible to replicate)

[Deleted user]

That was it. I had a vague understanding of what nop does in i3, but obviously not a full understanding. Changing the ID to just kitti3 fixed it.

PEBCAK. Closing.

Edit: Thank you :-)

[LandingEllipse]

Glad to hear it!

I'll update the documentation to highlight the voodoo and give a heads up to others who might want/need to use absolute paths.

Cheers,
Ariel