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.
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.
a. Adds a get_current_tag_number function to allow for above updates
and teaches get_current_layout(...) and arrange(...) to use it.
b. Adds an extra client_sel entry in struct Tag, updated on
focus(...), manage(...), and unmanage(...), and used in arrange(...).
this fix a bug when fast-switching between tags and dropping
some windows management as we should not.
Use window_getstate() (moved from awesome.c's getstate()) instead.
Julien Danjou
Nikos Ntarmos
MATSUU Takuto