It is now possible to add and remove rules. This is superior to how
`awful.rules` originally handled rules because modules can now
assume adding and removing rules works.
The reason for the methods rather than `table.insert` is partially
because future commits will add signals. In turn, this will allow
`gears.matcher` to be extended by module using it using the extra
"introspection" made possible by the signals.
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.
This will be shared by the notifications stored in a wibox/wibar and the
ones using a popup. It extends the constraint and margins container
to take care of some boilerplate code. While other widgets have their
own public API, those 2 are private since they are not different enough
to warrent a new public module.
There is some boilerplate code that make using the widget_template
harder when using the raw `wibox.container.background`. This widget
takes care of it.
It is a normal textbox with some extra boilerplate code. Having this
in a separate widget allows the notification to be defined from rc.lua
without a ton of beautiful options and connect_signal.
This way their name doesn't get mangle by the broken magic. It will also
eventually allow to `error()` in the template when the implicit
`@function` is used.
This commit also fixes a large number of issues found while
proof-reading everything.
ldoc has a magical `@classmod` module type which tries to detect
what is a method and what is a static function. It fails about as
often as it works. This commit makes everything explicit to remove
such issues.
Fixes#2640
Ref #1373
- Fill slider bar with a linear pattern based on current value (if `bar_active_color` and `bar_color` are correctly provided)
- Add examples for the apidoc
Even thought `awful.key` handles optional "release" parameter well,
parameters are also get used before passing them. In case (only)
optional "data" is provided, it faulty gets called on a release event.
* Add a request to handle the wallpaper when a screen is added or
resized.
* Add a request for screen decorations such as bars or gizmos when
a screen is added.
Both are also sent when a new handler is connected.
* naughty.legacy: Fix a regression caused by a prior fix.
The title was only set "later" because it was called too early.
The intended result was to prevent the code from being executed when
there is no leagcy popup, but it had this side effect.
* naughty.dbus: Expose the new "private" methods so they can be tested.
Because it now uses Gio instead of capi.dbus, it isn't possible to
just shim the backend anymore.
* shims: Upgrade the dbus shims to also emulate some Gio behavior.
As usual, it is the most basic version that produces the correct
result. It doesn't try to comply to the real API.
Previously, it would use the "real" args passed to the constructor.
It was a bad decision since:
* It doesn't allow the tag/tasklist to add properties internally
* It forces the widget to be created with a constructor rather than
the alternate declarative syntax
* It doesn't allow a tag/tasklist to be part of a widget_template
Technically this is a behavior change, but I doubt anybody will notice
given it is a dark and little documented corner of the API. Chances are
nobody have been using this API for years.
With this helper, it becomes possible to avoid manually setting common
properties such as the client in the tasklist of tag in the taglist when
the children widgets of the template have a set_+property_name.
This decision was taken out of necessity. While adding more style
elements to `awful.widget.common` isn't something I want, there is
little else to do here. The problem is that popup based lists only
have size constraints in one direction. So without a way to limit
the icon size, it will take 9999 pixels.
It makes some code easier to write. It is mostly useful when the margins
are exposed through another widget. In that case it avoids having to
proxy 5 different property or re-invent the wheel there.
Previously, the border "support" was limited to shapes and would not
move the content by the offset of the border. Borders are now better
supported and thus renamed from `shape_border_width` to `border_width.
In the end, shrinking the widget by the border size is too common to
ignore. It should have been the default all along, just like the clip.
Instead of having the default template hardcoded as code, this turns the
template into a descriptive version. This makes it easier to come up
with own templates: Just copy the default template and make a slight
change to it.
No functional changes are intended, but I cannot rule out that I did no
mistakes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
LGI truncates GVariant bytestring instances at the first embedded \0
byte when using .value for "unwrapping". This commit works around that
problem by avoiding the .value API for accessing the image data [0].
Thanks a lot to Will Dietz for finding this problem and for providing a
preliminary patch fixing the problem. That saved me a lot of time [1].
[0]: https://github.com/pavouk/lgi/pull/223
[1]: eecdeb7d46
Signed-off-by: Uli Schlachter <psychon@znc.in>
This starts the switch from our own, semi-broken DBus bindings to using
the sane bindings that Gio provides.
Part-of: https://github.com/awesomeWM/awesome/issues/1093
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Fixed input_passthrough property not being set
In the table of properties supplied to the `wibox` function, you couldn't set the `input_passthrough` property. You could only set it after the wibox was created like this: `my_shlick_wibox.input_passthrough = true`. This commit fixes that and now you can set it in both ways.
When you call `reset_timeout` on a notification with 0 timeout and thus no timer, a nil field error occures.
(can be tested with `awesome-client 'require"naughty".notification{message="TEST",timeout=0}:reset_timeout()'`)
Everywhere else in similar places (even at the beginning of the `reset_timeout`) the `self.timer` field is checked so i guess it was just forgotten there.
There is not much good reason why this should be required and making it
optional is almost trivial, as this patch shows.
Signed-off-by: Uli Schlachter <psychon@znc.in>
GLib has an internal pseudo-RNG that it initialises from /dev/urandom.
This commit adds code that uses this RNG to initialise various random
number generators that can be used by Lua.
This also removes some Lua code that initialises the random number
generator badly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, it would create a new object. The leaves the old
`replaces_id` logic mostly intact for now to keep the full backward
compatibility. I don't think anybody would have noticed the changed, by
time and time again we had proof that some silent users have some
amazing and advanced code hidden somewhere. It could be cleaned later
when breaking compatibility isn't an issue.
When the mouse is over or a keyboard driven menu is open, avoid
unexpected expiration to mess with the current notifications.
This commit also improve the `suspended` behavior to correctly
emit some signals.
The current API is non-compliant with the 1.0 spec and cannot represent
the v1.2 spec at all. The pair of name and callback fails to represent
the explicit ordering and cannot support the icons cleanly.
Plus to support the keyboard navigation use case, the notification
action need to be able to get some sort of focus state. Having an
object makes this easy.
In Lua 5.1, xpcall() has exactly two arguments: The function to call and
the error handler. Everywhere else, xpcall() passes extra arguments on
to the function to call. This includes LuaJIT, however since LuaJIT sets
_VERSION to "Lua 5.1", so far gears.protected_call used the workaround
for Lua 5.1 here.
This commit switches gears.protected_call to actually test for this
feature instead of just guessing based on _VERSION. Thus, this now also
uses the better code with LuaJIT.
Signed-off-by: Uli Schlachter <psychon@znc.in>
https://github.com/awesomeWM/awesome/issues/2596
Re-matched regex used elsewhere & updated test cases for "." in filename
Allowed for alternative extensions to be found even if specified
Reverted the change of behaviour but adjusted code for readability
Small readability change
Avoided delay searches that would never work
Untabify
Reverted possible [unlikely/undesired] behaviour changes
Untabify
Commit ba75da7976 worked around a bug in LGI. However, it did so by
just dropping the code that set the foreground color. Instead, it should
have changed the code so that cr:set_source() is only called if the
background container has a foreground color configured instead of "just
always".
Fixes: https://github.com/awesomeWM/awesome/pull/2609#issuecomment-459580395
Signed-off-by: Uli Schlachter <psychon@znc.in>
When $SOURCE_DIRECTORY is set, we are most likely currently running the
examples test, i.e. generating images. These images end up in the
documentation.
To make the images reproducable, i.e. independent from the current time,
this commit makes the textclock honor $SOURCE_DATE_EPOCH if
$SOURCE_DIRECTORY is set.
See commit 9d7eaf02 for some more details.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The current `awful.widget.layoutlist` is a fork of the so far uncommitted `naughty.widget.actionlist`. It was created because some of the support code for the new `naughty` implementation needed "easier to merge" usage examples. The `layoutlist` was chosen because it was both a low hanging fruit and genuinely useful.
cairo_get_source() is not bound correctly, leading to use-after-free
bugs. Cairo catches this and crashes.
Work around this by preserving the current source in a different way.
Instead of using cairo_get_source() and later cairo_set_source(), this
commit wraps everything that changes the current source between
cairo_save() and cairo_restore(). Thus, cairo saves the current source
for us without us having to grab an explicit reference.
Works-around: https://github.com/pavouk/lgi/issues/210
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the background container "just" used the shape and drew a
line around it. This means that half the line will be inside of the
shape and half of it will be outside. Thus, this hides the actual shape
that is used.
This commit changes that so that the line is added outside of the shape.
It does this via some tricks:
- In :before_draw_children(), :push_group() is used to redirect drawing
of the child widget to a temporary surface.
- In :after_draw_children(), the border is added to this group.
+ For this, another temporary surface is created. It will be used as a
mask.
+ The inside of the shape on this mask is cleared, everything else is
filled. Thus, the mask now contains everything "not content".
+ Everything inside the mask is filled with the background color.
- Also in :after_draw_children(), the group is drawn to the actual
target surface.
+ Again, this needs a mask.
+ This time, we draw the shape to the mask with twice the border width.
Thus, half of this line will be outside of the shape.
+ Then, the shape itself is also filled so that the mask contains the
shape and the border.
+ This mask is then used to copy the right parts of the temporary
surface were the child widget and border was drawn to the actual
target surface that will be visible on screen.
This approach has some upsides. Because we no longer have "half the
border" above content, colors with some transparency work fine for the
border. Also, this should avoid issues with anti-aliasing, because e.g.
the border is not just drawn with the border width, but also further out
to everything else so that the background cannot "bleed through".
Fixes: https://github.com/awesomeWM/awesome/issues/2516
Signed-off-by: Uli Schlachter <psychon@znc.in>
This module is half way between the tooltip and the raw wibox.
It supports the following features:
* Auto resize to its widget size
* Support parent objects and placement
Fix#1683
If the `layouts` are set during initialization, `t.layout` will
return `floating` if `t.layouts` is added before `t.layout`. By
using the raw layout, the fallback doesn't kicks in.
Commit ac8af66005 added beautiful.theme_path, which is used to save the
directory that contains the theme file that was loaded. Just two months
later, commit ca12473584 broke this code by adding a __newindex
metamethod. This caused the assignment to beautiful.theme_path to be
redirected to the theme. However, the theme is immediately replaced by
beautiful.init() after setting up the theme_path, so this assignment got
lost.
Fix this by using rawset() to bypass the metamethod.
Fixes: https://github.com/awesomeWM/awesome/issues/2573
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
mergify[bot]
Sergey Vlasov
Robert Andrew Ditthardt
Vishnunarayan K I
Uli Schlachter
worron
Uli Schlachter
Michael Beaumont
fREW Schmidt
fREW Schmidt
Hùng
zsugabubus
Will Dietz
Will Dietz
mergify[bot]
Adrian Gabriel
Anton Bulakh
Alphonse Mariya
Daniel Hahler
Daniel Hahler
Sorky
Sorky
warptozero
Kevin Zander
Aire-One