In theory it would be enough to only update the old and new screen of
the tag whose screen changed. However, we cannot easily get the old
screen, so just update all layoutboxes.
Fixes: https://github.com/awesomeWM/awesome/issues/1503
Signed-off-by: Uli Schlachter <psychon@znc.in>
In Gtk 2, the "first" argument to set_geometry_hints() is not optional.
However, this code does not provide any argument here. Improve the error
message in this case by checking for Gtk 3.
Reference: https://github.com/awesomeWM/awesome/issues/1495
Signed-off-by: Uli Schlachter <psychon@znc.in>
ldoc formatting has problems with code block lines that start with
spaces. use non-blocking-space (unicode 0xa0) as a work around.
Signed-off-by: Justin Charette <charetjc@gmail.com>
- added note that `awesome.quit` must be wrapped in an anonymous
function when used as a menu command.
- corrected tasklist diff to include missing lines from rc.lua. the
porting guide code doesn't make much sense otherwise.
- cleaned up diff columns on a couple other code blocks.
Signed-off-by: Justin Charette <charetjc@gmail.com>
As documented in
<https://keithp.com/~keithp/talks/xtc2001/paper/xft.html#sec-editing>,
the fallback value for Xft.dpi should be the vertical DPI reported by X.
On Xorg, this will generally be 96, unless the user has overridden the
value by either forcing Xorg to report the EDID-derived DPI, or by
setting the DPI themselves (via configuration, command line, or xrandr).
The 96 value is kept as ultimate fallback if anything goes wrong.
Xrandr provides new physical sizes in millimeters when sending a
RRChangeNotifyEvent, either to preserve DPI when monitors are added, or
to change DPI when a DPI change was requested. Keep track of the changes
so that our DPI information is always fresh.
Up to now we assumed that the default config is in a path where
xdgConfigFind() finds it. However, evidently this is not always the
case, so make this explicitly try the default configuration file.
Fixes: https://github.com/awesomeWM/awesome/issues/1346
Signed-off-by: Uli Schlachter <psychon@znc.in>
I explicitly did not add client_shape_input property since querying the
input shape of the client window seems useless to me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit c50d62749b added an empty table as a default theme. However,
when loading the actual theme fails, we will end up with theme having
value nil. This commit fixes this by reverting back to an empty table.
Fixes: https://github.com/awesomeWM/awesome/issues/1417
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves Lua initialisation to the latest possible point, just before
loading the configuration file. This requires to also move screen
initialisation and parts of EWMH initialisation to a later point.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, there was a function which attempted to load different
configuration files in the right order. There was a boolean argument
that decided if we are actually loading it or just checking for syntax
error (for the --check argument of awesome). This lead to some
not-so-nice code since we do not want to fall-back to another config
when checking for syntax errors.
Refactor this so that there is now a function which calls a callback
function with the different paths that should be tried. This function
returns as soon as the callback function returns true.
Since just checking if the config syntax is ok does not depend on any
Lua state, an empty Lua state is now used for this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It makes more sense to append the xdg config dirs to our list of
searchpath in awesome.c than in luaa.c. Plus, it simplifies some of the
following work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This removes some @EXPANSIONS@ from Lua files and removes a hack that
was needed. All is better now! :-)
Signed-off-by: Uli Schlachter <psychon@znc.in>
All versions of libxcb provide at least RandR 1.3 (if I remember
correctly). With version 1.5, the concept of a monitor was added. This
might make quite a difference for awesome and to help debugging bug
reports that are due to missing support for monitors, the existence of
this support was added to the --version output.
However, many people feel like they are missing out due to this, even
though the new RandR 1.5 stuff likely makes no difference for them. To
help these people, instead of having a yes/no, just print the full RandR
version. When a bug report that is due to missing monitor support shows
up, we can look up if the reporter has RandR 1.5. All other people are
no longer bothered.
Example-reference: http://stackoverflow.com/questions/41773529/no-randr-1-5-support-in-test-install-of-awesome-4-0-what-to-check
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
getzze
Kevin Zander
Emmanuel Lepage Vallée
Luke Bonham
actionless
Justin Charette
Holger Schurig
Daniel Hahler
Uli Schlachter
Giuseppe Bilotta
Daniel Hahler
Alexander Gehrke
SammysHP