[Interest] 5.5/5.6 QMLEngine management

[Bo Thorsen]

Den 10-01-2016 kl. 03:21 skrev mark diener:
> Hello List:
>
> I have a couple of core QMLEngine questions:
>
> Basic Code Snippet:
>
> QQmlEngine geng ;
>
> QQmlComponent gcomp(&geng)
> gcomp.setData( ByteArrayofQML , QUrl() ) ;
> gcomp.create() -> Show the QML in the QML Engine
> if (gcomp.isError() == false) -> we have visible QML!
>
> 1) How does one cause all properties in the root context for QML
> engine be triggered to re-evaluate their bindings again. For example
> Text { text: gvariable }, it want text object to re-fetch its own
> values instead of pushing values with Qobject->setProperty().  Generic
> pull instead of specific push.
>
> Can I cause a disturbance in the QmlContext and that would trigger and
> "expensive" refetching of text values for example.

On one hand, this question doesn't make sense. QML vars are considered 
changed immediately, and that's a basic design choice.

OTOH, it's very simple to do this yourself. Just create a function that 
pulls in the new variable values. You might need a proxy object between 
the real value place and the QML land, but other than that you need no 
tricks for it.

> 2) How does one clear out everything loaded in the root QmlEngine context?
>
> What is the best way to clear the root context of qmlengine of
> everything prior to calling
> gcomp->setData() and  gcomp->create( ) to load brand new QML into the QmlEngine?
>
> geng->clearComponentCache() ?  Does this really flush everything out
> regardless of anything that is currently visible on-screen?
>
> I do not want to build up a pile of QObjects in the engine, I want
> them cleanly flushed out.

Again, there are ways you could do this. Store the set of accepted vars 
and values and reset to exactly those when you want, for example.

But this idea smells badly of a fundamentally bad design. If you need to 
get rid of variables, reset them, etc. then they probably shouldn't be 
stored as context on the root engine. This sounds like one of the "how 
do I do B" because you are doing "A" already questions, and the problem 
is that "A" is wrong. We get those on this list all the time.

One idea I have used often is to have a backend object that is almost 
the only object exposed to QML. Inside this one you can set variables on 
the fly as you want. With the very limited amount of info you have given 
here this seems like a much more appropriate direction for you.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu