There is not much good reason why this should be required and making it
optional is almost trivial, as this patch shows.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a way to leverage the xproperty and startup_id APIs
to persist an execution token across restarts. It allows to use
`awful.rules` on clients that were executed by a previous Awesome
instance.
The main limitations of these methods is the lack of entropy used to
build the token. If the command is the same in multiple
`awful.spawn.once`, then it will not work as expected. To mitigate this
issue, the system try to concatenate the `awful.rules` table after the
command and hash the resulting string. Given rules are a table, it can
have loops and/or issues with keys ordering. The hash function sort and
limite recursion to prevent a stack overflow. Another issue is the
unreliability of startup notifications.
I do not know how a GDataInputStream / GBufferedInputStream decides
about the size of its internal buffer when reading input by line, but in
issue #2288, an example where the output of date (about 30 bytes) was
read ten times per second caused ten megabytes of memory usage for this
internal buffer. Try to save some memory by explicitly shrinking the
buffer size when we are done reading from the stream.
Reference: https://github.com/awesomeWM/awesome/issues/2288
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, there was a conflict between the spawn and
awful.rules rules.
Also, modules such as Tryannical monkey-patched this function to
add their own rules to the mix. This commit introduce a proper
API to add handlers.
The order is crutial for this to work, so a dependency system is
also added.
Fix#1482
Spawn callbacks were never invoked when no startup-notification-rules were
given. This commit fixes the code so that "startup done" callbacks are also
called when no rules were given.
Fixes: https://github.com/awesomeWM/awesome/issues/1218
Signed-off-by: Uli Schlachter <psychon@znc.in>
When adding callbacks as a `callback` entry in a property, the callback
is run by `awful.rules`, because it does `c.callback =
result_of_function`. This is obviously not intended. Also, this causes
the callbacks to run twice, because the code already handled this
`callback` property specially.
Fix this by just not merging callbacks with the normal rules at all.
Fixes: https://github.com/awesomeWM/awesome/issues/1159
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 requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Having many arguments can easily get confusing and hard to understand. This
commit uses a table instead so that we have names that identify what each
callback does.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds support for the callback that was added in the previous commit to this
function. We can just pass on the function that the caller gives us.
Fixes: https://github.com/awesomeWM/awesome/issues/185
Signed-off-by: Uli Schlachter <psychon@znc.in>
* This commit add a new module to avoid a (4 level) loop dependency
* It is now possible to call awful.spawn() with a table of properties
* awful.rules is used to execute the rules.
* Everything is public to allow alternative workflow modules such as
Tyrannical to use their own callback implementation.
worron
Uli Schlachter
Emmanuel Lepage Vallee
Daniel Hahler
tototest99
Uli Schlachter
Luke Bonham
Kevin Zander
Daniel Hahler
actionless