Add ignoreDisabled to @Config

[ryleu]

Adds a field in @Config that lets you override the @Disabled annotation, adding the configuration variables to the dashboard regardless of whether @Disabled is present.

[ryleu]

Forgot to give my reasoning for adding this, so here it is:

We use a single variable to enable and disable vast swaths of op modes at once, aka the RR tuning op modes. The way we do this is by making use of the @OpModeRegistrar annotation and putting @Disabled on all of our tuning op mode classes. The issue with this is it disables the config too. By having this option be configurable, we could put that boolean into @Config and override @Disabled's effect on the config.

If you aren't sure what I mean, look here.

This is one (admittedly odd) use-case, but I'm sure others will find more.

[rbrott]

Thanks for the patch. I haven't used these APIs in a while, but I believe you can remove both @Disabled and @Autonomous/@TeleOp from each tuning op mode to solve your problem.

[ryleu]

Thanks for the patch. I haven't used these APIs in a while, but I believe you can remove both @Disabled and @Autonomous/@TeleOp from each tuning op mode to solve your problem.

It throws an error if you try to register a class that does not have either @Teleop or @Autonomous from what I can remember. I can double check that, though.

[ryleu]

Update on this: I tested it and it does work, but now there's no way to disable the config when I don't want the op modes to show up on the dash.

I guess a better plan of action would be to make a boolean you can pass in to turn it off. I'm going to close this PR and make a new one with that patch instead.

[rbrott]

I guess a better plan of action would be to make a boolean you can pass in to turn it off.

I'm assuming "it" here is a @Config annotation. How does this approach compare with commenting the @Config out?

[ryleu]

The benefit of letting people pass a boolean is that they can enable / disable swaths of config settings with one variable change. I am planning on using this to register and enable the config visibility of all of the tuning op modes for roadrunner so I don't have to go through all 15-odd classes and edit 2 lines in each every time we make a hardware change to our robot.

By "it", I mean @Config.

It would be great if I could basically do this (please excuse the pseudocode):

TuningMode.java:

public class TuningMode {
    public static final boolean enableTuning = true;

    @opModeRegistrar
    public static void register(OpModeManager manager) {
        if (enableTuning) {
            manager.register(RandomTuningOpMode.class /*other stuff here for metadata*/);
        }
    }
}

RandomTuningOpMode.java:

@Config(enable=TuningMode.enableTuning)
public class RandomTuningOpMode extends OpMode {
    /*tuning code here*/
}

Another solution would be a way to add a way to pass in a class that the dashboard would search through for configurable variables (rather than having to register each variable one by one). If there's already a way to do this, my PR idea is mostly useless.

[rbrott]

Ah ok I'm finally processing the root problem. You can register configuration classes without reflection (a la OpModeRegistrar) with the more obscure tree-level API.

FtcDashboard.getInstance().getConfigRoot()
  .putVariable("MyOpMode", ReflectionConfig.createVariableFromClass(MyOpMode.class));

Update: After a batch of modifications, you should call FtcDashboard#updateConfig() to propagate the changes to the clients.

[ryleu]

Ah ok I'm finally processing the root problem. You can register configuration classes without reflection (a la OpModeRegistrar) with the more obscure tree-level API.

FtcDashboard.getInstance().getConfigRoot()

  .putVariable("MyOpMode", ReflectionConfig.createVariableFromClass(MyOpMode.class));

Update: After a batch of modifications, you should call FtcDashboard#updateConfig() to propagate the changes to the clients.

Awesome, thank you so much! Sorry for the confusion.

[ryleu]

Okay, I got everything sorted out. I'm considering making a PR to the RR quickstart...

Thank you for your help!