Re: Improved extensibility for window order

[Martin Stjernholm <mast lysator liu se>]

John Harper <jsh unfactored org> wrote:

> Sorry it took me so long to reply..

No problem, I certainly can relate to that. :\

> I don't want to add this ability to sawfish - window-order does one
> thing - maintain the mru ordering of windows, I don't think it's
> something that needs to be pluggable. As you saw, there's code that
> depends on the mru behaviour

I figured that there might be more code than x-cycle that uses the
window order to do fancy things in the future (or perhaps already?).
It's therefore better that the hookable interface is separated from
x-cycle, which can be regarded as an application on top of that
interface. That's why my patch added the interface to window-order.jl,
but it could just as well be a third separate module (although in that
case, the most appropriate name for it would arguably be
"window-order" while the current one becomes "window-mru-order").

> It may be useful to make the x-cycle module use an overridable
> window-order function

Ok, that would do in my case since I'm satisfied with x-cycle.

> (there's only two calls to window-order functions, so it's not hard
> to add two special variables that default to those functions),

Yes, but a little bit of refactoring in x-cycle is still necessary so
that the order is retrieved after the currently focused window has
been added to the list.

Also, it's not really within the scope of a window order package to
affect the set of windows to order, so getting a list of windows to
order instead of some flags that characterizes that set seems more
appropriate.

> but it's not something that should show up in the user interface

Why not? Maybe I should explain a bit more why there is at least one
plausible alternative to MRU order: The ordering I've implemented is
based on the window positions; windows are ordered in columns and each
cycle step goes to the next window in the same column, then on to the
next column of windows, etc.

The main advantage with that compared to MRU order is that it doesn't
change all the time as different windows are focused. That makes it
possible to adapt a habit for the number of cycle steps to get from a
certain window to a certain other window. It gets especially
convenient when the layout of windows is largely non-overlapping and
fairly static. Popups that are placed on the parent window are not a
problem though, as they always get the same position in the total
order.

I'd be happy to contribute this placement based order to Sawfish, of
course.

> Also, x-cycle shouldn't contain any code to query the pointer,

True, that doesn't make a lot of sense except in the specific window
ordering I've made. The reason that code ended up in x-cycle was that
it wasn't possible to get that behaviour any other way with the
current interface. It's of course much better if x-cycle instead calls
a window order function to retrieve the next or previous window
relative to one given as argument, and that argument may be nil if
there is no specific window to be relative to. I can put together a
new patch with that approach if you like.