Having an EnumMap<Enum, Boolean> GUI provider would be helpful for dynamic enum-based feature lists.

EnumSet<Enum> would likely be the proper data type to use, but the GUI provider would act akin to a map rather than a set. By that, I mean users could directly toggle the boolean for a specific enum constant rather than having to add it to a list, which would only serve to confuse the user.

I'll also add that EnumMap<Enum,Boolean> is roughly isomorphic to EnumSet<Enum>, if you don't actually allow null as a value in addition to Boolean.TRUE and Boolean.FALSE. If I feel the itch around having this piece in my config screen enough, I may code this up myself based on one of the existing "list list entry" classes and share back

EnumSet<Enum> would likely be the proper data type to use, but the GUI provider would act akin to a map rather than a set. By that, I mean users could directly toggle the boolean for a specific enum constant rather than having to add it to a list, which would only serve to confuse the user.

@haykam821 I think it depends on the size of the Enum and author preference to some extent. For instance, with a large enum where the user is only expected to pick one or two items, showing toggles for every item would be onerous.

Other than the list of toggles that you mention, I could also see having a SelectionListListEntry that is a typical "list entry" that has a button like the current SelectionListEntry as the cell widget. However, instead of simply cycling through all options in the Enum as it does now, the button callback would be sensitive to which values were already in use for other buttons. You'd also want to disable the "add" button once no more items are available in the enum to avoid an undefined scenario of a button with no available options.