On Tue, Oct 13, 2015 at 5:39 PM, Daniel Pocock <[email protected]> wrote:
> > > On 13/10/15 22:34, Gustavo Boiko wrote: > > Hi > > > > On Tue, Oct 13, 2015 at 5:18 PM, Daniel Pocock <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > > > If a connection manager uses some library that creates its own > threads > > (it is not a Qt based library either), are there any constraints on > how > > these threads interact with the TelepathyQt API? > > > > For example, if the connection is completed in another thread, is it > > safe to call setStatus() from that thread? > > > > > > 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. > > > > > > > Thanks for the feedback - could you suggest any example of this in > another connection manager or similar code that I can look at? > I don't recall seeing another CM with that, but it would be something like this: class MyConnection : public Tp::BaseConnection { ... public Q_SLOTS: void setStatusSlot(uint newStatus, uint reason) { setStatus(newStatus, reason); } } and then, in the other thread you would call: QMetaObject::invokeMethod(myConnectionObject, "setStatusSlot", Qt::QueuedConnection, Q_ARG(uint, status), Q_ARG(uint, reason)); That should be more or less what you need to do in your CM. Cheers Boiko
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
