[Development] qqmlengine/qqmlimport access

[md at rpzdesign.com]

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/2015 1:02 AM, Simon Hausmann wrote:
> On Tuesday, June 02, 2015 03:44:59 PM rpzrpzrpz at gmail.com wrote:
>> On 5/29/2015 9:53 AM, mark diener wrote:
>>> 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:
>>>
>>>
>>> QByteArray  gbytes("import  QtQuick  2.4\n  Rectangle  {
>>> objectName:\"myRecto\"\n  color:  \"blue\"  }");
>>>
>>> QQmlComponent  gcomponent(&gengine)  ;
>>>
>>> gcomponent.setData(gbytes,QUrl("Myrectangle.qml"));
>>>
>>>
>>> How to add the QQmlComponent in the QQmlEngine import database so that
>>> QQmlImports::addImplicitImport( ) can resolve component type?
>>>
>>> There is no new C++ type here, just a new component defined in QML, so
>>> qmlRegisterType<C++type>(bla,bla,bla) is a fail.
>>>
>>> Or maybe there is a non-qmldir file method to use importExtension with
>>> QQmlComponent?  (qmldir file alternative)
>>>
>>> Does QQmlEngine have a public access way to achieve the following:
>>>
>>> QQmlEngine::addImportComponent(QString gname,QQmlComponent& gcomponent) ;
>>> QQmlEngine::removeImportComponent(QString gname) ;
>>>
>>> In QML, I could either have an importExtension()  OR an implicitImport()
>>> in qqmlimports.
>>>
>>> Thanks,
>>>
>>> Mark
>>
>> Simon:
>>
>> I think the absence of responses from the dev list indicates I have
>> touched on a topic dead zone that resides in your area as QML/core
>> maintainer.
>>
>>   From what I can tell, the QML component cache and import mechanisms
>> lack any public access members for direct query,loading, and removal.
>
> Yes.
>
>> 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& component, QString&
>> importQmlName);
>>
>> int QQmlEngine::clearComponent(QString& importQmlName);
>>
>> bool QQmlEngine::isComponentLoaded(QString& component);
>>
>> The biggest concern I see is the caveat warnings given by qqmlimport.h
>
> I'm wondering what the specific use-cases are. More specifically what criteria
> would be used to call these functions?
>
> If you'd like to "pre-load" components, then I agree that we could have
> dedicated API for this, although you can already do this today by creating an
> async QQmlComponent and just not call create() on it.
>
>> Another concern I have is the Render Thread issues VS Gui thread issues.
>>
>> What group of devs is current this?
>>
>> Does that group even talk to strangers?
>
> Hehe.
>
>
> Simon
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

-- 
No spell checkers were harmed during the creation of this message.