If folks is built with the 'eds' backend it will get used by default.
During testing the system address book should not be queried.
It might even be impossible if the environment is not set up to
connect to the session bus raising the following warning:
(process:701522): folks-WARNING **: 09:13:54.291: Failed to find primary PersonaStore with type ID 'eds' and ID 'system-address-book'.
Individuals will not be linked properly and creating new links between Personas will not work.
The configured primary PersonaStore's backend may not be installed. If you are unsure, check with your distribution.
Fixes: #427
Copied from libfeedback as of 2e081602f627505e566cc0bdb6cd96c7642d8b65
and adjusted for our mocking needs.
The mocked library will be LD_PRELOADED for the moment,
but further changes to the build should allow us to simply link
to it in the future.
Objects of this type keep track of SDP of the local and remote peers,
allow generating offers and answers and codify default policy used for
cryptographic parameters.
When setting up a binding between GSettings and GObject properties the
CallsSetting used to set the value from the GSetting to the property and
back to the GSetting.
While the value was still the default value it was marked as non default
because it had explicitly been set without any user interaction.
Fixes the deprecation warning from meson:
DEPRECATION: target sip links against shared module sip, which is incorrect.
This will be an error in the future, so please use shared_library() for sip instead.
If shared_module() was used for sip because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
This gives us a better separation of concerns and it will make it a bit easier
to move the sip independent media pieces out of the plugin in the mid to long
term.
This makes sure that a NULL id will return a NULL contact and additionally
asserts that even a NULL contact will give us sensible primary/secondary display
information.
This was handled explicitly in the Call window.
By changing the logic to delay the emission of "ui-call-removed" we make sure
that the Call UI and the exported DBus object is consistent.
We also need to change the test cases to use run a GMainLoop because we now have
to wait until signal comes in.
We mock libfeedback and CallsCall to test the ringer for the following
scenarios:
- Call state changes
- User requested silencing of ringer
- Multiple calls
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.
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.
