I think neither QSharedMemory or WorkerScript will fit in this case.

Let me try to explain it better. Lets suppose I have the following basic model 
class

class Model {
        QML_PROPERTY ListOfTypeA
        …

        QList<TypeA*> _listOfTypeA
}

where

class TypeA {
        QML_PROPERTY ListOfTypeB                
        …

        QList<TypeB*> _listOfTypeB
}

class TypeB {
        properties
        …
}

The UI represents this model and interaction with it can changes the model, 
adding/removing instances of TypeA, adding/removing instances of TypeB, 
modifying properties inside of TypeB objects, etc. Everything regarding the 
model is written in C++

As I see it, I would need a Model that could be plugged to Qml in order to 
display its properties, and at the same time, having a thread iterating thru 
that model doing things. 

The problem I always end up is that I cannot plug the Qml to that model if that 
model is running on a different thread.

When I think in making the glue between a model that is attached to QML and 
another model that is running on a different thread, I cannot find a simple way 
of doing it. 

Sorry, I have some difficulty in describing this problem in english.

Is there any will know pattern for this problem? Maybe the solution is 
accomplished with your suggestions but i’m still in the dark.

Regards,

Nuno Santos
Founder / CEO / CTO
www.imaginando.pt
+351 91 621 69 62

> On 21 Oct 2015, at 14:57, Jérôme Godbout <jer...@bodycad.com> wrote:
> 
> You were probably aware of that but just in case, you may want to take a look 
> at Worker Script:
> http://doc.qt.io/qt-5/qml-workerscript.html 
> <http://doc.qt.io/qt-5/qml-workerscript.html>
> 
> or other Qt multi threading:
> http://doc.qt.io/qt-5/threads-technologies.html 
> <http://doc.qt.io/qt-5/threads-technologies.html>
> 
> We made a parallel QQmlEngine with it's own Qml objects tree and cloning or 
> moving object between them. I don't recommend it, it was painful regarding 
> Qml singleton (from qmldir singleton are not created by engine, C++ one on 
> the other hand can be created properly) and some others minor things. 
> Performance wise you need a lot of processing to be worth it. But Worker 
> Script may be what you are looking for, sadly only basic type can be exchange 
> between the working scripts.
> 
> 
> 
> On Wed, Oct 21, 2015 at 9:01 AM, Konstantin Tokarev <annu...@yandex.ru 
> <mailto:annu...@yandex.ru>> wrote:
> 
> 
> 21.10.2015, 13:28, "Nuno Santos" <nunosan...@imaginando.pt 
> <mailto:nunosan...@imaginando.pt>>:
> > Hi,
> >
> > I have been building a complex UI based on a data model that didn’t 
> > required threading. All the things could happen in the UI thread.
> >
> > Now I’m adding to that model a functionality that works under time critical 
> > events that can’t be compromised by UI interactions. This is specially true 
> > on mobile devices where the computing power is not abundant.
> >
> > As far as I know and from my testings, I can't expose to QML objects that 
> > are on a different than the GUI.
> >
> > Before advancing to a major refactor where all the time sensitive parts are 
> > running on a different thread and asynchronously updating it’s state to the 
> > UI thread, I would like to have your opinion about it.
> >
> > Is this my only option? Keep a clone model of my data on a different thread 
> > and respond to it’s updates on the UI thread?
> 
> You may want to use shared memory to avoid cloning of data.
> 
> 
> --
> Regards,
> Konstantin
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org <mailto:Interest@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/interest 
> <http://lists.qt-project.org/mailman/listinfo/interest>
> 

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to