[command] Rename trigger methods

[Starlight220]

NetworkButton should be pulled up to be a direct subclass of NetworkEvent (naming TBD); the alternative solution for its use-case--NT(4) listeners--isn't as much of a solution for the same problem-space as I initially thought: NT listeners demand attention to thread-safety, and they aren't interoperable with the EventLoop/Trigger API.

JoystickButton/POVButton are redundant by BooleanEvent-returning methods on the HID classes; they can be deprecated/removed.

Button itself is an identical abstraction to Trigger and the duplication causes much confusion, both at the class level as well as the method level. Button and its button-specific method names should be deprecated/removed and the conceptualization would be pronounced in (API) docs.

Trigger's *Active terminology is confusing due to the lack of a nonambiguous definition of "active"; it should be replaced by *High/*Low terminology to be consistent with BooleanEvent's digital signal terminologies. The when terminology is also somewhat ambiguous; it should be replaced by on.

The API will have the following command bindings:

• onRising: schedule on rising (replaces whenActive)
• onFalling: schedule on falling (replaces whenInactive)
• whileHigh: schedule once on rising, cancel on falling (replaces whileActiveOnce)
• whileLow: schedule once on falling, cancel on rising (replaces whileInactiveOnce)
• toggleOnRising: toggle on rising (replaces toggleWhenActive)
• toggleOnFalling: toggle on falling (replaces toggleWhenInactive)

To continuously repeat a command while a button is held, RepeatCommand should be used; if rescheduling on interruption is also desired then Command.schedule() can be manually bound to ifHigh.

[AustinShalit]

/wpiformat

[Starlight220]

Waiting on #4104

[Daltz333]

Can we have a corresponding PR to frc-docs that updates the current naming and explanations before we merge this?

[Starlight220]

Waiting on #4192

[Starlight220]

@Oblarg What do we want to do with the (Runnable, Subsystem...) overloads? I currently didn't touch them, but we should decide what we're doing with them -- I assume they see a fair amount of use.

[Starlight220]

Another question is what we should do with InternalButton and POVButton. Pull them up, maybe? InternalButton should probably be renamed to Settable*; I think that naming would be more intuitive.

[Starlight220]

I think we'll scrap the method renaming for 2023. There's enough confusion as is, and changing everything now will introduce even more -- especially if we're keeping BooleanEvent and Trigger separate, there's no point in them sharing the signal processing terminology. We'll deprecate Button, pointing users towards Trigger, and after 2023 we'll see if there's still significant confusion after cutting down to a single set of method names.

[sciencewhiz]

This will likely need robotbuilder changes. Will test later today.

[sciencewhiz]

With robotbuilder, I get deprecation warnings with Java, but compile errors in C++.

m_armUpButton.WhenPressed(ArmUp().WithInterruptBehavior(frc2::Command::InterruptionBehavior::kCancelSelf)); gives:

C:\Users\Joe\Documents\Robotics\RobotBuilder\build\test-resources\RobotBuilderTestProjectCpp\src\main\cpp\RobotContainer.cpp:77:26: error: no matching function for call to 'frc2::JoystickButton::WhenPressed(frc2::CommandPtr)' 77 | m_armUpButton.WhenPressed(ArmUp().WithInterruptBehavior(frc2::Command::InterruptionBehavior::kCancelSelf));

[sciencewhiz]

Please update the PR text to match where this PR ended up

[Starlight220]

With robotbuilder, I get deprecation warnings with Java, but compile errors in C++.

This is because only the new C++ bindings can take a CommandPtr, which is what the decorators now return. In Java, both new and old bindings simply take a Command.

[Starlight220]

ButtonTest was renamed to TriggerTest; git must've missed tracking it.