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