dnkl
/
fnott
2
24
Fork 8
Code Issues 9 Pull Requests 1 Releases 7 Activity
Labels Milestones
New Issue

Support "default-timeout" configuration #27

Closed
opened 9 months ago by sochotnicky · 4 comments
sochotnicky commented 9 months ago

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.
sochotnicky commented 9 months ago
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?)
sochotnicky commented 9 months ago
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.
dnkl commented 9 months ago
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
sochotnicky commented 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
Merge branch 'add-default-timeout'
dnkl closed this issue 8 months ago
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
releases/1.0
releases/1.1
releases/1.2
Labels
Apply labels
Clear labels
bug
Something is not working duplicate
This issue or pull request already exists enhancement
New feature help wanted
Need some help invalid
Something is wrong question
More information is needed wontfix
This won't be fixed
No Label bug duplicate enhancement help wanted invalid question wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch '%!s(MISSING)'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes