larsoner
commented
1 year ago While we're at it, I've also used vedo a bit instead of PyVista and some of the interfaces were quite nice. We could try it as well. It has nice stuff like working SSAO and classes for hover legends. One time I had to compute the intersection of two meshes and it was super easy (I just + / __add__ed them!).
In principle we could see how difficult it would be to add it as a new 3D backend. Right now PyVistaQt isn't maintained super well, and the interactions between PyVistaQt and PyVista cause problems fairly regularly. In vedo I think Plotter has first-class support for Qt given this example passes qt_widget=... in the Plotter class initialization. We already have a 3D abstraction layer for our transition from Mayavi a couple of years ago, so trying out vedo as a "new" backend might not be too difficult actually. (Maybe just a few hours of work to get surface plotting working?)
wmvanvliet
agramfort
@alexrockhill and now @wmvanvliet have raised issues about the complexity of our GUI backend abstraction. TL;DR is that it works most of the time for what we already have (brain and coreg I think), but can be very difficult to add new stuff.
I went looking for an abstraction layer for Qt/ipywidgets and it looks like there is one:
https://github.com/pyapp-kit/magicgui
It's MIT licensed, actively developed, and available on PyPI and conda-forge. One disadvantage is that it looks like it has a truck factor of one. But with our expertise maybe we can become active contributors there instead of just in our own code!
I'm tempted to take a look at look in the coming weeks at how it works and see if I can fairly easily get a
pyvistaqt.BackgroundPlotterin when it's Qt and a trame-backendpyvista.Plotterwhen it's in notebook with some interaction.EDIT: Might also take care of https://github.com/mne-tools/mne-python/issues/11027