Expose Camera2D in arcade's top level namespace

[pushfoo]

Changes

TL;DR: Enable arcade.Camera2D and from arcade import Camera2D

• Import Camera2D + supporting classes to arcade/__init__.py
• Add Camera2D + supporting classes to arcade.__all__

Why

1. Good DX
2. Make subsequent examples + porting guide PRs easier to read

[DigiDuncan]

Good idea. We have other "core" objects exposed (Text, Window, View, Sprite) and this makes sense to have. You want more complex cameras, dig into arcade.camera.

[einarf]

It does make sense historically, but I'm a little bit conflicted here. Should we not try to slim down the arcade module when possible? It already contains so much.

[DigiDuncan]

It does make sense historically, but I'm a little bit conflicted here. Should we not try to slim down the arcade module when possible? It already contains so much.

I would say our most important objects (and most accessible ones) should be top-level. Camera2D, Text, Window, View, Sprite, Sound, etc. The more advanced or specialized versions (PerspectiveProjector, or BasicSprite, etc.) can be accessed in their sub-modules.

[pushfoo]

@einarf TL;DR: We should fix Camera2D.__init__'s arguments + improve underlying camera behavior.

Should we not try to slim down the arcade module when possible?

The current custom viewport options for Camera2D are somewhat ugly. We have a choice of telling beginners to:

• use Camera2D.from_raw_data to create cameras
• set camera2d_instance.projection_viewport after creation
• use the camera.*Data classes with Camera2D.__init__

I think we should flip Camera2D's __init__ and from_raw_data arguments:

• It eliminates requiring a top-level exposure for the arcade.camera.*Data classes
• Beginners will be confused by the extra classes anyway
• Sharing CameraData between cameras is an advanced technique

[pushfoo]

The recent commits pushed:

1. Rebase onto development to get #2062's fixes
2. Remove the *Data classes from arcade.__all__

[einarf]

Might also be a good idea to update imports in examples here?

[pushfoo]

Might also be a good idea to update imports in examples here?

Yep. I think this might wait till after the following:

• #2065
• #2061
• The camera __init__ and from_raw_data swap

From what I remember of trying to test something like this locally, it also caused some havoc when trying to build doc in certain cases. That may have been due to trying to squeeze cameras into the current doc build system clumsily and in a rush. I'll revisit this PR in the coming days after the above.

[einarf]

Maybe we should just merge this quick to at least get the Camera2D doc generated? It's better than having no docs on it right now.

[pushfoo]

TL;DR: It might actually be very broken despite tests seeming to pass.

I haven't it recently and so I don't remember the details, but there was at some point a wall of red in build output related to this. From what I remember:

• They weren't the PDF build
• They were related to class detection
• I think replacing the quick index tooling as you suggested would've solved them

I was going to wait until the following are in place:

• [ ] #2057 (may be merged already from earlier in today, need to double check)
• [ ] Fix up vector / rotation handling of Camera2D (currently breaks other properites)
• [ ] Vec fixes for 3.0-mandatory #2021
• [ ] Rectangle abstraction to make camera code debuggable / fixable (@DigiDuncan and @DragonMoffon have been working on this)

[pushfoo]

This is redundant and additional work needs to be done before we're able to get the doc generating. That's WIP, so closing this.