Re: notifications-notify resets idle-time

[Michael Albinus <michael.albinus@gmx.de>]

Peter Münster <pmlists@free.fr> writes:

>> One idea would be to add a property `dont-reset-idle-time' to an
>> incoming event. Per default it is nil, and the timer is reset. But if
>> this property exists non-nil, the timer isn't reset.
>
> It should depend on the reason (second argument of signal), because when
> the user presses the mouse button, he is not idle. Expiration can happen
> without user action.

It is not possible to check arguments of an incoming D-Bus signal. The
signal is just put into the event queue. Arguments are inspected when
the event is handled by the respective handler, which is much too late
for the idle-time reset.

>> Wouldn't it suffice just to deregister signal "NotificationClosed"?
>
> How? With dbus-unregister-service?

Yes.

I have played with the other woraround option, reusing the notification
window. The following code snippet, based on your initial example, shall
give you an idea:

--8<---------------cut here---------------start------------->8---
(require 'notifications)
(defvar msg-id nil)
(defvar counter 0)
(defun my-test ()
  (setq counter (1+ counter)
	msg-id (apply 'notifications-notify
		  :title (format "%d" (or msg-id 0)) :body (format "%d" counter)
		  :timeout 0
		  (if msg-id
		      `(:replaces-id ,msg-id)
		    '(:on-close (lambda (&rest ignore) (setq msg-id nil))))))
  (message (format "idle: %d" (if (current-idle-time)
				  (cadr (current-idle-time))
				0))))
(run-with-timer 5 5 'my-test)
--8<---------------cut here---------------end--------------->8---

> Thanks for your efforts,

Best regards, Michael.