Telepathy's role has been diminishing continuously over the last
couple of years, so while chat integration is a nice feature for
those who use it, it is hard to justify keeping it as a hard
dependency. To address this, split out the component from the
client so we can handle missing typelibs gracefully by not
providing any chat integration.
https://bugzilla.gnome.org/show_bug.cgi?id=779878
The telepathy integration was written at a time where gjs didn't
allow to inherit from GObject classes, which is why we needed a
C helper class. This hasn't been the case for a while now, so cut
out the middle man and implement Tp.BaseClient directly.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
As the telepathy integration picks up existing channels on startup,
ChatNotifications are another case where the real time the message
was received may be before the time it is picked up by the shell.
While this is less of an annoyance than restored GNotifications, as
it generally only affects restarts from the run dialog, it's an
easy fix now ...
https://bugzilla.gnome.org/show_bug.cgi?id=775799
Since commit 82950ecea, we acknowledge pending messages when closing a
chat notification for a channel we are handling to prevent the channel
from popping up again immediately. While this isn't an issue for channels
we don't handle, the unread messages of the destroyed notification are
still considered for the messages indicator in the top bar, which is
clearly confusing (in particular when we end up showing the indicator
without any notifications in the list). As it's arguably correct to not
meddle with a channel handled by someone else, just reset the cache of
pending messages to address this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=770888
While a channel has pending messages, it will pop up again when
dismissed. That is clearly not what users expect, so clear them
out first before closing a channel.
https://bugzilla.gnome.org/show_bug.cgi?id=747991
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
Since commit 79c04c93e4, we launch Polari instead of Empathy when
activating a chat notification for an IRC channel. It therefore makes
sense to follow Polari's notification policy for those notifications
rather than Empathy's.
https://bugzilla.gnome.org/show_bug.cgi?id=752881
Sources are destroyed with their last notification. This is usually the
correct behavior, however in case of chat sources, the corresponding
telepathy channel might still be open, and any further messages that
should trigger a notification are lost because chat sources are only
created when telepathy's channel dispatcher notifies us about a channel
(via ObserveChannels).
Loosing messages like this is unexpected, so keep chat sources around
even without notifications while the channel is open.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
Currently the lifetime of a chat source and its single notification
are tied together. While this apparently makes sense, it means we
will lose all follow-up notifications when a source is destroyed
with the corresponding telepathy channel left open. We will fix this
soon by tying the source to the channel's lifetime rather than the
notification, prepare for this by recreating the notification if
necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
When the chat app is focused, we should hide all banners immediately.
A good way to do so, without tracking which app is focused, is
to look for messages that are acked when the banner is unexpanded,
which implies they were acked by some other telepathy client.
https://bugzilla.gnome.org/show_bug.cgi?id=746364
Since we stopped special-casing chat notifications to use the old
notification actor, we need to provide a notification banner to
maintain the inline chat functionality, so split out the UI from
the existing ChatNotification class.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Passing null as body always meant clearing the existing one. While this
mattered less with the old message tray which used the expanded actor,
the new message list in the calendar uses the unexpanded body. We clearly
don't want that to disappear on icon changes, so pass the existing one.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
There's a strong expectation that delegating or presenting a channel
will result in a window being activated, so close both overview and
calendar as we do elsewhere.
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
These notifications are annoying for the most part: presence
changes happen inside an app (empathy or polari), and that app
should have in app notifications for errors, instead of spamming
the global notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=745503
polari is the GNOME app for IRC, empathy is for everything else
So prefer polari to empathy for IRC channels. We don't need
to check that either exists (even though polari is not a core
app) because mission control tries every handler if the preferred
one fails.
Depends on bug 745418 for polari to be mission control activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=745431
Chat notifications are king of custom, so we'll leave them out for now
and keep using the old banner. However we can port the subscription
notification.
Nothing except for the chat notification is really custom, so stop
specifying the flag for anything else - it will soon become a bit
harder to create non-standard notifications, so don't do it for no
good reason (discouraging this is of course the reason for making it
harder in the first place) ...
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since the summary area was removed from the message tray, Source are not
longer represented in the UI, so right-click menus and summary icons are
no longer a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
When we will start to show notifications in the date drop-down, we
will not use the actual notification actor, but construct our own UI
based on Calendar.Message. This is similar to what we already do in
the lock screen, except that in this case clicking the notification
should activate the default action.
So rename the existing _onClicked() method to activate() to make it
clear that such use is acceptable. While not strictly necessary, also
rename the corresponding signal to match.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Ouch, classy - we are telling translators to use a '24h' time
format for the '12h' time format string.
Luckily, only a handful of translations actually followed the
comment (de,hu,id,is,kk,nb,nl), and most of the corresponding
locales do not support 12-hour format anyway (only is_IS, at
least on Fedora).
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
We need to put the actual actors in the history, not just the labels,
otherwise all emptyLine (which are not messages but are not empty
either) and all lines with a timestamp will get stuck in the scrollback.
https://bugzilla.gnome.org/show_bug.cgi?id=733899
It is a bit odd to request AM/PM format when the locale selected
by LC_TIME lacks the concept. We ignore the format setting in that
case elsewhere and assume 24-hour format, let's do the same for
chat timestamps for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=728271
Until now the timestamps were using 24h format.
Check gsetting clock-format to know when
the user is using 12h format or 24h format and
make the timestamp acordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=715158
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
The timestamp timeout specifies how long we should wait before
adding a timestamp to the notification. A timeout of one minute
ended up showing a lot of timestamps, so increase it to 3 minutes.
https://bugzilla.gnome.org/show_bug.cgi?id=687809
This filters out resident and transient notifications in the normal
case, but just returns the number of unread messages for the Telepathy
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=687787
Some notifications, despite being emitted by shell code, should appear
to be from application or "separable" system components. Do that by
associating them with a notification-daemon policy.
Note that for this to look really good, empathy should rename itself
to Chat.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
If the chosen action is not open, the tray should not be closed, to
let the user further interact with it (for example to mute or remove
more sources)
https://bugzilla.gnome.org/show_bug.cgi?id=689296
Invalid ID errors from that function are normal, because the set
of IDs to acknowledge may not match the set in the connection manager
due to race conditions.
This is also what empathy does.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
Instead of keeping track of the old adjustment.upper keep track of the
old adjustment.value that corresponded to the bottom scroll position.
This fixes the integrated chatview not always scrolling to the bottom
by removing the assumption that page_size is constant between updates,
which is not the case as the view is presented in various different ways.
https://bugzilla.gnome.org/show_bug.cgi?id=686571
pending-messages-removed is emitted for sent messages too, but we don't
include those in the _pendingMessages list. Avoid useless spew in the session
logs in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
Components are pieces of the shell code that can be added/removed
at runtime, like extension, but are tied more directly to a session
mode. The session polkit agent, the network agent, autorun/automount,
are all components, keyring, recorder and telepathy client are all
now copmonents.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
