I was looking back at this issue and realized that it is possible for
one of the x,y coordinates to be negative and yet a screen change must
be performed. This may happen when a window is moving with its
upper-left corner outside the upper part of the screen, and it crosses
the x-axis boundary between two consecutive screens.
Whith Xinerama active a client that moves outside the upper-left screen
boundary is erroneously changing screens. The attached patch changes
this behavior so that a client may change screen only when its new
coordinates are positive. The assumption is that the client can't fall
off the lower-right boundary since the mouse pointer can't go there when
moving. However, the upper-left corner of a window (which is the point
we use to compute the client's scren) can move more to the left or up
than the upper-left corner of the screen (coords 0,0) thus becoming
negative.
I was having this annoying issue with multi-head setups on d9b49f5,
where new clients would always get mapped to the same screen (leftmost).
It seems that the x and y coordinate in the XWindowAttributes of new
clients are set to 0,0. The attached patch ignores these values and uses
the coordinates of the mouse pointer instead.
It so happens that when two clients are fired up one after the other on
the same tag, they both get a 'focused'-type border. A bisect sequence
showed that the culprit was commit 001f430. I think that it all boils
down to client_manage just setting tag->client_sel and hoping for
arrange(...) to do the Right Thing (TM). The attached patch uses
focus(...) instead.
Having this twice has the funny effect of the tag being activated and (near)
constantly being deactivated again.
Signed-off-by: Florian Forster <octo@verplant.org>
Julien Danjou
Nikos Ntarmos
Mychael Janes
daniel@brinkers.de
Florian Forster