Polari moved to our gitlab instance. Gitlab and cgit don't use the
same format for accessing the raw file, so the redirect broke all
screenshots. Use the proper gitlab URLs instead.

This bit got lost in the meson port ...

Meh, this slipped for the last couple of releases - try building
the habit by adding the release notes now.

Update NEWS.

mjash authored May 22, 2017 and Florian Müllner committed Jul 19, 2017

As activating a checkbox via keyboard navigation does not emit
the ::row-activated signal, we need to handle ::toggled as well.
However as clicking a row will emit both signals, we currently
end up toggling the checkbox twice in that case (that is, back
to its original state). Address this by only handling ::toggled
in response to keyboard events.

https://bugzilla.gnome.org/show_bug.cgi?id=782969

We do the best we can to establish a connection, if the connection still
fails, then retrying endlessly is unlikely to turn up a different result.
Except that telepathy apparently disagrees, and keeps trying anyway;
stop it from doing that by explicitly setting the presence to offline,
until the network changes and it becomes worth checking again.

https://bugzilla.gnome.org/show_bug.cgi?id=784047

Unlike notify::network-available that is emitted when the availability
of a default route changes, ::network-changed is emitted on any network
changes, for example when previously unavailable ranges become available
after connecting to a VPN network. As this may well be the reason for a
previous connection failure, it makes sense for us to reconnect accounts
in response.

https://bugzilla.gnome.org/show_bug.cgi?id=784047

On startup, we need to pick up both the initial network status
as well as the account status (so we identify the user and
connect rooms when the account is already connected, for
example when restarted after a crash). We currently cover
both cases when handling changes to the network availability,
however as we are about to monitor more network changes, we
may end up reinitializing accounts that are already connected.
While that shouldn't break anything, we can avoid the unnecessary
work by handling network- and account status initialization
separately.

https://bugzilla.gnome.org/show_bug.cgi?id=784047

In addition to NickServ bots that don't support the username parameter
and those that optionally support it, there are also bots that require
it. To support those as well, store whether the user included the
username in the identify command - if it was, we know the parameter
is supported and we can always send it regardless of the currently
used nick.

https://bugzilla.gnome.org/show_bug.cgi?id=772915

Justyn Temme authored May 10, 2017 and Florian Müllner committed Jun 21, 2017

Many NickServ bots only take a password parameter, while we currently
send the username along unconditionally to make sure that identification
is still possible when connecting with a nickname that doesn't match
the registered one.
In order to work both with bots that support an optional username
parameter and those that don't understand the parameter at all,
omit the username when it already matches the currently used nick.

https://bugzilla.gnome.org/show_bug.cgi?id=772915

Justyn Temme authored May 10, 2017 and Florian Müllner committed Jun 21, 2017

Not all NickServ bots understand the username parameter, so the
identify command we send doesn't work at all on those networks.
We will address this by not sending the username unconditionally,
so as a first step make the parameter optional.

https://bugzilla.gnome.org/show_bug.cgi?id=772915

While an empty (self) nick is unexpected, it's apparently possible
under some circumstances. Handle that case explicitly to avoid
entering an infinite loop.

https://bugzilla.gnome.org/show_bug.cgi?id=781686

Center the indicator with respect to the whole view and dim its
color, as suggested by Lapo.

Update NEWS.

The entry area is meant to blend in seamlessly with the chat log,
which we achieve by adding the .view class. However since GTK+
commit efde7d15a, views do have a distinct :disabled styling,
which breaks the intended look for offline rooms.

Restore the previous look with an appropriate override in the
application style.

https://bugzilla.gnome.org/show_bug.cgi?id=781159

Depending on whether the room is currently connected, we either use
the self-contact's :alias property or the account's :nickname one
for the nick button text. Either of those properties can change, but
we currently only update the text in the former case. Start tracking
changes to the :nickname property is well to make sure we properly
update the button while disconnected.

https://bugzilla.gnome.org/show_bug.cgi?id=781161

https://bugzilla.gnome.org/show_bug.cgi?id=781161

Telepathy will remember the last used nickname and restore it when an
account gets connected. While not necessarily wrong, this conflicts
with us treating the nickname set from the popover as a temporary
change in contrast to the nickname configured in the properties,
so for us it makes more sense to reset the nickname at startup to
make sure it matches the configured one we are using to connect.

https://bugzilla.gnome.org/show_bug.cgi?id=781161

If a connection fails because the chosen nick is already in use, we
automatically retry with an appended underscore. But while we restore
the original name when the connection succeeds or we are giving up,
the underscores can stick around when polari is closed while still
connecting. And as the underscores are then considered part of the
original name when polari is next started, they tend to pile up after
a while. To counter that, assume that all trailing underscores aren't
part of the genuine nick and trim them instead of trying to restore the
original account name.

https://bugzilla.gnome.org/show_bug.cgi?id=781161

Currently when an error occurs during room list initialization, the
list for the account in question won't be available until polari is
restarted. Instead, handle errors so that we can retry the next time
the account gets connected.

https://bugzilla.gnome.org/show_bug.cgi?id=781072

In a one-to-one conversation, there's no reason to keep the channel
open after one of the participants disconnects - all further messages
will go straight to /dev/null anyway - so disconnect the channel in
this case.

https://bugzilla.gnome.org/show_bug.cgi?id=712635