self->best_match is never NULL:
The test suite used to wrap calls_contacts_provder_new() to always return
NULL which in turn caused the best match to be NULL.
This was done to avoid warnings raised by libfolks
about missing the primary store (eds).
This is no longer necessary as the environment now tells folks which
backend to use.
self->best_match is never NULL:
The test suite used to wrap calls_contacts_provder_new() to always return
NULL which in turn caused the best match to be NULL.
This was done to avoid warnings raised by libfolks
about missing the primary store (eds).
This is no longer necessary as the environment now tells folks which
backend to use.
self->best_match is never NULL:
The test suite used to wrap calls_contacts_provder_new() to always return
NULL which in turn caused the best match to be NULL.
This was done to avoid warnings raised by libfolks
about missing the primary store (eds).
This is no longer necessary as the environment now tells folks which
backend to use.
15 ms does not seem to be enough time for phosh-antispam to be able
to hang up before the incoming call screen shows up. In my experiement,
90 looks to be the minimum time needed for the incoming call to not show up.
I put it to 100 ms just to be safe.
The designs for the call details show information on the type of the call:
https://gitlab.gnome.org/Teams/Design/app-mockups/blob/master/calls/calls.png
So f.e. "Cellular", "Matrix WebRTC Video Call".
These properties can potentially also be useful in choosing the mechanism to
use for the audio controls from the call display.
This "ui-active" property should be set to FALSE for new incoming calls and set
to TRUE after a short delay of 20ms. This property is used to delay showing the
call display and starting to ring.
This delay gives DBus clients like
phosh-antispam (https://gitlab.com/kop316/phosh-antispam)
some time to make a decision whether a call should be hung up or not and defer
starting to ring and showing the display only afterwards.
We already had our mapping between CallsCallStates and CuiCallStates in place,
but the _DIALING state got renamed to _CALLING.
Additionally bundle CallsCallStates that map to the same CuiCallState to remove
some code.
We need a proxy object because implementing the CuiCall interface in the
CallsCall base class has it's own set of problems (f.e. the "state" property
would have a type collision CallsCallState vs CuiCallState).
