For the linking of camera's, here are my thoughts about it:

While it is certainly something you may want to do in certain cases, it is also something you may not want to do. Calling link(brain1, brain2) will link all UI events, including the camera. Excluding the camera is in the current version of link a pain, because you would need to specify a custom set of UI events to link. Perhaps the function signature should be changed to link(fig1, fig2, include_events=None, exclude_events=None). So one could do link(brain1, brain2, exclude_events="camera_move").

There's a performance consideration. The straightforward implementation of CameraMove is to call show_view(...). However, that function is slightly expensive due to some matrix transformations being performed. Camera movement might stutter if we implement it like this. The current _LinkViewer class solves this cleverly by assigning the same Camera object to both figures, making it super efficient. However, I don't see how that could be implemented through UI events. Perhaps a good solution is to have the CameraMove event take a pyvista Camera object as parameter and the implementation just copies over the parameters to the camera in the new figure. That would likely be efficient enough, but it breaks the semantics of UI events a little, in which I try to maintain high-level semantics, rather than such a low-level, implementation-specific object. WDYT?

However, that function is slightly expensive due to some matrix transformations being performed.

I'm surprised by this. I'd expect most to be 4x4 and very fast to compute or combine, and VTK should do a lot of it in c++ or in the GPU. Can you give an example bit if code that shows the slowdown? But in the end even if it's a bit slow during interactive rotation it's perhaps not necessarily a deal breaker.

This is ready for review now!

I haven’t benchmarked show_view yet, I’ll give it a try. But it feels inefficient seeing how many events camera movement will spawn

Even done in Python it seems quite fast to do some multiplies:

$ python -m timeit -s "import numpy as np; x = np.ones((4, 4))" "x @ x @ x @ x.T @ x"
50000 loops, best of 5: 4.03 usec per loop

And at the renderer level VTK should be smart enough not to render faster than 60 Hz (I think it is) and do all this stuff in C++ or (more likely) at the GPU level just at render time. So I'm still optimistic...

I've looked into building a CameraMove event. In principle doable and it does seem performant. Sorry for ever doubting it :)

However, I've run into a problem: if I get the camera parameters from brain.get_view() and assign them back into the proper parameters of brain.show_view(), the camera angle has changed. Same for going one level deeper with brain._renderer.get_camera() and brain._renderer.set_camera(). It seems that whatever the set_camera() is doing is not lining up with what get_camera() returns (other than having a different order of the parameters)

So for this PR, I'm going to leave it alone I think.

Works beautifully @wmvanvliet, in it goes!