If the user copy/pasted `naughty.config.*` into their config rather
than set values 1 by 1, we could no longer add new values since they
would get removed. To prevent more users being affected by this, we
now silently ignore the new table while still setting all the values.
Fix#3145
My initial implementation was overly optimistic. It turns out there
is no end in sight to "correctly" support icons. Apps randomly use
XDG name, paths and URLs. Rather than baloon the size of the
implementation, this commit moves toward to request:: pattern
found in other APIs. This will allow people who wish to "fix"
specific icons to do so in a way that scales.
The next 2 commits will move the current implementation to request
handlers.
The tag history kept a strong reference to a screen even after that
screen was removed. This prevented the garbage collector from cleaning
up.
Fix this by getting rid of the tag history on screen removal.
Related-to: https://github.com/awesomeWM/awesome/issues/2983#issuecomment-584249568
Signed-off-by: Uli Schlachter <psychon@znc.in>
Right now, there is still a memory leak *only* when there is active
`box` notification when the screen is removed. I failed to identify
where *this* leak is comming from. The previous few commits fix
~5 other leaks.
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.
The next commit will add modeline support. By default, modelines have
the final work on which options to set. However, mostly for testing,
this isn't flexible enough.
From now on, all core object will have their own rules. `awful.rules`
hardcodes some client specific code. All `rules` module have some form
of class specific code. This code will now be part of a new module
called `ruled`. Since a year or so, a lot of work has been done to
refactor the rules on top of the shared `gears.matcher` class. This way
there wont be as much duplication.
The default `rc.lua` was using the focus/unfocus signals to set
the border color along with `awful.rules`. This logic block was
no longer aligned with the rest of `rc.lua` since it was
the only place where `beautiful` variables where only used by
`rc.lua`.
On top of this, the new request handler also has extra contexts
for the urgent and floating/maximixed use cases. So it can be used
by themes to implement much smarter borders than just focus based
ones. They were previously limited by the fact most of the
(un-monkey-patchable) logic was in `rc.lua`.
Note that this commit also shuffle the awful.rules order between
the titlebar and the border and changes the tests accordignly.
After some consideration, I came to the conclusion the previous
behavior was bogus and the fact that the placement tests required
to know about the titlebar height is simply a proof of that. The
change was required in this commit because since the border is no
longer in the default rules, a new buggy edge case surfaced.