<div dir="ltr">Hi<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 5:18 PM, Daniel Pocock <span dir="ltr"><<a href="mailto:daniel@pocock.pro" target="_blank">daniel@pocock.pro</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<br>
If a connection manager uses some library that creates its own threads<br>
(it is not a Qt based library either), are there any constraints on how<br>
these threads interact with the TelepathyQt API?<br>
<br>
For example, if the connection is completed in another thread, is it<br>
safe to call setStatus() from that thread?<br></blockquote><div><br></div><div>It is probably not safe to call that from a different thread. If setStatus() was a Qt slot, you could use QMetaObject::invokeMethod() with Qt::QueuedConnection directly, but that's not the case. So, what you can do is to define a slot to proxy the request and use QMetaObject::invokeMethod() to call that slot.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or is there some way to propagate information from the threads used by<br>
the underlying library back to TelepathyQt?<br>
<br>
_______________________________________________<br>
telepathy mailing list<br>
<a href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/telepathy" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/telepathy</a><br>
</blockquote></div><br></div></div>