Spatial Window Switching

[Mikkel Kamstrup Erlandsen]

The purpose of this bug is to act as a discussion forum on how to get spatial navigation going in WinWrangler

[Mikkel Kamstrup Erlandsen (kamstrup)]

Alessio - I just tried your branch lp:~themolok/winwrangler/winwrangler-spatial-switch, but I can't get the switching to work. Not under Compiz or Metacity at least. The hotkeys are triggered fine, but the focus is just never switched.

Another thing I noted is that it is not always the window I expect to get focus that is targeted by the layout. I saw this while adding some debug statements to your code.

One other thing - if we are going to have handlers like this that change the active window, doing shades, or other we need to pass around the timestamp received from the hotkey callback. This is to be able to bypass the focus-stealing-prevention of the window manager. This means changing the signature of WWLayoutHandler to include a 'guint32 timestamp' variable. Which in turn means that all layouts must be updated to this new API, not a big task, but a task nonethless.

[Alessio Bolognino (themolok)]

You're right, there is definitely something wrong: it works under Compiz for me but not under Metacity; my bet is that it has something to do with the timestamp. Even under Compiz it doesn't switch between windows of different apps.
I don't think I'll be able to fix this very soon (I've got a couple of exams next week), but it seems trivial.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I'll continue to work a bit on this. I've branched your branch at lp:~kamstrup/winwrangler/winwrangler-spatial-switch

I have it working under Compiz now, but there is still something about the navigation that's not quite intuitive...

[Mikkel Kamstrup Erlandsen (kamstrup)]

I have this working in the above mentioned branch now. Tested with Compiz and Metacity under Karmic. Will merge to trunk during the weekend.

[Alessio Bolognino (themolok)]

I've looked at your branch, it works fine. One thing I'm not sure I like is that you use width and height in ww_find_neighbour to find the neighbour window; this works fine only if you are in a tiled environment; but if you have a smaller window under the currently focused there is no way to switch to it.

I understand it's not really a bug but more like a design choice though.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I see your point. I am quite sure it'll take some work to get the user interactions feel just right.

You have the same problem you describe in your own branch in the LEFT if-branch. There you use wx to detect the edges - hence you wont detect any completely covered windows. You need to use the right border when you go left, ie. wx+ww. This is coded as you describe in the RIGHT branch though.

I am really not sure if it is a feature or a bug in my branch. I did actually consider your scenario when I coded it, but thought that using the metaphor "when you hit LEFT the visible left border moves LEFT" (and same for RIGHT, UP, and DOWN) was what would be most obvious for the user... It is very possible this is not right.

This makes it impossible to select completely covered windows, yes, but since it is more or less the point with tiling windows that this shouldn't happen, I am not sure that it is a scenario we should optimize for? After all Alt-TAB still works.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I just merged lp:~kamstrup/winwrangler/winwrangler-spatial-switch to trunk. Any further changes and development happens there from now to make things easier.

[Mikkel Kamstrup Erlandsen (kamstrup)]

The more I toy around with the spatial switching the more I feel like the current neighbor selection algorithm is bad.

I have one particularly problematic case - namely that the spatial navigation can be "wrong" in a tiled grid if there is a small skew in the tiles. This can happen fx. because Metacity imposes the size hint steps of Gnome terminals (forcing the terminal size to fit an integer number of characters, see bug #305627).

In such a case the eye doesn't immediately perceive the slightly skewed grid and the spatial navigation appears wrong.

I think the best fix for this is to make ww_find_neighbour() use an algorithm based on the windows' centers of gravity instead of their borders. Selecting the window with the nearest center in the desired spatial direction. This will ensure that we always select the right window in a slightly skew grid.

[Alessio Bolognino (themolok)]

I don't think I can reproduce your bug. I mean, sure, there is a bit of space between Gnome Terminal windows, but I don't understand how that affects spatial switching. It seems to work fine here. Can you post a screenshot or something?

I've already thought about using the center of the window (assuming that what you mean with "center of gravity") to choose the neighbour, it probably would make more sense than the actual algorithm.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Ok... I have it working very well in trunk now I believe... Here follows some gory details for the interested...

Look at the attached screenshot. The calculator in the bottom right has the focus and I want to go LEFT and focus the Gnome terminal. When I hit left I will select the Nautilus window in the top left instead. This is because it is edge-wise closer to the calculator.

I first implemented a solution using distances between gravitational centers of the windows. This worked in 99% of all cases, but in some cases it would still not do what I expected. Fx. in a big non-perfect grid with some overlapping I would some times selct the window below when hitting LEFT - and stuff like that.

What I did was resort to using non-euclidian geometry to calculate the distance measures. So, when we move LEFT or RIGHT we use a distance measure that heavily punishes any differences in the Y-axis (and the converse for UP/DOWN). This prevents us from suddenly going to a window that lies loweror higher on the Y-axis even though it may technically be closer.

Enough of technical details - the bottom line is that this feels very natural for me when using it.

[Alessio Bolognino (themolok)]

OK, I understand the problem now and I like how you fixed it.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Released in 0.2.4