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>
We now always know a client's WM_PROTOCOLS property without asking the X server.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Sometimes we unref the icon image, but we did not reset NULL, which
can make the client refering to a not-refed image.
Signed-off-by: Julien Danjou <julien@danjou.info>
Uli Schlachter
Gregor Best
Julien Danjou
Ari Entlich
Brian Gianforcaro
koniu