The id property will be used to keep track of which origin was used for a call,
so that we can default to reusing the same origin when placing a call from the
history.
This avoids confusion when only the SIP plugin is loaded, but no account
is being used.
For this we introduce two new functions in the abstract CallsProvider class:
`is_modem()` to indicate whether the the provider deals with PTSN telephony and
`is_operational()` which by default simply checks if there any avalaible origins
These are the protocols that the provider plugin may support. The origins
must be queried independently whether or not they support any given protocol.
Example: A SIP origin/account may or may not support the "tel" protocol.
And adapt to changes
It's easier to track changes if we are using GListModel than
a GList. Also, eventually we shall have multiple providers,
and we can use GtkFlattenListModel to merge multiple origins
without manually managing pointers ourself.
Since several widgets has APIs to handle GListModels, it will
also help us create widgets from GListModels easily.
How `g_type_class_peek ()` was used it didn't return the correct parent
class in most cases.
G_DEFINE_TYPE macro creates a pointer we can use to get the parent
class `n_p_parent_class`.
Because we didn't use the correct parent class the object initialisation
wasn't fully completed for some GtkWidgets.
See https://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation
for more information.
This commit makes use of the `n_p_parent_class pointer` created for this
specific use case where ever possible.
Fixes: https://source.puri.sm/Librem5/calls/issues/118
We want to remove the modem if the currently removed interface is
Voice. It was previously removing the device if the removed
interface wasn’t Voice.
Fixes https://source.puri.sm/Librem5/calls/issues/94
This is an initial, static implementation of plugins. The
CallsApplication has a plugin name which can be changed with a new
--provider command line option. This plugin name is used to
instantiate the appropriate plugin when the application is activated.
From then on, the plugin cannot change.
In future, we can expand this support to include loading multiple
plugins at once, configurable through some UI. This will have
far-reaching implications though, and complicate things like
enumerating the provider hierarchy. There is also no practical
benefit right now; the mm and ofono plugins can't be used at the same
time because ModemManager and oFono don't play nice together, and the
whole raison d'être of the dummy plugin is undermined if you can make
use of one of the others. So for now, we just implement one static
plugin.
