LGTM, although it would be good to have an example experimental option.

Just to show a basic UI and RNA usage.

Suggest adding a UserDef_Experemental struct, where members can be added/removed, so flags aren't set elsewhere which may be used for a different purpose later on (if the experimental feature is removed).

Alright, patch finished. I include also an example panel. If you commented it out, register it and add real RNA/DNA properties you get:

Looks good. And it’s nice that you included links to phabricator also. Do you think it’s worth adding text here, or should we just add that in the Phab task instead?

Extra text can be in the tooltip I think, or in the task. Committing this to master then.

For the records, P1156 (manual entry, waiting for 2.81 manual to be out of the way so I can commit this).

As this is fine for adding new stuff. I do see the next limitations with this system in terms of maintainability/usability

• When a feature becomes mainstream the experimental flag must be cleared, otherwise the features get enabled without the user action.
• it is unclear what the rules of this system is. When is a feature enabled? Currently there are 3 toggles
  • I assume that Developer Extras does not do anything in the equation as it only shows options that are normally hidden to users
  • A feature is always active when USER_EXPERIMENTAL_ALL or the feature flag is enabled.

I would have liked to see more utility functions to help developers using this feature so the system would reduce the maintainability.

For example we could have a List of FeaturesID. This ID is not a flag but an integer value that can be increased. Having runtime data in the userprefs that flattens this list to a bitflag list. This list is updated every time a user changes the userprefs. The enable experimental all can be incorporated in this list, or added as a precheck to a function. Using this system the maintainability when something gets mainstreams will be reduced alot as no migrations are needed. I wouldn't want to clean them up as that might interfere when switching branches.

Add a some helper functions to help developers check for enabled features. Don't let us assume anything.

Hi @Jeroen Bakker (jbakker), thanks for the feedback. I'm just a bit concerned about over-engineering something that hasn't even being used yet.

Now, are you effectively suggesting we change the experience for the end user (i.e., how granular they can enable a feature)? Or did I misinterpret you?

When a feature becomes mainstream the experimental flag must be cleared, otherwise the features get enabled without the user action.

Correct, and to avoid branches problems, the cleaning can happen only on new releases or when we bump subvresion.

I assume that Developer Extras does not do anything in the equation as it only shows options that are normally hidden to users

Correct.

A feature is always active when USER_EXPERIMENTAL_ALL or the feature flag is enabled.

Correct.

For example we could have a List of FeaturesID.

How would that allow a user to pick and choose what they want to test? And when something goes mainstream and we want to reuse an old ID what do we do to prevent this being already enabled in files that have a high feature id enabled?

Thanks for the answers to the questions. Of course they should go to an official documentation :-)

I didn't suggest to change anything from the user experience. Those changes can easily handled by the RNA.

The suggestion was to in stead of using DNA flags to use a list of ID's in the DNA. I think it is more extensible and therefore more useful for development, feature will then be used more quickly and related bugs would be reduced.

Perhaps we should continue this topic on devtalk.