This allows to control which kind of icon actions can be done
on individual notifications. Once the second part of the permission
system will be merged, this will mostly be used in `ruled.notification`.
Currently, emit_signal always call all connected function. However,
it is very wasteful for some I/O intensive operations like icon
lookup. This commit adds a trick (private API) to stop once
a condition is met.
It will also in the future be used for the permission system, but
this is not yet implementd.
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.
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.
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>
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.
Just like clients and other CAPI classes, it is now possible to
connect to all instance signals. There was already a couple of
`request::geometry`, but no way to forward them, so it was
de-facto broken.
The next commit will all class level signals. The current design
is used in widgets, but is a bad fit for wiboxes. They should
behave more like client. In v5, setting methods on `wibox` directly
will be deprecated. `wibox.object` is already supported. I don't
think anyone really do that anyway and isn't documented.
This commit mostly rewrite the client documentation and pay the
technical debt accumulated over the years. Most of the client
documentation was still one-liners from the luadoc era. It now
has all the new tags, type. It also has actual description of
what the properties do beyond the name.
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.
This has to be in its own commit otherwise Travis will fail. This
is because it will keep the file in the build directory when
iterating all commits. Then `ldoc` will fail because the file doesn't
have documentation. If `config.ld` is updated first, then it will
fail because `ruled/init.lua` doesn't exist yet. When it is done
in a separate commit, then `config.ld` is already updated and comes
with `init.lua`.
actionless
Ari Breitkreuz
Hugo Trassoudaine
Gerome Matilla
hung
Seth Barberee
mergify[bot]
Emmanuel Lepage Vallée
ArenaL5
Rob Hoelz
handsome0hell
Unai Fernández
Xaver Hellauer
Mahe
Uli Schlachter
Aire-One
laith-m0