Closed Bug 404738 Opened 17 years ago Closed 12 years ago

Use dbus notification daemon to show alerts/notifications on the desktop

Categories

(Firefox :: Shell Integration, defect)

Product:
Firefox
Component:
Shell Integration
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: whimboo, Assigned: caillon)

References

(
URL
)

Details

(Keywords: mobile)

Attachments

(1 file, 1 obsolete file)

Potential look of Galago notifications.
5.49 KB, image/png
Details 
Due to D-Bus is now enabled by default (bug 388743) for trunk builds we should add support for DBusMessage. This will give us the opportunity to send system wide notifications (like with Growl on OS X) which can inform the user about ongoing actions or status messages

I'll file follow-up bugs for the download manager (finished downloads) and the auto-update notification.

Because there is no OSIntegration component in Core I have to file this bug under Firefox.
As example Amarok already is using this way to show the track currently started playing:

http://upload.wikimedia.org/wikipedia/commons/e/eb/AmaroK_stable.png
As I read, there is a difference between per-user and system wide daemons. Firefox will be a client which connects to a per-user daemon, right? Updating summary.
Summary: Use DBusMessage to send system wide notifications → Implement DBusMessage to send messages over per-user daemon
Growl on OS X is exposed in Gecko using the nsIAlertsService API. Is "DBusMessage" something that could replace our current "custom" linux implementation of that interface?
So nsIAlertsService is only used for OS X at the moment? What API do we use to display alerts on Windows? Is there something?

But anyway, I'm not too familar with dbus. We only had a discussion on IRC yesterday about the topic of displaying notifications or alerts. Due to we are using dbus on trunk now I think it would be a good idea to have a wrapper component for DBusMessage on Linux. But we should ask someone with more knowledge. 
No, nsIAlertsService is implemented on Mac, Windows, and Linux. For Mac it uses Growl, for Linux and Windows it uses a Gecko window that slides up. I was just wondering whether we could change the Linux implementation to use DbusMessage - though even if that would theoretically work requiring DbusMessage might not be feasible.
I searched the web and found some nice articles and specs about using dbus. I think the following URL could be the way of using the notification daemon to display any notification or alert on the desktop:

http://www.galago-project.org/specs/notification/0.9/index.html

How is it handled on OS X if Growl is not installed on the system? Do we have an alternated way? Is the normal AlertService used instead? I ask because it would be similar to this implementation.
URL: http://dbus.freedesktop.org/doc/dbus/... → http://www.galago-project.org/specs/n...
Summary: Implement DBusMessage to send messages over per-user daemon → Use dbus notification daemon to show alerts/notifications on the desktop
This was generated using dbus-python and a Firefox icon to simulate how a Firefox notification could look if it was sent through dbus to Galago's libnotify/notification-daemon.
Currently, the main problem (probably) is that the DBus service in the tree only allows for a single client, and currently that's the NetworkManagerListener (to toggle offline mode automatically). So work needs to be done to extend the DBus service to handle multiple clients before it can conceivably be used for notifications. Perhaps that's a 2-hour job if you're a ninja like roc (the original implementer of the DBus service), I don't know.

(For Mozilla/DBus desktop integration in general, there is/was a Google SoC project called DBuzilla, but it seems abandoned and was separate from the main project to begin with. In the future it would be conceivable to expose interesting parts of Firefox through DBus: the download manager, Places and such. But that's another bug entirely.)
Assignee: nobody → caillon
We can use notify-send instead of direct DBus connection :> .
But DBus is better though as we can connect to ActionInvoked so we know when the user clicks on an action button.  Which is what I'm doing and should have a patch this weekend.
Status: NEW → ASSIGNED
This bug should be dupe of bug #402934, but there were no action.
Hm, so there's a semi problem here, actually...  Our alerts APIs expect to treat clicks on the actual notification as "action clicks", but the fd.o spec (and of course libnotify) treat that as a dismissal.

So, at this point we either need to change the way moz does notifications (which probably means changing strings and thus is not feasible right now), or get the spec changed and patch the notification library (which means this probably won't work on anything except the latest greatest distro)...


(In reply to comment #13)
> So, at this point we either need to change the way moz does notifications
> (which probably means changing strings and thus is not feasible right now), or

Axel, when is the final deadline for string changes?
Deadline for string changes was last week.

Whether we break that for this depends on the amount of changes and the benefit of the change. The later this comes in, the smaller are its chances.

At this point, string changes are not the only argument against landing patches, too, but I have no idea what the regression risk is, what the current load of reviewers would be and all that.
Blocks: 415417
No longer blocks: 415417
Blocks: 415419
Bug 388743 is fixed, so the work can be continued, I think.
This bug was created after that bug was fixed, it is even referenced as being fixed in the first comment
It's like fitting a triangle into a square hole, here.  In order to do this we need to change the way notification-daemon works or we need to change the way mozilla's notifications work.  They just expect different things at this point.  Which is frustrating because they are similar.
(In reply to comment #13)
> Hm, so there's a semi problem here, actually...  Our alerts APIs expect to
> treat clicks on the actual notification as "action clicks", but the fd.o spec
> (and of course libnotify) treat that as a dismissal.

Is that necessarily a problem? If org.freedesktop.Notifications constitutes the "default behavior" for notifications on Linux, then one could argue that Firefox is currently equipped with the wrong user interface (vis-à-vis platform integration).

Of course, mapping the textClickable argument for showAlertNotification() to whether the text argument is an action or not may not always be pretty, but it's certainly possible. 
fd.o is "dismissed". See Gajim for example. Since notification provides "close" button, clicking doesn't dismiss the notification, but triggers action, and this is exactly what users expect.

fd.o isn't an organisation which always is right.
(In reply to comment #13)
> Hm, so there's a semi problem here, actually...  Our alerts APIs expect to
> treat clicks on the actual notification as "action clicks", but the fd.o spec
> (and of course libnotify) treat that as a dismissal.
> 
> So, at this point we either need to change the way moz does notifications
> (which probably means changing strings and thus is not feasible right now), or
> get the spec changed and patch the notification library (which means this
> probably won't work on anything except the latest greatest distro)...

I'm not sure what the problem is, exactly. So clicking on libnotify's alert just dismisses it and there's no way to perform an "action click"?

If that's the problem, why is it considered a big problem? Because the notification strings imply you can click on the notification to make something happen? What's an example of that?

(In reply to comment #8)
> Currently, the main problem (probably) is that the DBus service in the tree
> only allows for a single client, and currently that's the
> NetworkManagerListener (to toggle offline mode automatically). So work needs to
> be done to extend the DBus service to handle multiple clients before it can
> conceivably be used for notifications.

It's easy enough to bang in another hardcoded DBus client there. It was designed to make that easy.
(In reply to comment #22)
> fd.o is "dismissed". See Gajim for example. Since notification provides "close"
> button, clicking doesn't dismiss the notification, but triggers action, and
> this is exactly what users expect.
> 
> fd.o isn't an organisation which always is right.

Clicking _should_ dismiss the notification. It's the way other libnotify notifications behave, and we should aim to fit into the desktop environment as well as possible -- not simply try and emulate Growl or whatever.

Notice the cool new GTK+ integration features in Firefox 3.0? We should let that continue to libnotify.

The normal way for a user to initiate action from a libnotify dialog is to add a button to the balloon. See screenshot of a PackageKit notification for example:

http://www.packagekit.org/img/gpk-updates-warning.png

Clicking on the text in that example will dismiss the balloon, but clicking on the buttons will initiate action.

This is the preferred behaviour.
(In reply to comment #21)
> Of course, mapping the textClickable argument for showAlertNotification() to
> whether the text argument is an action or not may not always be pretty, but
> it's certainly possible. 

Yeah.
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/public/nsIAlertsService.idl
Seems like if textIsClickable is true, we can just put the entire text in a button. Otherwise we leave the text as-is. A bit ugly, but comports with the current interface.
Jeremy, test yourself what's comfortable, esp. in instant messenger - targeting into BIG notication or into LITTLE button?

And about "cool new GTK+ integration feature in Firefox 3.0" - I noticed nothing special...
(In reply to comment #27)
> Jeremy, test yourself what's comfortable, esp. in instant messenger - targeting
> into BIG notication or into LITTLE button?

Every desktop environment has its own interface culture and, simply, "the way things are done". They are done in that way for no apparent reason, other than that is the way it is "done" in that environment.

GNOME is no different. It has an established user interface with conventions and traditions. Do not dismiss these traditions simply on the grounds of personal preferences.

> And about "cool new GTK+ integration feature in Firefox 3.0" - I noticed
> nothing special...

Which brings me to this. Firefox 3.0 introduced much better support for GTK+ themes. Have you noticed that Firefox now has GTK+ stock icon support? Out-of-the-box, I have Tango icons that perfectly integrate with my GNOME theme.

XUL menus are now pixel-perfect with native GTK+ menus. Tabs are pixel-perfect, too. Even when using the latest Clearlooks theme, the ugly dotted selection rectangle is hidden, just as with native GTK+ apps. It now even uses the native GNOME print dialog when printing. You couldn't ask for more, could you? :)

This represented a great focus shift for Mozilla: that a familiar look and feel gains more new friends. I used to despise Firefox on Linux, because it didn't look, feel, and work like a GNOME application. Now, Epiphany has a serious run for its money.

The libnotify issue is like that. We should strive to fit in with the desktop.

If every GNOME developer designed their user interfaces according to his (or her) own personal tastes, GNOME would be the most lagubrious hodgepodge of soup ever created.

Global Mac menu with transparent toolbars on windows with pixel UI fonts with lolcats with landscape wallpapers (with GNOME logos pointlessly slapped on top) with glossy icons with inconsistent menu labelling with Mac-style dock launch with desktop icons to launch applications as well.

Is that the GNOME we know? No! It is beautiful and consistent. I may not agree with every decision they have made ("Preferences menu in Edit menu? What the heck?"), but what touches me is the special effort the developers have made to apply the unique and special GNOME culture all over.
Thanks probably not good place for discussion...

> Every desktop environment has its own interface culture and, simply, "the way
> things are done". They are done in that way for no apparent reason, other than
> that is the way it is "done" in that environment.
>
> GNOME is no different. It has an established user interface with conventions
> and traditions. Do not dismiss these traditions simply on the grounds of
> personal preferences.

Notifications specs were done by fd.o people and they're know from being frequently not right. I don't know who introdoced "dismiss by default". It's app-specific, not to being specified anywhere... 

For example "low battery" you probably want to dismiss, but notification from e-mail checker or instant messenger you want to do something when clicked.

> Which brings me to this. Firefox 3.0 introduced much better support for GTK+
> themes. Have you noticed that Firefox now has GTK+ stock icon support?
> Out-of-the-box, I have Tango icons that perfectly integrate with my GNOME
> theme.

Oh, forgot. That's so natural that it should this, so I forgot.

> XUL menus are now pixel-perfect with native GTK+ menus. Tabs are pixel-
> perfect, too. Even when using the latest Clearlooks theme, the ugly dotted 
> selection rectangle is hidden, just as with native GTK+ apps. It now even 
> uses the native GNOME print dialog when printing. You couldn't ask for more, 
> could you? :)

Tabs are not so pixel perfect as you might think. Minor bug is present (like bug 412436 and more, reported by me, of course).

> This represented a great focus shift for Mozilla: that a familiar look and 
> feel gains more new friends. I used to despise Firefox on Linux, because it 
> didn't look, feel, and work like a GNOME application. Now, Epiphany has a 
> serious run for its money.

Epiphany is doing some things better than Firefox - it starts faster, its history loads faster and when user wants to delete some history, it's done quick. However, Epiphany has no dropdown button in location bar and that's what I dislike in Epi. Another problem are extensions. No XPI support because of mixed UI (GTK+XUL) etc.

> The libnotify issue is like that. We should strive to fit in with the desktop.

I think that spec in fd.o should be a little modified to suite user needs. I'm not the only one who wants notification from IM/browser to do something, be sure ;) .

> If every GNOME developer designed their user interfaces according to his (or
> her) own personal tastes, GNOME would be the most lagubrious hodgepodge of 
> soup ever created.

But, isn't it? Many things are done "because developer wanted to suite his needs", not "because users requested". Many things are ignored. Especially in big projects, where many bugs and requests are filed.

> Global Mac menu with transparent toolbars on windows with pixel UI fonts with
> lolcats with landscape wallpapers (with GNOME logos pointlessly slapped on 
> top) with glossy icons with inconsistent menu labelling with Mac-style dock 
> launch with desktop icons to launch applications as well.
> 
> Is that the GNOME we know? No! It is beautiful and consistent. I may not agree
> with every decision they have made ("Preferences menu in Edit menu? What the
> heck?"), but what touches me is the special effort the developers have made to
> apply the unique and special GNOME culture all over.

Many things done by GNOME I find very good - Preferences are not Tools, but something to be edited. Same for button placement in dialogs - my mouse is usually near right window border. That's independent from me ;) .



I hope some smart people in fd.o will think more about users and their needs than on technological things.
maemo also uses DBus to display status updates, so this would be useful for mobile
Keywords: mobile
Attached patch Use libnotify (obsolete) — — Splinter Review 
At UDS Jaunty they discussed plans to remove the notification action callback functionality completely (as well as really sex up the notification popups). This makes it quite suitable for our own use considering the callbacks for the current alerts are redundant actions.

As for mobile, I saw libnotify installed on the Maemo system under /usr/lib (if you look at the terminal).
Attachment #353271 - Flags: superreview?(roc)
Attachment #353271 - Flags: review?(roc)
Comment on attachment 353271 [details] [diff] [review]
Use libnotify

roc told me to file a new bug as this won't immediately give mobile support.
Attachment #353271 - Attachment is obsolete: true
Attachment #353271 - Flags: superreview?(roc)
Attachment #353271 - Flags: review?(roc)
Depends on: 469880
No longer blocks: 415419
So is this a duplicate of bug 469880? If not, what's left to do?
No longer blocks: 697382
Could someone explain what's the situation of notifications under Linux? Is there something else to work on?
We're going to use nsIAlertsService to give users feedback after a webapp successful installation (see bug 755934).
The libnotify implementation is a problem due to issues described in bug 750141.
It sometimes works, probably quite well for distro-compiled builds.
Depends on: 750141
Bug 783765 landed, so we won't need this.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: