* fix(naughty: icon: new, fit): use `icon_size` from the notification object if defined (fixes#3752)
* fixup! fix(naughty: icon: new, fit): use `icon_size` from the notification object if defined (fixes#3752)
* fixup! fixup! fix(naughty: icon: new, fit): use `icon_size` from the notification object if defined (fixes#3752)
The goal is to catch cases where the return value exists, but is
forgotten. There was a large enough number of them to turn this
into a real check. Initially, I just wanted to implement it to fix
the problems, then delete the code. But since this is so common, I
think it is worth the annoyance.
* Rendering problems
* Incomplete type information
* Obsolete type information
* Missing type information
* Missing return value
* Incomplete return value type
luajit was failing to GC the notification about 5% of the time. This
commit stores all widget notifications in a weak table and don't let
any lambda access the parent object notification object.
Each of those changes reduces the failure rate. There might still be
a couple in there, but the test passed 200x on my laptop with 100%
success rate.
By fixing some suspend bugs a few weeks ago, I "regressed" this
a little. By that, I mean there were bugs in the suspend code
which caused `ignore_suspend` to work simply because suspend
globally failed rather than `ignore_suspend` being implemented
correctly.
Fix#3465
There is more into that table than just screens. If `get_by_id` was
called with an invalid notification (or a "future" one in case of
suspended / do_not_disturb), it would explode.
If a config with naughty.layouts.box crashes at startup and the
fallback config uses naughty.layouts.legaxy, it is possible their
will be some lookup for an object which isn't tracked by the legacy
module.
If the problem happens early enough, it was possible that the
screen arrway wasn't initialized yet. In that case, the notification
would fail to render.
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
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`.
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.