only launch notify-osd for GNOME session

Bug #338279 reported by Scott Kitterman on 2009-03-05
12
Affects Status Importance Assigned to Milestone
notify-osd (Ubuntu)
Medium
Martin Pitt
Jaunty
Medium
Martin Pitt

Bug Description

If a user has both (for example) ubuntu-desktop and kubuntu-desktop installed they will have notify-osd, but if they are running in kubuntu-desktop they will not have a messaging indicator. It would be useful is notify-osd would provide old style notifications in this condition so that users would not have to remove it to get effective notifications.

On Thu, 2009-03-05 at 22:53 +0000, Launchpad Bug Tracker wrote:
> If a user has both (for example) ubuntu-desktop and kubuntu-desktop
> installed they will have notify-osd, but if they are running in kubuntu-
> desktop they will not have a messaging indicator. It would be useful is
> notify-osd would provide old style notifications in this condition so
> that users would not have to remove it to get effective notifications.

Considering that notify-osd doesn't share any code with the older
notification daemon "falling back" isn't really an option. Adding the
rendering into notify-osd would be a major undertaking, and unreasonable
to do after Feature Freeze. (even if we did it I would have to lie on
the FFe to get it accepted) Also, for the amount of work, I think it
would be more reasonable to build a messaging indicator for KDE. But,
again that's not going to be available for Jaunty.

So, I'm trying to think of what we could do for Jaunty to solve this
problem. I'm not sure how to implement this, I'm hoping someone with
packaging expertise can help.

What I think would be interesting is if someone installed
kubuntu-dekstop the old notification daemon got installed, but with a
desktop file that had Show-Only-In:KDE and we could set the notify-osd
one to only show in GNOME. Could that work?

I'm not sure how that would work. It's unfortunate the impact of these
changes on other flavors was not considered up in the design process.

None of this design has been accepted as appropriate for Kubuntu, so making
assumptions that it will is premature.

On Fri, 2009-03-06 at 16:05 +0000, Scott Kitterman wrote:
> I'm not sure how that would work. It's unfortunate the impact of these
> changes on other flavors was not considered up in the design process.

That is a blanket statement that you have no evidence to support and I
think that you should consider retracting it.

Continuing on-topic...

Pitti has made it so that the notification desktop file will launch
either the older notification-daemon or notify-osd depending on whether
or not one is using the standard Ubuntu desktop or the Vanilla GNOME
desktop. We should be able to add KDE to this case statement as a
better solution to the one that I proposed above.

Subscribing Martin. Martin does this sound reasonable to you?

Ted Gould [2009-03-07 13:32 -0000]:
> Martin does this sound reasonable to you?

Yes. This could either happen by adding another test, or by entirely
inverting it. The latter might be better if the new notify-osd is
really depending on gnome and the messaging indicator. Such as

 Exec=/bin/sh -c "if [ $GDMSESSION = gnome ]; then exec /usr/lib/notify-osd/notify-osd; else exec /usr/lib/notification-daemon/notification-daemon; fi

...... Original Message .......
On Sat, 07 Mar 2009 13:32:28 -0000 Ted Gould <email address hidden> wrote:
...
>That is a blanket statement that you have no evidence to support and I
>think that you should consider retracting it.
>
Agreed. It was over the top. My aplogies.

Scott Kitterman (kitterman) wrote :

On Sat, 07 Mar 2009 13:32:28 -0000 Ted Gould <email address hidden> wrote:

>Pitti has made it so that the notification desktop file will launch
>either the older notification-daemon or notify-osd depending on whether
>or not one is using the standard Ubuntu desktop or the Vanilla GNOME
>desktop. We should be able to add KDE to this case statement as a
>better solution to the one that I proposed above.
>
That sounds reasonable. I think this same issue applies to Xubuntu too.

Martin: I'm using GNOME here and $GDMSESSION's value is "default", so that won't work.

Siegfried Gevatter (RainCT) [2009-03-07 16:43 -0000]:
> Martin: I'm using GNOME here and $GDMSESSION's value is "default", so
> that won't work.

Right, in Ubuntu we need to treat "default" as

  [ $(basename `readlink /etc/alternatives/x-session-manager`) = gnome-session ]

Scott Kitterman wrote:
> I think this same issue applies to Xubuntu too.
>
Cody, do you know if anyone is looking into providing a libindicate
panel item for Xubuntu? That would ease integration of notify-osd if you
want it. Alternatively, look into how the gnome-strachiatella-session
pieces are fitting together and perhaps Pitti could help you adopt that
approach for Xubuntu.

Cheers,
Mark

Hi Mark,

On Sun, Mar 8, 2009, Mark Shuttleworth wrote:

> Scott Kitterman wrote:
>
> I think this same issue applies to Xubuntu too.
>
>
> Cody, do you know if anyone is looking into providing a libindicate panel
> item for Xubuntu? That would ease integration of notify-osd if you want it.
> Alternatively, look into how the gnome-strachiatella-session pieces are
> fitting together and perhaps Pitti could help you adopt that approach for
> Xubuntu.
>

Unfortunately, we won't be able to invest in developing a libindicate panel
item for Xubuntu Jaunty, nor allocate the necessary testing needed to
hapilly switch to notify-osd this late in the cycle, due to our limited man
power and major changes required for our move to Xfce 4.6 from 4.4. However,
I imagine the Xubuntu team and upstream Xfce developers will be very
interested in further examining notify-osd at UDS Karmic for possible
inclusion early in the karmic release cycle.

Naturally, we're eager to see if notify-osd finally irons out some of the
longstanding memory leak issues that have historically plagued the original
notification-daemon.

>
>
> Cheers,
> Mark
>
>
Cheers,

--
Cody A.W. Somerville
Software Systems Release Engineer
Foundations Team
Custom Engineering Solutions Group
Canonical OEM Services
Phone: +1-781-850-2087
Cell: +1-506-471-8402
Email: <email address hidden>

Ok, thanks for discussing the solution. We're going to implement the test in the service launcher file the way pitti described it.

As for Xubuntu or (other flavor) support, I think it deserves a separate bug report to capture the request.

Changed in notify-osd:
assignee: nobody → dbarth
status: New → Triaged
importance: Undecided → Medium

This should be handled by the session startup processes. Notify-OSD
won't implement two different approaches.

 status wontfix

I'm glad you're taking care of this. I don't understand why the design
case is not the same for any flavor that does not provide the new design?
A new bug just seems like extra paperwork. What would be different about
Xubuntu?

Changed in notify-osd:
status: Triaged → Won't Fix
Martin Pitt (pitti) wrote :

While the upstream wontfix is justified (upstream notify-osd shouldn't know about these issues), we need to update the dbus service check in the Ubuntu package. I'll see to this.

Changed in notify-osd (Ubuntu):
assignee: nobody → pitti
status: New → In Progress
Changed in notify-osd (Ubuntu):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package notify-osd - 0.9.10-0ubuntu2

---------------
notify-osd (0.9.10-0ubuntu2) jaunty; urgency=low

  * data/org.freedesktop.Notifications.service.in: Only run notify-osd on
    GNOME sessions; if you have both Kubuntu and Ubuntu installed, Kubuntu
    shouldn't get notify-osd. (LP: #338279)

 -- Martin Pitt <email address hidden> Wed, 08 Apr 2009 22:26:26 -0700

Changed in notify-osd (Ubuntu Jaunty):
status: In Progress → Fix Released
no longer affects: notify-osd
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers