21.10.2015, 17:15, "Nuno Santos" <nunosan...@imaginando.pt>:
> 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.
You can make pointer to your model accessible from code of your Qml-facing
classes, then read and modify it from both threads. Don't forget to add mutexes
to prevent races
>
> 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
>>
>> or other Qt multi threading:
>> 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>
>> wrote:
>>> 21.10.2015, 13:28, "Nuno Santos" <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
>>> http://lists.qt-project.org/mailman/listinfo/interest
--
Regards,
Konstantin
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
