Skip to content

(feat): Config Dependency improvements #650

@MicrocontrollersDev

Description

@MicrocontrollersDev

Is your feature request related to a problem? Please describe

Config dependents are annoying, especially when they span (sub)categories

Describe the behaviour you'd like

  1. When a dependency leads to an option being disabled, there should be a reasoning given as to why (meaning it should clearly state what needs to be enabled).
  2. Might also be useful if the option cannot be toggled/changed as the fade isnt that apparent
  3. Easier way to create inverse dependents (if config option A is on, B and C are disabled). Currently have to do
    "B", "UNUSED STRING", () -> A ? Property.Display.DISABLED : Property.Display.SHOWN. This also applies to hideIf, which I'm not sure can even do this.

Describe alternatives you've considered

I don't want to have to clog already long descriptions when the dependency should be signifying this.

Additional context

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions