bug#10807: 24.0.93; dbus NotificationClosed signal should not reset idle-time when reason=1

bug#10807: 24.0.93; dbus NotificationClosed signal should not reset idle-time when reason=1

[Peter Münster]

Hello,

The current idle-time is reset to 0, when a notification window expires.
IMO it should not, or it should be configurable.

Discussion on usenet:
http://thread.gmane.org/gmane.emacs.help/83685

Test file:
; save file in /tmp/test.el and run "emacs -Q -l /tmp/test.el"
(require 'notifications)
(notifications-notify :timeout 1000)
(defun my-test ()
  (let ((it (current-idle-time)))
    (message "idle time = %f"
             (if it
                 (+ (cadr it) (/ (nth 2 it) 1000000.0))
               0))))
(run-with-timer 1.5 nil 'my-test)

Result:              idle time = about 0.5
Expected result:     idle time = about 1.5

Use case, where resetting the idle-time to 0 is annoying:

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.

-- 
           Peter

bug#10807: 24.0.93; dbus NotificationClosed signal should not reset idle-time when reason=1

[Michael Albinus]

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

> Hello,

Hi,

> The current idle-time is reset to 0, when a notification window expires.
> IMO it should not, or it should be configurable.

notifications.el uses D-Bus for communication. Incoming D-Bus events,
like the NotificationClosed signal, are handled via `special-event-map'.

In keyboard.c, the idle-time is reset for every incoming event. This is
useful for keyboard or mouse events, but it might not be desired for
D-Bus events. As a solution, one could change keyboard.c such a way,
that D-Bus events do not result in a reset of idle-time.

OTOH, for some D-Bus it might be desirable to reset the idle-time.
Roughly spoken, D-Bus signals should not reset idle-time, and D-Bus
method-return events should. This could be made configurable.

And there might be also other events handled via `special-event-map',
which should not reset idle-time when arriving. A candidate could be
`config-changed-event'. In order to achieve this, "struct input_event"
could be extended by a field "reset_idle_time", which is TRUE by
default. Events which shall not reset the idle-time set this to FALSE.

Best regards, Michael.

bug#10807: 24.0.93; dbus NotificationClosed signal should not reset idle-time when reason=1

[Michael Albinus]

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

> Hello,

Hi,

> The current idle-time is reset to 0, when a notification window expires.
> IMO it should not, or it should be configurable.

I have modified notifications.el such a way, that the corresponding
signal handler is registered only in case :on-close has passed as
argument to `notifications-notify'. This shall avoid superfluous arrival
of signals, which generates D-Bus events.

Best regards, Michael.