Why:
* Two different (but related) concepts had the same name
* Users were confused for years on IRC
* The wibar name was already in use in some doc to avoid confusion
This was only partially implemented. The margins were substracted from
the area too early in the pipeline. Now, they are added when getting
the size and substracted when setting it. This way, the margins will
"survive" when a placement function set an absolute value in one of
the field. Previously, this caused one (or more) of the margins to
be lost.
Before this commit, it was necessary to call 'rawset' to be
able to add new fields to the wibox. This is no longer required.
This solution was choosen because wibox is itself a base class of
menus and wibars. Those classes can now add new properties without
hacks.
The problem was that get_square_distance() made the screen one pixel larger to
the bottom/right than it really was. Thus, the (x+0,y+0)-pixel of a screen that
was below or to the right of some other screen had distance zero to both of
these screens.
This commit fixes the screen size computation and adds a small unit test for
getbycoord() and get_square_distance().
Reported by Elv13 here:
https://github.com/awesomeWM/awesome/pull/878#issuecomment-219272864
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in gears.wallpaper currently sets a wallpaper in a deferred fashion.
Only a while after it is told to do something does it actually do the wallpaper
change. This is to incorporate many wallpaper changes right after another. These
changes happens during startup where the wallpaper for each screen is set one
after another.
However, since we no longer restart on RandR changes, the screen configuration
could change while we have a pending wallpaper. In this case, part of the
wallpaper could be "chopped off", because the surface that we draw the wallpaper
to is too small.
This commit makes gears.wallpaper track the size of the pending wallpaper and
create a new surface if the already-pending one is too small.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Any clients with these tags end up somewhere random (the first tag on the first
remaining screen). This certainly can be improved in the future, but at least
this is a start.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When this force-argument is not given, the code will refuse to delete a tag
which has a non-sticky client. With this force argument, the client will just be
moved to the fallback tag.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This code uses delayed calls to lazily update things. Thanks to this, it can try
to update a screen long after it was removed. Fix this by just doing nothing on
invalid screens.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Uli Schlachter
Daniel Hahler