Simon:
I just finished reviewing the QQuickImageProvider framework
and that might also be an known interface pattern acceptable to the team.
Component { source: "memory://myqmlprovider/myqmlcomponent" }
And it may just "fit" nicely into the current "qrc:" pattern.
Just my 2 cents...
md
On 6/9
Robin:
I am fairly new to the process, and just eyeballing the source trees
does not give me a working understanding how the render thread and the
GUI thread play nice together.
So knowing the point at which to add a call to int
QQmlEngine::addComponent(QByteArray& gbqml,QString gsimportname)
On 6/9/2015 1:02 AM, Simon Hausmann wrote:
> On Tuesday, June 02, 2015 03:44:59 PM rpzrpz...@gmail.com wrote:
>> On 5/29/2015 9:53 AM, mark diener wrote:
>>> Hello dev list:
>> Maybe after the 5.5 release, I would like to explore adding public
>> access member functions to QQmlEngine.h/cpp:
>>
>> i
>>* There are the blunt force methods of QQmlEngine->clearComponentCache()
*>>* and QQmlEngine->trimComponentCache().
*>> >>* Maybe after the 5.5 release, I would like to explore adding public
*>>* access member functions to QQmlEngine.h/cpp:
*>> >>* int QQmlEngine::loadComponent(QQmlComponent& com
On Tue, Jun 2, 2015, at 11:44 PM, rpzrpz...@gmail.com wrote:
> Another concern I have is the Render Thread issues VS Gui thread issues.
Can you elaborate on this concern? The current description is impossible
to address, which might explain the lack of response.
--
Robin Burchell
ro...@virot
Hello dev list:
Qt 5.4.1.
At the top of qqmlimport_p.h, it discusses how it is NOT part of the QT API
and subject to change.
In qqmlengine.h, there is addImportPath( ) to allow qqmlimport to resolve
types using a module/qmldir file.
But ByteArray derived components have no equivalent treatment:
