Avoid manually creating signals for every field in java

[mchistovib]

Hello,
is there a way to avoid creating signals for fields manually in java code?
Lets say we have object with 200 fields, and we don't plan to use their signals in java code, qml still requires us to create signal for every field id we use them in qml environment. Is there a way to create them automatically in compile time or runtime so we don't have to do it manually and create 200 unused signals? cc @omix

[omix]

QtJambi extracts all properties, invokables, slots and signals of a class at runtime. A signal is only detected if there actually is a signal field in Java code. It cannot be auto-generated. However, it does not make sense having a property notifiier signal without a signal field. I think you might want to call emit in the getter, don't you?

public void setFoo(int foo){
    this.foo = foo;
    fooChanged.emit(foo);
}

public final Signal1<Integer> fooChanged = new Signal1<>();

[mchistovib]

@omix when setFoo is called from QT, doesn't qt itself emit the signal automatically?

[omix]

No it doen't. When setting a property in Qt (either C++ QObject::setProperty("foo", value) or QML foo: value) QMetaObject calls Java method setFoo(value). The setter method has to call the corresponding notifier signal if the new property value is accepted. Only then all property bindings in QML are considered "dirty" causing a recalculation of the dependent properties, e.g.:
property int square: parent.foo*2

Thus, it absolutely makes sense to create a notifier signal wherever you use a property in QML. Here, programming in Java is completely analogue to using Qt in C++.

However, maybe you don't want to make these 200 fields to be mutable properties. Maybe you don't want to use them in QML bindings. I believe you can use ´eval(...)` to avoid creating a property binding.

[omix]

In fact, QProperty is the best solution to create fields that can be used in QML. However, according to my tests, QtJambi misses to set flag "scriptable" to properties defined with QProperty. Thus, QProperties cannot be used in QML up to now. The next update will fix this.

Then you can simply define:

// java:
class Singleton extends QObject{
    public final QProperty<String> text = new QProperty<>("Hello, world!");
}

Singleton s = new Singleton();
QtQml.qmlRegisterSingletonInstance(s, "test", 1, 0, "Singleton");

// qml:
import test 1.0
import QtQuick 2.0

Item{
    property string text: Singleton.text
}

Item's text will change whenever s.text changes.

If it is not possible or desirable to store the value in a QProperty, e.g. it is elsewhere computed, then you can use QComputedProperty instead:

// java:
class Singleton extends QObject{
    private String computeText(){...}
    public final QComputedProperty<String> text = new QComputedProperty<>(this::computeText);
}

Once the computed value changes you have to call text.notifyProperty(); to update all dependencies.

[omix]

Since bufix patch release 6.3.4a (also 6.2.7a) it is possible to use QProperty-based object properties from within QML.

[mchistovib]

@omix does this mean I can use this with 6.2.7 jambi from maven?

[mchistovib]

I see 6.2.7a build for some of jjambi libs, but not all. will it work with 6.2.7 jars?

[mchistovib]

https://central.sonatype.dev/artifact/io.qtjambi/qtjambi-native-windows-x64/6.3.4/overview 6.2.7 is not avilable for windows native, but available for https://central.sonatype.dev/artifact/io.qtjambi/qtjambi/6.2.7a

[omix]

It is only the module qtjambi being versioned 6.2.7a, and here, only the java component. All other artifacts and native components remain version 6.2.7 and are fully compatible to 6.2.7a.

[mchistovib]

But when I replaced 6.2.7 jambi with 6.2.7a jambi, qml stopped loading with "qrc:/mgMvp/main.qml not found" error. After rollback to usual 6.2.7 jar it started to work fine

[omix]

Ok, that's weird.

[omix]

You can use QProperty in 6.2.7a to define bindable properties:

class Singleton extends QObject{
    public final QProperty<String> text = new QProperty<>("Hello, world!");
}

Make sure to declare property fields final.
QProperty still causes issues when also defining parametrized notifier signal. I've detected this while preparing for the next release.

[mchistovib]

so QComputableProperty is still broken? I had issues with it

[omix]

I believe it should be improved in #.#.#a.