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.
ldoc has a magical `@classmod` module type which tries to detect
what is a method and what is a static function. It fails about as
often as it works. This commit makes everything explicit to remove
such issues.
Fixes#2640
Ref #1373
Until now there wasn't much documentation available about how to use
these properties. With the new work on `awful.spawn` that rely more and
more on `awful.rules` integration, it is worth fixing.
This commit add a new documentation section and a future commit will
aggregate them to generate an index.
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.
This property is based on Motif WM hints and checks if the client
requests that it is not decorated with a titlebar.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are some cases where a client's floating state "silently" changes.
For example, a fullscreen client will be considered floating. However,
even though c.floating changes its value in this case, we did not emit
the property::floating signal.
Fix this by explicitly tracking the "implicitly floating" state. When
some property that influences this "implicitly floating" state changes,
we update it and if a client which was not explicitly assigned a
floating state observes a change in this value, property::floating is
emitted.
This was tested by running a terminal and two xeyes in a tag with a
tiling layout where awful.ewmh was patched so that clients do not change
their geometry when fullscreening or maximizing. It was observable that
after this patch e.g. the titlebar and the tasklist update to show the
floating state of the client which became implicitly floating due to
being maximized.
Fixes: https://github.com/awesomeWM/awesome/issues/1662
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move table functions out of awful.util into new gears.table
* travis: Use v9999 prefix for full requests
Make sure no newly deprecated functions are used
* Move all `awful.util.table.*` calls to `gears.table.*` calls
Move table test functions from awful/util_spec to new gears/table_spec
Change awful.util.subsets call to gears.math.subsets in awful/key.lua
Before this commit, do this:
c.maximize_hoizontal = true
c.maximize = true
c.maximize = false
assert(c.maximize_hoizontal)
Would not work because the states were not preserved individually.
This commit fixes that. Awesome wont be confused about it's own
state anymore.
This may seem pointless, but when it come to undoing these
maximizations, it was ambiguous.
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>
Instead of using a weak table with some magic to save properties of a
client, the code now uses the c.data table provided by the C code
instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of having an extra weak table to save a boolean per client, this
now sets a property directly on the client.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a tparam alias "@screen" for "@tparam screen" (when used to
document e.g. arguments for callbacks), and "@screen_or_idx" when a
function accepts a "screen" or "number".
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>
Rules refactor, part 1
This fix the following awful.rules bugs:
* **x**: Broken when "border_width" is set or left titlebars are used
* **y**: Borken when"border_width" is set or top titlebars are used
* **width**: See above + right litlebar
* **height**: Same as above
* **switchtotag**: Have a race with the "manage" -> "tag.withcurrent" code in `awful.tag`
* **tag**: Had dead code
* **screen**: Had a race condition with switchtotag
* **urgent**: Had a race with screen and another with switchtotag+focus
* **focusable**: Was broken yet again when request::activate was introduced (and also because of FS1098, that I also fixed)
* **no_overlap**: The "no_overlap" call in rc.lua "manage" section conflict with the geometry rules as the hints are not set (idk why).
* **size_hints_honor**: If set to false, it would be applied too late, causing height and width offsets due to placement or various geometry related properties
The new stateful layout system try to avoid coupling and therefor
doesn't use these methods. It is not planned to deprecate the
stateless layout API, so these functions are just kept as-is with
the old naming convention.
Emmanuel Lepage Vallee
fREW Schmidt
Sergey Vlasov
mergify[bot]
Uli Schlachter
Peter Kasza
Rastislav Barlik
Daniel Hahler
SammysHP
Kevin Zander
copycat-killer
Daniel Hahler
Uli Schlachter
cmertz