This implementes the FIXME added a few commits ago. A new
request::geometry handler turns client requests into normal
lua `c.maximized = true` property changes.
This function tried to move the client to its new screen based on
shifting around its current geometry. However, it assumed that the
client was actually visible on its current screen, which is not always
the case.
Fix this by just forcing the client into its new screen if our moving
approach does not work.
This also reverts commit d5e365804c which
is no longer necessary. This commit only hid the issue (partly).
Fixes: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code here made sure that clients were not moved outside of the root
window. However, that's not enough, because clients can still end up
inside the root window, but outside of anything that is visible in some
output. Thus, just remove this.
Related-to: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
A relatively common problem with awesome is with mixing sticky clients
and the focus history. Once a sticky client ever had the focus, it will
always get the focus after a tag switch. This is because the focus
history is global and the sticky client is always the most recently
focused and currently visible client in the list.
Work around this by discriminating sticky clients: First try to find a
client to focus, but ignore sticky clients. When this does not find
anything, try again, but this time also consider sticky clients.
(Basically the same issue exists with clients that are on multiple tags,
but I guess that one can be ignored.)
Fixes: https://github.com/awesomeWM/awesome/issues/733
Signed-off-by: Uli Schlachter <psychon@znc.in>
Once upon a time, 4b9584fdb1 already fixed this problem: We have to
set the border width to zero before applying the new geometry to the
client, because changing the border width makes the client move
according to its gravity.
Then came e54387904b and made this code use awful.placement instead
of just fullscreening the client itself (without explaining why in the
commit message!). After this commit, the border width was just ignored
and left as-is. This was then fixed in 0bf8bb6a64 (no idea which
callback the commit message refers to, the old code was basically just
c.border_width=0, c:geometry(screen_geo)). However, now the border width
was again changed after the geometry and the bug that was fixed by
4b9584fdb1 was back.
This commit fixes this regression again by making sure that the border
width is set to zero before the geometry is set. This becomes slightly
more complicated, because now it is also awful.placement's job to
restore the old border width.
This is why this commit adds a new option to awful.placement so that it
sets the border width to zero after creating its memento of the old
border width.
Fixes: https://github.com/awesomeWM/awesome/issues/1607
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a C program which tests if the window manager handles
gravities correctly. This program is loosely based on metacity's
test-gravity.c, but completely rewritten and this version does automatic
tests instead of allowing the user to perform testing by hand.
By having this as a self-contained C program, it is possible to compare
awesome's behaviour with the behaviour of other WMs.
In my testing, only metacity and awesome pass this test. This is not
that much of a big surprise since awesome was fixed in
https://github.com/awesomeWM/awesome/pull/505 to work correctly with
metacity's test-gravity.c. However, I am surprised that e.g. Fluxbox
gets this wrong.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Change indexing so that a keyboard map with a single group still gets
displayed in awful's keyboardlayout widget.
Signed-off-by: Quentin Minster <quentin@minster.io>
Aborting the process is sometimes a bit harsh for a failed assertion.
This adds a non-fatal assert() macro called "check()" and uses it in
some places where we might be able to survive the error.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are some cases where a client's floating state "silently" changes.
For example, a fullscreen client will be considered floating. However,
even though c.floating changes its value in this case, we did not emit
the property::floating signal.
Fix this by explicitly tracking the "implicitly floating" state. When
some property that influences this "implicitly floating" state changes,
we update it and if a client which was not explicitly assigned a
floating state observes a change in this value, property::floating is
emitted.
This was tested by running a terminal and two xeyes in a tag with a
tiling layout where awful.ewmh was patched so that clients do not change
their geometry when fullscreening or maximizing. It was observable that
after this patch e.g. the titlebar and the tasklist update to show the
floating state of the client which became implicitly floating due to
being maximized.
Fixes: https://github.com/awesomeWM/awesome/issues/1662
Signed-off-by: Uli Schlachter <psychon@znc.in>
For a while now we had our code coverage tools tell us that the coverage
for one line of code fluctuated. Sometimes it was being executed and
other times it was not. This is useless noise.
I think what is happening here is that the coverage depends on the order
of iteration over a table. Either the tooltip that is being created was
first made visible and then it text changed, or things happened in the
opposite order.
Fix this by doing this by explicitly changing the tooltip's text while
it is surely visible.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We were only using this for tag names. This means we are assuming that
everything is UTF8, but tag names are provided in the local locale and
need to be translated into UTF8? That makes no sense, so just drop this.
Fixes: https://github.com/awesomeWM/awesome/issues/1753
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit made this code handle invalid directories correctly.
However, it was still possible that we come across invalid file names
for which :get_path() returns nil and then we assumed this was a file
name.
Fix this by silently ignoring such files.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, the code always used GFile instances, then used
get_path() for a recursive call and turned the path into a GFile
instance again. This is not only inefficient, but also causes issues
with directories with invalid utf8, because the get_path function
returns nil in this case.
Fix this by keeping things as a GFile all the time.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Regression in v4.1. It causes the `rc.lua` (and the fallback) to
exit when the wallpaper is missing or something went wrong.
In <= 4.0, the wallpaper wasn't loaded, but Awesome didn't "crash".
There should be no asserts in the code called during the first
event loop iteration.
Every call to client_ignore_enterleave_events() must be paired with a
following call to client_restore_enterleave_events(). In between these
two calls, no other calls to client_ignore_enterleave_events() is
allowed.
The code in banning_refresh() sometimes broke these rules. This can
happen because the code causes signals to be emitted and Lua code can do
basically anything.
Fix this by moving the calls into the called functions.
Fixes: https://github.com/awesomeWM/awesome/issues/1746
Signed-off-by: Uli Schlachter <psychon@znc.in>
Adds a third parameter "timezone" to the textclock widget that is
optional. Defaults to local timezone if nil.
Signed-off-by: Matt Harrison <matt@harrison.us.com>
Possible use-case could be a do-not-disturb mode where notifications
should be suspended, but some notifications triggered directly by
a user interaction (e.g. change of keyboard layout, etc.) should
still be shown.
Fixes: https://github.com/awesomeWM/awesome/issues/1728
I failed to see the obvious. Thanks to mlen from IRC to make
me look into i3's source code so that I can figure out the obvious.
First, what is the problem? We want to be informed about mouse clicks on
client windows, e.g. for client-to-focus. For this we have to grab mouse
buttons on the client window, since only a single client at a time can
ask for information about all mouse clicks (I think...) and that right
is reserved for the actual application and not the WM.
We also want to be informed about mouse clicks on the titlebar, so that
clicking there actually does something (and also e.g. click-to-focus).
Obviously, we can just grab mouse buttons on the titlebar as well.
However, this causes lots of problems. The X11 window containing the
titlebar is not just the size of the titlebar, but also includes all of
the actual client window. This means that clicking into the client also
activates our button grab on the titlebar. This, in turn, causes the
input focus to briefly shift to the window for the titlebar. This shift
of focus can be detected by clients and caused various issues.
This fix is so obvious that I missed it. We don't have to grab buttons
on the titlebar window. We can just use the "normal" event propagation
without grabs there, i.e. we just include the event masks for button
press and button release and get informed about all mouse events. In
fact, we already have this event mask in place, so the whole use of
grabs is redundant.
That's what this commit does. It also partially reverts commit
394ff06589 which is where this unnecessary grabbing was introduced.
Fixes: https://github.com/awesomeWM/awesome/issues/1479
Fixes: https://github.com/awesomeWM/awesome/issues/1658
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
BuildTools
Benoit de Chezelles
Uli Schlachter
Daniel Hahler
Uli Schlachter
Quentin Minster
Thomas G
Matt
Tim Roes
getzze