On Tue, Oct 24, 2017 at 3:48 PM, Jan Mulder <[email protected]> wrote:
> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On Mon, Oct 23, 2017 at 5:37 PM, Jan Mulder <[email protected] >>>> <mailto:[email protected]>> 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_BUI >> LD_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. This is something that we can poke thiago, and thiago can poke more people. And it's a serious issue as this can break a lot of usecases of qt. > > --jan > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
