no luck with Qt 5.9.2

[Jan Mulder]

On 23-10-17 18:23, Jan Mulder wrote:
> 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))

Ok, after again multiple hours of searching, trying, bisecting, etc, I 
finally made some progress.

I found one commit that is in Qt 5.9.2 (and not in 5.9.1) called "Fix 
qml cache invalidation when changing dependent C++ registered QML 
singletons"
(commit 98358715930739ca8de172d88c5ce6941c275ff3 in qtdeclarative). 
Related to QTBUG-62243.

The rationale of that commit is fully sane to me, but ... I reverted 
this one, and my problem of unable to start Subsurface-mobile build with 
5.9.2 (on desktop, for now) due to a silent failure of 
engine.load("main.qml") is gone, and the mobile-on-desktop app runs 
correctly as before.

So, now the big question is ... how to proceed? I still cannot rule out 
that the whole issue is a result of some (still unknown) bug in 
Subsurface itself, or Kirigami or ... But, building a tiny bug 
demonstrator for Qt might be over my skill set :-)

For anyone that might wonder how I found this suspicious commit ... I 
found earlier that the Kirigami file Units.qml was involved, and that is 
a singleton type object. That made me search for singleton related code 
changes in Qt.

--jan