- We are tracking focus, using FocusIn/FocusOut events handlers, so user
should never be confused about which client has focus
- window_setfocus function generates focus change requests to the X server
- client_focus uses window_setfocus to set input focus
- revert_to when setting input focus set to Parent, compliant with
ICCCM convention ([1])
- DEBUG flag for those who want to debug focus handlers
Most of the changes, are compliant with X11 handbook ([0]), but some
where obtained experimentally.
Kudos to Maarten Maathuis who helped a lot with this.
[0]
http://cgit.freedesktop.org/xorg/doc/xorg-docs/plain/hardcopy/X11/xlib.PS.gz
[1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.7
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Mariusz Ceier <mceier@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
- gnome-panel (for example) requests the space for all it's windows
- this approach can never work for multiple applications, so we clamp it
Signed-off-by: Julien Danjou <julien@danjou.info>
- WINDOW_TYPE_DOCK are chosen first.
- Top/Bottom take precedence over Left/Right.
- Struts are automatically updated.
- Automatically avoid overlap with other struts or wibox'es.
Signed-off-by: Julien Danjou <julien@danjou.info>
Just a minor change: since capi.awesome.spawn does a double fork, there
is no need to use a '&' to background the spawned process.
Cheers.
\n\n
From 843d7cc255afb8d07e7c91a3a9d1ed706bc07c88 Mon Sep 17 00:00:00 2001
From: Nikos Ntarmos <ntarmos@cs.uoi.gr>
Date: Sun, 29 Mar 2009 21:40:57 +0300
Subject: [PATCH] No need for & as capi.awesome.spawn double-forks
Signed-off-by: Nikos Ntarmos <ntarmos@cs.uoi.gr>
Signed-off-by: Julien Danjou <julien@danjou.info>
Cheers,
Alex
From b5816ec55073507d4527ad3a77eae1878adb30d3 Mon Sep 17 00:00:00 2001
From: Alex Cornejo <acornejo@gmail.com>
Date: Sun, 29 Mar 2009 14:24:27 -0400
Subject: [PATCH] Fixed some styling issues.
Noticed in the latest pull that a commit introduced a lot of styling
inconsistencies, decided to remove those and others found by a simple
grep.
Signed-off-by: Alex Cornejo <acornejo@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
This list was generated with the following shell script snippet:
for x in $(tr "[a-z]" "[A-Z]" < common/tokenize.gperf)
do
y="A_TK_$x"
if git grep " $y[:)]" > /dev/null
then
: echo found: $y
else
echo not found: $y
fi
done
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
- struts are now additive
- allow multiple docks at the edge of the screen, trigger is approaching workarea from inside
Signed-off-by: Julien Danjou <julien@danjou.info>
I just realized this variable was unused in the original code, and in my
patched version. I removed it.
Signed-off-by: Alex Cornejo <acornejo@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Now we support a list of fallback targets when opening the socket, and
socket binding/connect is done inside socket.* instead of luaa.c or
awesome-client.c
Signed-off-by: Alex Cornejo <acornejo@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Unless I am missing something there is no purpose of using two loops
instead of one.
Signed-off-by: Alex Cornejo <acornejo@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
On corporate/university environments it is not uncommon for the home
folder of each user to be hosted on OpenAFS (so you can work from any
terminal and IT services can backup everything at will).
However it is not possible to create sockets in AFS, hence when awesome
attempts to create a socket at ~/.awesome-ctl it fails. To fix this
awesome now uses /tmp/.awesome-ctl as a fallback before giving up.
Signed-off-by: Alex Cornejo <acornejo@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
This patch makes awesome-client give up after 10 tries when it lost the
connection to awesome. Also it now waits for some time between reconnect
attempts.
I like the behaviour of this, but some of the code seems a little icky...
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>