[Development] Changed enum property behaviour in Qt v6.8

[Phil Thompson]

Hi Fabian,

The change was https://codereview.qt-project.org/c/qt/qtbase/+/559265

Reverting this change means I get the same behaviour as I get with v6.7.

I am (and always have been) using QMetaObjectBuilder and addEnumerator() 
(the overload that takes a QByteArray argument).

I've compared the following scenarios...

a moc-generated meta-object where Q_ENUM is not used
a moc-generated meta-object where Q_ENUM is used
a dynamically created meta-object.

...for v6.7.1, v6.8.0 and v6.8.0 with the change reverted. In each case 
I looked at the results of...

QMetaEnum.metaType().isValid()
QMetaProperty.metaType().isValid()
QMetaProperty.isEnumType()

The results in all cases for v6.7.1 and v6.8.0 with the change reverted 
were identical.

For moc-generated meta-objects...

- the results were consistent across all versions of Qt
- QMetaProperty.metaType().isValid() always returned true (even if 
QMetaEnum.metaType().isValid() returned false)
- QMetaProperty.isEnumType() returned true if Q_ENUM was used and false 
if it wasn't

For dynamically created meta-objects...

- the results were dependent on the version of Qt
- QMetaProperty.metaType().isValid() always returned false
- QMetaProperty.isEnumType() returned true for v6.7.1 and false for 
v6.8.0

I was surprised by the result of QMetaProperty.isEnumType() for a 
moc-generated meta-object without Q_ENUM. The docs suggest this should 
be true for all enums whether or not Q_ENUM is used.

This actually means that the v6.8 dynamic behaviour is closer to the 
moc-generated behaviour but means it seems to be impossible to 
dynamically create an enum property where QMetaProperty.isEnumType() 
returns true.

Some questions...

Why does QMetaProperty.metaType().isValid() always return true for 
moc-generated meta-objects and false for dynamically created 
meta-objects?

Is there any way to dynamically register an enum with the meta-type 
system (so that QMetaEnum.metaType().isValid() returns true)?

Regards,
Phil

On 04/10/2024 08:02, Fabian Kosmale via Development wrote:
> Hi Phil,
> 
> I'm not quite sure which change caused the issue, and I believe a
> bugreport with a reproducer might shed some light on the issue.
> 
> Nevertheless, if you're already using the private QMetaObjectBuilder
> API, I would expect that it should work if you build the enum also
> dynamically via addEnumerator and then working with the returned
> QMetaEnumBuilder.
> 
> Kind regards,
> Fabian
> 
> On 03.10.24 17:52, Phil Thompson via Development wrote:
>> On 03/10/2024 16:31, Volker Hilsheimer wrote:
>>>> On 3 Oct 2024, at 17:07, Phil Thompson via Development 
>>>> <development at qt-project.org> wrote:
>>>> 
>>>> On 03/10/2024 15:44, Thiago Macieira wrote:
>>>>> On Thursday 3 October 2024 05:06:08 GMT-7 Phil Thompson via 
>>>>> Development wrote:
>>>>>> Yes, that's the change - commenting out the new test fixes the 
>>>>>> problem.
>>>>>> I am dynamically building the meta-object. You don't really build 
>>>>>> an
>>>>>> enum, you just provide a description of it to the meta-object. It 
>>>>>> would
>>>>>> be nice to be able to register an enum with the meta-type system
>>>>>> dynamically.
>>>>> Or you can set the EnumOrFlag flag in the QMetaProperty flags field 
>>>>> to
>>>>> force the
>>>>> constructor to search.
>>>> 
>>>> Sorry, can you be more specific? I can't see how to do it given the 
>>>> private nature of the flags.
>>>> 
>>>> Phil
>>> 
>>> 
>>> Hey Phil,
>>> 
>>> How do you generate a dynamic meta object without using private APIs?
>>> Do you use QMetaObjectBuilder (which is private), or do you generate
>>> the tables and arrays by hand?
>>> 
>>> If you use QMetaObjectBuilder, then
>>> QMetaPropertyBuilder::setEnumOrFlag would be the way to go.
>>> 
>>> Volker
>> 
>> I'm using QMetaObjectBuilder and already calling setEnumOrFlag, so 
>> that doesn't seem to solve the problem.
>> 
>> An alternative that would work for me would be to bypass the new test 
>> if the meta-type was invalid (ie. the enum wasn't registered) but I 
>> don't know if that would nullify the purpose of the new test.
>> 
>> Phil
> 
> --
> Fabian Kosmale
> Manager R&D
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> fabian.kosmale at qt.io
> +49 1638686070