There is a race if a channel is invalidated during its preparation: the
'invalidated' signal is already emitted so the Shell will never notice.
We fix this by simply checking if the channel is already invalidated when
receiving it from telepathy-glib.
In the approving case, we reject the full ChannelDispatchOperation as we only
support approving one channel at the time.
https://bugzilla.gnome.org/show_bug.cgi?id=677457
clutter_actor_get_children requires making a temporary GSList from
a linked list structure, and then creating a JS Array from that GSList.
For simple cases like the number of children, use clutter_actor_get_n_children.
https://bugzilla.gnome.org/show_bug.cgi?id=677426
For most subclasses, this is a direct swap -- a lot of the time, the
constructor was a blank class that override createNotificationIcon,
and called _setSummaryIcon in _init.
https://bugzilla.gnome.org/show_bug.cgi?id=661236
When receiving another message or responding in a new expanded chat
notification that has no prior chat history, the notification moved down
below the edge of the screen instead of expanding up, making part of it
invisible. Avoid this by making sure the notification's position is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=661944
Empathy uses to support 2 D-Bus API for calls:
- StreamedMedia: legacy API
- Call.DRAFT: experimental version of the new API
Since 3.3.90, Empathy only supports Call1, the first stable version of the new
API, so the Shell should do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=667694
this.parent was ported from calling the parent class's method like
MessageTray.Notification.prototype._init.call(this, ...);. When
porting to Lang.Class, the 'this' parameter is now passed automatically, but
removing it was forgot in a few places. Fix these places.
https://bugzilla.gnome.org/show_bug.cgi?id=665017
We need to notify when the channel dispatcher calls HandleChannels on
us with a channel we already handle. However, we don't want to notify
if we claim a new incoming channel which doesn't actually have
anything interesting in it yet.
For example, a new channel pops up just to give a delivery
notification. We want (or, need) to handle it but don't want to notify
for it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=666243
Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Third step in the class framework port, now it's the turn of
MessageTray.Source and MessageTray.Notification, as well as
the various implementations around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
tp-glib can sometimes emit a notify::alias signal when the alias doesn't
actually change. Bail out early instead of pushing an alias change message.
https://bugzilla.gnome.org/show_bug.cgi?id=660774
Not doing so is considered as a bug as we don't accept the context right away.
It leads to tp-glib returning directly from the AddDispatchOperation() D-Bus
call and so automatically approve the channel if the Shell is the only
approver running.
https://bugzilla.gnome.org/show_bug.cgi?id=660084
Previously, when the avatar changed, we would not update the summary icon
for the source at all and would only update the notification icon when the
next message was received. Instead, we should update both immediately upon
recieving the signal that the avatar has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=659768
Direction containers group all contiguous messages in the same direction into
their own parent container, allowing for smarter styling of similar messages.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
It's generally more useful to see when a person sent a message instead of when
we received it. Also, a recent change in Telepathy made the received timestamp
be 0 for messages we send.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
The shell should only notify in case no other client handles the message.
Empathy will ack the message if focused, so we don't want to step on its
toes.
As an effort to prevent a string freeze to land timestamps on 3.0, we reused
translations for the calendar. Now that the string freeze is long gone, make
some proper strings.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
This is needed if we are handling an incoming text channel and then user tries
to open a chat with the same contact using Empathy. In this case, the Shell
should delegate the channel back to Empathy and just continue observing it as
it does for usual outgoing channels.
Depends on telepathy-glib 0.15.3 as
tp_base_client_set_delegated_channels_callback() has been added in this
version.
https://bugzilla.gnome.org/show_bug.cgi?id=654237
If we're typing we want to send composing. If we empty the entry we
want to send active. If we're typing but don't type any more for
COMPOSING_STOP_TIMEOUT seconds, we want to send paused. Simple.
This behaviour was stolen from Empathy where it has won many awards.
https://bugzilla.gnome.org/show_bug.cgi?id=650196
Based on patch from Jonny Lamb <jonnylamb@gnome.org>
Signed-off-by: Alban Crequy <alban.crequy@collabora.co.uk>
