Open gabrielmontagne opened 3 years ago
Hmm, it doesn't look like a packaging problem, but I'm not sure what's going on /cc @dkogan
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:
xmodmap -pk
to check if the error makes senseAre either of those easy to implement?
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.
I'm looking at ioncore_parse_keybut()
: https://github.com/raboof/notion/blob/e98a4dff1abc7e41e334f22e293158f1acfa530f/ioncore/conf-bindings.c#L61
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?
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
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.
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!
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!
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 :love_you_gesture:
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(_)"),
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?
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?
I'd rather prefer a popup as it really grabs your attention that the binding will not work.
JFR, since my keyboard doesn't have a Windows key (I know, rare these days) I use Caps as META (remapped to Mod4).
On fresh install on Debian -- using the bundled version,
4.0.2+dfsg-5
, I get the following error on startup,I know it could be a packaging problem, but does this ring a bell? If it's not a bug, is there a work-around for it? On other machines with notion 3, I have zero problems.