By moving some of the technical details to dedicated sections of the docs, we can add more (or simplified, less technical) information without cluttering the API commands.
These can still be viewed on the full Motor class description. But on EV3, these functions are not so relevant as all motors have encoders.
Then we can also remove the encoded/encoderless rubric, further removing clutter.
Instead, show shorter, simpler Motor docs platform-devices pages. For the moment, this just means deleting the advanced methods section from those pages, but we may choose to simplify further.
This change makes it easier to navigate the ev3devices/pupdevices pages because the motor sections aren't overly long.
Details will still be available on the Motor pages for those who wish to use the more advanced motor capabilities such as adjusting the PID settings.
Because this module describes devices that can be built into a hub or other device.
Since this design is now explicitly shown in
the docs as well, we don't need to hide this
module in the package.
This makes the user code easier to read:
brick.buttons()
brick.buttons.pressed()
It also opens up possibility to add features in the future such as:
brick.buttons.released() # return which buttons are not pressed
brick.buttons.clicked() # return which buttons were clicked since we last checked
This follows the same style as the new light API: some devices have specific instances of a KeyPad class.
A good example that nicely demonstrates the concept is the LPF2 RemoteControl, which has instances of a ColorLight and a KeyPad. It's added in this commit.
Same result as in 92e3735d63, but now achieved by patching the Sphinx configuration instead of patching the API.
Now it doesn't break the API for the purpose of checking and autocomplete, etc.
This is an experimental method for adding lights to some sensors.
And add workaround to make it show up correctly in the docs.
Also some doc8 formatting
Laurens Valk