local functions and metatable based constructors are not
documented unless an explicit @function is added.
Also add missing return values and fix formatting.
The behavior was changed during the rewrite. This was a mistake
as it was assumed (wrongly) that nobody used this function with
wiboxes other than "wibars" (awful.wibox).
Fixes#917
Since the screen removal patchset, the tags properties were
cleaned too early. This caused code connecting to "property::activated"
to be called with the tag already partially deleted. For code depending
on those properties, such as radical.impl.taglist, this caused errors.
Apparently, there is such thing as not leaking enough...
Also try to clear the widgets from mywibox. This seem to help.
Time will tell.
Fixes#914, unfixes #808
Similar systems already exist un luaobject, wibox and the declarative
widget system. This close the gap and also bring the property based
syntax to wibox and other gears.object users.
While this need to be enabled explicitly for legacy reasons, it
doesn't break the API.
Once widespread, this implementation will replace the one found
in wibox.widget.base_widget.
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.
This commit changes the markup applied to the action description text to
emphasize the fact that the action zone is actually clickable. Bold is
replaced with underline, the Unicode 261B symbol (right pointer) is
added as well.
According to the Desktop Notification specification document [1] the
clients supply actions available along with a notification in a form of
a list of pairs where first element is an identifier of an action and
the second is a localized message that will be displayed to the user.
Up to now the naughty code directly used the action identifier text as a
part of the notification layout exposed to the user. This commit makes
use of a localized action description for that purpose.
1) https://developer.gnome.org/notification-spec/
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>
As wibox contain a drawin, but isn't one, it is necessary to map
drawin to wibox.
This could eventually be fixed by turning wibox into drawin just
like the client, tag and screen do.