Early PR for Custom/Enum Props

[svipal]

resolves #1211
Hello ! I've started to implement enum props, as discussed in the discord and on the linked issue.

I made an early PR even though not everything is implemented, as suggested by bjorn.
Here's what's not yet in it :

• enum props are the only possible custom props instead of just one subclass
• properties of custom type do not persist between sessions

Here's what works :

• loading/saving custom properties from project
• editing/saving enum props with the editor
• making new properties with thus made "enums"

Let me know what you think !

[bjorn]

It's a good start! But I think there's one major issue, which is that you're storing the whole definition of the custom type with each value. I think they should be separated. We can have a "default value" member of the custom type (though I'd say we pick the first one by default for now), but the actual value should not be stored along with the type definition.

I think we need a separate struct for storing the value, something like:

struct CustomValue
{
    QVariant value;
    QString type;
};

It's going to be a bit confusing, but we would then store this in the QVariant storing a property value, and when value.userType() == qMetaTypeId<CustomValue>(), we'd be able to look up both the actual value (using value.value<CustomValue>().value) and its type. We'd use the type to look up the information about the type so that we can set up appropriate widgets in the VariantEditorFactory.

In addition:

• The toExportValue function would need to handle custom types.

• typeToName will need to take the full QVariant as parameter instead of just the type ID, so that it can return the CustomValue::type member when appropriate.

• nameToType can't just return a type ID anymore. I think the function can be integrated into fromExportValue, passing the type as string instead of int to that function. Considering this, it probably makes sense to integrate typeToName also with toExportValue, probably making it return a CustomValue with the value member being the value for export and the type member the type name to export.

I've left further minor comments inline.

[edin-m]

Is this being worked on?

[bjorn]

@edin-m There hasn't been any activity for some months, so I think this change is currently abandoned. Since it's still a priority request from a sponsor I do intend to start work on it soon. Are you asking because you'd like to help complete this feature?

[edin-m]

Maybe... I'll see after the components feature.

[bjorn]

I've rebased the changes on the latest master and applied some initial review feedback. I plan to continue working on this change with the goal of finishing it later this week.

[bjorn]

So in the end, we now have (stripped):

struct PropertyType
{
    int id = 0;
    QString name;
    QStringList values;
};

struct PropertyValue
{
    QVariant value;
    int typeId;
};

Where the property types (stored in the project) are for now only defining enums with their possible values, and the property value class always wraps an int value together with the ID of the enum type. This is then used by the Properties view to display the value using a combo box where the other possible values can be selected.

When saving and loading, the value is currently written as its string value alongside the name of its type. This may still change, to either replace it with the int value and type ID or to add those alongside.

Thank you @svipal for getting this change started!