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
This includes the following changes:
- Introduce a `providers` hash table to keep track of multiple CallProvider's
and remove the `provider` member
- Remove `calls_manager_get_provider()` and `calls_manager_set_provider()`
in favour of `calls_manager_add_provider()`, `calls_manager_remove_provider()`
and `calls_manager_has_provider()`
- Introduce a `origins` GListStore to keep track of available origins.
`origins` is updated in `items_changed_cb()` when the origins of any
CallsProvider are updated.
- Adapt to changes with respect to `calls_manager_get_origins()`.
- Introduce `origins_by_protocol` hash table to keep track of available origins
per protocol.
- Adjust tests
- We temporarily break country code lookup which was handled previously
with the "default-origin" mechanism. We will add it back to the CallsSettings
class which will provide a better application-wide mechanism.
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.
* src/calls-manager.h: Add lookup function to header
* src/calls-manager.c: Implement lookup function to be used for the call
history, call notifier and call display
* src/calls-call-holder.c: Use calls_manager_get_contact_name ()
* src/calls-notifier.c: Use calls_manager_get_contact_name ()
The manager is a central place for handling data e.g. calls history and
provider managment.
This introduces only the base for feature work. Therefore it manages
only the provider for now, but the manager isn't yet used anywhere.
The propagets events from the provider and origins. It also adds a new
signal called `error`. The `error` signal should be emited only when
something went wrong and we need to inform the user about it, containing
the message to be displayed to the user. Windows should connect to the
event and display a in-app-notification on error. This event isn't
emitted, because the plugins don't give us a usable error.
