The code in property_update_wm_transient_for() looked at the transient_for
relation before the new transient got set. However, the code is supposed to
check if we get a loop after introducing this new transient_for.
Thus, if we arrive back at the client that we started from, we can be sure that
there is a cycle. Signal this by setting the loop counter high enough to abort
the loop and make the rest of this function do nothing.
No idea how I missed this case before nor why I cannot reproduce this on debian,
but can reproduce it on Arch just fine.
Reported-By: Kasimir Knallkopf at http://article.gmane.org/gmane.comp.window-managers.awesome/10415
Signed-off-by: Uli Schlachter <psychon@znc.in>
Lots of code assumes that it can recursively follow a client's transient_for
field until it reached an end without a transient_for client. Instead of fixing
all those places to properly handle loops, this patch just makes us ignore
WM_TRANSIENT_FOR if the property causes a loop.
This means that it can be a little random which WM_TRANSIENT_FOR property is
ignored, because it will always be the one that happens to complete the cycle. I
don't think that this is bad, because there shouldn't be any loops in the first
place.
Lots-of-kudos-to: David Mohr <david@mcbf.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Now that the C code uses lightuserdata for passing around cairo surfaces, they
are no longer automatically garbage collected. To avoid memleaks, this commit
compares the C code to use cairo_surface_t pointers instead of the lua stack.
This also fixes a memleak were a client's icon was leaked.
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>
Previously, client_set_icon() popped the image that was being used. When I made
this use oocairo, I accidentally made this function not pop anything at all, so
the caller has to do this now.
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>
Since each handler is only for one single atom, there is no point in passing the
atom that was changed to the callback.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of calling each property handler with a property reply, it's now up to
the handlers to request the properties.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For each property we handle, there is now a function which sends a request and
returns the cookie and a second function that takes the cookie and saves the
result in the client_t struct. This should make it possible to improve our
latency later on.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We no longer use libxcb-event, so we don't have to follow it's API any more.
This means the pointless arguments and return values can be removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Upstream removed most of the code from libxcb-event and there is no
event-related stuff left in this library. We now no longer use any of the parts
that were removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We no longer have to follow libxcb-property's API for these function, so we can
remove arguments which we don't use anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
libxcb-property will be dropped from xcb-utils in the next release, because
upstream thinks it's not really useful and well-designed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The memory referred to by the reply argument of
property_update_wm_protocols is automatically free'd
by xcb later on, so it is not safe to simply use the
value of reply in our own data structures. If we did
this, future calls to xcb_get_wm_protocols_reply_wipe
free the data which has already been free'd by xcb,
causing a double-free and corrupting the heap. In
addition, it isn't safe to use free'd memory as if
it is still allocated. Instead, duplicate the data
referred to by reply and use the duplicate instead.
It seems to me as if the duplication should actually
be done in xcb_get_wm_protocols_from_reply, but I'm
not really sure. If that is the case, this is simply
a work-around until xcb can be fixed.
Signed-off-by: Ari Entlich <atrigent@ccs.neu.edu>
Signed-off-by: Julien Danjou <julien@danjou.info>
property_update_wm_hints() pushes the client but never pops it. This is a really
bad thing (tm).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Without this patch c.class shows the instance and vice versa.
Signed-off-by: koniu <gkusnierz@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Instead of using the given atom name it always requested the WM_NAME property of
a client.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Uli Schlachter
Gregor Best
Arnaud Fontaine
Julien Danjou
Ari Entlich
Brian Gianforcaro
koniu