Support "default-timeout" configuration #27

Closed
opened 9 months ago by sochotnicky · 4 comments

Currently fnott allows setting of timeout - but that seems to override all timeouts (optionally per-urgency level). That means if an app sets a timeout of 5 seconds, but fnott has timeout set - 5 seconds get ignored and config value used.

What I would like to see is default-timeout - which would only be used if an app didn't provide any timeout. Current behaviour in this scenario is that by default the notification never disappears (it counts timeout -1 as 0). If timeout is set in the config file - it overrides every notification timeout, ignoring application requests.

As per this spec:
https://www.galago-project.org/specs/notification/0.9/x408.html#command-notify
I think basically we'd be talking about config that would get used only when -1 is used for expire_timeout in the dbus call.

Easy enough to test with:

notify-send Neverending story -t -1

This notification never disappears with default config.

Currently fnott allows setting of timeout - but that seems to override *all* timeouts (optionally per-urgency level). That means if an app sets a `timeout` of 5 seconds, but fnott has `timeout` set - 5 seconds get ignored and config value used. What I would like to see is `default-timeout` - which would only be used if an app didn't provide any timeout. Current behaviour in this scenario is that by default the notification never disappears (it counts timeout -1 as 0). If timeout is set in the config file - it overrides every notification timeout, ignoring application requests. As per this spec: https://www.galago-project.org/specs/notification/0.9/x408.html#command-notify I think basically we'd be talking about config that would get used only when -1 is used for `expire_timeout` in the dbus call. Easy enough to test with: ``` notify-send Neverending story -t -1 ``` This notification never disappears with default config.
Poster

Alternatively and a more powerful option would be a way to override/define different notification styles per application calling (but I don't think there's a nice/portable way to get a dbus caller PID/process name etc that could be put in the config?)

Alternatively and a more powerful option would be a way to override/define different notification styles per application calling (but I don't think there's a nice/portable way to get a dbus caller PID/process name etc that could be put in the config?)
Poster

And if needed - I can take a stab at implementing this - just want to make sure the basic idea is OK from your POV.

And if needed - I can take a stab at implementing this - just want to make sure the basic idea is OK from your POV.
Owner

That means if an app sets a timeout of 5 seconds, but fnott has timeout set - 5 seconds get ignored and config value used.

It should use the smallest of the two, if I remember correctly.

Alternatively and a more powerful option would be a way to override/define different notification styles per application calling (but I don't think there's a nice/portable way to get a dbus caller PID/process name etc that could be put in the config?)

Each notification does have an application name associated with it (the -a option in notify-send). Kind of like how top-levels in Wayland have an application ID.

That said, having a default timeout probably covers most use cases.

Either way is fine I think, and mostly comes down to how much time you/I want to spend implementing it :)

And if needed - I can take a stab at implementing this

Please do!

> That means if an app sets a timeout of 5 seconds, but fnott has timeout set - 5 seconds get ignored and config value used. It _should_ use the smallest of the two, if I remember correctly. > Alternatively and a more powerful option would be a way to override/define different notification styles per application calling (but I don't think there's a nice/portable way to get a dbus caller PID/process name etc that could be put in the config?) Each notification _does_ have an application name associated with it (the `-a` option in `notify-send`). Kind of like how top-levels in Wayland have an application ID. That said, having a default timeout probably covers most use cases. Either way is fine I think, and mostly comes down to how much time you/I want to spend implementing it :) > And if needed - I can take a stab at implementing this Please do!
dnkl added the
enhancement
label 9 months ago
Poster

That means if an app sets a timeout of 5 seconds, but fnott has timeout set - 5 seconds get ignored and config value used.

It should use the smallest of the two, if I remember correctly.

I am looking at this:
https://codeberg.org/dnkl/fnott/src/branch/master/notification.c#L781

The method gets called from here with timeout_ms set to 0:
https://codeberg.org/dnkl/fnott/src/branch/master/notification.c#L685

Not yet sure I am reading it right - but that method also gets called from within dbus handler where it picks 0 if the timeout requested is -1:
https://codeberg.org/dnkl/fnott/src/branch/master/dbus.c#L308

Anyway - I'll re-test how it behaves.

Alternatively and a more powerful option would be a way to override/define different notification styles per application calling (but I don't think there's a nice/portable way to get a dbus caller PID/process name etc that could be put in the config?)

Each notification does have an application name associated with it (the -a option in notify-send). Kind of like how top-levels in Wayland have an application ID.

That said, having a default timeout probably covers most use cases.

Either way is fine I think, and mostly comes down to how much time you/I want to spend implementing it :)

Yeah, the notification spec says the app string can be blank - not sure how often it actually is. But as you say - I think we don't need to overcomplicate things and the default probably handles most cases. KISS :-)

And if needed - I can take a stab at implementing this

Please do!

ACK

> > That means if an app sets a timeout of 5 seconds, but fnott has timeout set - 5 seconds get ignored and config value used. > > It _should_ use the smallest of the two, if I remember correctly. I am looking at this: https://codeberg.org/dnkl/fnott/src/branch/master/notification.c#L781 The method gets called from here with `timeout_ms` set to 0: https://codeberg.org/dnkl/fnott/src/branch/master/notification.c#L685 Not yet sure I am reading it right - but that method also gets called from within dbus handler where it picks 0 if the timeout requested is -1: https://codeberg.org/dnkl/fnott/src/branch/master/dbus.c#L308 Anyway - I'll re-test how it behaves. > > Alternatively and a more powerful option would be a way to override/define different notification styles per application calling (but I don't think there's a nice/portable way to get a dbus caller PID/process name etc that could be put in the config?) > > Each notification _does_ have an application name associated with it (the `-a` option in `notify-send`). Kind of like how top-levels in Wayland have an application ID. > > That said, having a default timeout probably covers most use cases. > > Either way is fine I think, and mostly comes down to how much time you/I want to spend implementing it :) Yeah, the notification spec says the app string can be blank - not sure how often it actually is. But as you say - I think we don't need to overcomplicate things and the default probably handles most cases. KISS :-) > > And if needed - I can take a stab at implementing this > > Please do! ACK
dnkl referenced this issue from a commit 8 months ago
dnkl closed this issue 8 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.