Fix redirected, non-https donation URL to the destination URL.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/302>

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/303>

https://git.fsfe.org/reuse/tool/commit/5895f3682ba09ced99 marked
"QT Creator's UI files" as "uncommentable", which unfortunately
applies to GtkBuilder's UI files as well.

As a result, all .ui files are now considered non-compliant,
simply because the tool refuses to read the perfectly fine
copyright information.

Work around this by patching out the offending line, so the tool
processes the files normally again.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/305>

The existing code is still using a pattern from the GTK3 era, in
GTK4 we can simply set up a couple of bindings.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/306>

The reuse-tool regression was fixed, so the work-around is obsolete.

This reverts commit c47f8b5f.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/307>

While .appdata.xml is still supported, it is a legacy name and
.metainfo.xml is generally preferred.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/308>

The data resource is a dependency of the main executable, but
it's still unexpected that sources in data/ are built from src/.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/308>

Group elements into sections for better readability.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/308>

There are no LGPL-licensed sources in the project, so only list
GPL-2.0-or-later.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/308>

Using the existing metainfo to populate the about window means that
we stop duplicating information, which is generally a good idea.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/308>

Pipelines for non-protected branches are set to 'manual', and
thus cheap. However they may still get picked by `@marge-bot`,
meaning that the bot waits for the completion of a pipeline that
never starts.

Avoid that by not creating pipelines for branches with open
merge requests.

Credit to Jordan, who came up with this for gst.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/309>

Child windows are not well-suited on mobile platforms, so
libadwaita introduced adaptive dialogs that turn into
"bottom sheets" at small sizes.

Eventually all transient windows should use the new widgets.

Start with the about dialog, which is pretty-much a drop-in
replacement.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/310>

Another fairly straight-forward case.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/310>

This dialog requires more care, as there's no longer a separate
window that prevents key events from reaching the application
window from processing shortcuts.

Also the dialog is still not fully adaptive, as the connection
selector on the main page is too wide.

It's still a step in the right direction, so no good reason for
delaying it.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/310>

We have used a small message object to abstract differences between the
telepathy-glib and telepathy-logger message types ever since we started
to include backlogs. So far we just used a plain JS object, however we
will soon need to represent messages in C code as well, so add a new
boxed type that can replace the existing intermediate object.
This will promote the existing telepathy-logger dependency from runtime-
to build-time dependency, however this is temporary and we will soon get
rid of the dependency altogether.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

We'll use it to store out chat logs.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

Include Tracker SPARQL 3.0 dependency.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

This is the ontology we will be using to store messages and
corrsponding properties like accounts and contacts.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

We will use a private database with a custom ontology to store
logs. A singleton connection is more effective, and also allows
us to keep the required parameters in a central place.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

One of the responsibilities of a local store is properly shutting
down the connection on exit. Unclean shutdowns are not problematic
per se, but will trigger additional checks on next startup.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

We will use this to log new messages to tracker.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

When we stop relying on telepathy-logger, we are responsible to log
messages ourselves intead of leaving it to an external process.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

When we are running in parallel to another instance, we can assume
that the primary instance is logging messages.

If we logged the same message again, we'd end up with duplicated
log entries.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

As telepathy-logger is unsuitable for anything more advanced than
retrieving logs sequentially (at least with acceptable performance),
we want to replace it with tracker eventually. To prepare for that,
add our own helperclass that wraps a tracker compiled statement
and provides a convenient API to get result objects from SPARQL
queries, and implement a LogWalker class from it.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

Now that we log new messages to tracker, it's time to also retrieve
the logs from tracker.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

We have now switched to tracker for chat logs, so the dependency
is no longer needed.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

It is now unused.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

Telepathy-logger uses GMarkup functions to escape markup when writing
logs, so for maximum compatibility we should use the same for reading.

That means the implementation has to happen in C, so add a new
importer class that imports the contents of an XML log file
into tracker.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

Now that we have the TplImporter API, it looks like the right
place to also collect the list of files that need importing.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

The flatpak uses the variable to point to the unsandboxed user
dir, to make it possible to pick up logs from the host (when
telepathy-logger is installed and running there).

We shouldn't use logs in that case, so handle the case like
our patched telepathy-logger library did: Use the directory
from the host if it exists, otherwise use the regular user data
dir.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

If the number of rooms is high enough, querying log entries for all
chatViews at the same time is likely going to result in a bunch of
thread contention (since the DB interfaces are limited).

Make it query on map instead, which will likely be one at a time.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

It will be nice to show UI about the importing progress, add an
overlayed progress bar so we can display it.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

This happens on the first run that creates the chatlogs Tracker
database, and holds the application until it's done.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

This does not seem to add much, besides artificially delaying
the backlog query. Remove it so it feels snappier.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

At that moment it might return partial results or no results, avoid
falling in these situations.

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/264>

- Add the <developer><name> tag
- Mark the <developer_name> tag as deprecated
- Mark the developer name as untranslatable
- Fix deprecated named display_length tag

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/304>

- Add appstreamcli beside appstream-util to validate appdata

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/304>

We now have a better alternative with welcome.gnome.org.

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/51

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/312>

Software and other app stores use it to point potential contributors
to build instructions.

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/51

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/312>

Instead of pointing to the (about to be retired) wiki, link to
the module page in damned lies.

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/51

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/312>

Flathub recently added support for "brand colors"[0] that app
stores can use to improve an app's presentation.

Sam Hewitt was kind enough to provide some for us, add them
to the metainfo.

[0] https://docs.flathub.org/blog/introducing-app-brand-colors/

Part-of: <https://gitlab.gnome.org/GNOME/polari/-/merge_requests/313>

The spec[0] explicitly suggests fediverse handles as alternative to
a reverse DNS-name, but does not mention e-mail.

[0]
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer

Update NEWS.