[Librem-5-dev] MMCall objects from CallAdded signal

[Bob Ham]

On 17/07/18 20:47, Aleksander Morgado wrote:

> Yes, for "watching" new calls being added, you can connect to the
> "call-added" signal in the MMModemVoice interface-specific object.
> Once you have the path to the call object, you can list existing calls
> with mm_modem_voice_list_calls() and get a MMCall when the path
> matches.

I've implemented this scheme but unfortunately it doesn't work due to
how the generated MmGdbusModemVoiceSkeleton class emits D-Bus signals
for changed properties.

In the ModemManager daemon, the call_added() function in
mm-iface-modem-voice.c makes sense: it calls
mm_gdbus_modem_voice_set_calls() to set the Calls property on the D-Bus
skeleton and then calls mm_gdbus_modem_voice_emit_call_added() to emit
the CallAdded D-Bus signal.  However, the skeleton object doesn't send
out the PropertiesChanged D-Bus signal immediately.

The skeleton object queues changed properties on a list (in
mm_gdbus_modem_voice_skeleton_set_property()) and then sets an idle
callback (in mm_gdbus_modem_voice_skeleton_notify()) which in turn emits
the PropertiesChanged D-Bus signal.

This means that the CallAdded D-Bus signal is emitted immediately while
the PropertiesChanged D-Bus signal is emitted some time later, whenever
the main loop becomes idle.  As a consequence, the MMModemVoice's
"call-added" GObject signal is emitted before the MMModemVoice's call
list contains the relevant MMCall object.

My software reports this:

"No calls on MMModemVoice `SIMCOM_SIM7100E' after call-added signal"


I'm not sure how the high-level libmm-glib API could deal with this.
For me, I think immediately I'm going to have to forego the high-level
APIs and make direct use of the generated MmGdbusModemVoice API,
listening to the GObject notify signal for the proxy object's "calls"
property and then comparing the call list with my internal data.


Regards,

Bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.puri.sm/pipermail/librem-5-dev/attachments/20180723/4d113a2b/attachment.sig>