no luck with Qt 5.9.2

Jan Mulder jlmulder at xs4all.nl
Mon Oct 23 09:23:48 PDT 2017


On 23-10-17 17:44, Dirk Hohndel wrote:
> 
>> On Oct 23, 2017, at 11:41 AM, Tomaz Canabrava <tcanabrava at kde.org 
>> <mailto:tcanabrava at kde.org>> wrote:
>>
>>
>>
>> On Mon, Oct 23, 2017 at 5:37 PM, Jan Mulder <jlmulder at xs4all.nl 
>> <mailto:jlmulder at xs4all.nl>> wrote:
>>
>>             Unfortunately, very very limited progress. I found out
>>             that 2nd code fragment above does not tell the whole
>>             story. Obviously, it needs an "import QtQuick.Controls
>>             2.2" the get the ApplicationWindow defined. However,
>>             adding "import org.kde.kirigami 2.0 as Kirigami" triggers
>>             the exit on the "can't create window object". So, its only
>>             one input that triggers the error of an almost empty main.qml
>>
>>             The big question is now: is it Kirigami or Qt/QML? Of even
>>             a combination of both?
>>
>>
>>         Have you tried running this under strace to see if it tries to
>>         open some library that it can't find or something?
>>         I haven't been able to reproduce this on the desktop, only on
>>         iOS for some reason - and I have no idea how to run strace
>>         there :-(
>>
>>             I even tried to compile mobile-on-desktop against the beta
>>             of Qt 5.10.0. No luck there, and the exact same behavior.
>>
>>
>>
>>     Ok, again having some time after the release of 4.7.1, I
>>     investigated this issue further.
>>
>>     First. I'm (still) very tempted to say that it is a Kirigami
>>     issue, that's why I put Marco in the to list.
>>
>>     With commenting 1 line of code in Kirigami, the Subsurface code:
>>     engine.load(QUrl(QStringLiteral("qrc:///qml/main.qml"))) passes.
>>     That one line of code is:
>>
>>     qmlRegisterSingletonType(componentUrl(QStringLiteral("Units.qml")), uri,
>>     2, 0, "Units")
>>
>>     from kirigamiplugin.cpp.
>>
>>     Obviously, our code fails somewhere later, as we use the units
>>     extensively. Looked trough the git history of Kirigami and do not
>>     see anything obvious, so I am still not 100% sure that it is
>>     Kirigami, as there is also some relation to Qt 5.9.2.
>>
>>     So, Marco, do you see any lead here what might be going on? I just
>>     do not understand enough with respect to qmlRegisterType stuff.
>>
>>
>> This tries to register a C++ class into the Javascript engine that 
>> serves Qml, it will fail in runtime if it doesn't finds the Qt plugin 
>> for the type or if the string with the classname in the 
>> qmlRegisterType has a typo.
>> can you check if your kirigami shared lib is $QT_PLUGIN_PATH ?
> 
> We're building Kirigami as static library, right? Is something with that 
> broken?
> See CMakeLists.txt

The function where that one is commented out is 
KirigamiPlugin::registerTypes(). There are at least 20 qml files 
registered as type. Only the Units.qml poses a problem. There is no 
issue with not finding libs (and yes its static: 
add_definitions(-DKIRIGAMI_BUILD_TYPE_STATIC))

--jan



More information about the subsurface mailing list