no luck with Qt 5.9.2

[Tomaz Canabrava]

On Tue, Oct 24, 2017 at 3:48 PM, Jan Mulder <jlmulder at xs4all.nl> 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 <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_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
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171024/91d08415/attachment.html>