Awesome: Notifications with default timeout don't disappear (with naughty.list.notifications)

[robn]

Output of awesome --version:

awesome v4.3-897-g66b1780d (Too long)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: no
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: 0.9.2
 • Transparency enabled: yes
 • Custom search paths: no

How to reproduce the issue:

• Add a notifications list wibox using the example at https://elv13.github.io/widgets/naughty.list.notifications.html
• Send a notification with an explicit expiry timeout: notify-send -t 2000 first
• Send a notification without an explicit expiry timeout: notify-send second

Actual result:

The first notification disappears after 2 seconds.

The second notification never disappears.

Expected result:

When no explicit expiry timeout is set, the notification should disappear after the default timeout (5 seconds).

More info

If I add this to my rc.lua:

naughty.connect_signal('added', function(n)
    print(n:get_timeout())
end)

It shows the timeout on the notification is set to the default of 5. This suggests something is wrong with its setup. To confirm this, I made this patch:

diff --git a/lib/naughty/dbus.lua a/lib/naughty/dbus.lua
index 98b36a7f..2eea8b94 100644
--- a/lib/naughty/dbus.lua
+++ a/lib/naughty/dbus.lua
@@ -278,6 +278,8 @@ function notif_methods.Notify(sender, object_path, interface, method, parameters
         end
         if expire and expire > -1 then
             args.timeout = expire / 1000
+        else
+            args.timeout = 5
         end

         args.freedesktop_hints = hints

With this in place, the notifications disappear.

My guess; the timer for new notifications is being created before the default timeout is set, so it sees "no timeout" and doesn't set up. I haven't been able to follow the code well enough to confirm that, let alone fix it, but there it is.

[ShayAgros]

Hi, I'm not able to reproduce this issue. Tried:

• Running the code in Xephyr with both master branch code and 4.3 tag (the former didn't reproduce the issue and the latter doesn't seem to support the code you posted). Used default awesome config with the problematic code snippet
• Same without Xephyr

Also verified that we have the same output for awesome --version

Does this issue reproduce for you with the default config file (awesomerc.lua)?

[Aire-One]

• Running the code in Xephyr with both master branch code and 4.3 tag (the former didn't reproduce the issue and the latter doesn't seem to support the code you posted). Used default awesome config with the problematic code snippet

The naughty library was updated by @Elv13 after the 4.3 release. It is a normal behavior you can't use the new API on the stable 4.3 release of awesome as the related code is not part of it. You have to use the git version to use the new naughty API.

---

I also tried to run some test with the default awesomerc.lua on Xephyr :

• notify-send -t 2000 first displays correctly the notification for 2 seconds ;
• notify-send second displays this notification for 5 seconds (without any patch!).

Looking at the source code, notif_methods.Notify build notification arguments from the dbus event received then calls the naughty.notification.create method to build the notification. We can then find in naughty/notification.lua: https://github.com/awesomeWM/awesome/blob/master/lib/naughty/notification.lua#L873:

-- @int[opt=5] args.timeout Time in seconds after which popup expires.

So these 5 seconds for the second nofity-send seems to be a wanted and already working behavior.

However, the documentation (https://awesomewm.org/apidoc/core_components/naughty.notification.html#naughty.notification) don't have this field (and many other):

Parameters:

    args The argument table containing any of the arguments below.
        shape gears.shape Widget shape. (default `beautiful.notification_shape`)
        opacity gears.opacity Widget opacity. (default `beautiful.notification_opacity`)
        margin gears.margin Widget margin. (default `beautiful.notification_margin`)
        run func Function to run on left click. The notification object will be passed to it as an argument. You need to call e.g. notification.die(naughty.notification_closed_reason.dismissedByUser) from there to dismiss the notification yourself. (optional)
        destroy func Function to run when notification is destroyed. (optional)
        preset table Table with any of the above parameters. Note: Any parameters specified directly in args will override ones defined in the preset. (optional)
        callback func Function that will be called with all arguments. The notification will only be displayed if the function returns true. Note: this function is only relevant to notifications sent via dbus. (optional)
        actions table A list of naughty.actions. (optional)
        ignore_suspend bool If set to true this notification will be shown even if notifications are suspended via naughty.suspend. (default false)
    opt string =beautiful.notification_border_color or beautiful.border_color_active or '#535d6c'] args.border_color Border color.

@robn: (It's out of scope for this issue but can lead to misunderstandings) Please use the documentation generated by ldoc. It will be local to you device, so no loading time to read doc + it will be up-to-date with the awesome version you built. Or use the official documentation at https://awesomewm.org/apidoc/index.html which is up-to-date with master. Keep in mind the documentation at https://elv13.github.io/ is maintained kept up-to-date by Elv13 for his own awesome version. You can for example find over there the documentation for the dynamite module (https://elv13.github.io/client_tiling/dynamite.html) which is not yet part of the official awesome repo.

@Elv13:

• It seems the @int and @string, and probably other are ignored by ldoc. Do we miss a patch for ldoc on awesome master?
• The default timeout of 5 seconds seems to come from naughty.constants.lua (I'm not sure to totally understand the cst.config.notify_callback call nor where are the defaults n values from in https://github.com/awesomeWM/awesome/blob/master/lib/naughty/notification.lua#L1013-L1018) which sets different timeout depending on the notification type. So the documentation is misleading by saying it defaults to 5 seconds here. (And I guess we can have use cases where timeout will be sets to 0, as here)

[robn]

Ahh I see, thanks. I had assumed that the elv13 docs were tracking master (I had no reason to think that, other than they seemed to work). I will learn how to use ldoc.

That said, now that I've found https://awesomewm.org/apidoc/widgets/naughty.list.notifications.html, I notice the example is the same. So I suppose its still a real problem.

I'm not quite following the rest of the conversation. But anyway! It sounds like my non-default rc.lua might be in play, so I will go and test further with that next. Thanks!

[Aire-One]

Technically, you don't have anything to learn about ldoc. The documentation is automatically built when you run make if you have ldoc installed on your system (I think it's even a hard dependency, so it should be). You can then find a local version of the doc in your build directory build/doc/index.html is the home page. You can load it into your browser with the file://PATH-TO-YOUR-LOCAL-AWESOME-REPO/build/doc.index.html (Note the path will start with / so it'll look like file:///home/...)

It sounds like my non-default rc.lua might be in play, so I will go and test further with that next. Thanks!

It's a possible cause for this. Can you please check if you still have the issue with the default awesomerc.lua configuration? As I mentioned in my post, I also don't understand everything going on, so it's also possible there is something else we're missing here... I think it's safe to take an extra test with the default configuration on your device.