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.
While not every class or interface is properly documented and annotated yet,
adding them to the docs should still be valuable.
Additionally it is a good reminder for ourselves to add some proper description
because things like missing a annotated class description really stand out
currently.
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.
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.
When introducing the per protocol dial actions we started setting the widget
self->target as the action target instead of the target property of
self->record.
Bizzarely we only sometimes got greeted with a critical:
11:30:20.5184 GLib[887977]:CRITICAL: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failed
Thread 1 "gnome-calls" received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff7ea400e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1417
1417 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
at ../../../glib/gmessages.c:2898
Fixes: 687dd7ff383476523ae0a8a38879a171cb0b9a5a
Closes#398
By connecting to the "ui-call-added" and "ui-call-removed" signals instead of
"call-add" and "call-remove".
This allows us to shave off a few lines of code.
This is part of a refactoring which should help separating concerns between
CallsCall and CallsUiCallData better.
To accomplish this we want to stop passing around CallsCall objects and instead
pass CallsUiCallData objects.
In this commit we added new signals instead of changing the existing ones
because that results in a lot of churn. It allows to do the switch per module
allowing smaller individual patches and a more manageable patchset.
