Keybinding "Appears" to Do nothing
typkrft opened this issue · 10 comments
Surely I'm doing something wrong so please forgive me.
I installed using pip. It appears in my path when I run which. At the bottom of my i3 config I added the lines.
###############################################################################
# User Configuaration
###############################################################################
# Launch Kitty Drop Down
exec --no-startup-id kitti3
bindsym $alt+` nop kitti3
I've also attached my entire config file for i3, which is just the default regolith config. I had to rename it with a .txt suffix to attach it.
config.txt
Hi Brandon,
Nothing obvious wrong with the config. Have you restarted i3wm since changing the config? If you only do a config reload this will AFAIK not actually spawn kitti3 (I think i3 doesn't trigger execs in the config to prevent respawning existing processes?). What you can do if you don't want to restart i3 is to trun kitti3 via dmenu initially (and then it will be triggered throught he i3 config on future restarts).
Something else I just finally realised the cause of is that an i3 config reload will cause any kitti3 instances to exit; I'm pretty sure that's due to the Python IPC wrapper we're using and I'll have a look at fixing that in an upcoming release.
OK, I've just taken the 5 minutes I should have months ago to figure out what's going on...
The first issue: currently, kitti3 is spawned through the i3 config. However, as it is triggered by the exec keyword and not exec_always, after a fresh install it won't actually be spawned by neither an i3 restart nor config reload - you need to either exit i3 completely and jump back in, or spawn kitti3 manually via e.g. dmenu.
Related issue: by default, the IPC library we're using exits the event loop when i3 restarts, so if you've already got kitti3 running and you decide to reload i3wm (I keep defaulting to the restart keybinding instead of the config reload one out of habit...) then kitti3 simply exits. Good if exec_always is used in the config as a new instance of kitti3 is spawned, but bad if exec is used and you're left without a running instance.
Solution: change exec --no-startup-id kitti3 to exec_always --no-startup-id kitti3 and restart i3wm inplace (e.g. $mod+Shift+r).
Hopefully this addresses the issue you've been having; I'll update the documentation to recommend using exec_always.
Hope that helps,
Ariel
Sorry for the late reply. As soon as I'm back on that computer I'll give it a whirl. I thought maybe it had something to do with Regolith installing some configs in nonstandard places, but your explanation makes sense.
Update:
Unfortunately, I still wasn't able to get it to work. I have a feeling Regolith is breaking it's functionality. I'll try a vanilla install of i3 on Ubuntu or Arch and see if I can't get it working.
Also, I just read your note on on ligatures, which cracked me up because this is exactly how I found this project. It's 2020 VTE let me use Victor Mono.
I'm actually on i3-gaps and I'm having kinda of this issue.
Even if I launch kitti3 from the terminal nothing happens at all how should I proceed to further debug this issue ?
The keybinding looks like it doesn't do anything, something may be failing silently, I'd like it if this software had a verbose output flag that you could use when launching it to see what's going on and what went wrong instead of just nothing.
I have installed the package using pip3.
Salut Lahfa,
I realise that the piggybacking off of i3wm's keybinding/bindsym system can be a bit fiddly. I think the verbose mode is a good idea, and I'll see if it can be integrated in the not too distant future.
With regards to the debug steps, please first ensure that you've followed the readme, and especially that you've remembered to do a hot reload of i3wm's config after adding the bindsyms.
If the bindsym you've defined still isn't popping up Kitty, then you can run i3-msg -t subscribe -m '["binding"]' on the command line to listen in and verify that the bindsym is actually being triggered by i3wm and published over IPC. Example output for me with the stock config:
➜ i3-msg -t subscribe -m '["binding"]'
{"change":"run","binding":{"input_code":0,"input_type":"keyboard","symbol":"n","command":"nop kitti3","mods":["Mod1"],"event_state_mask":["Mod1"]}}
In the above, the "command":"nop kitti3" part corresponds to the config line bindsym $mod+n nop kitti3, and this is what Kitti3 is listening to over IPC to determine if it should trigger showing/hiding Kitty. The kitti3 part is the instance name, and you can of course set that to whatever, so long as it's the same in the bindsym and the -n flag to Kitti3, e.g.:
exec_always --no-startup-id kitti3 -n sesame
bindsym $mod+n nop sesame
should also work.
So, to sum it up: if you..
- have reloaded the i3-wm config; and
- you see the bindsym trigger IPC message from
i3-msg; and - Kitti3 is either being launched by an
exec_alwaysin the config, or manually on the command line, with matching instance names for the bindsym and Kitti3; and - you have Kitty installed in the first place (you have, right? 😬); and
- you're still not seeing Kitty pop up when you're triggering the keybinding
then we're in new territory and need to dig a bit deeper!
Cheers,
Ariel
So here is what I have when I press the keybinding, the command appear to be run but nothing happens on i3wm, there is no Kitty that slides out of the screen or goes back to hide.
{"change":"run",
"binding":
{"input_code":0,
"input_type":"keyboard",
"symbol":"t",
"command":"nop kitti3 --session
/home/xxxx/.config/kitty/kittystartupwork",
"mods":["shift","Mod4"],
"event_state_mask":["shift","Mod4"]}}I have indeed done step 1 and 2, step 4 is yes I do have kitty installed (I use it as my main terminal as of currently hence why I'm trying to use kitti3).
It seems we are in a new territory, however I want to precise one thing my kitty version is quite old (due to the Ubuntu package not being updated that much), it is 0.15.0 latest is 0.18.3 so my version dates back to 2019, it may be that some bugs that were a thing before have been solved now with the new versions of kitty hence explaining my issue.
Even if I manually type in the command line kitti3 nothing happens and nothing shows up.
"command":"nop kitti3 --session /home/xxxx/.config/kitty/kittystartupwork",
This hints at a misunderstanding in your config. As mentioned in the readme and in Kitti3's help text, passing arguments to Kitty is done when spawning Kitti3 (i.e. the exec_always config line), not through the bindsym line. An example from the readme:
exec_always --no-startup-id kitti3 -n caterwaul -p left -s 1.0 0.3 -- --session ~/.kitty_session
bindsym $mod+n nop caterwaul
You separate the arguments to Kitti3 (e.g. -p left) from those to Kitty (e.g. --session ...) by two dashes (--).
I hope this solves it. In any case I again agree that a verbose/debug mode could be helpful. If my analysis is correct then your Kitti3 is indeed listening, it's just not instructed to react to malformed keybind triggers - but it would be trivial to instruct it to echo events that don't match when in debug mode, which would have helped highlight the issue in this case.
My bad I thought after reading that the documentation said that all argument with double dashes -- would be forwarded to kitty, now I tried with the fix as you've said.
Here is the command :
"command":"nop kitti3 -- --session /home/akechi/.config/kitty/kittystartupwork"
But still nothing appears on screen is a kitty windows supposed to appear when I press the keybinding ?
Sorry, I wasn't being entirely clear.
In your i3 config file you have two lines. To bring back the example from my last post:
exec_always --no-startup-id kitti3 -n caterwaul -p left -s 1.0 0.3 -- --session ~/.kitty_session
bindsym $mod+n nop caterwaul
The first starts with exec_always and is the line that invokes Kitti3 when i3 starts (which lets Kitti3 sit in the background waiting for bindsym events over IPC). This is the line where you append any additional arguments to Kitty. In this example: -- --session ~/.kitty_session.
The second line starts with bindsym and is the line that tells i3 to look out for a keybinding ($mod+n in my examples), and when it is triggered, do something in response. The way it's implemented here is that a nop command (i.e. "no operation" - do nothing) is chosen to be executed, which actually triggers an IPC event (the one you've listened for with i3-msg before). The neat thing is that the nop can take a parameter. It is this parameter that we use as the instance ID/name that Kitti3 is looking out for when listening over IPC. In my last post I showed an example of how this can be set to e.g. "caterwaul", but then you have to instruct Kitti3 on the previous line to look out for this ID specifically instead of the default "kitti3"; this is done via the -n caterwaul in the line above. I have a feeling that my use of "kitti3" as the default instance ID is probably more than a little confusing; I'll revise the documentation (though changing the defaults would break backwards compatibility so that's probably out of the option).
Long story short
❌ You appear to be doing this:
exec_always --no-startup-id kitti3
bindsym $mod+n nop kitti3 -- --session /home/akechi/.config/kitty/kittystartupwork
✔️ But you should be doing this:
exec_always --no-startup-id kitti3 -- --session /home/akechi/.config/kitty/kittystartupwork
bindsym $mod+n nop kitti3
Let me know how it goes.
Thanks it seems that this works :
exec_always --no-startup-id kitti3 -- --session /home/akechi/.config/kitty/kittystartupwork
bindsym $mod+n nop kitti3
Excellent! Feel free to get in touch if you encounter any other issues in the future, or if there are any features that you'd like to request.
Cheers,
Ariel