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

[Michael Albinus]

Peter Münster <pml...@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.

[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

[Michael Albinus]

Peter Münster <pml...@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.

[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

[Michael Albinus]

Peter Münster <pml...@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.

[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

[Michael Albinus]

Peter Münster <pml...@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.

[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

[Michael Albinus]

Peter Münster <pml...@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.

[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

[Michael Albinus]

Peter Münster <pml...@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.

[Peter Münster]

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

[Michael Albinus]

Peter Münster <pml...@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

[Michael Albinus]

Peter Münster <pml...@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.

[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

[Michael Albinus]

Peter Münster <pml...@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.

[Stefan Monnier]

A looming question is "what is meant by idle?".
Is it "the time Emacs was idle" or "the time since the user last
interacted with Emacs"?
Having a current-idle-time seems to imply the second definition (since
Emacs is clearly not idle while running this function), but other parts
of the design point to the first definition.
I wouldn't be surprised if Emacs's design in this regard is confused.


Stefan

[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

[Michael Albinus]

Peter Münster <pml...@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.