Fresh install startup errors "Could not convert keysym to keycode" about notion HOT 14 OPEN

Cool. So this is 100% clear then. notion4 has some binding with Caps_Lock in it that notion3 doesn't have. With your configuration, notion4 can't find the Caps_Lock key on your keyboard, so it barfs.

gabrielmontagne: configuring your notion to not have bindings that use this key whould fix it. Search for Caps_Lock in /etc/X11/notion/cfg_bindings.lua, and you should see the bindings that need changing. Or simply delete the two relevant bindings from that file.

raboof: remapping Caps_Lock is common-enough that we maybe shouldn't have any default bindings that use this key. Strong feelings about removing or changing those by default?

Also, unsettable bindings maybe should produce a warning instead of causing notion to not run at all. It'd be awesome if there was an error message that stated what binding failed, and what config file it came from.

Thanks!

from notion.

Hmm, it doesn't look like a packaging problem, but I'm not sure what's going on /cc @dkogan

from notion.

The keysym/keycode table can be printed with xmodmap -pk. gabrielmontagne: I would guess you have something unexpected in your keyboard map. You're probably setting something it doesn't like in your X configuration somewhere? This isn't your fault, and notion should do better, but it's not entirely clear what's happening, yet.

raboof: two things could be improved with our diagnostics here:

1. We should print what keysym specifically we're looking for. This is an integer. If we had that, the user could xmodmap -pk to check if the error makes sense
2. Can we print out the C backtrace too? Or maybe dump a core also? We could get better diagnostics from those.

Are either of those easy to implement?

from notion.

We should print what keysym specifically we're looking for. This is an integer. If we had that, the user could xmodmap -pk to check if the error makes sense

Agreed. That looks pretty simple (https://github.com/raboof/notion/blob/master/ioncore/conf-bindings.c#L100), do either of you want to give it a go?

Can we print out the C backtrace too? Or maybe dump a core also? We could get better diagnostics from those.

I agree that would be great, tracked in #104, not sure how hard it would be.

from notion.

I'm looking at ioncore_parse_keybut():

It looks at the binding (Mod4+Shift+Caps_Lock in this case), splits it on +, converts the string to a keysym with XStringToKeysym(), and then converts that keysym to a keycode by calling XKeysymToKeycode(). This last part fails for one of the 3 components of the binding (it'd be nice if the error message said which one). A random guess: the user has redefined Caps_Lock to function as a control, or something, and did this in a way that breaks the keysym/keycode conversion.

I haven't looked to see what notion3 does differently here.

gabrielmontagne: can you tells us about your custom keyboard config?

from notion.

I haven't looked to see what notion3 does differently here.

Ah, I don't think they default keybindings in notion3 bound anything to capslock at all, while in notion4 they do

from notion.

Might be worth mentioning -- I don't know why I didn't specify it before -- both Debian and Notion are both freshly installed. I haven't changed any configuration of anything yet. So if you install the distro, install Notion and try to start it, you get the error.

from notion.

gabrielmontagne: can you tells us about your custom keyboard config?

Ah, no, but yes, you are totally right @dkogan, I do have exactly that, Caps_Lock working as a Ctrl
On, /etc/default/keyboard I have XKBOPTIONS="ctrl:nocaps,terminate:ctrl_alt_bksp"

Sorry, I should've mentioned that!

from notion.

It worked perfectly! Thanks so much! I've been using this WM since before the not- times. I love it so much. Thanks for keeping it fresh and youthful 🤟

from notion.

I changed those caps lock bindings before using them and accidentally avoided this issue. They might suit you

kpress(ALTMETA.."S", "WFrame.switch_next(_)"),
...
kpress(ALTMETA.."A", "WFrame.switch_prev(_)"),

from notion.

raboof: remapping Caps_Lock is common-enough that we maybe shouldn't have any default bindings that use this key. Strong feelings about removing or changing those by default?

I think having that one is really central to the consistency of the default keybindings, so I'd much prefer to keep it.

I agree remapping capslock is common enough that we should handle it gracefully, though, so...

unsettable bindings maybe should produce a warning instead of causing notion to not run at all. It'd be awesome if there was an error message that stated what binding failed, and what config file it came from.

Yeah, maybe it should just be a warning in the logs, not even a popup?

from notion.

Yeah, maybe it should just be a warning in the logs, not even a popup?

Maybe...

For a default, a warning in the logs would be ok. But for something in a user config, there should be a popup: the user explicitly asked notion to do something that it ended up not doing. So it should loudly communicate to the user that their intent was ignored.

I'm assuming it's not really easy to tell whether something came from a default config or not, right? So we should just pick one of the behaviors (log message or popup). Maybe a popup would be the better of the two? If it told the user what to do to silence the warning?

from notion.

I'd rather prefer a popup as it really grabs your attention that the binding will not work.

from notion.

JFR, since my keyboard doesn't have a Windows key (I know, rare these days) I use Caps as META (remapped to Mod4).

from notion.