Closed Bug 478463 Opened 11 years ago Closed 10 years ago
Add libnotify (+ libindicate) support to Thunderbird
Similar to how we use Growl on Mac, we should be using libnotify on Linux for notifications. There is now libnotify support in toolkit, so this is much easier than it would have been before.
xref bug 469880 which added it to firefox
Hardware: x86 → All
Adding this demo of notifications from Shuttleworth's blog, see URL above.
This patch uses LIBNOTIFY by default to show notifications.
(In reply to comment #3) > Created an attachment (id=363937) [details] > Libnotify Support > > This patch uses LIBNOTIFY by default to show notifications. I haven't looked at this in detail yet. My immediate question is given the code you are removing, what happens if libnotify isn't installed?
Assignee: nobody → chinmay_patel
Status: NEW → ASSIGNED
Notification Looks like this image, when Libnotify is installed and enabled.
Notification looks like this image when Libnotify is not installed in the machine.
I have checked that this patch works fine when Libnotify is not installed in the machine. The only issue with this patch is that it shows libnotify notifications only with trunk build, not with 1.9.1 branch. In the trunk there is a check at line http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/src/nsAlertsService.cpp#78 available. It checks wether Libnotify is available or not. If it there, use Libnotify notifications. But this check is not available in the 1.9.1 branch. I have checked the patch with latest mozilla trunk and it worked pretty well.
IMO, this patch is not enough for thunderbird. The new notification system involves improvement to the notification bubbles, but since it removes the ability to use actions, it is supposed to go in together with a more stateful indicator for message notifications: libindicate. Just this patch would be a regression, as it a) doesn't support accumulated notifications (e.g. notify more than one new message) and b) libnotify implementation on trunk doesn't provide actions - which is why we didn't pull this to 1.9.1 branch yet; and c) notification daemon in ubuntu will not have action support. The complete approach would be: 1. design a toolkit interface for abstract messaging notifications 2. implement a default implementation that is xul based (in xulrunner) 3. implement libindicate/libnotify support which is used if both are available on the system (in xulrunner) 4. make thunderbird (and other messagin/chat apps based on xulrunner) use new messaging notification component.
Since Ventnor is responsible for the toolkit code, I think his thoughts would be helpful here. Adding him to the CC.
So how is libindicate different from libnotify exactly? I can't find any API documentation on libindicate.
Comment on attachment 364831 [details] [diff] [review] Adding Libnotify Support Based on comments 8 and 10, this seems a little early. If I understand "action" correctly, as being able to click on the alert and Thunderbird will come up, then loosing that certainly isn't acceptable. Additionally, as there isn't libnotify support on 1.9.1 branch, I expect we'd either want to ifdef MOZILLA_1_9_1_BRANCH or hold off a month or two until we do a formal comm-central branch if its going to regress functionality. If I've understood wrong, feel free to re-request review.
No its allright. We don't want this patch without libindicate support in thunderbird/messaging. Maybe some background on libindicate. In short libindicate is supposed to answer the frequently asked question: "What to do with notifications where actions are valid use case". So, the canonical design team found that there are a few use cases where actions in notification make sense. One is messaging notifications. However, they found that actions in notifications are only one possible answer and that one should rather use a more stateful messaging indicator on the desktop. This is why ubuntu now ships a messaging indicator on the gnome-panel by default; apps like evolution and pidgin add their messages there. Similarly, the idea would be that thunderbird adds its messages there. ... chatzilla too or other xulapps that want to provide messaging. To make the transition smooth, we could make that toolkit component sensitive on whether the right facilities are available on the desktop or otherwise fallback to actionful notifications. Oh, I will provide more info on the libindicate API details once we have them. so stay tuned.
Assignee: chinmay_patel → nobody
Status: ASSIGNED → NEW
Summary: Add libnotify support to Thunderbird → Add libnotify (+ libindicate) support to Thunderbird
Would love to look into providing a service for this but I still cannot find any documentation on the API (which is strange, Ryan Paul said he got libindicate working in his messaging program).
That gives some examples on how to use libindicate in a couple of languages and has some pointers (Disclaimer: I didn't try it myself, just googled it to help Michael).
Maybe I'm missing something, but I find this a really braindead API decision: indicate_server_set_desktop_file 1) How are we supposed to find out where the desktop file is? 2) What about users who don't have a desktop file for Thunderbird or any other Mozilla application that will use this? 3) Why can't we set the name and icon of our application directly (and anything else the library reads from the desktop file)?
(just adding Fedora me too from bug https://bugzilla.redhat.com/show_bug.cgi?id=550689)
(In reply to comment #17) > (just adding Fedora me too from bug > https://bugzilla.redhat.com/show_bug.cgi?id=550689) Can you use the see also function for that ?
Shat is the status of libindicate? If you want to support it, is it available/supported by any other linux distribution? Is it a part of any desktop environment? I can't find any Fedora package for instance.
Ted Gould added the following comment to Launchpad bug #334344: The reason that we used the desktop file is becuase it provides a lot of nice information. The high resolution icon, the name, the description and those are already translatable. Desktop applications on Linux do have desktop files whether they get added by upstream sources or distributors. For instance, Thuderbird wouldn't show up in the software center to be installed unless it had a desktop file. We haven't uploaded the API documentation anywhere on the web officially. It is included in the libindicate-doc package. I have uploaded that here: http://people.canonical.com/~ted/libindicate/current/ Hopefully that helps. -- http://launchpad.net/bugs/334344
You know, libnotify supports from 1.9.2. The target of comm-central is 1.9.2 and trunk (1.9.3). So we should cleanup code for this.
Attachment #364831 - Attachment is obsolete: true
Attachment #423907 - Flags: review?(bugzilla) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: nobody → m_kato
Target Milestone: --- → Thunderbird 3.1rc1
Target Milestone: Thunderbird 3.1rc1 → Thunderbird 3.1b2
(In reply to comment #22) > landed > http://hg.mozilla.org/comm-central/rev/5c4928d99bad As discussed with Makoto, partly as a result of bug 555536, I've just backed this out from the comm-1.9.2 branch: http://hg.mozilla.org/releases/comm-1.9.2/rev/e54fc70745ba Therefore updating the target milestone accordingly.
Target Milestone: Thunderbird 3.1b2 → Thunderbird 3.2a1
Thunderbird 3.1 final is out. How do you make it to use this feature?
You don't. It has been moved to target Thunderbird 3.2 according to comment 23 above: https://bugzilla.mozilla.org/show_bug.cgi?id=478463#c23 However, there is an extension that works with libnotify and the indicator applet. See here for more details: http://ubublogger.wordpress.com/2010/06/28/new-version-of-libnotify-for-mozilla-0-2-stable/
Why is this marked as Resolved/Fixed?
My thought exactly. Such important feature is missing.
RESOLVED/FIXED does indeed appear to be a mistake. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Now I'm confused. Comment 22 says this landed on trunk. Comment 23 says this was backed out of TB 3.1 (but that means it stays on trunk = TB 3.2). A bug is "FIXED" when it landed on trunk (independent of any releases).
Quite right; my mistake. Good catch, Ben!
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.