Liferea shouldn't include actions if notification server doesn't accept them

Bug #328606 reported by David Barth
12
Affects Status Importance Assigned to Milestone
liferea (Ubuntu)
Fix Released
Low
Emilio Pozuelo Monfort

Bug Description

When Liferea shows notifications for feeds with new items (the “Show a popup window with new headlines.” option, which is on by default), the notifications are sent with “Open Feed”, “Mark all as read”, and “Show details” actions regardless of whether the notification server advertises that it accepts actions.

The actions should be made conditional on whether the notification server advertises that it accepts actions.

Related branches

Revision history for this message
Alexander Sack (asac) wrote :

You have filed two bugs here:
 1. remove actions if notification daemon doesnt have the capability
 2. redesign liferea notification concept

please file a new bug for 2 and maybe remove those parts from this bug description.

Lets keep this bug for 1. (action removal).

Also, do you have a wiki page or something describing how to probe for the action capability using the most common apis/programming languages? If you have, please provide that info in your bugs.

Thanks!

Changed in liferea:
status: New → Incomplete
Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

I'll take care of this

Changed in liferea:
importance: Undecided → Low
status: Incomplete → Triaged
Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

I mean, I'll take care of "remove actions if notification daemon doesnt have the capability"

Changed in liferea:
assignee: nobody → pochu
Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

I've just fixed it upstream with the attached patch.

http://liferea.svn.sourceforge.net/viewvc/liferea?view=rev&revision=4468

description: updated
Revision history for this message
Chow Loong Jin (hyperair) wrote :

Looking at the patch, doesn't it only check for actions when starting up? What happens in the notification daemon was changed after startup? Perhaps killing notify-osd and starting notification-daemon or vice versa.

Revision history for this message
Ken VanDine (ken-vandine) wrote :

I think this is fine, switching notification daemons requires a logout and back in anyway (I think).

Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 328606] Re: Liferea shouldn't include actions if notification server doesn't accept them

On Thu, 2009-02-26 at 19:53 +0000, Ken VanDine wrote:
> I think this is fine, switching notification daemons requires a logout
> and back in anyway (I think).
>
No it doesn't. Just kill the existing one, and the one specified
by /usr/share/dbus-1/services/org.freedesktop.Notifications.service will
spawn the next time a notification appears.
--
Chow Loong Jin

Revision history for this message
Vadim Peretokin (vperetokin) wrote :

The example code here: https://wiki.ubuntu.com/NotificationDevelopmentGuidelines#Layout%20cases%20(with%20examples%20in%20C,%20Python%20and%20C#) checks each time before using the capability. Makes the desktop experience more robust too - nobody wants to restart their session when they shouldn't have to...

Revision history for this message
Ted Gould (ted) wrote :

Checking capabilities requires a round trip on DBus. Which could be delayed by the notification daemon being busy. It definitely will be if everyone check capabilities all the time. For the number of times that people change notification daemons, I think it's better to check once.

The correct way to implement it would be to attach the name owner and then handle the case where the name owner is destroyed as it drops off the bus. But, those patches would get rather large. Again, I think this is a pretty minor usecase.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Fri, 2009-02-27 at 18:37 +0000, Ted Gould wrote:
> Checking capabilities requires a round trip on DBus. Which could be
> delayed by the notification daemon being busy. It definitely will be if
> everyone check capabilities all the time. For the number of times that
> people change notification daemons, I think it's better to check once.
>
> The correct way to implement it would be to attach the name owner and
> then handle the case where the name owner is destroyed as it drops off
> the bus. But, those patches would get rather large. Again, I think
> this is a pretty minor usecase.
>
By "busy" you mean that it has hung, don't you? I highly doubt you could
spam notify-osd (or any other notification daemon) enough to make it
hang.
--
Chow Loong Jin

Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

Hi folks,

My current patch has the downside that, if there's no notification daemon available, notify_get_server_caps() will spit a warning that it couldn't connect to DBus:

"libnotify-Message: GetCapabilities call failed: The name org.freedesktop.Notifications was not provided by any .service files"

The message comes from libnotify itself:
g_message("GetCapabilities call failed: %s", error->message);

Is there something I can do to avoid that? Or should libnotify not log those messages at all?

Changed in liferea:
assignee: pochu → nobody
Revision history for this message
Cody Russell (bratsche) wrote :

I think the patch is fine, but it should be generated with -p1 I think.

Changed in liferea:
assignee: nobody → pochu
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package liferea - 1.4.26-0ubuntu1

---------------
liferea (1.4.26-0ubuntu1) jaunty; urgency=low

  * New upstream bugfix release (lp: #325750).
    - debian/patches/90_autoreconf: refreshed.
  * debian/patches/notification_check_for_actions_support:
    - New patch backported from upstream r4468, check for actions support
      in notifications before using them (lp: #328606).

 -- Emilio Pozuelo Monfort <email address hidden> Tue, 10 Mar 2009 23:47:50 +0100

Changed in liferea:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.