Introduce OptionsQmlModel class to bind node settings with GUI

[hebasto]

This PR adds only a basic implementation with a support for the -prune setting only.

[hebasto]

cc @jarolrod

[johnny9]

I see

2022-10-27T18:02:45Z GUI: qrc:/qml/components/StorageSettings.qml:24: TypeError: Cannot read property 'pruneSizeGB' of null
2022-10-27T18:02:45Z GUI: qrc:/qml/components/StorageSettings.qml:16: TypeError: Cannot read property 'prune' of null

in debug.log

[johnny9]

I believe you need to use qmlRegisterSingletonType and then import the registered module in order to access the object in the StorageSettings component. It seems only the root component has access to the object when using setContextProperty.

Edit: Here's a potential patch
https://gist.github.com/johnny9/0534358700749a8b5cb2008606d27cbc

A caveat with this, as Jarol mentioned in a previous PR, is that this way to register objects to the QML engine is outdated as of 5.15 but we might need some improvements to the qmake or cmake build to support the new registration macros. https://www.qt.io/blog/qml-type-registration-in-qt-5.15

Edit2: With the above patch applied, I see "prune" property being set in settings.json and 2022-10-27T20:27:34Z Setting file arg: prune = 4768 in debug.log but I also see 2022-10-27T20:27:35Z Setting NODE_NETWORK on non-prune mode. I'm not familiar enough with the details of setting pruning to know if that means it worked.

[shaavan]

Concept ACK

The implementation looks standard. But as @johnny9 suggested, we can experiment using the qmlRegisterSingletonType.

@hebasto
I know you are currently occupied with finishing the CMake project, so I would like to share the burden of the work with you.
I want to work forward on this branch if that's okay with you. Thank you.

[jarolrod]

@shaavan @johnny9 registering with the qml macro makes qml responsible for the lifecycle of the optionsmodel, we wouldn't want that. The way around this would be to subclass the qml engine, but there's no strong use-case for that right now.

[johnny9]

Is that something unique to using the macro? Is there not an equivalent of qmlRegisterSingletonInstance using the macros to allow you to manage the lifecycle yourself?

[johnny9]

Ok I found what you were referring to here https://doc-snapshots.qt.io/qt5-5.15/qqmlengine.html#QML_SINGLETON. Sounds like we should continue to use qmlRegisterSingletonInstance to override ownership of the object if we decide to use the macros.

[jarolrod]

@johnny9 seems that you are correct in suggesting we use qmlRegisterSingletonInstance for many reasons including the performance hit of context properties and the non-constant lookup time. The ownership of the object can stay with c++ and not with the qml engine by specifying the QQmlEngine::CppOwnership flag.