Closed strfry closed 5 years ago
Right. It would be nice if the className was something like "TupleObject<int,void,float>
"
But for that to work, we would need to be able to derive a compile time string for each variant.
This could be possibly done if vedrigris allowed to override manually the name, by creating a constepxr auto W_ClassNameOverride() -> StaticString<...>() { ... }
It would use SFINAE to detect the member, and then it could be re-implemented in TupleObject to somehow return a string that depends on the template parameter.
Implemnted with https://github.com/woboq/verdigris/pull/69
Verdigris allows to register generic QObjects:
As mentioned in #50, we derive verdigris-internal structures like ̀ w_PropertyState` from the template arguments. This aspect works fine, to expose this objects with Properties in QML.
A problem arises from the impl declaration:
The staticMetaObject's className is derived from the first argument, and is now for every template instantiation "TupleObject". Which thwarts the reflection of types based on QML's
instanceof
.Fortunately, Qt allows Alias Registration, e.g. introducing a new Type name to QML to an already registered type, through", and qmlRegisterType tries to register the
qmlRegisterType
and friends. But this doesn't work for us, likely because Qt isn't used to templates, because of moc's limitations: Since our register d className has the shape of a template "TupleObjectQmlListProperty<T>
,qNormalizedType()
, expands this to:"QmlListProperty<TupleObject<Ts...>SPACE>"
Which is inconsistent with another internal macro...So, i'm unsure if it's the right direction to push for a fix in qmlRegisterType*, when custom names for template instances in Verdrigris seems like cleaner solution. Do you guys have any ideas on this?
Regards, Jonathan