Open Bug 329676 Opened 18 years ago Updated 2 months ago

Display alarm slider in addition to alarm popup dialog (use libnotify / libindicate)

Categories

(Calendar :: Internal Components, enhancement)

x86
All
enhancement

Tracking

(Not tracked)

People

(Reporter: ssitter, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 6 obsolete files)

Currently we have the problem that the alarm dialog does not pop up in the foreground. So it can be easily missed by the user.

My idea was to display an additional alarm slider, similar to what Thunderbird does for New Mail messages or Firefox does for Download Completed message.

The alarm message is displayed in a small window that slides up from the bottom of the screen, holds there for a few seconds, then slides down.

Pros:
Alarm slider is always displayed in the foreground. In addition with an alarm sound this will notify the user adequate. (And it looks better than the popup dialog)

Cons:
Currently (Mozilla 1.8) does not work on Mac OS X. The slider disappears after a few seconds. So the popup dialog is still required.
Attached image example screenshot (obsolete) —
This is an example screenshot showing a alarm slider. This example was achived with about five lines of code.

What do you think?
I like it.
Great
Attached patch show title and time (obsolete) — — Splinter Review
Open points:
We need a better icon that matches our theme for the alarm slider.
Allow the user to enable/disable alarm notification by preference (as done in Thunderbird for new mail message)?
Assignee: base → ssitter
Status: NEW → ASSIGNED
Attachment #220813 - Flags: first-review?(jminta)
Comment on attachment 220813 [details] [diff] [review]
show title and time

+   //------------------------------------------------------------------------
+   // Display alarm notification
+   //------------------------------------------------------------------------
+   try {
+      // XXXSitter: find a better icon that matches our theme
+      var alertImageUrl = "chrome://global/skin/icons/Error.png";
+      var alertTitle = props.GetStringFromName("alarmNotificationTitle");
+      var alertText = event.title + " (" + timeString + ")";
+
+      var as = Components.classes["@mozilla.org/alerts-service;1"]
+                         .getService(Components.interfaces.nsIAlertsService);
+      as.showAlertNotification(alertImageUrl, alertTitle, alertText, false, "", null);
+   } catch (e) { }

Some thoughts here:
1) What are you catching and why?
2) We should probably have a callback listener that will open the event-dialog when the user clicks on the message.
3) Nit: Use a better variable name for the alertsservice.
4) I'm not really sure how I feel about the commenting style here.  Just a white-space line and a single comment line would probably be enough.

I do think we want some sort of preference control here, although I'm not sure how to distinguish that from the  normal pop-up preference.

I like the idea though, but it'd be nice to get some feedback from others too.
Attachment #220813 - Flags: first-review?(jminta)
Attached patch show title and time, v2 (obsolete) — — Splinter Review
Updated patch. Use helper functions where possible. Use new pref to control behaviour.

If possible I would like this patch to land for 0.3 release. It will help users not to miss events in the cases where our normal alarm dialog does not show up on top of all windows.

(In reply to comment #5)
> 1) What are you catching and why?
According to the documentation this does not work on Mac OS X. Therefore I put it into try-catch-block so that we don't fail here.

> 2) We should probably have a callback listener that will open
>    the event-dialog when the user clicks on the message.
I don't know how to achieve this at the moment so I would like to postphone this to a followup patch.

> 3) Nit: Use a better variable name for the alertsservice.
Fixed.

> 4) I'm not really sure how I feel about the commenting style here. 
Fixed.
Attachment #220813 - Attachment is obsolete: true
Attachment #231772 - Flags: first-review?(jminta)
Whiteboard: [cal-ui-review needed]
Comment on attachment 231772 [details] [diff] [review]
show title and time, v2

+         var alertImageUrl = "chrome://global/skin/icons/Error.png";
We need a follow-up bug to get a better icon here.

+# Alarm
+alarmNotificationTitle=Calendar Alarm
+
I bet you want to use 'Sunbird' or 'Lightning' here.

r=jminta with that.
Attachment #231772 - Flags: first-review?(jminta) → first-review+
(In reply to comment #7)
> +alarmNotificationTitle=Calendar Alarm
> +
> I bet you want to use 'Sunbird' or 'Lightning' here.

Do you have any suggestion on how to differentiate between Sunbird/Lightning during runtime for string creation? Using something like 'brandShortName' during build process will only work in Sunbird.

Also note that the title of the normal alarm dialog is 'Calendar Alarm' too.
(In reply to comment #8)
> Do you have any suggestion on how to differentiate between Sunbird/Lightning
> during runtime for string creation? Using something like 'brandShortName'
> during build process will only work in Sunbird.
> 
> Also note that the title of the normal alarm dialog is 'Calendar Alarm' too.
> 
Hmm... we may want to farm this out to another bug then.  I'll leave this up to the UI-review folks.  If you want to sort it out at runtime, you can use nsIXULAppInfo, or some such beast.
(In reply to comment #7)
> (From update of attachment 231772 [details] [diff] [review] [edit])
> +         var alertImageUrl = "chrome://global/skin/icons/Error.png";
> We need a follow-up bug to get a better icon here.

I filed Bug 348517.
To be honest, i'm not that sure about this bug. We have a problem: the alarm dialog is not on top. But showing the information that is already in the popup in some other place, that happens to be on top for a few seconds, doesn't look like the right solution to me. It's a temporary solution: after a few seconds, it's gone again.
I think we need something better, that stays on top. It would be best if it wasn't really over the window you are working on now, because then you are likely to cancel it right away, without even reading it.
Maybe the popup slider from this bug, but without the auto-remove part? And then we might even remove the dialog, because it's just a copy of the same data. No need to show the same thing twice.
(In reply to comment #11)
Answer I gave on IRC some weeks ago:
<mvl> ssitter: did you see my question about the alarm slider?
<mvl> the one more fundamental then the icon to use :)
<ssitter> mvl: yes i saw but did not comment yet. you are right that
          the real problems need to be fixed. but i'd say better have a
          80% working solution for 0.3 now instead of a 99% working 
          solution in unknown time. we also could use the proposed slider
          to get user feedback to find the proper solution.
<mvl> ssitter: i'm just afraid that the slider won't go away anymore
<mvl> ssitter: do you think it would be possible to make a slider without
      the hiding after n seconds?
<mvl> so that it stays visible?
<ssitter> mvl: the slider is toolkit functionality. maybe one could
          implement a custom widget with that functionality - but 
          basically that would be like a normal dialog i think
<mvl> ssitter: do you know the name of the widget?
<mvl> filename or tagname
<ssitter> mvl: http://developer.mozilla.org/en/docs/nsIAlertsService
<mvl> we could patch alert.js to allow a sticky sliding alert
<mvl> not sure if ti would be accepted
<ssitter> mvl: mmh, a sticky sliding alert would hide parts of the
          system tray and taskbar on Windows, so it had to be moveable
          - like a dialog
<mvl> sure, you can remove it
<mvl> but it's not like on top of what you are working on
<mvl> so slightly less irritating
<mvl> hmm, but if alerts can be on front of anything, why can't our
      alarm dialog?

-->
I don't know how to fix the alarm dialog. 
I don't know how to subclass or override nsIAlertsService to change behavior.
But I'd like to get this in as proposed for 0.3 as it improves the current situation.
Attached patch display alarm slider, v3 (obsolete) — — Splinter Review
Small changes compared to v2 version: Use new icon. Event/Task title is shown in slider title now. Location will be shown if available.
Attachment #214363 - Attachment is obsolete: true
Attachment #231772 - Attachment is obsolete: true
Attachment #238700 - Flags: second-review?(mvl)
Attachment #238700 - Flags: first-review?(mattwillis)
Attached image screenshot for v3 —
Comment on attachment 238700 [details] [diff] [review]
display alarm slider, v3

>Index: mozilla/calendar/base/content/calendar-alarm-dialog.js
>===================================================================
>-   var prefService = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService);
>-   var calendarPrefs = prefService.getBranch("calendar.");
>+   // Display alarm notification (if enabled)
>+   var showNotification = getPrefSafe("calendar.alarms.showSlidingNotification", false);
>+   if (showNotification) {
>+      try {
>+         var alertImageUrl = "chrome://calendar/skin/cal-icon32.png";
>+         var alertTitle = event.title;
>+         var alertText = timeString;
>+         if (locationString && locationString.length > 0) {
>+            alertText = alertText + " (" + locationString + ")";
>+         }
>+         var alertService = Components.classes["@mozilla.org/alerts-service;1"]
>+                                      .getService(Components.interfaces.nsIAlertsService);
>+         alertService.showAlertNotification(alertImageUrl, alertTitle, alertText, 
>+                                             false, "", null);
>+      } catch (ex) {
>+         dump("Failed to display alarm notification. (" + ex + ")\n");
>+      }
>+   }
Nit: Since you're adding this whole section, use 2-space indenting to match the above bit, rather than 3. _Eventually_ we'll get all the 3-space stuff out of this file.

> 
>-   var playSound = calendarPrefs.getBoolPref("alarms.playsound");
>+   // Play alarm sound (if enabled)
>+   var playSound = getPrefSafe("calendar.alarms.playsound", false);
>    if (playSound) {
>      try {
>-       var soundURL = calendarPrefs.getCharPref("alarms.soundURL");
>+       var soundURL = getPrefSafe("calendar.alarms.soundURL", null);
>        var sound = Components.classes["@mozilla.org/sound;1"]
>                              .createInstance(Components.interfaces.nsISound);
>        if (soundURL && soundURL.length && soundURL.length > 0) {
>          soundURL = makeURL(soundURL);
>          sound.init();
>          sound.play(soundURL);
>        } else {
>          sound.init();
>          sound.beep();


>Index: mozilla/calendar/lightning/content/lightning.js
>===================================================================
>+pref("calendar.alarms.showSlidingNotification", true);
Wrap this in a #ifndef XP_MACOSX to prevent the alerts-service exception on Mac


>Index: mozilla/calendar/sunbird/app/profile/sunbird.js
>===================================================================
>+pref("calendar.alarms.showSlidingNotification", true);
Wrap this as well


r1=lilmatt with those three things fixed.
Attachment #238700 - Flags: first-review?(mattwillis) → first-review+
Attached patch display alarm slider, v3 (obsolete) — — Splinter Review
Updated according to previous comment. Carry over r1=lilmatt.
Attachment #238700 - Attachment is obsolete: true
Attachment #238717 - Flags: second-review?(mvl)
Attachment #238717 - Flags: first-review+
Attachment #238700 - Flags: second-review?(mvl)
Comment on attachment 238717 [details] [diff] [review]
display alarm slider, v3

This does not need a 2nd review anymore, since the module owner (joey) already gave a positive review for the v2 patch and in addition lilmatt r+'ed the v3 patch.
Attachment #238717 - Flags: second-review?(mvl) → ui-review?(mvl)
Attached patch display alarm slider, v3 (obsolete) — — Splinter Review
Resubmitting because previous version of patch is rotten. 
Carry forward r+ from jminta and lilmatt.
Attachment #238717 - Attachment is obsolete: true
Attachment #259038 - Flags: ui-review?(mvl)
Attachment #259038 - Flags: first-review+
Attachment #238717 - Flags: ui-review?(mvl)
I still wonder why we need this. We already show a window with alarm information. If that window has the problem that it won't show on top of other (non-sunbird) windows, i have a hard time believing that the slider window will show on top. It uses the same code to try to get on top!

The slider is not as useful as the dialog, because it goes away after a few seconds.
Personally, I like it. Nevertheless agree that its kind of redundant to have both windows show up at once and its not a good idea to get rid of the dialog. My suggestion would be to show the slider and wait for it to go away before you get the attention of the dialog. If this proposal is acceptable, check out the bug this one blocks, that already adds a listener. It would just need to be extended to also observe the event that is fired when the slider goes away.

For some reason the slider gets into the foregroud a bit better. It even showed up  in front of my remote desktop session, whereas the alarm dialog didn't come to the front.
Comment on attachment 259038 [details] [diff] [review]
display alarm slider, v3

This redundant dialog won't do much good imo. It would be very confusing.
We need to look for a better total solution for the problem. That might also involve changes to the dialog. But this partial solution won't improve things, i think.
Attachment #259038 - Flags: ui-review?(mvl) → ui-review-
(In reply to comment #21)
> This redundant dialog won't do much good imo.

I totally disagree. This non-invasive dialog would absolutely enhance our alarm UI.

> It would be very confusing.

Care to explain? I can't deduct this from your other statements in this bug, mvl.
(In reply to comment #22)
> I totally disagree. This non-invasive dialog would absolutely enhance our alarm
> UI.

It would. If we could get rid of the invasive dialog. But we can't, since the slider will only stay visible for a short time. So we need both, which means we just add UI, thus adding confusing.

> Care to explain? I can't deduct this from your other statements in this bug,
> mvl.

You see the same information twice, without a clear difference. (because there is no difference!) Which dialog should I read? Why am I seeing two? What happens if I click in one? etc.
I also like this feature. Christian, what's your opinion on this?
Christian, have a look at this one, please. This slider is really cool and the 'thunderbirdisch' way to notify users anyway.
Even though mvl is right, the slider's information is redundant, we cannot assume the popup window being on top (as mvl already noted). Thus IMO this is our only safe way to get visual attention of the user, which is good, +1. Stealing focus (e.g. bringing the popup window on top, if this is safely possible at all) is IMO a no-no.
Removing [cal-ui-review needed] because there was an ui-review.
Whiteboard: [cal-ui-review needed]
I'd like to have an official decision here: My patch was reviewed and the idea was well received by some users/developers. Nevertheless ui-review was denied. So should this bug be closed wontfix? Or can I convince Michiel and Christian to take a second look?
I also support this feature (as I already stated in a previous comment), +1 from me. Christian, would you mind taking UI review for this?
I have mixed feeling regarding the Alarm Slider. It has lots of pros, but there are 2 severe cons.

Pros:
	* Alarm Slider appears in front
	* Alarm Slider slider is not annoying
	* It would fit into the overall design of Thunderbird
	
Cons:
	* It duplicates information
	* It fades away automatically
	
Fixing the fading problem should be easy -- display the slider until the user hits Dismiss, Dismiss All or the Closer.  A solution for the other problem is a little bit harder to find.  First, we should decide if we want to have a Alarm Dialog or a Slider. Having both, or worse displaying both at the same time makes IMHO no sense.

If we go with the Alarm Slider solution we should.....:

... Make it Thunderbird 2.0 conform.
	* Add a Closer
	* Add Hyper links (to Title) -> A click should call up the
	  event dialog
	* Make sure that the slider occurs on the primary screen
	  (two displays config)

... Improve the visual appearance:
	* Replace Icon
	* Replace background
	* Increase size
	
... Add Features such as:
	* Dismiss
	* Dismiss all
	* Snooze
	* Display more than one alarm at once


My 2 Cents
(In reply to comment #31)
> Created an attachment (id=270891) [details]
> Alarm Slider Mock-up -> Thunderbird 2.0 styled
> 
What would be the difference between the red cross and the "Dismiss all" button? The latter is IMO not needed.

Btw, I like the idea to totally replace the alarm window.
(In reply to comment #32)

[...]
> What would be the difference between the red cross and the "Dismiss all"
> button? The latter is IMO not needed.

"Close" should close the slider without deleting reminders automatically. 
"Dismiss" (the red round button) with the X) deletes a single reminder.
"Dismiss All" deletes all reminders in one step.

...Maybe it makes sense to design the "Dismiss" icon not so "Closer" like.

> 
> Btw, I like the idea to totally replace the alarm window.
> 
 Good :)
It's true that the alarm dialog needs a redesign, there already exists bugs for this. But the dialog should not be replaced by a slider. For example it must be possible to keep the alarm dialog open and accessible via taskbar while working on other stuff, it should be resizeable to view multiple alarms, it should be possible to move it on screen, etc. All things that can't be done using the slider. 

The purpose of this bug / the slider is to draw more attention to the alarm dialog. Bug 374659 filed by Philipp would add more functionality as clicking the slider would move the focus to Sunbird and the real alarm dialog. 
Please don't morph this bug into a different one.
I think it must be implement based on the model of Thunderbird.

Thunderbird:
email - slider - trayicon (link opens mail)

Lightning:
alarm - slider - trayicon (link opens alarm dialog)

I think the Thunderbird-model is an approved method and the slider in Lightning would be make a unform look and feel.

Comment on attachment 259038 [details] [diff] [review]
display alarm slider, v3

patch is rotten again
Attachment #259038 - Attachment is obsolete: true
After 18 months I give up working on this.
Maybe someone wants to create an extension out of this proposal.
Assignee: ssitter → nobody
Status: ASSIGNED → NEW
IMO it should work like in Thunderbird 2.0. My idea: the slider should appear for 2 or more seconds in lower right corner of screen and then fade. There should be an icon next to system clock flashing to notify user that some events are missed. Double clicking on icon opens alarm popup dialog. The alarm dialog could have also option to minimize to tray.
(In reply to comment #35)
That is what I think it should work
Christian, mvl: what do you think of comment 35?
I still think the same as i did back in comment 19 and comment 23: just adding UI doesn't fix the problems of the dialog.

The huge difference between new mail and an alarm is that new mail doesn't already open the mail window. If we make alarms not open a window, but only add a tray icon and add the alarm to some list in an already open window, the slider is OK. But as things are now, only adding the slider doesn't solve anything.
(In reply to comment #40)
> Christian, mvl: what do you think of comment 35?
> 

I think we should work on a concept if 0.7 is out of the door.
Bug 404941 arguments, that this would be nice for growl integration on trunk.
The slider does not resolve the issue if it is not persistent.  Say you leave your office for 5 minutes, and during this time, the slider shows up for 3s.  You missed it.  It failed its mission.

We need a solution that remains on top of all windows and require the user to click on it to remove it.  I understand the problem with modal windows, but it is still, of all solutions, the best under Ubuntu 08.04.  I, as a user, want a modal window that disturb me in what I am doing.  At least, give me this option.
I totally agree with comment #49 and in general with Michiel van Leeuwen's position.
A slider like Thunderbird's one (maybe smaller size) is ok only if it is *persistent* because you can't miss an allarm only for looking out of the window to see if it rains.
With Tb' slider you can continue to use your application but slider is on top (lower right corner). With a Lg\Sb slider, you should click on the slider for close it and opening reminder dialog window.
A modal reminder window as option is also necessary. I understand those that want to be "disturbed" from the alarm (for disturbed I mean not allow to countinue your work on your application) because be fired for missing something to do is not so good ;) 
(In reply to comment #46 and #47)
That's why I filed this bug as "Display slider __in addition__ to popup dialog".
In comm-1.9.2 we could instead use libnotify / libindicate, see bug 478463 for the Thunderbird implementation. I don't want to stir up the discussion again, this has been a controversial bug, but maybe someone is willing to start this as an extension.
Summary: Display alarm slider in addition to alarm popup dialog → Display alarm slider in addition to alarm popup dialog (use libnotify / libindicate)
Attached patch patch v1 — — Splinter Review
Just idea patch.
Comment on attachment 427527 [details] [diff] [review]
patch v1

How about a first review on the concept? :)
Attachment #427527 - Flags: review?(philipp)
Comment on attachment 427527 [details] [diff] [review]
patch v1

This patch has similar issues to the original discussion. If you enable the system-notification (btw, the pref is flipped, false = show, true = hide), then it will show for a short moment and then go away. No alarm window is shown. People might miss alarms this way.

On the other hand, if we show both the alarm window and the slider, we'll be duplicating information. Quite a dilemma, this bug.

The actual time the notification is shown might differ depending on the nsIAlertsService implementation, but the issue stays the same.

Also, I'm not quite sold on the fact that clicking on the alarm slider causes the alarm window to open.

Personally, I could live with showing the system notification *in addition* to the normal alarm window.

Also I'd suggest using the alarm dialog icon instead of cal-icon32.
Attachment #427527 - Flags: review?(philipp) → review-
I want this functionality and suggest these fixes for possible missed alarms:

1. Have a tray icon that has a circle with a number in it (that is animated and glows to grab some attention) for the number of missed alarm bubbles

Clicking that tray icon would pop up a window with the alarm events in it

2. Allow user to set a preference to automatically snooze any missed bubbles for "X" minutes (they can set the number of minutes
It's very disappointing that this bug has existed for 6 years. This makes Lightning unusable for me at the office. Missed reminders means missed appointments, which is unacceptable for me.
The slider proposed here will go away, the alarm window we have stays. I don't see how fixing this bug will make you miss less alarms.
Sorry, with "go away" I mean it will, once implemented, vanish after a few seconds.
(In reply to Philipp Kewisch [:Fallen] from comment #56)
> Sorry, with "go away" I mean it will, once implemented, vanish after a few
> seconds.

What about a tray icon with that lists the missed alarms surrounded by a "glowing" or bllinking circle? If you see it animating, you'll notice you missed alarms.
Some months ago I started to write an extension for the slider solution, based on the proposals in this bug: "Calendar Alarm Slider"
http://www.nadelundhirn.de/wp/tag/calendar-alarm-slider/
I'm no coding expert, but I don't hear complaints so it seems to work. ;-) The install.rdf /version numbers are outdated, it should install nevertheless.

Unfortunately the blog posts with some description in it are only German and I don't have any time to work on this ATM - but maybe people interested in this bug want to give it a try or even carry on working on it.
To clarify, I am experiencing the problem as stated in the original post:
"Currently we have the problem that the alarm dialog does not pop up in the foreground. So it can be easily missed by the user."

Right now, all alarms show up behind whatever else is on the screen. They are missed nearly 100% of the time. Ideally, I would prefer that bug be fixed by making the reminder pop up appear in the foreground, like dozens of other dialog windows that presume that's what you want (correctly or no). When I searched, I hadn't found another bug report that describes this bug. If there is another one for fixing that bug, I can comment there instead.
I willing to start work on the reminders if there is some support.  Please see
https://bugzilla.mozilla.org/show_bug.cgi?id=1092552#c4
Flags: needinfo?(ulf.stroehler)
Flags: needinfo?(thorsten)
Flags: needinfo?(tclark77)
Flags: needinfo?(tarek)
Flags: needinfo?(steff)
Flags: needinfo?(sebo.moz)
Flags: needinfo?(samuelmortier)
Flags: needinfo?(omarb.public)
Flags: needinfo?(mozilla)
Flags: needinfo?(mozilla)
Flags: needinfo?(michael.buettner)
Flags: needinfo?(m_kato)
Flags: needinfo?(hans)
Flags: needinfo?(donrhummy)
Flags: needinfo?(dbo.moz)
Flags: needinfo?(chris.j.bugzilla)
Flags: needinfo?(bv1578)
Please don't needinfo everyone just to get a comment. I've added the appropriate needinfo on the bug you linked.
Flags: needinfo?(ulf.stroehler)
Flags: needinfo?(thorsten)
Flags: needinfo?(tclark77)
Flags: needinfo?(tarek)
Flags: needinfo?(steff)
Flags: needinfo?(sebo.moz)
Flags: needinfo?(samuelmortier)
Flags: needinfo?(omarb.public)
Flags: needinfo?(mozilla)
Flags: needinfo?(mozilla)
Flags: needinfo?(michael.buettner)
Flags: needinfo?(m_kato)
Flags: needinfo?(hans)
Flags: needinfo?(donrhummy)
Flags: needinfo?(dbo.moz)
Flags: needinfo?(chris.j.bugzilla)
Flags: needinfo?(bv1578)
(In reply to Philipp Kewisch [:Fallen] from comment #61)
> Please don't needinfo everyone just to get a comment. I've added the
> appropriate needinfo on the bug you linked.

This bug is also affected if work on bug-id 1092552 is started.  So, it's reasonable to have also some feedback of people interested in this bug.
I'm sorry, but this work is too late for me. I don't work any more with Thunderbird in my Company and forced Microsoft Exchange/Outlook instead.
It's so much time ago (2008!!!), but i tell you what i think the main problem was (about the reminder):
-The reminder pops up somewhere under the active window, so it can easily happen that you don't recognize it at all.
-There is no possibility to make a "snooze" to the reminder. Sometimes people are in work and can not edit/execute the mails at current time. It would be nice to adjust a snooze time and the reminder disappears for that time.
-If a new incoming mail was read by another user (the read flag is part of the pop3 protocol) the reminder still shows that unread message. This Behaviour is very important for group accounts.

Unfortunately i am in some other projects now and don't have time to attend this bug.
Therefore i will delete my mail address from the cc.

Good luck!
For this bug I think we should see what options we have with the notify popup. On Mac, its quite common to have a notification popup, their calendar client can display system popups that don't go away until clicked. If we can do something like that on all platforms, I think this would be a good way to go about it. Back then it was only possible to have notifications that go away after some time.
The original bug no longer exists on Manjaro (up to date) or Linux Mint based on Ubuntu 14.04 (Thunderbird version 31.2.0).
"Currently we have the problem that the alarm dialog does not pop up in the foreground."

The notifications in Thunderbird are now appearing in the foreground.

Making the reminder pop ups more modern & improving the UI is a great idea. IMO that's feature improvement and not necessarily a "bug fix". It looks like the feature improvement is happening in other cases, so this one might be able to be closed if no one else is still reporting the problem.

Also see bug 1092552 bug 412202 bug 654726 etc

From Bug 1497434 Comment 4, I understand that this is a duplicate of Bug 1497434.
Feel free to reopen if you think otherwise, although I'd think a new bug would be more appropriate.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

Almost but not quite. We now have both systems. I think we could make alarms go that route too. The reminder dialog is one of the worst UIs we have IMHO.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
See Also: → 433531
Severity: normal → S3

Free desktops have a standard for this that is implemented by D-BUS: https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: