emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add notifications.el


From: Jan Moringen
Subject: Re: [PATCH] Add notifications.el
Date: Fri, 11 Jun 2010 11:27:03 +0200

> > Maybe it's a bug in the notification daemon? It happened for every
> > notification I produced from Emacs on this machine. The notifications
> > also varied significantly. So in case of an error it wouldn't exactly be
> > a corner case which makes this possibility seem unlikely.
> 
> Does it happend with the ones made from notify-send?

I don't have notify-send on this system, but here is an example where
evolution caused the notification:

method call sender=:1.764 -> dest=org.freedesktop.Notifications
path=/org/freedesktop/Notifications;
interface=org.freedesktop.Notifications; member=Notify
   string "evolution-mail-notification"
   uint32 0
   string "mail-unread"
   string "New email"
   string "You have received 1 new message
in Inbox."
   array [
   ]
   array [
      dict entry(
         string "y"
         variant             int32 1188
      )
      dict entry(
         string "xdisplay"
         variant             string ":0.0"
      )
      dict entry(
         string "urgency"
         variant             byte 1
      )
      dict entry(
         string "x"
         variant             int32 1313
      )
   ]
   int32 -1
method return sender=:1.19 -> dest=:1.764 reply_serial=1011
   uint32 258
signal sender=:1.19 -> dest=:1.764 path=/org/freedesktop/Notifications;
interface=org.freedesktop.Notifications; member=NotificationClosed
   uint32 258

The NotificationClosed signal has no reason, just like with Emacs.

> Anyhow, nothing allows you to work-around the bug by putting reason
> &optional. Anybody can emit a wrong formatted signal on the dbus, even
> with dbus-send. Based on that, any D-Bus bad formatted signal/method
> call will raise an error.
> 
> Bad that's like calling a Lisp function with requires 2 arguments with
> only 1. It raises an error because you call it badly. I don't see why we
> wouldn't do the thing even if the function is called via D-Bus.
> 
> But yes if, you don't want to know about bugged implementation, you use
> &optional in every dbus signal/method function you will use (even
> outside notifications.el).

I agree, working around other people's bugs is undesirable. However,
since this system is a Ubuntu LTS version, the problem could potentially
affect many users.

Kind regards,
Jan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]