notifications-notify resets idle-time

notifications-notify resets idle-time

[Peter Münster]

Hello,

How can I prevent `notifications-notify' from resetting the idle time?

In detail: when evaluating the following code, you'll see, that the idle
time does not increase:

--8<---------------cut here---------------start------------->8---
(require 'notifications)
(defun my-test ()
  (notifications-notify)
  (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---

TIA for any hints,
-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> Hello,

Hi,

> How can I prevent `notifications-notify' from resetting the idle time?
>
> In detail: when evaluating the following code, you'll see, that the idle
> time does not increase:
>
> (require 'notifications)
> (defun my-test ()
>   (notifications-notify)
>   (message (format "idle: %d" (if (current-idle-time)
> 				  (cadr (current-idle-time))
> 				0))))
> (run-with-timer 5 5 'my-test)
>
> TIA for any hints,

I have no problem. I've just evaluated your code snippet, and I get

idle: 2
idle: 7
idle: 12
idle: 17
idle: 22
idle: 27
idle: 32
idle: 2

"GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.6)
 of 2012-01-29 on xxx"

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Sat, Feb 11 2012, Michael Albinus wrote:

> I have no problem. I've just evaluated your code snippet, and I get
>
> idle: 2
> idle: 7
> idle: 12
> idle: 17
> idle: 22
> idle: 27
> idle: 32
> idle: 2

Why not "37" here?
(I get 5, 10, 2, 2, 2, 2, 2....)

Version: GNU Emacs 24.0.93.1 (x86_64-suse-linux-gnu, GTK+ Version 2.22.1)

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> On Sat, Feb 11 2012, Michael Albinus wrote:
>
>> I have no problem. I've just evaluated your code snippet, and I get
>>
>> idle: 2
>> idle: 7
>> idle: 12
>> idle: 17
>> idle: 22
>> idle: 27
>> idle: 32
>> idle: 2
>
> Why not "37" here?
> (I get 5, 10, 2, 2, 2, 2, 2....)

'Cause I've started to type something. This resets the idle timer.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Sat, Feb 11 2012, Michael Albinus wrote:

>>> idle: 2
>>
>> Why not "37" here?
>> (I get 5, 10, 2, 2, 2, 2, 2....)
>
> 'Cause I've started to type something. This resets the idle timer.

It seems, that the issue depends on the :timeout parameter. Perhaps our
default values are different. Could you please test with

  (notifications-notify :timeout 1000)

With this timeout value, I get 5, 3, 3, 3, 3.....

Can others confirm this behaviour?

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> It seems, that the issue depends on the :timeout parameter. Perhaps our
> default values are different. Could you please test with
>
>   (notifications-notify :timeout 1000)
>
> With this timeout value, I get 5, 3, 3, 3, 3.....
>
> Can others confirm this behaviour?

It doesn't change the behaviour for me. I still get 

idle: 0
idle: 4
idle: 9
idle: 0
idle: 5
idle: 10
idle: 15
idle: 20
idle: 25
idle: 30
idle: 35

Have checked your code snippet by starting plain "emacs -Q"?

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Sat, Feb 11 2012, Michael Albinus wrote:

> It doesn't change the behaviour for me. I still get 
>
> [...]
>
> Have checked your code snippet by starting plain "emacs -Q"?

Yes. "emacs -Q" then copying the code snippet into *scratch*,
then M-x eval-buffer.

Strange, how could I debug this?

It seems, that closing the notification window resets the idle time, by
mouse-click or by :timeout does not matter.
I've just tried ":timeout 30000" to keep the windows for a longer timer,
and when I close a notification window with a mouse-click, the idle time
is reset.

I've just recompiled emacs-trunk, but nothing changes...

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> It seems, that closing the notification window resets the idle time, by
> mouse-click or by :timeout does not matter.
> I've just tried ":timeout 30000" to keep the windows for a longer timer,
> and when I close a notification window with a mouse-click, the idle time
> is reset.

Ahh, that's the difference. I haven't closed the notification window, I
let it expire. This does not reset idle-time.

It sounds acceptable to reset the idle timer on Emacs, when you touch
the notification window. A signal is returned, and a callback function
is activated, which might be the reason of the reset.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Sat, Feb 11 2012, Michael Albinus wrote:

> Ahh, that's the difference. I haven't closed the notification window, I
> let it expire. This does not reset idle-time.

Me too, I let it expire. I've just done another test with closing by
mouse-click. The result is the same: when the windows closes (by click
or expiration) it resets the idle-time.

Any idea how to debug this?


> It sounds acceptable to reset the idle timer on Emacs, when you touch
> the notification window.

I agree. But IMO it should not happen when the window expires.

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> On Sat, Feb 11 2012, Michael Albinus wrote:
>
>> Ahh, that's the difference. I haven't closed the notification window, I
>> let it expire. This does not reset idle-time.
>
> Me too, I let it expire. I've just done another test with closing by
> mouse-click. The result is the same: when the windows closes (by click
> or expiration) it resets the idle-time.
>
> Any idea how to debug this?

keyboard.c.

notifications.el is implemented by D-Bus calls and signals. In
keyboard.c, D-Bus events are handled like other input events, for
example keyboard pressing. This might also reset idle-time, I haven't
checked further.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Sun, Feb 12 2012, Michael Albinus wrote:

> notifications.el is implemented by D-Bus calls and signals. In
> keyboard.c, D-Bus events are handled like other input events, for
> example keyboard pressing. 

I'm quite sure, that when I debug keyboard.c, I'll just find that the
window-close-event resets the idle-time. The question for me: where is
the difference between our systems? Perhaps it's related to the
windowmanager, or the environment variables?
Later (when I've more time), I'll try other setups (other user, other
WM, perhaps other opensuse-version), and I'll report back.

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> I'm quite sure, that when I debug keyboard.c, I'll just find that the
> window-close-event resets the idle-time.

Look for the code which is embedded in

#ifdef HAVE_DBUS
#endif

But IIRC, there's nothing special with the idle_timer settings, related
to D-Bus. So you should check the whole logic of resetting it.

> The question for me: where is the difference between our systems?
> Perhaps it's related to the windowmanager, or the environment
> variables?

Maybe it's a timing issue.

> Later (when I've more time), I'll try other setups (other user, other
> WM, perhaps other opensuse-version), and I'll report back.

I run Ubuntu 11.10.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Sun, Feb 12 2012, Michael Albinus wrote:

> Look for the code which is embedded in
>
> #ifdef HAVE_DBUS
> #endif

Yes, the code is executed, when the notification windows expires.

The timer is reset on line 2849 in keyboard.c:

--8<---------------cut here---------------start------------->8---
 non_reread:

  if (!end_time)
    timer_stop_idle ();
  RESUME_POLLING;
--8<---------------cut here---------------end--------------->8---

I've found that with some `puts("xxx")' here and there. I tried gdb
(using ddd) but without success: the execution stops before I can set a
breakpoint...


> Maybe it's a timing issue.

I don't know. But I've prepared now a very simple test file and it would
be nice if you could try it please on your system and send me the
*Messages* buffer afterwards, just to compare it with mine.
You just need to save the attached file in /tmp and then run
"emacs -Q -l /tmp/notify.el"
The test takes just 2 seconds ;)

Thanks for your efforts!
-- 
           Peter

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: notify.el --]
[-- Type: text/x-emacs-lisp, Size: 325 bytes --]

(require 'notifications)
(setq dbus-debug t)
(notifications-notify :timeout 1000)
(defun my-test ()
  (let ((ct (current-idle-time)))
    (message (format "idle time: %f"
                     (if ct
                       (+ (cadr ct) (/ (nth 2 ct) 1000000.0))
                       0)))))
(run-with-timer 1.5 nil 'my-test)

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> I don't know. But I've prepared now a very simple test file and it would
> be nice if you could try it please on your system and send me the
> *Messages* buffer afterwards, just to compare it with mine.
> You just need to save the attached file in /tmp and then run
> "emacs -Q -l /tmp/notify.el"
> The test takes just 2 seconds ;)
>
> Thanks for your efforts!

That's the result:

For information about GNU Emacs and the GNU system, type C-h C-a.
Fdbus_call_method: org.freedesktop.Notifications /org/freedesktop/Notifications org.freedesktop.Notifications Notify
Fdbus_call_method: Parameter1 :string Emacs
xd_signature: s
xd_append_arg: s Emacs
Fdbus_call_method: Parameter3 :uint32 0
xd_signature: u
xd_append_arg: u 0
Fdbus_call_method: Parameter5 :string /usr/local/share/emacs/24.0.93/etc/images/icons/hicolor/scalable/apps/emacs.svg
xd_signature: s
xd_append_arg: s /usr/local/share/emacs/24.0.93/etc/images/icons/hicolor/scalable/apps/emacs.svg
Fdbus_call_method: Parameter7 :string 
xd_signature: s
xd_append_arg: s 
Fdbus_call_method: Parameter9 :string 
xd_signature: s
xd_append_arg: s 
Fdbus_call_method: Parameter11 (:array)
xd_signature: as
xd_append_arg: a s nil
Fdbus_call_method: Parameter12 (:array :signature {sv})
xd_signature: g
xd_signature: a{sv}
xd_append_arg: a {sv} nil
Fdbus_call_method: Parameter13 :int32 1000
xd_signature: i
xd_append_arg: i 1000
Fdbus_call_method: Message sent
xd_retrieve_arg: u 223
xd_retrieve_arg: s :1.240
xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus NameAcquired (:1.240)
idle time: 1.297380

Re: notifications-notify resets idle-time

[Peter Münster]

On Sun, Feb 12 2012, Michael Albinus wrote:

> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
> org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus NameAcquired
> (:1.240)
> idle time: 1.297380

Thanks! The only difference is, that you don't get a NotificationClosed
signal, but on my system I do:

--8<---------------cut here---------------start------------->8---
xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 1773 :1.10
/org/freedesktop/Notifications org.freedesktop.Notifications
NotificationClosed (221 1)
xd_read_message_1: Event stored: (:session 4 1773 :1.10
/org/freedesktop/Notifications org.freedesktop.Notifications
NotificationClosed notifications-on-closed-signal 221 1)
DBus-Event (dbus-event :session 4 1773 :1.10
/org/freedesktop/Notifications org.freedesktop.Notifications
NotificationClosed notifications-on-closed-signal 221 1)
idle time: 0.498186
--8<---------------cut here---------------end--------------->8---

So there are 2 issues:

- The NotificationClosed signal resets the idle-time, and IMO it should
  not. (emacs issue)

- You don't get the NotificationClosed signal and that's probably a bug
  of your notification system, perhaps this one:
  https://bugs.kde.org/show_bug.cgi?id=228743

  On my system, it's the notification-daemon-0.5.0.

  According to the spec, the NotificationClosed signal should be sent:
  http://www.galago-project.org/specs/notification/0.9/x408.html#signal-notification-closed

Should I make an emacs bug report?

Does anyone know a workaround?

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> Thanks! The only difference is, that you don't get a NotificationClosed
> signal, but on my system I do:

I was too hasty: I've copied the *Messages* buffer before the
notification did expire. No error at all.

> So there are 2 issues:
>
> - The NotificationClosed signal resets the idle-time, and IMO it should
>   not. (emacs issue)

It is not NotificationClosed specific. I would rather say that is due to
the nature of D-Bus events, handled via `special-event-map'. I guess that
all events defined in that map will reset the idle timer.

> - You don't get the NotificationClosed signal and that's probably a bug
>   of your notification system, perhaps this one:
>   https://bugs.kde.org/show_bug.cgi?id=228743

Not a bug, as said.

> Should I make an emacs bug report?

I still don't understand why it disturbs you. Could you, please, explain
your use case?

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Mon, Feb 13 2012, Michael Albinus wrote:

> I was too hasty: I've copied the *Messages* buffer before the
> notification did expire. No error at all.

That means, that ":timeout 1000" did not work for you...!?


> It is not NotificationClosed specific. I would rather say that is due to
> the nature of D-Bus events, handled via `special-event-map'. I guess that
> all events defined in that map will reset the idle timer.

Yes. It would be good, if there was a method to filter these events.
(perhaps there is already, but I don't see it...)


> I still don't understand why it disturbs you. Could you, please, explain
> your use case?

On the one hand, I use `gnus-demon-add-handler' for several actions,
that need to be done repeatedly and only when idle for at least some
minutes.

On the other hand I use 
    (setq appt-disp-window-function 'pm/todo-notify ; popup notify-windows
          appt-display-interval     1)
and
    (org-agenda-to-appt t '((headline "TODO")))
in such a way, that the notification windows are refreshed once per
minute (":timeout 60000"). This is nice, because I don't need to click
on the notification window, I just edit my org-mode-todo-list (switch
an item from todo to done), and the notification window will disappear
automatically in at most 60 seconds.

But when I'm idle, and once per minute a notification windows expires,
the gnus-demon won't activate my handlers, because the idle-time is
always reset, and this can be annoying.


I admit, that this use case is quite particular and I don't expect emacs
developers to fix it. Nevertheless, I'm going to fill a bug report, just
in case.

In the meanwhile, I've patched my notification-daemon, so that it does
no more send any event, when windows expire (ugly work-around, but I
don't need to touch emacs).

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

>> I was too hasty: I've copied the *Messages* buffer before the
>> notification did expire. No error at all.
>
> That means, that ":timeout 1000" did not work for you...!?

It works for me, don't worry.

>> It is not NotificationClosed specific. I would rather say that is due to
>> the nature of D-Bus events, handled via `special-event-map'. I guess that
>> all events defined in that map will reset the idle timer.
>
> Yes. It would be good, if there was a method to filter these events.
> (perhaps there is already, but I don't see it...)

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.

Then we could extend `dbus-register-signal' in order to allow setting
this property, or not. "NotificationClosed" would be registered with
this property, and "ActionInvoked" without.

> I admit, that this use case is quite particular and I don't expect emacs
> developers to fix it. Nevertheless, I'm going to fill a bug report, just
> in case.

Please do. I wouldn't call it bug but wishlist, but it might be worth to
implement. Chances are good that I will do, but I would like to discuss
first with the other developers.

Please add also your use case to the bug report.

> In the meanwhile, I've patched my notification-daemon, so that it does
> no more send any event, when windows expire (ugly work-around, but I
> don't need to touch emacs).

Wouldn't it suffice just to deregister signal "NotificationClosed"? You
don't need this signal, if I understand your use cases.

Another idea would be to send a new notification message to the opened
notification window, before it expires. I haven't tried by myself, but I
remember vaguely that it shall be possible.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Mon, Feb 13 2012, Michael Albinus wrote:

> 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.


> Please do. I wouldn't call it bug but wishlist, but it might be worth to
> implement. Chances are good that I will do, but I would like to discuss
> first with the other developers.

Ok, done.


> Wouldn't it suffice just to deregister signal "NotificationClosed"?

How? With dbus-unregister-service?

Thanks for your efforts,
-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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.

Re: notifications-notify resets idle-time

[Peter Münster]

On Tue, Feb 14 2012, Michael Albinus wrote:

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

It seems, that I rather need dbus-unregister-object, because I only want
to unregister the closed-signal, not the action-signal. So I patched
notifications.el:

--8<---------------cut here---------------start------------->8---
--- notifications.el~	2012-03-04 22:00:27.851590759 +0100
+++ notifications.el	2012-03-04 22:00:43.625016422 +0100
@@ -96,6 +96,12 @@
 This must be kept, because the notification daemon could be
 restarted, and the registered signals cannot be identified anymore.")
 
+(defvar notifications-action-signal-object nil
+  "Object of the registration of the action signal.")
+
+(defvar notifications-closed-signal-object nil
+  "Object of the registration of the closed signal.")
+
 (defun notifications-on-action-signal (id action)
   "Dispatch signals to callback functions from `notifications-on-action-map'."
   (let ((entry (assoc id notifications-on-action-map)))
@@ -106,13 +112,14 @@
       (remove entry 'notifications-on-action-map))))
 
 (when (fboundp 'dbus-register-signal)
-  (dbus-register-signal
-   :session
-   nil
-   notifications-path
-   notifications-interface
-   notifications-action-signal
-   'notifications-on-action-signal))
+  (setq notifications-action-signal-object
+        (dbus-register-signal
+         :session
+         nil
+         notifications-path
+         notifications-interface
+         notifications-action-signal
+         'notifications-on-action-signal)))
 
 (defun notifications-on-closed-signal (id &optional reason)
   "Dispatch signals to callback functions from `notifications-on-closed-map'."
@@ -128,13 +135,14 @@
       (remove entry 'notifications-on-close-map))))
 
 (when (fboundp 'dbus-register-signal)
-  (dbus-register-signal
-   :session
-   nil
-   notifications-path
-   notifications-interface
-   notifications-closed-signal
-   'notifications-on-closed-signal))
+  (setq notifications-closed-signal-object
+        (dbus-register-signal
+         :session
+         nil
+         notifications-path
+         notifications-interface
+         notifications-closed-signal
+         'notifications-on-closed-signal)))
 
 (defun notifications-notify (&rest params)
   "Send notification via D-Bus using the Freedesktop notification protocol.
--8<---------------cut here---------------end--------------->8---

And in my init.el I do now:
--8<---------------cut here---------------start------------->8---
(require 'notifications)
(dbus-unregister-object notifications-closed-signal-object)
--8<---------------cut here---------------end--------------->8---


> 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:

I understand: instead of closing the window, you replace it by another
and no event is sent to emacs. But it does not really fit my needs:
Now I use https://github.com/p-m/org-notify with a personal setup that
opens notification pop-ups once per minute with a timeout of 10 seconds
for example.

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

> It seems, that I rather need dbus-unregister-object, because I only want
> to unregister the closed-signal, not the action-signal. So I patched
> notifications.el:

Well, I've played also with notifications.el, in order to make
fine-grained signal registering. The ide was, that a new register-signal
shall be applied exactly for the signal we do expect. In general it is
possible, one could say how the arguments look like of the incoming
signals. But unfortunately, the ID argument of the
notifications-action-signal and notifications-close-signal is of type
UINT32, and using arguments for registering signals is only possible if
they are of type STRING.

So I failed.

Let's wait for Emacs 24.2. Either we will suppress resetting the idle
timer when D-Bus events arrive, or I find a way to discriminate incoming
signals also by arguments of non-STRING type.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Michael Albinus]

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

Hi Peter,

> It seems, that I rather need dbus-unregister-object, because I only want
> to unregister the closed-signal, not the action-signal. So I patched
> notifications.el:

I have generalized your patch. It is not needed anymore to call
`dbus-unregister-object' in your code.

Could you, please, check whether it fits your needs? Note that this
patch is based on notifications.el as I have committed to the trunk two
days ago,

--8<---------------cut here---------------start------------->8---
*** /home/albinus/src/emacs/lisp/notifications.el.~107516~	2012-03-06 11:18:32.000000000 +0100
--- /home/albinus/src/emacs/lisp/notifications.el	2012-03-06 11:18:32.000000000 +0100
***************
*** 88,112 ****
  (defvar notifications-on-action-map nil
    "Mapping between notification and action callback functions.")

  (defvar notifications-on-close-map nil
    "Mapping between notification and close callback functions.")

  (defun notifications-on-action-signal (id action)
    "Dispatch signals to callback functions from `notifications-on-action-map'."
    (let* ((unique-name (dbus-event-service-name last-input-event))
  	 (entry (assoc (cons unique-name id) notifications-on-action-map)))
      (when entry
        (funcall (cadr entry) id action)
!       (remove entry notifications-on-action-map))))
!
! (when (fboundp 'dbus-register-signal)
!   (dbus-register-signal
!    :session
!    nil
!    notifications-path
!    notifications-interface
!    notifications-action-signal
!    'notifications-on-action-signal))

  (defun notifications-on-closed-signal (id &optional reason)
    "Dispatch signals to callback functions from `notifications-on-closed-map'."
--- 88,113 ----
  (defvar notifications-on-action-map nil
    "Mapping between notification and action callback functions.")

+ (defvar notifications-on-action-object nil
+   "Object for registered on-action signal.")
+
  (defvar notifications-on-close-map nil
    "Mapping between notification and close callback functions.")

+ (defvar notifications-on-close-object nil
+   "Object for registered on-close signal.")
+
  (defun notifications-on-action-signal (id action)
    "Dispatch signals to callback functions from `notifications-on-action-map'."
    (let* ((unique-name (dbus-event-service-name last-input-event))
  	 (entry (assoc (cons unique-name id) notifications-on-action-map)))
      (when entry
        (funcall (cadr entry) id action)
!       (when (and (not (setq notifications-on-action-map
! 			    (remove entry notifications-on-action-map)))
! 		 notifications-on-action-object)
! 	(dbus-unregister-object notifications-on-action-object)
! 	(setq notifications-on-action-object nil)))))

  (defun notifications-on-closed-signal (id &optional reason)
    "Dispatch signals to callback functions from `notifications-on-closed-map'."
***************
*** 118,133 ****
      (when entry
        (funcall (cadr entry)
  	       id (cadr (assoc reason notifications-closed-reason)))
!       (remove entry notifications-on-close-map))))
!
! (when (fboundp 'dbus-register-signal)
!   (dbus-register-signal
!    :session
!    nil
!    notifications-path
!    notifications-interface
!    notifications-closed-signal
!    'notifications-on-closed-signal))

  (defun notifications-notify (&rest params)
    "Send notification via D-Bus using the Freedesktop notification protocol.
--- 119,129 ----
      (when entry
        (funcall (cadr entry)
  	       id (cadr (assoc reason notifications-closed-reason)))
!       (when (and (not (setq notifications-on-close-map
! 			    (remove entry notifications-on-close-map)))
! 		 notifications-on-close-object)
! 	(dbus-unregister-object notifications-on-close-object)
! 	(setq notifications-on-close-object nil)))))

  (defun notifications-notify (&rest params)
    "Send notification via D-Bus using the Freedesktop notification protocol.
***************
*** 287,296 ****
  	  (unique-name (dbus-get-name-owner :session notifications-service)))
        (when on-action
          (add-to-list 'notifications-on-action-map
! 		     (list (cons unique-name id) on-action)))
        (when on-close
          (add-to-list 'notifications-on-close-map
! 		     (list (cons unique-name id) on-close))))

      ;; Return notification id
      id))
--- 283,311 ----
  	  (unique-name (dbus-get-name-owner :session notifications-service)))
        (when on-action
          (add-to-list 'notifications-on-action-map
! 		     (list (cons unique-name id) on-action))
! 	(unless notifications-on-action-object
! 	  (setq notifications-on-action-object
! 		(dbus-register-signal
! 		 :session
! 		 nil
! 		 notifications-path
! 		 notifications-interface
! 		 notifications-action-signal
! 		 'notifications-on-action-signal))))
!
        (when on-close
          (add-to-list 'notifications-on-close-map
! 		     (list (cons unique-name id) on-close))
! 	(unless notifications-on-close-object
! 	  (setq notifications-on-close-object
! 		(dbus-register-signal
! 		 :session
! 		 nil
! 		 notifications-path
! 		 notifications-interface
! 		 notifications-closed-signal
! 		 'notifications-on-closed-signal)))))

      ;; Return notification id
      id))
--8<---------------cut here---------------end--------------->8---

If that works for you, I would be willing to commit it to the trunk,
still for Emacs 24.1. We could close then also bug#10807.

Best regards, Michael.

Re: notifications-notify resets idle-time

[Peter Münster]

On Tue, Mar 06 2012, Michael Albinus wrote:

> Could you, please, check whether it fits your needs?

Yes, it does! Very fine, thanks!


> If that works for you,

Yes, it works.


> I would be willing to commit it to the trunk, still for Emacs 24.1. We
> could close then also bug#10807.

Yes, I agree.

-- 
           Peter

Re: notifications-notify resets idle-time

[Michael Albinus]

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

>> I would be willing to commit it to the trunk, still for Emacs 24.1. We
>> could close then also bug#10807.
>
> Yes, I agree.

Done.

Best regards, Michael.