Since commit 00ab02ca added the ability to run in the background,
the ::prepare-shutdown signal is emitted either when the main window
is closed (and the app shouldn't keep running), or when explicitly
quitting the app. But as the quit action also closes all windows, it
is possible for the signal to be emitted twice, resulting in a warning
when the telepathy client releases an additional app reference (it
doesn't hold).
Avoid this by making sure the signal handler which emits the signal
when closing the main window is disconnected from the quit action.
!79

Both queues are owned by the application, which may outlive the main
window. It probably makes sense to rethink the ownership in the future,
but for now avoid warnings from follow-up main windows by not destroying
them with the previous window.
!79

The room mananager is a singleton whose lifecycle is tied to the
application, while any widget's lifecycle is tied to the window.
App- and window lifecycle are different when Polari is set up to
keep running in the background, so disconnect the signals to avoid
warnings.
!79

The room mananager is a singleton whose lifecycle is tied to the
application, while any widget's lifecycle is tied to the window.
App- and window lifecycle are different when Polari is set up to
keep running in the background, so disconnect the signals to avoid
warnings.
!79

One reason for a nick status change is that we disconnect the account.
If we also close the corresponding room at the same time (for example
on shutdown), there's a good chance that the room's channel property
is unset after we send the request to ack all pending messages, but
before the operation's callback is called. Avoid accessing an undefined
property in that case by using the callback parameter, which will still
be alive under all circumstances at that point.
!79

Ubuntu's dh_translations tool for its language packs
assumes that the translation templates match the project id.
Let's follow that pattern.
Before, the translation templates were named polari.pot and
help-org.gnome.Polari.pot
Now they are named polari.pot and help-polari.pot
See comment 21 on https://launchpad.net/bugs/1762889

Since commit 7fdbaf00, we now use backtick strings where possible;
however as it turns out, xgettext not only doesn't support extracting
backtick strings, but in fact chokes up completely on backtick strings
that contain slashes[0]. Work around the issue by escaping affected
strings until the underlying bug is fixed.
[0] https://savannah.gnu.org/bugs/?50920#comment5!72

Not all networks use UTF-8, so any input and output requires conversion
to avoid garbled characters. Telepathy-idle handles that transparently,
provided the correct 'charset' account property is specified.
For predefined networks, we can simply pass on the option if the network
data specifies it. We'll have to see whether it is worth exposing this
also in the UI and thus supporting custom networks as well.
#43

There have been several changes this cycle that require the last stable
gjs release - debugger support, using Uint8Array for raw data - which
means we neither compile nor run with older releases.
Make this explicit by requesting an appropriate gjs version.
#76

The portal implementation now fetches the initial state asynchronously,
which means that "offline" can now either mean "offline" or a newly
initialized singleton that hasn't fetched its state yet.
Address this by tracking whether the state is valid, and wait for a
::network-changed signal otherwise. In particular this fixes cutting
off existing connections on startup due to an incorrect offline state.
!68

The first issue was fixed in gjs and is no longer needed.
The second issue has been partially addressed in that the portal
will now fetch the initial state, albeit asynchronously and thus
with a small delay. This is unfortunately going to stay with us,
so we'll need to properly address this in master instead of adding
a partial workaround in the flatpak.
!68