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>
XCB_CURRENT_TIME really should be avoided as much as possible (see
ICCCM).
However, the screen, mousegrabber and keygrabber code have cases where
they really want up-to-date information / want to activate a grab *now*.
These cases are fine with XCB_CURRENT_TIME since they are not related to
some events.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This changes the xembed code so that the caller passes in a timestamp
that should be used instead of XCB_CURRENT_TIME.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are lots of places where ICCCM says that using CurrentTime for a
timestamp is wrong. So, instead of having globalconf.timestamp
initialized to CurrentTime, initialize it with a proper timestamp.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ldoc was not installed for the DO_CHECKQA build.
This merges it with the BUILD_APIDOC build job, which is one of the
faster ones; installing ldoc into the DO_COVERAGE=coveralls would slow
that one down a lot.
This also moves the two slowest builds (with coverage reporting) to the
top, so they get started first.
Fixes https://github.com/awesomeWM/awesome/issues/1710.
Closes https://github.com/awesomeWM/awesome/pull/1716.
The longer name is a bit more self-explanatory. The plural is meant to
indicate that this recursively creates missing parent directories and
does not just try to create the single given target directory.
Since filesystem.mkdir() is part of the v4.1 release, a deprecation stub
is needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes get_cache_dir() try to ensure the cache directory that it
returns exists.
Should-fix: https://github.com/awesomeWM/awesome/issues/1663
Signed-off-by: Uli Schlachter <psychon@znc.in>
The changes should not actually make a difference. If creating the
directory fails, the error will now be different, but that should be
about it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously it would print a table which would include the memory
location where the table was stored. Thus, this produces a different
result on every build.
Signed-off-by: Uli Schlachter <psychon@znc.in>
All we do with MappingNotify events is to print a warning. This is
because the XKB protocol specification says (§12.4):
Once a client requests XkbMapNotify events, the server stops
sending it MappingNotify events to inform it of keyboard changes.
However, as our test-keyboard-layout-changes.lua test shows, this is not
actually what happens. Instead, we seem to be getting both XkbMapNotify
and MappingNotify events.
Thus, just drop this print-a-warning-code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I didn't actually test this, but at least this now looks like valid Lua
code to me, so this is definitely an improvement.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The entry "gtk+3.0" caused the following to happen:
Note, selecting 'libcanberra-gtk3-0-dbg' for regex 'gtk+3.0'
Note, selecting 'monodoc-gtk3.0-manual' for regex 'gtk+3.0'
Note, selecting 'libgtk3.0-cil' for regex 'gtk+3.0'
Note, selecting 'libavahi-ui-gtk3-0' for regex 'gtk+3.0'
Note, selecting 'libwxgtk3.0-0-dbg' for regex 'gtk+3.0'
Note, selecting 'libseed-gtk3-0' for regex 'gtk+3.0'
Note, selecting 'libgtk3.0-cil-dev' for regex 'gtk+3.0'
Note, selecting 'libcanberra-gtk3-0' for regex 'gtk+3.0'
Note, selecting 'libinfgtk3-0.5-0' for regex 'gtk+3.0'
Note, selecting 'libwxgtk3.0-0' for regex 'gtk+3.0'
Note, selecting 'gir1.2-dbusmenu-gtk3-0.4' for regex 'gtk+3.0'
Note, selecting 'libwxgtk3.0-dev' for regex 'gtk+3.0'
This was clearly not intended. Fix this by using gir1.2-gtk-3.0 instead,
which is what we actually want (GObject introspection data for GTK 3).
This pretty much reverts commit 30a527fcfd.
Signed-off-by: Uli Schlachter <psychon@znc.in>
tests/run.sh waits for awesome to exit via tail's "--pid" option. This
makes tail check once per second if the process still exists and if not,
tail will exit. However, the default of "once per second" causes lots of
wasted time for us.
This commit adds the argument "-s 0.1" to tail which makes tail check
once every 0.1 seconds. This commit changes the time that "tests/run.sh"
runs on Travis from about 60 seconds to about 35 seconds, which is a big
improvement.
Closes: https://github.com/awesomeWM/awesome/issues/1374
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the keyboard layout is modified via xmodmap, each single "change"
(line of input to xmodmap) causes an "the keyboard configuration
changed"-event to be sent. Awesome reacted to each of these events by
reloading the keyboard layout. Thus, awesome reloaded the keyboard
layout a lot and appeared to freeze.
Fix this by asynchronously update the keyboard state: When such an event
comes in, instead of reloading things immediately, we set a flag which
makes us update the state at the end of the main loop iteration. This
means that many events still cause only a single (or at least few)
re-quering of the layout. Thus, a lot of time is saved.
This commit removes the argument to the (undocumented!) signal
xkb::group_changed. Previously, the argument was the active group
number. Since this argument was unused and I'm lazy, I just removed it.
The alternative would be that it might be visible to Lua that some "the
active group changed"-events are dropped.
Fixes: https://github.com/awesomeWM/awesome/issues/1494
Signed-off-by: Uli Schlachter <psychon@znc.in>
Most of the entries that are marked as "TODO: Get rid of these" were
handled. wibox.layout.align:get_children() never worked (it always
called a non-existent function), so we can easily fix this entry without
introducing a regression.
I opened https://github.com/awesomeWM/awesome/issues/1672 to track the
underlying problem behind the broken :get_children() function (which is
missing test coverage).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallée
Uli Schlachter
Matt
Tim Roes
Daniel Hahler
getzze
paul-axe
Uli Schlachter
Daniel Hahler
axujen
Tomoya Tabuchi
Jonathan
Kevin Zander