The big change here is that we now keep our configuration structure in a global
variable called globalconf. This radically simplifies many interfaces, since
passing awesomeconf everywhere is no longer necessary. There are also more
subtle interface effects - now we can reliably identify a screen from just a
screen ID, rather than an awesomeconf, screenid tuple.
Overall, this patch makes most of the interfaces in awesome much nicer to use -
enjoy!
Yes, this is a huge patch, but since a lot of the refactoring was done
systematically using vim macros, splitting this up would have been very hard.
Hi there.
awesome-client is now linked against the whole hog of x-related libs
that awesome depends on. These get pulled in by awesome-client using the
same LDFLAGS as awesome. Removing x-related libs from the LDFLAGS for
awesome-client is only half of the story, as it also depends on util.c
which now has a couple of x-related functions. The attached patch also
splits these functions into a separate xutil.{c,h} file pair and teaches
the rest of the files to use them. Apart from the small difference in
file size (I see a 3-3.5% decrease in file size, both for a stripped and
a non-stripped awesome-client binary), this should also somewhat reduce
the startup time (since awesome-client won't have to map all of these
libraries).
Cheers...
\n\n
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.
Aldo Cortesi
Julien Danjou
Nathan Hüsken
Nikos Ntarmos