* Rendering problems
* Incomplete type information
* Obsolete type information
* Missing type information
* Missing return value
* Incomplete return value type
GCC 10 builds with -fno-common by default, which causes linker errors when
variables are declared in header files and included in multiple places.
See also: https://gcc.gnu.org/gcc-10/porting_to.html
`awesome.get_key_name()` accepts a key in any format that `awful.key()` understands (querying current locale configuration if fed a keycode), and returns its keysym name and printable representation, if any.
This method is based in development code from xkbcommon/libxkbcommon that has not yet been released in a stable API; for this reason, code from 0345aba082 has been copied into a new C file.
Signed-off-by: ArenaL5 <arenal5@gmx.com>
The API level concept is something used by other projects such as
Android and iOS to allow deprecated features to be removed and the
bahavior to be altered without breaking compability with existing
code.
The same will apply to AwesomeWM. The current API level is "4" and
as long as config use this, no deprecation or bahavior change will
be exposed. If the user sets it to an higher value or we release
the next major version and new users start to use the, then current,
default config, they will use the new API level.
The the far future, if ever, we could fork the entire Lua libraries
to support legacy APIs. This would only require to keep the core
API support for those legacy calls. In the meantime, `gears.debug`
will use this to manage the deprecation and some conditional code
will be added as a last resort attempt to preserve behavior
compatibility while moving forward with breaking changes.
This commit add an optional `--screen off` command to initialize Lua
without first adding the screens. This is inconvinient for most users
since it restrict the APIs that are usable out of the box.
However, this allows AwesomeWM to work independently from the hardware.
This means that when a screen is unplugged, it is the Lua code that will
remove the screen instead of CAPI pulling the carpet from under. It also
allows to ignore some screen areas before the screen is ever created.
Combined, it makes it possible to work with screens even when they are
physically disconnected. Finally, it will allow for an awful.rules like
API to control how screens are created.
All in all, some people need this for their setup and some people might
want to do it anyway for fine grained and/or dynamaic multi-screen
setups.
This commit also adds 4 new signals to `capi` to be able to
execute code at specific points during the initialization. The commit
improves naughty error notifications to work even if problems occurs
before the screens are added.
Note that AwesomeWM will exit if no screens are created. While it would
be easy to just call `refresh_screen();` after unsetting the magic
variable, doing so would have corner cases. Better be harsher and
prevent the user from shooting themselves in the foot from not reading
the f****** manual. Code introduced in future commits will take care
of automatically calling fake_screen in the event nothing is created.
Fixes#1382
This way their name doesn't get mangle by the broken magic. It will also
eventually allow to `error()` in the template when the implicit
`@function` is used.
This commit also fixes a large number of issues found while
proof-reading everything.
The function selection() is now registered in the Lua global table from
selection.c instead of in luaa.c. This "feels cleaner" to me and is
preparatory for later changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds the necessary method calls to setup the class and also
so that xfixes selection notify events can be handled. Currently, these
are empty functions, but later commits will fill them.
Signed-off-by: Uli Schlachter <psychon@znc.in>
From `kill(3p)`:
> If pid is greater than 0, sig shall be sent to the process whose
> process ID is equal to pid.
> If pid is 0, sig shall be sent to all processes (excluding an
> unspecified set of system processes) whose process group ID is equal to
> the process group ID of the sender, and for which the process has
> permission to send a signal.
> If pid is −1, sig shall be sent to all processes (excluding an
> unspecified set of system processes) for which the process has
> permission to send that signal.
> If pid is negative, but not −1, sig shall be sent to all processes
> (excluding an unspecified set of system processes) whose process group
> ID is equal to the absolute value of pid, and for which the process has
> permission to send a signal.
The documentation for awesome.register_xproperty, awesome.get_xproperty
and awesome.set_xproperty were lost in commit 26f15a13f3. This
commit adds them back.
Fixes: https://github.com/awesomeWM/awesome/issues/1817
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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>
* luaa.c: Remove useless stack operation
We get package.loaded and immediately throw away the result. That's
pointless, so remove this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Refactor modification of package.path
Awesome adds various entries to package.path during startup. This commit
moves that into a helper function. No functional changes intended. The
only change I did to the code was changing a call to lua_type(L, 2) into
lua_type(L, -1);.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Modify package.cpath just like package.path
This adds, for example, paths specified via the --search argument also
to package.cpath.
Fixes: https://github.com/awesomeWM/awesome/issues/1248
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function should only be necessary for the test suite. It makes sure
that the X11 server received and handled all previous requests that
awesome sent. This will be needed, for example, in tests that use
root.fake_input().
After a call to awesome.sync(), we are sure that "faking input" has been
done and the next main loop iteration will handle the input event.
Without the sync, it could happen that the X11 server did not yet fake
the input in the next iteration.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Add a single "do" to the beginning of the config. This causes a parsing
error ("'end' expected") and then another warning saying "something was
left on the Lua stack.
Fix this by popping the error message where we need to do so.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The same effect could be achieved by modifying $LUA_PATH or with symlinks, but
having a special option to do this seems easier.
Note that the man page translations were generated via Google translate. I'm
looking forward to people submitting correct translations...
Inspired-by: https://github.com/awesomeWM/awesome/pull/485
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a function is disconnected from a signal ("disconnect_signal") that is not
actually connected to the function, two things happened:
1. The attempt to remove the function from the signal array didn't do anything
2. Unreferencing the function noticed that the function wasn't referenced
The second step printed a big, fat scary warning.
Actually, this has the possibility of causing errors. For example, in the
following code, awesome would wrongly unreference the function at the
disconnect_signal() call and might later still try to call it when the
"refresh" signal is emitted:
do
local function f() end
awesome.connect_signal("refresh", f)
awesome.disconnect_signal("debug::error", f)
end
Fix this by making signal_disconnect() return a boolean value indicating if it
actually did something. All callers are fixed to use this value and only update
the reference counts if something was actually disconnected.
Fixes: https://github.com/awesomeWM/awesome/issues/814
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Elyes HAOUAS
Reiner Herrmann
ArenaL5
mergify[bot]
Uli Schlachter
Daniel Hahler
Daniel Hahler
Uli Schlachter
Holger Schurig
Renato Botelho