key input issue - clean_sym vs composed_sym ? #1980
Comments
|
Same issue with another keybind: The numbersign (
The relevant debug log for the key press: We have: Btw, I'm not sure what It looks like the solution would be to use the |
|
And don't map |
It's not a kitty mapping, but a keybind I use in zsh, so I have to use the keys that the terminal app will receive AFAIK I will try your PR |
Oh, then my PR will most likely not do anything. Are you using macOS? If so see https://sw.kovidgoyal.net/kitty/conf.html#opt-kitty.macos_option_as_alt. |
|
No, I'm using Archlinux ( |
|
Then I don't know why this isn't working, sorry. |
|
That's likely because the key press is alt+shift+/ not alt+/ There is no alt+shift+/ key combination in traditional terminal keyboard protocols, so you get nothing. I suggest mapping alt+: instead of alt+/ in your shell config. Ar if you dont want to do that, use send_text in kitty.conf to map alt+shift+slash to \x1b\x2f which IIRC is alt+/ |
|
I think there is a misunderstanding here @kovidgoyal
I'm aware of that, but I'm not trying to map The keybind in my zsh config is something like: bindkey '^[/' some_function1
bindkey '^[#' some_function2(with ==> Note that in |
|
Ok, actually I'm having this issue with Alt + most french-related keys: The french keyboard looks like this (image from wikipedia): As you can see, the key with Here is a comparaison between urxvt and kitty: On each terminal, I press the key K1 (the key with the 1 on it, see above) using some mods:
With a space between each step for clarity.
Do you see my point? |
|
Just add the send_text command I mentioned to kitty.conf and you will be |
That would be a workaround, but the core behavior is still wrong, don't you agree? Adding custom mappings with send_text in kitty.conf for all Alt+french_symbol_key seems wrong to me |
|
Well, you are welcome to come up with a patch to fix it. I dont know of Well technically one can, but it requires changes to the |
|
After reading #606 and xkbcommon/libxkbcommon#61 I think I start to understand the problem and the general logic behind the current kitty behavior regarding these "complex" keybinds 🤔 Now reading the code of the function
|
|
On Wed, Sep 18, 2019 at 07:59:31PM -0700, Benoit de Chezelles wrote:
Now reading the code of the function `glfw_xkb_handle_key_event` in `glfw/xkb_glfw.c`, I currently don't understand the relationship between the xkb keysym and the final glfw key:
- Do the key events comes from xkb and converted somehow to glfw? (then why can't we use the resolved keysym using xkb?)
kitty is cross platform, which means key events need to be abstracted
somehow. So xkb keys are mapped to glfw keys, just as cocoa keys are
mapped to glfw keys.
The problem is not in the mapping, it is that the key combination
alt+shift+: represents two things, alt+shift+: and alt+/ glfw currently
reports only one thing to kitty. So kitty has no way of knowing which
one to use. It uses the former not the latter, as that is what glfw
sends. If it used the latter there would be now way to bind to
alt+shift+key. To fix this properly one would need to report both things
to kitty and re-write the kitty key handling code to make use of that
extra information. And also make the same changes in the glfw cocoa
backend.
|
That is something I'd love to have too, and I'm willing to try to implement this if it's ok with you. I've been reading the input implementation in alacritty, they are not using glfw but a bunch of rust libraries that separates the GL drawing (glutin) from the window creation/input handling (winit), which directly exposes the physical scancode, mods, and the virtual key code after OS keyboard layout application. From what I understand, kitty embeds a version of glfw in the root of the repository (in
Does that mean that glfw actually does not send both? / there is not way to get both? Also, should I open a new issue for this? I guess so? (to put discussion and implementation questions there) |
|
On Sun, Sep 22, 2019 at 01:19:14AM -0700, Benoit de Chezelles wrote:
> To fix this properly one would need to report both things
to kitty and re-write the kitty key handling code to make use of that
extra information.
That is something I'd love to have too, and I'm willing to try to implement this if it's ok with you.
Sure, feel free.
---
I've been reading the input implementation in alacritty, they are not using glfw but a bunch of rust libraries that separates the GL drawing ([glutin](https://github.com/rust-windowing/glutin)) from the window creation/input handling ([winit](https://github.com/rust-windowing/winit)), which directly exposes the physical scancode, mods, and the virtual key code after OS keyboard layout application (so basically the data you described as the proper solution 🎉).
From what I understand, kitty embeds a version of glfw in the root of the repository (in `glfw/`) + a few glue/wrapper files used by kitty to interact with glfw (`xkb_glfw.{c,h}`, `dbus_glfw.{c,h}`, `ibus_glfw.{c,h}`), right?
> glfw currently reports only one thing to kitty. So kitty has no way of knowing which one to use. It uses the former not the latter, **as that is what glfw sends**.
Does that mean that glfw actually does not send both? / there is not way to get both?
OR that the wrapper you did around glfw's X input handling currently only reports this?
glfw does not send both. And kitty does not have a wrapper around glfw,
kitty has a fork of glfw, indeed the major reason for the forsk wsa
glfw's extremely inadequate key handling which I improved to dd support
or dead keys, live keyboard layout switching, etc.
If you want to get started the wy to do it is to change the
glfwKeyboardCallback function to accept a struct instead of individual
parameters. Then in the future, it will be easier to add inormation to
the struct.
The information we need is what is currently passed, and in addition the
effective key after consuming the shift modifier. Then the kitty key
handling code will need to be re-written to take this information into
account. Currently it hardcodes shifted key info for the US ascii layout
(look for shifted_keys in keys.py
And there is also the question of cocoa and what to do there, since I
dont recall if this information is even available there.
---
Also, should I open a new issue for this? I guess so? (to put discussion and implementation questions there)
I dont really care, continue here or we can move the discussion to a new
issue/PR.
…--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
|
If you get this working for Linux I'll try to make it work for macOS. |
|
Thanks @Luflosi ! @kovidgoyal What is the |
|
It is used by the IME subsystem, for example for writing east asian |
|
Indeed thanks - * @param[in] Used for Input Method events. Zero for normal key events.
+ * @param[in] state Used for Input Method events. Zero for normal key events.For the struct, it seems that the public GLFW API never passes a non-opaque struct to the caller / callback / user.. fyi, the struct I'm going to go with looks like this for now (pretty much WIP): struct _GLFWkeyevent
{
GLFWwindow *win;
int scancode;
int action;
int key;
int mods;
int virtual_key; // default: ?
int virtual_mods; // default: 0
// or: os_key / resolved_key / ?
// or: os_mods / resolved_mods / ?
char text[64]; // default: empty
int ime_state; // FIXME: store it here ?
}; |
|
On Sun, Sep 22, 2019 at 06:31:10AM -0700, Benoit de Chezelles wrote:
For the struct, it seems that the public GLFW API never passes a non-opaque struct to the caller / callback / user..
So I figured I would make a struct in the internals of glfw, pass it as an opaque struct to the callback and add a few methods (one for each field?) to extract the data from the struct from the callback, and re-create a struct (mirroring the one in glfw) in kitty's codebase to easily pass all the information around, does that sound right to you?
That sounds fine to me, although given the glfw is now just a part of
kitty, I dont particularly mind exposing a struct directly. However
wrapping it in a function interface is definitely preferable in general.
fyi, the struct I'm going to go with looks like this for now (pretty much WIP):
```c
struct _GLFWkeyevent
{
GLFWwindow *win;
int scancode;
int action;
int key;
int mods;
int virtual_key; // default: -1
int virtual_mods; // default: -1
// or: os_key / resolved_key / ?
// or: os_mods / resolved_mods / ?
char text[64]; // default: empty
int state; // FIXME: store it here ?
};
```
I think for a first PR just create a struct that passes exactly the same
info as the existing callback gets. We will add/modify the struct later
as needed.
|
Ok I'll do that. What is the reasoning behind |
|
On Sun, Sep 22, 2019 at 08:07:16AM -0700, Benoit de Chezelles wrote:
Ok I'll do that.
What is the reasoning behind `glfw3.h` vs `glfw-wrapper.h` ?
Do I duplicate the struct definition in the 2 ? Would it be possible (here or later) to include `glfw3.h` in the wrapper to avoid the duplications?
It's a legacy from when glfw and kitty were separate. And is used to
make glfw backend independent. You dont need to
duplicate it, it is auto-generated by running glfw/glfw.py
|
|
Nevermind, diffing the two gave me the reasoning. I still think it would benefit to include |
|
Oh ok, I don't touch it then (I'll add a line saying that this file is autogenerated though, to avoid thinking about this later) |
|
On Sun, Sep 22, 2019 at 08:24:12AM -0700, Benoit de Chezelles wrote:
Nevermind, diffing the two gave me the reasoning.
I still think it would benefit to include `glfw3.h` in the wrapper, and simply add all the wrappers after it.
Why? Since the rest of the wrappers have to be generated anyway, what do
we gain?
|
|
On Sun, Sep 22, 2019 at 08:26:27AM -0700, Benoit de Chezelles wrote:
Oh ok, I don't touch it then (I'll add a line saying that this file is autogenerated though, to avoid thinking about this later)
Sure I should have done that.
|
Sorry it wasn't clear.. Kitty's codebase always includes I can change the python generator to keep the full definition of the struct (based on a special comment or something) or include one into the other (and can strip the opaque type definitions from the generator), or I'm I missing something? |
|
Actually, putting the new type among the rest of the opaque types generated it for the wrapper as well, so I guess it's fine. |
|
So I got something working (extract the struct, change everywhere), still a few things to change I think, I'll open a PR soon! Forget the following, let's continue the discussion on #2000 ! I noticed a change between 0.14.4 & current master for the second example I gave, using I think it's because there is nothing in Line 606 in fb1c318 prevents getting the text when ctrl / super / alt is pressed (but then I don't know why it works when I do a simple keybind like Alt+x).
I tried to remove the condition, but now I get Hopefully all these issues will go away with my later work to add physical keys + 'resolved' keys detection.... |
|
On Tue, Sep 24, 2019 at 08:54:54AM -0700, Benoit de Chezelles wrote:
So I got something working (extract the struct, change everywhere), still a few things to change I think, I'll open a PR soon!
Also, what is difference between the xkb states `state`, `clean_state` ?
One is the current state after processing all key events to date, the
other is the state when no key events have been processed. This allows
us to get the actual keyname based on the current layout without
modifiers changing it.
|
Hello,
I'm having an issue with the keybind
Alt+/not doing anything in terminal apps (cat, zsh, nvim, ..)I'm using the french keyboard layout, which has the slash and colon symbols on the same key (to get the slash I do
Shift+colon).The actual keys I have to press are
Alt Shift colon(useful for the debug output below).Here is the relevant debug output:
The most interesting lines seems to be:
We can see
clean_sym: colon composed_sym: slash, but I'm not sure what is actually sent for theon_key_inputsince thetext: ''is empty..Tested on version
0.14.4and git version.On Archlinux, with X11.
The text was updated successfully, but these errors were encountered: