QT designer with custom widget plugin setting incorrect qualified enum property name

[hippos]

Hi all I am seeing some strange outcomes when using QT designer and a custom widget plugin.

I have declared an enum like so. I originally tried with the enum inside a class that extended QObject (while using the Q_ENUM macro) and the results are the same.

namespace SettingsTypes
{
    Q_NAMESPACE

    enum class Network {
        NETWORK_IP,
        NETWORK_PORT
    };
    Q_ENUM_NS(Network)
}

My widget declares the enum as a property.

class QDESIGNER_WIDGET_EXPORT SettingsWidget : public QLineEdit {
Q_OBJECT
    Q_PROPERTY(SettingsTypes::Network setting READ getSetting WRITE setSetting)

public:
    explicit SettingsWidget(QWidget *parent = nullptr);

    SettingsTypes::Network getSetting();
    void setSetting(SettingsTypes::Network s);


public slots:
    void valueChanged(const QString &);

private:
    SettingsTypes::Network setting;
};

At this point everything works great, the widget shows up in designer. I can even use the widget in my main app.

The issue I am facing is when I select my settings property value in designer (which shows up correctly with my list of enum values) and then build the app, I see this.

 error: 'NETWORK_IP' is not a member of 'SettingsTypes'; did you mean 'SettingsTypes::Network::NETWORK_IP'?

Which is happening from the designer generated code.

settingswidget->setSetting(SettingsTypes::NETWORK_IP);

It appears to be messing up the qualified name for the enum. If I change the generated code to SettingsTypes::Network::NETWORK_IP everything compiles and is happy.

Any ideas how designer has gotten confused? I have tried to call qRegisterMetaTypeSettingsTypes::Network("SettingsTypes::Network"); in the widgetplugin constructor but that didn't make a difference either. I am using CLion and CMake if you think that could have an effect.

[Christian Ehrlicher]

I'm not sure if 'enum class' is supported here. Maybe search the bug report system and/or create a bug for it.

[hippos]

@Christian-Ehrlicher damn, you are correct. Making it an Enum fixed it. Thanks!