Most of the notification code is from 2017. Soon after being written,
the permission system started to take shape. This required to
standardize the `request::` signals into the "object, context, args"
style. The notification code wasn't merged during that refactoring
and was accidently merged without the fixes.
Since this is still unreleased, I break the API now before it is too
late. Sorry about this.
The rational behind this is that adding more and more `beautiful`
variables doesn't scale. While not everybody is on board with this,
I think we should move more logic into the theme to put an end to
the unscalable complexity plagging some modules (such as the
tasklist).
Instead of adding a variable for the background and foreground color
of urgent notification, we can now use the rules.
Since it is used only one, use require() directly. This allows
to require it from `beautiful` without a circular dependency.
In turn, this allows to set colors using the rules rather than
adding an endless amount of theme variables.
This commit introduce the new "ruled" module. This new top level
module will eventually host all "rules" related modules.
As for the content of the commit, it adds rules for notification. They
are mostly identical to the client rules and can be used to customize
or filter the notifications. It replaces the old "preset" API. The
preset API inner working was mostly a duplication of the early
`awful.rules` API, but was never as flexible. Thus the idea behind this
work is to converge all "core" classes to use a similar declarative API.
When less space is available than was asked, systray:draw() has to
compute the right base size so that all the icons fit into the available
space. This computation so far ignored the icon spacing, resulting in a
too large base size.
Fixes: https://github.com/awesomeWM/awesome/issues/2981
Signed-off-by: Uli Schlachter <psychon@znc.in>
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 function returns the geometry of the parent object. As it was used,
it was passed the parent object directly. The means the parent geometry
of the parent object was used instead of the geometry of the parent
object. This worked "fine" as long as the mouse was in the same screen,
but it was just hiding the bug.
Because it was using a metatable proxy instead of a full copy,
`pairs()` wasn't working and thus any code based on it was
blind to the `args`.
Fixes#2956
The original idea was to decouple the notification and the screens, but
this causes the default `rc.lua` to behave in very unexpected ways.
This commit re-implement the `legacy` logic for the `box` layout.
This caused a behavior change it wasn't clear how to use the
permission API to change the focus mode.
The change will only take effect if the user override the API
level.
Now that modeline are supported, they will affect the content of
version. This commits only adds the new information. `--version` has
to be the last command line argument and the modeline isn't parsed
yet.
Another commit will make sure --version parses the modeline and
finishes to process the command line arguments in case it isn't
last. Please note that luarocks also affects data points such as
the LGI version. It should be smarter and check if `rc.lua` has
`require("luarocks")`. This commit does *not* do it.
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 commits re-use the modeline code from the previous commit
to support Lua scripts starting with #!. Previously, it was
non-trivial to add support since most *nix OS wont parse the
command line arguments correctly. Since we now have a state
machine good enough for 95%+ of the use case, it is easy to
support them.
This commits adds the ability to add an `-- awesome_mode:` comment
to `rc.lua`. This line will be interpreted before Lua starts and
allow command line options to be set in the file.
There is also a partial shebang mode (`#!`) support. While it is
not yet possible to make a random Lua file executable and start
`awesome`, it is at least supported to configure AwesomeWM. The
next commit will add the missing bits.
This commit implements the parsing using a state machine. While
glib has its own functions, they don't do 100% of what we need.
It could have been possible to use them anyway and get quotes,
escaping and UTF-8 support for free. The downside would have been
duplicated code to handle shebangs and modeline. The state machine
code fully support 3 different ways of loading the arguments with
the same code path.
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.
Emmanuel Lepage Vallee
Mahe
Uli Schlachter
mergify[bot]