XFit-style dipole fitting GUI

[wmvanvliet]

This adds a GUI to perform guided dipole modeling in the spirit of MEGIN's XFit program. This PR contains the base functionality needed to make the GUI useful. Useful enough to include in the next release of MNE-Python. The plan is to keep adding features in future PRs as well as some sorely needed speed improvements.

See here for a list of currently supported features: #11977
This PR depends on: #12071

Minimal example:

import mne

data_path = mne.datasets.sample.data_path()
evoked = mne.read_evokeds(
    f"{data_path}/MEG/sample/sample_audvis-ave.fif", condition="Left Auditory"
)
evoked.apply_baseline((-0.2, 0))
trans = mne.read_trans(f"{data_path}/MEG/sample/sample_audvis_raw-trans.fif")
cov = mne.read_cov(f"{data_path}/MEG/sample/sample_audvis-cov.fif")
bem = mne.read_bem_solution(f"{data_path}/subjects/sample/bem/sample-5120-5120-5120-bem-sol.fif")
subject = "sample"
subjects_dir = data_path / "subjects"

evoked.pick("grad")

# Quick and dirty. No MRI whatsoever.
g = mne.gui.DipoleFitUI(evoked)

# Slow and proper. With proper BEM model.
# g = mne.gui.DipoleFitUI(evoked, trans=trans, cov=cov, bem=bem, subject=subject, subjects_dir=subjects_dir)

Todo:

• Unit tests
• Proper documentation page
• Towncrier

[larsoner]

Great to see progress here, let me know when it would be useful to get usability and/or code feedback!

[wmvanvliet]

The actual functionality is ready for testing. I'd love some feedback on usability, ideas for improvements and overall thoughts.

[cbrnr]

Would it be worth discussing if the various GUIs should be moved to a separate package? I feel like things like dipole fitting don't have to live in the main MNE-Python package. Thoughts?

[larsoner]

Interactive dipole fitting is perhaps the oldest source localization method and still quite widely used, so to me it's within scope to put it in in MNE-Python itself. To me it's something we've always been missing / a deficiency of our software. I don't see too many advantages to splitting this one off unless @wmvanvliet plans to need to iterate and release faster than MNE-Python itself.

[wmvanvliet]

Would it be worth discussing if the various GUIs should be moved to a separate package?

It's certainly worth discussing. As @larsoner says, well established source estimation techniques should be within scope of MNE-Python. It may at some point still be wise to split it off into its own package when we want to become more ambitious with its interface. The precedent for this is mne-qt-browser. As long as the functionality provided by this GUI works within the Figure3d class, all is good, and I think this will be the case for the foreseable future. When we want access to the full Qt functionality we should probably split off.