Add a flag so custom classes and custom enums are only usable as class members

[adrien-bon]

Feature request description
As far as I know, it is currently not possible to select which custom enums we see when adding a new property.
We always see all available enums, while some of them could only be used through custom classes (and not directly added as properties).
It would be nice to be able to select which enum to show or to hide.

Describe the solution you'd like
When creating a new custom enum, add the possibility to hide it when adding new properties, ie. to not use it as a property value.

It could be done the same as for custom classes, by adding a Property value tickbox:

For JSON export, we could use the same useAs array but only take into account the property value.

[eishiya]

Class members and properties directly on objects are all "properties". The reason Classes have a checkbox for use as property values is that they can also be Classes set on objects (causing those objects to inherit the class members as top-level properties), which isn't something that makes sense for Enums. Since Enums can only be property values, they don't have the checkbox.

That said, I do think it would be nice to have an additional checkbox or something to distinguish enums and classes that are intended for use only as class members from those intended to (also) be top-level properties. This should be available for both classes and enums, not just enums.

For now, a common workaround seems to be to use prefixes to make the property list easier to navigate, but it would be nice if these weren't necessary.
A different possible solution to this problem (and organisational problems due to having many classes more generally) is to allow a custom sort order on custom property types instead of listing them alphabetically, so that "unwanted" types can be put at the end, and so related types can be together.

[bjorn]

I've noticed the same issue, not just for enums but also for classes. I guess it's quite a common need that some of your types are simply never relevant on their own but only as class members (or also, that some properties are only used as property values and never as class members?).

I guess we can indeed just have another usage flag for "class member" separately from "property value" and to also add these usage flags for enums. Just a little tricky to add this in a backwards-compatible way.

[adrien-bon]

Class members and properties directly on objects are all "properties". The reason Classes have a checkbox for use as property values is that they can also be Classes set on objects (causing those objects to inherit the class members as top-level properties), which isn't something that makes sense for Enums. Since Enums can only be property values, they don't have the checkbox.

Oh! I did not see that!
Yeah, you are right. I though that by un-ticking the Property Value tickbox I was only preventing to add this class as a custom property, but actually it also prevents me from using it as a member in another class.

That said, I do think it would be nice to have an additional checkbox or something to distinguish enums and classes that are intended for use only as class members from those intended to (also) be top-level properties. This should be available for both classes and enums, not just enums.

That would be my actual feature request :)
I'll rename the issue accordingly.

For now, a common workaround seems to be to use prefixes to make the property list easier to navigate, but it would be nice if these weren't necessary.

I'm actually importing several hundreds of pre-existing types so not a practical solution for me.

A different possible solution to this problem (and organisational problems due to having many classes more generally) is to allow a custom sort order on custom property types instead of listing them alphabetically, so that "unwanted" types can be put at the end, and so related types can be together.

A custom sort order would be very nice to have, or some way to filter out some types dynamically ?
But probably more complicated to implement.