Awesome! I will provide more feedback later. This one bit just caught my eye:

it also removes a lot of the getters and setters which (as far as I could tell) are just simple one-line wraps around calling the private version of the attribut

@almarklein does this matter for the reactivity abstraction?

@almarklein does this matter for the reactivity abstraction?

Yes. I agree that props in Python are a bit verbose, but we use them, so the props get properly documented, and so we can apply checks in the setters. And the ones where the value is stored on self._store are indeed necessary, because those sets and gets are tracked so the render system can be informed when stuff changes.

And the ones where the value is stored on self._store are indeed necessary, because those sets and gets are tracked so the render system can be informed when stuff changes.

I just saw the Trackable code. I will restore those getters/setters. I have a strong feeling that this can probably be solved concisely via a python descriptor, but we can look at that in a future PR.

You may want to hold off on refactoring the cameras and controllers until #457 is merged

I changed this to keep showing the arcs in screen mode so that users can get a better understanding of how the XZ and YZ rotation handles will rotate the object.

That sounds reasonable. IIUC that way to show the Gizmo is also more correct, right? I mean, since the translations and rotations appear relative to the camera view-direction, independent of where the object is on the screen?

I guess this means that we want to add a validation example or two to improve coverage in the process?

Good idea. We have validation examples using .show_pos and .show_rect, but none using show_object. That would already be an improvement. We could also add an example that programmatically uses a controller, but we can also do that later. It's arguably less important, since the controller's code is more self-contained and should not change very often.

Let's try to keep things smaller in the future.

That's always a good idea for PR's 😄 In your defense, this changes touched a lot of code. E.g. in hindsight it might have been better to update the Gizmo in a later PR, but that'd have left main in a partly broken state. Its messy either way.

IIUC that way to show the Gizmo is also more correct, right? I mean, since the translations and rotations appear relative to the camera view-direction, independent of where the object is on the screen?

I wouldn't say that it is more or less correct. The 2D gizmo has utility when you want to transform objects in 2D (on some plane with constant offset from the camera). The 3D gizmo (how it is now) has utility if you want to transform a 3D object relative to the camera's position.

Many examples don't initialise well, and have weird camera rotations, maybe the orbit camera was broken somewhere in the up/gravity changes? (e.g.cylinder.py, spheres.py, multi_slice1.py, etc.)

@almarklein Could you try this again with the latest version of this PR? I can't seem to reproduce this or don't see what is weird/wrong.

Alright. I addressed all the comments made in #482 (comment) except for the controller failures that @almarklein reported, because I can't reproduce them. I also dealt with all the open conversations.

Now there should be only two things left:

1. Since there were changes I need another round of approval.
2. Once everything is settled I will write a comment on optimization opportunities.

The Gizmo is looking good!

except for the controller failures that @almarklein reported, because I can't reproduce them.

My bad, I had not updated pylinalg 😊 But we have a thing for that! Could you update the __pylinalg_version_range__ in pygfx/__init__.py? (This is probably my final request 😄 )

@almarklein sure. Done.

I will look into the optimization notes next and then we should be LGTM.

@FirefoxMetzger that was an amazing display of grit. Great work, it's very much appreciated.

If anyone still complains pygfx is not pythonic enough after this, I will throw in the towel :)

Can you put the optimization options in a new issue?