Private fork of https://github.com/awesomeWM/awesome
10fa808a5a
When a keyboard grab activate/deactives, the input focus jumps to the window which does the grab. These FocusIn events sometimes managed to confuse awesome. The symptom was that a newly mapped/started client didn't receive the input focus: - You press your key-combo to start a terminal. This activates a passive grab and the input focus jumps to the root window - The terminal opens and the "manage" rule does client.focus = c - This doesn't set the focus yet, but instead causes globalconf.focus.need_update = true and .client = new_terminal - Before the focus is updated, the key combo is released and the focus jumps back to the previously focused client - The FocusIn with mode == Ungrab causes awesome to think that the previously focused client got focused again and thus globalconf.client.focus gets re-set to what it was before - Finally the focus is refreshed and the previously focused client gets focused The fix is simple: We don't need the FocusIn events which are generated when a grab activates or deactivates, so we can just ignore them. Thanks to Majic for reporting this to me. Signed-off-by: Uli Schlachter <psychon@znc.in> |
||
|---|---|---|
| build-tests | ||
| build-utils | ||
| common | ||
| icons | ||
| lib | ||
| luadoc | ||
| manpages | ||
| objects | ||
| themes | ||
| utils | ||
| .gitignore | ||
| AUTHORS | ||
| BUGS | ||
| CMakeLists.txt | ||
| LICENSE | ||
| Makefile | ||
| PATCHES | ||
| README | ||
| STYLE | ||
| awesome-version-internal.h.in | ||
| awesome.c | ||
| awesome.desktop | ||
| awesome.doxygen.in | ||
| awesome.h | ||
| awesomeConfig.cmake | ||
| awesomerc.lua.in | ||
| banning.c | ||
| banning.h | ||
| color.c | ||
| color.h | ||
| config.h.in | ||
| dbus.c | ||
| dbus.h | ||
| draw.c | ||
| draw.h | ||
| event.c | ||
| event.h | ||
| ewmh.c | ||
| ewmh.h | ||
| globalconf.h | ||
| keygrabber.c | ||
| keygrabber.h | ||
| keyresolv.c | ||
| keyresolv.h | ||
| luaa.c | ||
| luaa.h | ||
| mouse.c | ||
| mouse.h | ||
| mousegrabber.c | ||
| mousegrabber.h | ||
| property.c | ||
| property.h | ||
| root.c | ||
| screen.c | ||
| screen.h | ||
| selection.c | ||
| selection.h | ||
| spawn.c | ||
| spawn.h | ||
| stack.c | ||
| stack.h | ||
| strut.c | ||
| strut.h | ||
| systray.c | ||
| systray.h | ||
| xwindow.c | ||
| xwindow.h | ||
README
awesome
=======
awesome is a highly configurable, next generation framework window manager for X.
Building and installation
-------------------------
After extracting the dist tarball, run:
make
This will create a build directory, run cmake in it and build awesome.
After building is finished, you can install:
make install # you might need root permissions
Running awesome
---------------
You can directly select awesome from your display manager. If not, you can
add the following line to your .xinitrc to start awesome using startx
or to .xsession to start awesome using your display manager:
exec awesome
In order to connect awesome to a specific display, make sure that
the DISPLAY environment variable is set correctly, e.g.:
DISPLAY=foo.bar:1 exec awesome
(This will start awesome on display :1 of the host foo.bar.)
Configuration
-------------
The configuration of awesome is done by creating a $XDG_CONFIG_HOME/awesome/rc.lua file.
An example configuration named "awesomerc.lua.in" is provided in the source.
Troubleshooting
---------------
In most systems any message printed by awesome (including warnings and errors)
are written to $HOME/.xsession-errors.
If awesome does not start or the configuration file is not producing the desired
results the user should examine this file to gain insight into the problem.