Open ikn opened 8 years ago
You have a point.
Actually, history-based switching is one of my favorite features: It makes sense that going right and then left returns you to the same place you started with. It also makes sense that the windows you use the most are the easiest to focus.
On the other hand, if you don't remember which one was the last window you used it can be impossible in some situations to figure out what window you are selecting and therefore you have to look at the screen for whichever window was matched and correct it if necessary.
The proposed algorithm allows the user to know what they are selecting beforehand independently from the focus history... at the price of them needing to position the most often used windows near the top left corner if they want to be able to select them in the least number of steps.
Depending on your workflow you may prefer one approach or the other and I have no problem providing a console switch to pick one or the other, e.g. -a
(--algorithm
).
If you want to implement the algorithm, fork the project and replace the content of find_next_window()
in find_next_window.cpp
with your procedure. Build and test it, and when you feel it's ready, send me a pull request. I'll take care of adding the console switch to keep both. Also, please pick a name for your algorithm. It will be used as an argument to the --algorithm
switch and other places in the merged codebase.
Yeah, I prefer knowing the required keystrokes beforehand because the part that's slow isn't pressing multiple shortcuts, it's looking at what happened and reacting to it. I do also have a history-based shortcut set up, but only to switch between the two most recent windows.
I have also been testing out a system like Vimperator's hints to display character sequences over each window, which, when typed, will perform an action on that window. It's pretty rough right now, but it works. Of course, this is mostly useful when you have lots of windows, usually across multiple monitors.
Anyway, I'll have a go at implementing that, but no idea when I'll get to it.
I have issues with the existing directional focus algorithms available to me:
focus_by_distance = true
: this finds the nearest windows in the target direction (ie. considering only the parallel distance), then takes the centre point of the nearest edge of each window and chooses the one which is nearest the centre point of the edge of the focused window in the target direction. I find that with this, there are many common situations where it's hard to judge which window will be chosen.focus_by_distance = false
: this finds the node on the other side of the edge of the focused window in the target direction, then uses the internal binary tree representation of the windows in that node to choose a target window (ie. moving left/up will take the 'last' window and moving right/down will take the 'first'). This makes it possible to know which window will receive focus, but only if you remember the internal binary tree, which cannot be determined from just the current window placements.My suggestion is to take the top or left edge of the focused window, and follow it along to find the target window. The behaviour is easier to judge than bspwm with
focus_by_distance = true
because you have the window border as a visual guide. I've done a quick implementation of this in bspwm; I've been using it for a while and it works well for me. I believe this is better-suited to this project than bspwm, given its narrower focus on just implementing directional window focus.I would also be willing to implement this (albeit with rather C-like C++), I'd just need to find the time.