This commit makes awesome measure how long all the event handling takes. That
is, this measure the time between waking up from poll and going to sleep again.
If that time is above 0.1 seconds, we print a warning and increase the limit for
this warning to the last duration to avoid flooding messages.
This should help figuring out cases were people do stupid things in their
config, like synchronously contacting an IMAP server and getting the number of
unread mails.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We detect other WMs when we fail to request SubstructureRedirect on the root
window. Previously, the code used an unchecked request and then tried to
cleverly detect if an error occurred. This isn't needed.
Instead, we now use a checked request and use xcb_request_check() to see if any
errors were generated. This also gets rid of a round-trip to the server (one is
still implicitly done by xcb_request_check()).
Signed-off-by: Uli Schlachter <psychon@znc.in>
A drawin's and a client's bounding and clip shape can now be queried and is
returned as a cairo surface. Also, a client window's shape (e.g. xeyes setting
its own shape) can be queried via c.shape_client_bounding and
c.shape_client_clip. All of these properties now emit signals when changed.
(This also silently fixes a bug in luaA_drawin_set_shape_bounding() which forgot
to include the drawin's border in its size calculation)
Signed-off-by: Uli Schlachter <psychon@znc.in>
The above-mentioned bug report says that a window cannot be moved via its
titlebar if you move the move quickly while clicking.
The reason for this was awesome's "event compression": We don't handle all
MotionNotify events, because they can come in big quantities. Instead, we only
want to handle the latest one and ignore all earlier ones (the mouse isn't in
that position anymore anyway).
The problem now appears if a MotionNotify is moved across a ButtonPress event
and the ButtonPress is what should cause the window to be moved. Awesome first
handles the ButtonPress event normally and starts grabbing mouse input. Then,
our event loop feeds us with an old MotionNotify event in which the button was
not pressed yet. The code for moving clients gets a motion event in which no
mouse button is pressed, concludes that the move is done and ungrabs the mouse
again, even though the button is still physically pressed.
Fix this by making sure that MotionNotify events are never moved across
ButtonPress or ButtonRelease events. We already did this for EnterNotify and
LeaveNotify events for similar reasons.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit c3bca6ac34.
This caused problems where clients would always spawn on the top-left screen and
couldn't be moved around. This was because lua placed them on the other screen,
but when the titlebar got added, their top-left corner was moved over again.
This kind of forces every client to have a window gravity of "static".
This fixes most of the problem of clients moving around across restarts due to
the titlebar. What is left is that they move due to the border width which
should be handled in another patch. Also, another patch should make this honor
the client's actual window gravity.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For setting up the wallpaper, awesome needs a second connection to the X11
server (isn't SetCloseDownMode just great?).
However, it was possible to have a dead-lock with our main connection due to
this. Awesome does a GrabServer during startup so that nothing else can use the
X11 server while we set ourselves up. The server is ungrabbed right before the
lua config is read. However, nothing makes sure that this ungrab request really
is sent to the server instead of just waiting in xcb's output buffer.
The dead-lock would now happen if we try to establish a second connection to the
X11 server before the ungrab request was flushed on the main connection. The
server will wait for the ungrab on the first connection, awesome is waiting for
the second connection to be successfully established.
Fix this by making sure the UngrabServer request is flushed before parsing the
config file.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Thanks to Michael Stapelberg, there is now a xcb-only port of libXcursor which
does everything we need. This patch switches awesome over to that new library.
Since the only reason for using XOpenDisplay() instead of xcb_connect() was so
that we can use libXcursor, we can get back to that older state again. This
means that this effectively reverts the following commits:
531f8b415c "Added initial support for Xlib cursor themes"
77243cd09a "Add x11-xcb to the pkg-config checks"
779d43fc46 "Don't let Xlib own the event queue"
03759b4847 "Fix keyboard layouts"
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 08ca70c00d added support for Xlib cursor themes by making awesome use
Xlib for its X11 connection and for setting cursor icons. Everything else was
still done through xcb.
However, an unexpected side effect of this is that Xlib enabled the XKB
extension without asking us. This changes the way that keyboard events are
reported which causes problems with various keyboard events.
(Normally, Xlib hides these things by silently fixing up the events that it
hands out to applications. However, since we bypassed Xlib via xcb...)
The fix is simple: Luckily Xlib provides a function for disabling its XKB
support which is just what we need.
Signed-off-by: Uli Schlachter <psychon@znc.in>
X11 is a great protocol. When a window manager dies, it can make sure that
client windows don't get destroyed via the save-set. However, revert-to-parent
focus handling means that the focus now shifts to the parent which gets
destroyed and afterwards the focus is "none", which is a really bad state.
Fix this in two places:
First, when shutting down, we switch to PointerRoot mode. This makes sure that
the input focus follows the mouse pointer if no window manager is started.
Also make sure that we set the input focus the way we want it to be after start
up. This obviously cleans up any weird state which might exist before we manage
the input focus.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit ports awesome from libev to the glib main loop. This means that
awesome has fewer dependencies, because we were already depending on glib before
and now no longer need glib.
However, the main reason for this change is that, thanks to lgi, we have glib
bindings for lua. This means that lua code can add all kinds of event sources to
the main loop (timeouts, fd watchers, SIGCHLD watchers, ....). Yay
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 03e0ee53d2 removed window shapes, because at the time I was too
lazy to port them from the old image system to oocairo.
This commit re-adds them, but for now only as a way to set the shape.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit 531f8b415c, we are using Xlib for our X11 connection. However,
we still use XCB for event processing. This means we actually have to tell Xlib
to leave all events alone.
This might fix FS#1047. Perhaps.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I hope this time i got all right with git format-patch.
Signed-off-by: Tumin Alexander <iamtakingiteasy@eientei.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
My intel driver no longer is broken with ARGB visuals, so let's enable this by
default again. Let's see how long it takes for someone else to hit a broken
driver and complain. :-)
This reverts commit c7da695e10.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If loading of any config file fails, awesome will now remember the error message
and make it available to lua. The default config is modified to open a naughty
popup on errors.
This should help all those people who modify their config and then wonder why
there change is ignored, not noticing awesome's error message on stderr.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves the loading of the rc.lua and managing of pre-existing clients to
after we ungrab the server during startup. To make sure we have no races with
clients which start up parallel to awesome, we do the QueryTree for all the
clients that we have to manage before the ungrab, but start managing the clients
only after the ungrab.
This means that we have already selected our event mask on the root window in
scan() and thus received an UnmapNotify event when we reparent windows into a
frame window. This has the effect that we immediately unmanage the client again,
whoops.
To fix this, we grab the server again and remove our event mask on the root
window again while we reparent.
This should hopefully fix all cases where we deadlock during startup because
pulseaudio wants to talk to the X server, but is being ignored because we have
the server grabbed while at the same time we are waiting for pulseaudio.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This option is no longer valid in modelines, so it has been removed from
all modelines using the following shellscript:
#!/bin/ksh
git ls-tree -r HEAD | cut -f2 | while read f; do
egrep -e '^(//|--) vim: .*encoding=' $f >/dev/null || continue
sed -E -e '/^(\/\/|--) vim:/s/:encoding=utf-8//' $f > /tmp/foo
mv /tmp/foo $f
done
Signed-off-by: Gregor Best <gbe@ring0.de>
Signed-off-by: Uli Schlachter <psychon@znc.in>
xcb-util is now split into several repositories since 0.3.8. This
release also cleaned up the API a lot, thus update the code
accordingly.
Signed-off-by: Arnaud Fontaine <arnau@debian.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
awesome.c contains this comment:
There can be no events yet, so if his function returns something, it must be
an error.
Sadly, this wasn't true. It seems like something managed to generate
MappingNotify events (no idea how).
Fix this by discarding all pending events after our GrabServer, but before we
ask for SubstructureRedirect on the root window.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some time ago I added a --no-argb option with the short-hand version -a.
However, the short version didn't actually work. Whoops!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the X connection breaks for whatever reason, awesome wouldn't properly
exit, but go into a busy loop instead. Fix this by dying when our connection to
the X server dies.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Seems like there are enough bugs in the X server that one can't really use a 32
bit visual. Looks of repaint errors. :(
This should somehow be fixed properly before release. For now, this just swaps
the default behavior and the "--no-argb" behavior.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For performance reasons, we only handle the last motion notify we receive.
However, we must make sure that the motion isn't moved after enter or leave
notifies. Else, breakage is ensured!
Signed-off-by: Uli Schlachter <psychon@znc.in>
If awesome is started with that flag, it won't use ARGB visuals. Theoretically,
this shouldn't be necessary, but it seems like this triggers bugs in the X
server. (Or is it just my server that doesn't like me?)
Signed-off-by: Uli Schlachter <psychon@znc.in>
We don't have any window with globalconf.depth yet at this point, so we have to
create one just for setting up our GC.
Signed-off-by: Uli Schlachter <psychon@znc.in>
With this commit, awesome prefers ARGB visuals over the screen's default visual.
This means that all our (visible) windows now can get an alpha channel that a
compositing manager can use for producing transparent windows.
The reason why this is done is to fix a bug. We are reparenting clients into
other windows. If one of these client window uses an ARGB visual, its
transparency would have no effect.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The window that is specified when a GC is created is used for two things. First,
it specifies which protocol screen the GC should be associated with. Second, it
specifies for which color depth the GC is valid.
Due to this second property, we have to use the systray window instead of the
root window. The systray window uses globalconf.default_depth.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes awesome support only a single X11 protocol screen. If you are still
using zaphod mode, you can run multiple instances of awesome on the single
screens, e.g.:
DISPLAY=:1.0 awesome & DISPLAY=:1.1 awesome &
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves the setting of the event mask after scan() so that we won't receive
any events from scan()'s activity (especially no UnmapNotifies which would cause
us to lose clients).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
kardan
Tumin Alexander
Gregor Best
Arnaud Fontaine
Chris Newton