Re: head and window



Teika Kazura <teika lavabit com> writes:

> It's that (current-head w) returns wrong value when w is outside of
> the current viewport. He guessed (find-head) in C behaved wrongly,
> but not. (find-head x y) is correct, by returning nil when the point
> lies outside of the screen (when Xinerama is present, it's all screens
> combined.)
>
> The culprit is current-head in wm/misc.jl. You can see that the 'and'
> clause fails after nil return value from (find-head).

Hmm.. Now that you bring it up again and I look again I think that the
current behavior is right.  current-head is used in, e.g., placement, to
decide which head to place a window in.  For that purpose it makes sense
to use the window with focus rather than the pointer if the two give
different results.  And for this purpose if there is no such window or
it's not in the current viewport it obviously shouldn't be used.  Though
what use it would be to supply the window to use for this isn't clear to
me -- shouldn't it always be the focused window (i.e., the default)?

So the "problem" is that people who don't look close enough (myself, for
example) might try to use current-head as a way to get the head of a
particular window, but it's not really suited for that purpose.  There
should probably be a window-head (and -dimensions, and -offset) which
returns nil when the location is outside of the viewport.
current-head(-*) could be redone to use those.  And both sets of
functions should be documented.

I can go ahead and do this (unless you want to, Teika), but I'll wait to
see if you or anyone else has anything to say before doing so.  One
question is whether we should remove the ability to specify a window in
calls to current-head, as a way of catching anything that might be using
it inappropriately.  Or maybe leave it, but generate a warning message.

> * 'current-head', and its derivativs
>   'current-head-{dimensions,offset}' seem to be usually expected to
>   return the head, rather than nil. Currently it returns the head
>   containing the center of the window, so a window which is only
>   partially visible, or which spans across multiple heads are treated
>   wrongly. And the precise definition of the function is not
>   documented. Anyway, what's needed should be met.

Is that the wrong behavior?  Windows that don't fit within a head (or a
viewport) are, quite frankly, a pain to deal with because it's not
always easy to know what head (or viewport) it should be considered to
be in.  And it's also not a common situation (unless you use
infinite-desktop?) so we shouldn't waste too much time trying to get it
exactly right.  So I think that using the center of the window is a good
simple approach.

> * Since current-head is incomplete, the functions which call it may be
>   so, too. (grow-pack may fail with 3 or even with 2 heads. :/)

I think the problem might be if these other functions are using
current-head when they should be using a window-head function instead.
I don't know grow-pack, so I don't know if that's the case there.

-- 
Jeremy Hankins <nowan nowan org>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]