As needed for the application test.

As GOM does not allow us to cancel asynchronous tasks,
we need to hold references temporarily.

This is useful for testing the CallsApplication.

Previously the application was only properly shut down
when it received SIGTERM/SIGINT.

If this is not the primary instance self->main_window and
self->call_window will not have been created in the first place.

Fixes: e878fabb

As Calls cannot deal with call waiting we should disable it entirely.
This works around issues where call audio get's completely broken once
the waiting call is disconnected on the BM818 modem shipped with the
Librem 5.

See https://source.puri.sm/Librem5/OS-issues/-/issues/311

g_signal_connect takes a gpointer, so the instance parameter does not
need to be cast explicitly.

mm_object_get_modem() is transfer full,
so we need to unref it when we're done.

mm_object_get_modem_voice() is transfer full,
so we need to unref it when we're done.

This is better than the implicit conversion of the enum.

Not strictly needed here, because we don't depend on the parent being
constructed but this is how it should generally be done.

- Prefer char* over gchar*
- g_auto* variables come first
- Two newlines between functions

Prefer char over gchar and some whitespace cleanups.

Today the tarball magically changed back.

This reverts commit 22898281.

Today the tarball magically changed back.

This reverts commit 745987f3.

GitHub is great. Probably no malware ¯\_(ツ)_/¯

GitHub is great. Probably no malware ¯\_(ツ)_/¯

It has been reported that the BM818 sometimes unexpectedly
changes the call state from "active" back to "ringing-in"
(as reported by ModemManager) shortly after accepting an incoming call.

ModemManager[734]: <info>  [modem1/call1] user request to accept call
ModemManager[734]: <info>  [modem1/call1] call is accepted
ModemManager[734]: <info>  [modem1/call1] call state changed: ringing-in -> active (accepted)
ModemManager[734]: <info>  [modem1/call1] call state changed: active -> ringing-in (unknown)

This leads to a failed assertion and program termination.
Instead of crashing raising a critical warning is more appropriate
and may allow the user to pick up the call after all.

Closes: #547

Closes: #493

Jürgen Benvenuti authored Jan 28, 2023 and Administrator committed Jan 28, 2023

(cherry picked from commit 57ac3607)