add a default timeout property to Notifd

[paulhersch]

Is your feature request related to a problem? Please describe.
See #317: I wanted to keep a record of notifications timed out and if i want to resolve manually because a notification does not have a specified timeout, the application crashes

Problem(s):

• The timeout with the timeout of expire_timeout is only created, if expire_timeout is set at Notification spawn (see: https://github.com/Aylur/astal/blob/main/lib/notifd/daemon.vala#L139), which few applications actually do; meaning i would have to add a timeout that resolves this in my non-vala user code
• As per LGI warnings/crashes when firing on_resolved signal on notification #317 the whole interaction with letting notifications expire through manually resolving from user code (in this case lua) causes a crash.

Describe the solution you'd like

add a default timeout for notifications as per spec (https://specifications.freedesktop.org/notification-spec/latest/protocol.html#id-1.10.3.3.4)

If -1, the notification's expiration time is dependent on the notification server's settings, and may vary for the type of notification.
this might be accompanied by a property on the daemon.

Describe alternatives you've considered
i considered not using resolve but pretending i used the method i want to use for expired messages, however i feel like this kind of defeats the purpose of offering the expire functionality inside the library.

Additional context
i think the logic should look something like this if i understood the spec correctly?

        if (expire_timeout == -1) {
            expire_timeout = default_timeout
        }
        if (!ignore_timeout && expire_timeout > 0) {
            Timeout.add(expire_timeout, () => {
                if (!ignore_timeout) {
                    resolved(id, ClosedReason.EXPIRED);
                }
                return Source.REMOVE;
            }, Priority.DEFAULT);
        }

[Aylur]

1. you are not supposed to invoke on_resolved
2. if you want to resolve a notification use dismiss

local DEFAULT_TIMEOUT = 2000

function notifd:on_notified(id)
	local n = notifd:get_notification(id)

	if n.expire_timeout == -1 then
		timeout(DEFAULT_TIMEOUT, function()
			n:dismiss()
		end)
	end
end

I don't really understand your usecase from #317. Do you need the notification to be resolved with EXPIRED instead of DISMISSED_BY_USER? Because in that case it would be better to add int default_timeout { get; set; } to the notifd class

[paulhersch]

2. if you want to resolve a notification use dismiss

regarding the terminology: as far as i understood, dismiss implies, that a user actively wanted the notification gone, so if a notification is resolved with reason DISMISSED i shouldn't put it into my notification center.

I don't really understand your usecase from #317. Do you need the notification to be resolved with EXPIRED instead of DISMISSED_BY_USER?

It looked to me like manually firing resolved with the timeout would work as a hack to cover above intention, which caused the described problems.

Because in that case it would be better to add int default_timeout { get; set; } to the notifd class

exactly my point for the default_timeout property. What i would like is for the daemon to have a default_timeout property, so that notifications with a timeout of -1 can get their expire_timeout set accordingly, which would also cover the described behavior in the linked FreeDesktop specification.
Sorry for causing confusion, after reading my issue again i realized that half of my text is incomprehensible.

[Aylur]

Regardless of reason if a notification is resolved it ceases to exist and is removed from the notifications list and you should no longer try to access that notification.

I'm assuming you want to have a popup list where you can hide the popup but still show it in a notification center. In which case you are not supposed to close the notification at all and just handle it in user code.

On the notified signal simply add a widget to the popup list where the close button just simply removes the widget,
this way the notification is not yet resolved and you can still show it in a notification center.

Notifd does not have a concept of popups

[paulhersch]

Regardless of reason if a notification is resolved it ceases to exist and is removed from the notifications list and you should no longer try to access that notification.
I'm assuming you want to have a popup list where you can hide the popup but still show it in a notification center. In which case you are not supposed to close the notification at all and just handle it in user code.

okay, i wasn't aware about that. In that case default_timeout still makes sense from how i see it tho, as it would still be interesting to know why a notification was removed from notifications.

Edit: consumer code to underline why i think this would be useful:

    -- this should usually cover all bases, if closing is done as expected
    function notification:on_resolved(reason, _)
        if reason == Notifd.ClosedReason.EXPIRED then
            _copy_to_saved(notification)
        end
        _delete_from_shown_if_exists(self.id)
    end

    -- added part to cover timeout = -1 and edgecases where notifications are resolved
    -- before this timeout runs
    if notification.expire_timeout == -1 then
        timeout(default_timeout, function()
            -- if it still exists, dismiss it after copying the data
            local _, notification_maybe = _get_from_shown(id)
            if notification_maybe then
                _copy_to_saved(notification)
                notification:dismiss() -- end notification lifecycle
            end
        end)
    end

although to be fair, i copy objects into another table that is offered as a facade, so this might look simpler if using notifd directly.