The destroy signal handler is kept connected despite the NotificationMessage
being destroyed, which leaves dangling NotificationMessage objects that will
be mass destroyed when the Notification object these depend upon is finally
destroyed.
Depending on the amount of accumulated NotificationMessages, this may lead
to temporary freezes or other more funky issues when recursion limits are
hit.
https://bugzilla.gnome.org/show_bug.cgi?id=755425
Resident notifications are not really a thing anymore with the new
design, so all the user sees are some notifications that mysteriously
cannot be closed. That's utterly confusing, stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=746860
Since commit 75745fc23f, the bodyStack itself is no longer start-aligned
to not break custom body actors like chat notifications. However we still
want "normal" body actors start-aligned to get the correct RTL behavior.
Currently dismissed events will simply reappear when browsing
back and forth between dates, which is clearly broken. Instead,
hide events that have been dismissed permanently. For now, we
simply store a list of ignored IDs ourselves, until we get API
in evolution-data-server to reliably store custom per-event
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
The design calls for differentiating between dismissable reminders
and permanent events, based on whether the selected date is "today"
or some other day.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
While messages in the EventsSection are currently simple enough to
use the generic Message baseclass, the design calls for events to
only be dismissable on the current day. We will need a subclass to
implement this behavior cleanly, so add one.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
As the design calls for slightly different behavior for the current
day, move the _isToday() function out of MessageListSection to have
it available elsewhere as well ...
https://bugzilla.gnome.org/show_bug.cgi?id=744927
Currently the clear action in the section header simply removes all
messages from the section. While the result looks exactly as if the
close button of each individual message had been clicked, the messages
are not actually closed - after a restart (or some other condition that
triggers a reload), the messages simply reappear, which is confusing.
Do the expected thing instead, and make clear close all messages in the
section.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
Currently a message can only be closed by its close button. However
as we want to make a section's clear action synonymous with clicking
the close button of each individual message in the list, we will need
to expose the close action, so add a corresponding method.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
Currently closing all messages is subtly different from clearing
a section, which is confusing. Start making the behavior more
predictable by only showing a close button in the message when
the section's clear button would remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
If a different message ends up underneath the pointer at the end
of the removal animation, it won't receive an enter event until
the pointer is moved, and thus its hover state will not be correct.
Fix it up manually with an explicit pointer sync.
https://bugzilla.gnome.org/show_bug.cgi?id=746019
As we use two separate body actors for expanded and unexpanded
notifications, updating only one of them on notification updates
is not enough - if the notification has already been expanded,
we need to update the second label as well.
Enabling line-wrapping of the unexpanded body is not enough to enforce
a single line when the text has embedded newlines, so replace these with
spaces (this is similar to setting ClutterText:single-line-mode, however
that would use a paragraph separator glyph instead).
Currently both the timestamp and the position in the notification list
are static once a notification has been added; however notifications may
be updated later, in which case those properties should be reevaluated.
https://bugzilla.gnome.org/show_bug.cgi?id=745132
Replace the time formatting in notifications and events with the
new utility method - this makes sure that all times are now following
the clock-format setting and use LC_TIME.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
While those elements cannot be activated, they still provide useful
information to screen readers, so include them in the focus chain.
For the same purpose, set a more verbose accessible name, given that
it is not bound by the same space constraints as the visible label.
https://bugzilla.gnome.org/show_bug.cgi?id=706903
It doesn't make much sense to show a section if it must remain empty
due to the session mode - there won't be any events if the session
mode disallows events, or notifications if those are disallowed. So
take the session mode into account and update the sections' visibility
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=745494
Messages can be dismissed using a pointer device by clicking the
close button, there's no reason to not make the same action
available via keyboard as well. Delete looks like an obvious
choice ...
https://bugzilla.gnome.org/show_bug.cgi?id=745279
We reuse the old body text on useMarkup changes and for expanded
labels. However just taking it from the label actor does not work
when markup is used, as once applied it will be stripped from
ClutterText:text.
So to preserve markup, keep our own copy of the original string
around.
https://bugzilla.gnome.org/show_bug.cgi?id=744907
Markup in notification titles is not support (and never has been).
Therefore the text is run through g_markup_escape_text(), and as
a result we do have to use markup internally to correctly show
legal-but-escape characters like '&' or '"'.
https://bugzilla.gnome.org/show_bug.cgi?id=744894
Notifications in the message list cannot be expanded, however we will
soon use NotificationMessage to re-implement notification banners, where
we still want actions and expanded content.
While this functionality logically belongs to the future banner subclass,
it is cleaner and easier to have the basic support in the base class.
This also leaves the door open for expanded notifications in the summary,
should that become a thing again.
Display notifications that have not been dismissed in the message
list - eventually this will replace the existing message tray summary.
Notification messages show icon, title and one line of the body and
can be clicked to activate the default action. However they cannot be
expanded, so other actions or the full body text are not accessible
in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Turn the existing EventsList into a MessageListSection and add the
message list to the calendar drop-down. The new events list only
displays events for the currently selected day, but in a more
structured and friendlier way than the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is a scrollable list that will hold sections of
different types of time-related messages like notifications,
calendar events or birthday reminders. When no section displays
any content for the selected date, a placeholder is shown instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will start using both URLHighlighter and the _fixMarkup() helper
method the same way it's used in MessageTray. Usually we should
make fixMarkup() public and call the existing methods, but we are
planning for them to go away soon, so just keep two copies until
the original one is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
In certain cases the timeout for starting the calendar helper can
be reached but the calendar helper still loads fine. If so, just
ignore the timeout and wait until we get a notification from
dbus of the successful start.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
Correctly computing the ISO week number is tricky and we already
have code in the platform to do it, so just refer its computation
to GDateTime rather than doing it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=736722
Leading zeros are common in the 24h format, and indeed used in the
wallclock in the top bar. Convention and consistency within the
same clock format trumps inconsistency between different time formats,
so reverting commit 316f825b2a.
https://bugzilla.gnome.org/show_bug.cgi?id=658675
This patch inlines the function _ellipsizeEventTime into its only caller
_addEvent. This also removes the need for the global const
EventEllipses and is thus removed by this commit as well.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
With commit dc6a60dde, the calendar displays the ending day and time of
a continuing multi-day event on its ending day. This results in the list
not appearing to be sorted. This patch sorts the list according to the
displayed day/time.
With the two appointments
Thursday 0800-1000 Foo, and Wednesday 0900-Friday 1200 Bar and today
being Monday, the rest of the week list currently displays:
F ...1200 Bar
T 0800 Foo
With this patch, the displaying order is switched because Friday comes
after Thursday.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
Currently, multi-day events are shown as individual appointments on each
day. This patch ellipsizes multi-day events to indicate continuation on
the prior or following day (or other time-period.)
The time label spot is now replaced by a box layout that contains the
prefix ellipsis label, the time label and the postfix ellipsis label.
In order to keep the alignment, ellipses are merely invisible (zero
opacity) when hidden.
The ellipses are styled using the events-day-time-ellipses class which,
by default, take the color of the event text.
When RTL is used, the box contents are adjusted accordingly (clutter
does that for us).
An event spanning three days now displays "...All Day..." in the
calendar on the second day.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
