The deprecation wrapper that we still have for this function didn't return
anything. However, awful.util.pread() used to return strings. This breaks
script.
Work around this by returning an empty string. That way code will still break,
but at least it should not error out.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The default config creates the same set of tags for all screens ("1" to "9"). An
awful.rules-rule with e.g. screen = 2, tag = "3" should obviously tag matching
clients with tag "3" of the second screen.
However, the implementation used the first matching tag in the list of all tags
and thus the client ended up tagged with tag "3" from screen 1. Fix this by
calling find_by_name() with the screen that the client is assigned to.
The existing implementation of awful.rules guarantees that any
"screen"-properties are applied before the code touched by this commit is run,
thus this should always work.
This commit does not add a test catching this because we are currently quite bad
at testing multi-screen scenarios and I don't want to invent the necessary
machinery right now.
Fixes: https://github.com/awesomeWM/awesome/issues/988
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 0318c6132840413b1f added an image for the minimize button which was
missing before. However, only the default theme and xresources where fixed to
contain the path to the image.
This commit adds the path to all themes.
Also, minimized clients aren't visible, just as closed (=killed) clients aren't
visible. Thus, we don't need an "active" version of this image.
This commit makes us handle the image for the minimize button just like we
handle the close button: There is no difference between "active" and "inactive"
and the file path in the theme doesn't get any path suffix.
Fixes: https://github.com/awesomeWM/awesome/issues/387
Signed-off-by: Uli Schlachter <psychon@znc.in>
The actual bg is drawn either with fake transparency over the wallpaper (this
uses operator OVER) or for true transparency with operator SOURCE. The bgimage
should be drawn ontop of this without erasing the background and thus needs
operator OVER.
However, before this commit the bgimage was drawn in the same way as the bg and
thus inherited its SOURCE operator if a compositor is running. Fix this by
restoring the default operator (OVER) and also e.g. the default source before
drawing the bgimage.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
When called with the file name of an image, this function failed to turn that
file name into a cairo surface.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
All other shape did it. While it usually have no side effects,
as seen in #920 screenshot from @actionless, there is instances
where this produce a invalid rectangle.
If:
1) An app is open in a tag
2) A new tag is created
3) The app is closed in the first tag
4) The first tag is deleted
5) The new tag is deleted
Then this history would try to restore an inactive tag without
a screen. Bad things will then happen.
Reported on IRC. I am not sure why swap() is not enough, but the
old code removed before the mouse refactor did this, so apparently
it is necessary.
The fix has been reported to work by spyroboy on IRC, thanks!
First some reminder on how client geometries works (in X11, awesome just copied
that!):
- The position (x,y) defines where the border of the client begins
- This means that the content starts at (x+border_width,y+border_width)
- However, the size is the size of the client without border
- Thus, the client covers the rectangle from (x,y) to (x+2*bw,y+2*bw)
The client snapping code got this wrong. It only deals with rectangles and thus
for things to work as expected, the width/height have to be increased by two
times the border width. When snapping a client against other visible clients,
the geometry of the client to snap against wasn't calculated correctly.
This was apparently noticed at one point and worked around by decreasing the
position by two times the border width. While this is terribly wrong, it
actually makes things work correctly when snapping to the right or bottom edge
of a client, but breaks for the other edges.
Fix this by just calculating things correctly.
This is based on a patch from jk411.
Fixes: https://github.com/awesomeWM/awesome/issues/928
Signed-off-by: Uli Schlachter <psychon@znc.in>
The requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There was already a bug, as self.active_child.visible
was used instead of self.active_child.wibox.visible
This caused some confusion that this attribute was a widget.
It wasn't.
It was set as `module` instead of `class` because ldoc was confused
set shown the methods as functions and functions as methods.
This commit set the explicit section so ldoc don't gress (wrongly)
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>
Emmanuel Lepage Vallee
cmertz
Julian Wollrath
Uli Schlachter
Uli Schlachter
modk
Daniel Hahler
Salorium
Max
actionless
Jajauma
Daniel Hahler