Topomap refactoring

[christian-oreilly]

The objective of this issue is to refactor the topomap code so that the generation of a single topomap is a function or class of its own, so that it can be more easily reused outside the specific context of PyLossless (for an eventual fork of the visual components to their own project).

[scott-huberty]

The objective of this issue is to refactor the topomap code so that the generation of a single topomap is a function or class of its own, so that it can be more easily reused outside the specific context of PyLossless (for an eventual fork of the visual components to their own project).

I've had this on my mind as well.. +1!

[christian-oreilly]

Yeah... that was self-interested. I want to make a topoplot now for some project and instead of going the usual way of tweaking mne code to get it done, I thought I give this a shot.

[scott-huberty]

Well.. If you end up getting to it on your own - let me know if any of the topo Docstring is incorrect/confusing - I did my best to represent the code but i'm sure I made mistakes.

[scott-huberty]

that was self-interested. I want to make a topoplot now for some project and instead of going the usual way of tweaking mne code to get it done, I thought I give this a shot.

Nah IMO this is a perfect example of how a feature request should be done.. Driven by a real and reasonable use-case!

[christian-oreilly]

That thing is mostly done. Took much more time that I cared for, but it is done. For plotting a single topomap:

For a grid of topomaps:

For embedding it as a dash component of an existing app:

For an on-the-fly standalone dash app:

These classes are properly integrated, such that you can get a plotly figure from the dash objects:

@scott-huberty We should discuss package naming because I think it would be a good occasion to push this into a new repo in the context of #94 (which will also support #33).

[scott-huberty]

Looks awesome!

Yes, let's chat this week