Hi again.
I keep seeing incorrect behaviors in the focusing behavior of notion, and it
finally bothered me enough to look into it. I have
warp = false
mousefocus = sloppy
I used (not)ion for years with warp = true, and the focusing was much more
correct with that setting, for what it's worth. In the rest of this message I'm
assuming that the right focusing behavior with those settings is
The window beneath the mouse pointer should have focus, unless the pointer is
currently grabbed by a different window.
If this underlying premise isn't right, maybe the following doesn't apply.
I see several different focus failure modes, Two of them are described here, but
there are others that don't come up as often.
Failure mode 1
Suppose I have two workspaces. One has a single big window in it, and the other
is split into two vertical panes with a window in each:
Workspace A Workspace B
+---------------+ +-------+-------+
| | | | |
| | | | |
| 1 | | 2 | 3 |
| | | | |
| | | | |
+---------------+ +-------+-------+
Let's say the pointer is in window 2, and this window is focused. Now I switch
workspaces. The pointer is now in window 1; that window is now focused. Now I
move the pointer to the right half of the screen. I'm still in window 1, and the
focus is still there. Now I switch workspaces again. The pointer is now in
window 3, but the focus is still in window 2. This is wrong.
I tracked this down to a bit of code in ioncore_handle_enter_window() in
ioncore/eventh.c :
if(ioncore_g.focus_next!=NULL &&
ioncore_g.focus_next_source<IONCORE_FOCUSNEXT_ENTERWINDOW){
return;
}
Removing this block makes the above scenario work correctly. focus_next_source
was IONCORE_FOCUSNEXT_OTHER . I looked through the git logs for this logic, and
they're extremely unhelpful; all I learned after reading those is that Tuomo
thought that focusing logic was a pain in the butt. In any case, for the last
few days I've been running with a custom build of notion that removes that chunk
of code, and I haven't found anything that broke. Does anybody on this list know
what that logic was supposed to accomplish?
Failure mode 2
This is somewhat similar to mode 1, but instead of changing workspaces and
moving the mouse, it is triggered by entering full-screen mode in a window and
then moving the mouse. More specifically:
I'm in window 2. I press the key combination to full-screen this window (more on
this in a minute). I then move the mouse to the right half of the screen and
press the key combination again. Once more, the mouse ends up in window 3, but
the focus in window 2.
The key binding I was using to toggle full-screen mode is
kpress_wait(META.."Return", "WGroup.set_fullscreen(_, 'toggle')"),
This comes straight from etc/cfg_notioncore.lua in the notion repo. The _wait
part of this does a pointer grab, and this pointer grabbing and ungrabbing
confuses the logic in that same function ( ioncore_handle_enter_window() ) to
break the focus. Changing the kpress_wait() to kpress() makes this work.
Questions:
Why kpress_wait() in the sample config file? Would kpress() suffice? Why
kpress_wait() for anything? I couldn't find any description anywhere about what
kpress_wait() does and why one may want to use it. It may be good to fix the
logic bug to make this work even with kpress_wait(), but I'm not clear enough on
what all the logic does to know what to do yet.
|
