GNOME Bugzilla – Bug 780076
Evolution's alarms / reminder notification dialog is terrible
Last modified: 2018-05-11 11:37:28 UTC
Created attachment 347980 [details] screenshot Not GNOME Calendar's fault, strictly speaking, but within the scope of "the stuff it should fix on the GNOME desktop as a good citizen" and the list of things it needs to fix to have a good user experience: the dialog that pops up in your face when an event's alarm goes off is terrible, and I am reminded daily of its obtrusiveness and un-helpfulness. Screenshot attached. Note: I'm writing this bug report with some pretty unvarnished words, but not meaning to offend anyone, so please read it in a humoristic tone. Main issues: 1- It is system-modal: always-on-top and on every work space. You CANNOT see any window under it until you close it or move it out of the way. Which means you are forced to just mess around with this thing to finish the work you were doing at this very second. 2- It is HUGE. Point #1 wouldn't be that big of an issue if it wasn't so comically huge, especially on laptop screens. 3- It's full of useless features and buttons that contribute to problem #2. Half of the time, my events don't have a description but it shows me this huge empty textfield that takes away from the space to have the list of alarms. But even then, that text field has apparently been put there in part to justify the huge height consumed by the event-contextual action buttons, half of which are useless: a) "Print". Seriously, who is *printing* their calendar events, especially *at the time when the alarm goes off*? This is not the eighties anymore. b) Who *edits* an event from that very dialog at the time the alarm goes off? c) The delay/report feature takes way too much space for nothing, and the "Report" button is not even in the same area. 4- As soon as you have more than 1 alarm/event, it becomes a scrollfest, due to #3 taking all the dialog's vertical space. 5- It should use a headerbar/client-side decorations to save a ton of vertical space with the "Close all" button becoming the replacement for the "X" button. Actually, the "close all button" has no point in existing if the individual "Close" button was put in a more contextual place and named "Acknowledge" or something. Or, arguably, the close/clear-this-event button shouldn't even exist: you either close everything or you report individual events before closing everything. 6- There's an icon eating space for nothing on the left, etc. Essentially, this dialog should be scrapped and redesigned from the ground up. I'd be happy to help design a new dialog mock-up if someone is willing to go through the beast that is Evolution Data Server (or Evolution itself?) to implement it :)
I'm tentatively reassigning this to the EDS product. Jean-François, can you please share a mockup (or even wireframes, anything that could guide us) of a better alarm dialog?
So for one thing I'm wondering why Evolution's Data Server doesn't *just* display a "persistent" native gnome-shell (libnotify) notification, with the various things available in https://developer.gnome.org/libnotify/unstable/NotifyNotification.html so that: - It shows "View" and "Dismiss" (and maybe "Snooze") buttons in the notification - The notification never expires or goes away when the mouse passes over it, only when the user clicks "Dismiss" Without forcing a GtkDialog that requires a bunch of window management hacks, it would stop being an big input-stealing annoyance. Clicking "View" or "Snooze" could then bring up the more complete dialog allowing various actions (but that dialog could be redesigned more elegantly to solve the various problems I pointed earlier) So yeah the main multi-notifications dialog could be improved, but I'm wondering if part of its feature set should be just outsourced to libnotify instead... I'm not sure there's a huge interest in having Evolution work on Windows these days!
Thanks for a bug report. That dialog comes from evolution-alarm-notify, which is part of evolution itself and it's auto-started after login. Feel free to disable its start, but then you might not get any notifications. In evolution, Edit->Preferences->Calendars and Tasks->Reminders tab. The very first option (Display reminders in notification area only) says whether opening the dialog or not. The second option (Keep reminder notification window always on top) is new in 3.24.x. With respect of the layout of that dialog and the actions being offered there, yes, it's old and maybe not that useful these days. I do not have any real plan or timeframe for it, but I do think that the most useful would be to open the dialog from within some client application, thus it would be tight to something, rather than coming out of blue (recall the dialog asking for login credentials), in case any such client is running, but fallback to previous behaviour, if not. That would also allow people to call the dialog manually, because there are bug reports here asking to have the dialog remember its content until events are explicitly dismissed. Different people, different habits, different use cases. > I'm not sure there's a huge interest in having Evolution work on Windows > these days! The main block is WebKitGTK+ using WebKit2. I have locally built 3.18.something under Windows and it can read my IMAPx data, but it's very old and there had been issues even with storing information into registry in that time (glib thing), thus nothing to really offer it in general. As mentioned, the WebKit2 is bigger issue, because it has, for WebKitGTK+, no port for Windows at the moment, thus it's a no go at the moment.
Hi Milan, let me make it clear: while I moved this issue from Calendar to Evolution, I totally volunteer to work on it still. We just need to agree on a direction, and I'll make sure to get it ready for 3.26 :)
Hi Milan, My "Windows" question was about whether or not we could afford to hard-depend on libnotify for the primary function of notifying about calendar events, under the assumption (maybe I'm wrong) that libnotify isn't around on Windows... I had not fully realized that the current dialog living as a "standalone app" was the reason it was not attached to the Evolution window (when Evolution is running), I thought it really was "by design" that it was system-modal, and I was afraid the answer might have been "this won't change" :) so it's relieving to hear that this could indeed change! Would we have pretty much total freedom design-wise to think of a way this can be solved (ie not tied to particular requirements/constraints)?
(In reply to Georges Basile Stavracas Neto from comment #4) > let me make it clear: while I moved this issue from Calendar to Evolution, I > totally volunteer to work on it still. We just need to agree on a direction, > and I'll make sure to get it ready for 3.26 :) Okay, thanks. I had no problem with the move to Evolution, because it is in Evolution and gnome-calendar is not a culprit here by any means. (In reply to Jean-François Fortin Tam from comment #5) > My "Windows" question was about whether or not we could afford to > hard-depend on libnotify for the primary function of notifying about > calendar events, under the assumption (maybe I'm wrong) that libnotify isn't > around on Windows... libnotify is an optional dependency of Evolution, rather not hard-depend on it. Not due to windows, but just in general. > Would we have pretty much total freedom design-wise to think of a way this > can be solved (ie not tied to particular requirements/constraints)? Eeks, I hope not, but if you are willing to iterate on this multiple times, then we can start with some "totally crazy idea" and fine-tune it during other iterations. You still should keep some basic stuff there, though, where the dialog is rather basic, from my point of view.
It sounds to me like one logical way forward here, at least in GNOME, would be to move the responsibility of notifying for calendar events to the same component that is currently responsible to display them (right next to the notifications, in fact!) which is GNOME Shell. Among other things, the Shell *is* also the notification server, and already has code to fetch appointments from e-d-s. Then distributors could effectively stop shipping evolution-alarm-notify by default for this, without a significant loss of functionality. It would also be nice to still have a way for users to use the old evolution-alarm-notify if they want, and not get double notifications for events. (Either by having a way to disable the built-in notifications, or automatically detecting in GNOME Shell that evolution-alarm-notify is available and avoid notifying in that case.)
(In reply to Cosimo Cecchi from comment #7) > ... at least in GNOME, would be to move the responsibility ... which is GNOME > Shell. Yes, there is some ongoing discussion to move evolution-alarm-notify into gnome-shell-calendar-server code, also to lower memory requirements a bit in GNOME. Alberto only didn't file corresponding bug for GNOME Shell yet. That won't fix this bug though. > Then distributors could effectively stop shipping evolution-alarm-notify by > default for this without a significant loss of functionality. No, that's wrong. We are talking about GNOME, not about every single desktop environment. The distributors/distributions should not change anything. Once GNOME Shell will be able to notify about reminders, then the evolution-alarm-notify can be disabled in its .desktop file for GNOME only and evolution can be taught to not auto-start evolution-alarm-notify when it's under GNOME. That would be fairly simple change on its own.
(In reply to Milan Crha from comment #8) > (In reply to Cosimo Cecchi from comment #7) > > ... at least in GNOME, would be to move the responsibility ... which is GNOME > > Shell. > > Yes, there is some ongoing discussion to move evolution-alarm-notify into > gnome-shell-calendar-server code, also to lower memory requirements a bit in > GNOME. Alberto only didn't file corresponding bug for GNOME Shell yet. That > won't fix this bug though. Yeah, it wouldn't fix this bug, but it would make this bug much less relevant. I opened https://gitlab.gnome.org/GNOME/gnome-shell/issues/155 > > Then distributors could effectively stop shipping evolution-alarm-notify by > > default for this without a significant loss of functionality. > > No, that's wrong. We are talking about GNOME, not about every single desktop > environment. The distributors/distributions should not change anything. Once > GNOME Shell will be able to notify about reminders, then the > evolution-alarm-notify can be disabled in its .desktop file for GNOME only > and evolution can be taught to not auto-start evolution-alarm-notify when > it's under GNOME. That would be fairly simple change on its own. Exactly, we're saying the same thing. (A distribution like Endless OS, where there is only a GNOME desktop session, would probably opt for removing evolution-alarm-notify from the core OS completely, if its functionality was available in GNOME Shell.)
Created attachment 371088 [details] what Exchange 2013 OWA shows Just as one example, this is what I see in the OWA (in-browser) interface of Exchange 2013. The part on the left, till the scrollbar, is the list of "overdue" reminders. I can double-click it, which opens it in a popup window where those other actions can be done. I can Ctrl+Click to select multiple of them. It shows 4 overdue items, the number is also visible on the left of the Mail | Calendar | ... at the top and when I click that white square then it hides/shows the list of the overdue reminders. It surprised me they do not care of the description, because it can contain important information like URLs for video conferences and such, but as the double-click opens it in a separate window it's probably fine. This is not exactly the same as a standalone application, because it runs in a browser, but it doesn't look that bad and I believe it addresses most of the concerns in comment #0 and it might be a good compromise between relying on libnotify and the current situation, at least for Evolution itself. GNOME shell can implement this differently, of course.
I move the evolution-alarm-notify to evolution-data-server [1], thus: a) other applications can avoid implementing reminder notification and rely on this, independently of evolution itself b) past reminders persist between sessions, until they are dismissed c) snoozed reminders persist between sessions d) the UI is different, looks similarly as the above in OWA e) work with the Reminders dialog is also slightly different [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=8ba0b06b7 https://git.gnome.org/browse/evolution/commit/?id=499518d53c
And I forgot to add, it's for 3.29.2+.