The name is self explanatory, it adds more actions to a notification.
One of the use case is adding a snooze/reming_me action. Another one
is "mute similar notifications".
The reason is that if actions are provided by rules, only one instance
exist. It was a mistake to couple actions with their notifications. It
could not work reliably and has to be removed.
The commit also change the notification action storage to be a copy
instead of the original table. This allows to append actions (not part
of this commit) without risking adding them to the wrong notification.
**WARNING** This break an unreleased API by removing the `notification`
property of an action.
* app_name: To be used in filters when no clients are found.
* max_width: Allow to set it from the rules, it might be different
when a `widget_template` is used.
* widget_template: Now it can be set from the rules without further
boilerplate code.
The old preset code had a primitive implementation of the rule API
used in `naughty.dbus`. Now that `gears.matcher` is extracted from
`awful.rules`, it is possible to share the code.
The first step is to only enable the old API when the new
`request::preset` isn't connected. This is the same way the legacy
popup is only enabled when nothing is connected to `request::display`.
This removes the imperative "mutex" logic from rc.lua, where it doesn't
belong. It also makes it closer to the "vision" of making `rc.lua` fully
modular.
* action icons
* persistence
* residence
* categories
* animated icons
* more ways to get icons
In addition, the commit also tries its best to attach notifications to
objects using various dubious semi compliant hints or the DBus PID. It
works often enough to be useful.
Some titlebar widgets (`awful.titlebar.widget.titlewidget`,
`awful.titlebar.widget.button` and other specific button widgets) could
not be garbage collected until the associated client was unmanaged,
because the signal connection used to update the widget was never
destroyed, and the signal handling function was keeping a reference to
the widget in its environment. This resulted in high memory usage when
the titlebar widgets were recreated multiple times for the same client
(this does not happen with the default Awesome configuration, but may be
needed for dynamic titlebar reconfiguration in a custom config).
Modify the code to use weak tables instead of direct signal connections
to avoid keeping strong references to widgets. The widget update
functions still keep strong references to the widget itself (creating a
reference loop, but the Lua GC should handle it correctly) and the
client object, but this should not be a problem.
One publicly visible change is that `awful.titlebar.widget.titlewidget`
now has an `update` function, like the button widgets.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
This is needed because if async code is run inside of a tooltip timer func the started property may not still be false.
The current version causes random spurious timer already started errors.
This is configurable globally or per-notification. When it is
replaced over dbus, it has a new timeout and *that* should be the
new timeout (starting when the notification is replaced).
Closes#2821
The awful.placement.no_overlap function always looked at the currently
visible clients when placing a new client. This produced a confusing
result when using awful.rules or the sn_rules argument of awful.spawn to
place the client on an unselected tag (the client was placed as if it
would be placed on a currently selected tag; if multiple clients were
placed on the same unselected tag, in many cases they were placed at the
same position, overlapping each other).
Make awful.placement.no_overlap check tags of the placed client and
handle the case of placement on an unselected tag in a more useful way:
- If the client is sticky or at least one of the client tags is
selected, keep the previous behavior: avoid overlap with all other
floating clients which are currently visible, and use the currently
active layout to determine the floating status.
An explicit check based on `c:tags()` is made instead of using
`c:isvisible()`, so that the previous behavior is kept even if the
client is hidden or minimized for some reason.
- If all client tags are unselected, avoid overlap with all other
floating clients which either are sticky or share at least one tag
with the placed client, and use the layout of the first tag of the
placed client to determine the floating status.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
A call to cairo_close_path() adds a straight line to the beginning of
the current sub-path. This is used in some of the shapes to, well, close
the shapes.
Sub-paths can be created explicitly via cairo_new_sub_path(), but also
implicitly via cairo_move_to(). When a new sub-path is started, there is
no current point on the path. This means that e.g. cairo_line_to() is in
this start equivalent to cairo_move_to() (= no line is created) and that
cairo_curve_to() first does a cairo_move_to() to the beginning of the
curve. Similarly, cairo_arc() and cairo_arc_negative() first do a
line_to() to the beginning of the arc, and this line_to() can be
implicitly turned into a curve_to().
The problem with the code in gears.shape is that parts of the code
(implicitly) assume that there is not yet any path when the shape
function is called. If this assumption is broken, the call to
close_path() could go to the wrong point, because the path did not start
at the expected position.
Most of the functions in gears.shape already implicitly start a new
sub-path via a call to cairo_move_to(). Those that do not (necessarily)
begin with a call to cairo_move_to() are handled in this commit: They
get an explicit call to cairo_new_sub_path().
This change fixes the issue reported at
https://github.com/awesomeWM/awesome/pull/2804, because the shapes will
no longer be influenced by the pre-existing path. The move_to() that was
left around and caused that issue turns into a degenerate part (it only
has a move_to(), so nothing can be drawn) and is then discarded by
cairo.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Cairo's save/restore methods handle all properties except for the
current path. The path is just left as-is.
A widget's draw method could create some path without consuming it. This
path would then interfere with random things later which did not expect
a path to already exist.
This commits adds calls to cairo_new_path() in the relevant positions to
clean things up.
This not only applies to a widget's draw method, but also
{before,after}_draw_{child,children}. However, these methods could (for
whatever reason) create paths that are to be consumed in one of the
other methods. To keep this working, the path is only cleared after all
of these methods ran.
I do not expect this commit to break anything, because a widget cannot
really assume much about what widget is drawn after it. Especially so,
because partial redraws could mean that some later widget is skipped and
not redrawn.
This should fix the issue reported at
https://github.com/awesomeWM/awesome/pull/2804.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function checks if a given cairo context has an empty clip. It was
written with the assumption that cairo_clip_extents() produces the x, y,
width, height of the clip extents. However, that function actually
produces x1, y1, x2, y2, where (x1, y1) and (x2, y2) are the corners of
the rectangles.
Due to the way the function is written, it will return non-zero numbers
when there is a translation (cr:translate()). Thus, this function worked
basically never.
Fix this by checking if both points have the same X- or Y-coordinate.
Signed-off-by: Uli Schlachter <psychon@znc.in>
With draw_empty=false, :fit() can return 0,0. Then, when :layout() is
called, it will compute negative widths and heights. This can then cause
lots of problems later on.
Avoid this by having :layout() return nothing instead of producing
negative sizes.
Fixes: https://github.com/awesomeWM/awesome/issues/2799
Signed-off-by: Uli Schlachter <psychon@znc.in>
Also document the `test` property as deprecated. It exists because the
older API (`naughty.notify`) had it. It exists on purpose in the
rewrite, it cannot just be removed even if it was never in a release.
Emmanuel Lepage Vallee
mergify[bot]
Sergey Vlasov
Robert Andrew Ditthardt
Vishnunarayan K I
Uli Schlachter
worron
Uli Schlachter