From: Dima K. <no...@di...> - 2013-01-02 07:45:37
|
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. |