All parts not related to credentials are now being set when creating the nua
handles and then updated with nua_set_params() when the credentials get updated.
This is a bit of a hack to get the country code property hooked up
and will require a rework when multiple provider support is being added.
As the default origin is not being used anywhere else in the code
it's currently not a problem that we're not tracking if the default
origin is being removed.
Additionally test-manager.c needed some adjustment.
Shorten the needed sources from
calls_sources, calls_enum_sources, calls_resources,
wl_proto_sources, wayland_sources,
to
calls_sources
so adding new things such as generated dbus sources doesn't have to
happen in four locations but just one.
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.
Otherwise this can trigger test failures. Similar to what we
did in libhandy.
Fixes errors like:
---
G_DEBUG='gc-friendly,fatal-warnings' G_TEST_BUILDDIR='/home/purism/builds/calls/_build/tests' PYTHONDONTWRITEBYTECODE='yes' MALLOC_CHECK_='2' GSETTINGS_BACKEND='memory' G_TEST_SRCDIR='/home/purism/builds/calls/tests' /home/purism/builds/calls/_build/tests/manager
--- stderr ---
(/home/purism/builds/calls/_build/tests/manager:10212): dbind-WARNING **: 12:01:50.237: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
-------
The CallsBestMatchView and CallsPhoneNumberQuery classes are written
in Vala because they may be generally useful and to leave open the
possibility of adding them to libfolks itself, which is written in
Vala.
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.
