Didn't get to it this week, might have time Monday. If not, then it'll probably be another week because next week is full of meetings for me!

There's no hurry :)

@wmvanvliet this is in draft mode, is this good to go from your end? If so feel free to mark as ready, ping me, and I'll try actually using it and see if there are any show-stopping issues.

CircleCI failure is real:

        ../tutorials/inverse/21_interactive_dipole_fit.py failed leaving traceback:
    
        Traceback (most recent call last):
          File "/home/circleci/project/tutorials/inverse/21_interactive_dipole_fit.py", line 41, in <module>
            mne.gui.dipolefit()
        TypeError: dipolefit() missing 1 required positional argument: 'evoked'

so is its style complaint

/home/circleci/project/doc/generated/commands.rst:457: WARNING: Option list ends without a blank line; unexpected unindent. [docutils]
/home/circleci/project/doc/generated/commands.rst:461: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]

in case you want to test locally, I can replicate the example error with

larsoner:~/python/mne-python/doc$ PATTERN=interactive_dipole make html-pattern

I'll look to see if I can see what docutils is angry about

Fixed ref cycle (need weakrefs to all callbacks) and improved scraping to use GUI-style scraping

Only thing blocking this IMO is faster unit tests with better coverage.

@wmvanvliet looks like still draft mode, let me know when I should look and test it out (and hopefully merge!)

You already helped a lot figuring out the ref cycles. We still need better test coverage before thinking about merging this.

Do you need help with tests? I might have time next week to get some in

Of course any help is appreciated and motivating! My main issue with writing these tests is speed. How can we test this GUI at any type of reasonable speed?

How can we test this GUI at any type of reasonable speed?

A couple ideas to get the ball rolling:

1. Use as few GUI instances as possible: test as many things as feasible with each spun-up GUI.
2. Monkey-patch slow functions that are tested properly elsewhere to do a really bad job really quickly instead of a correct job slowly: For one example, the field line mapping code that returns an ndarray of shape (n_sensors, n_head_vertices) can just return a rng.normal(...) instead of doing a meaninful computation (we check that correctness elsewhere!).

With these in place maybe it's already doable, but if not we should look to see what takes a lot of time and figure out how to make it faster (e.g., via caching, more monkey patching, etc.)