Open arq5x opened 11 years ago
Sounds like a good idea.
One option could be to have HilbertBase, HilbertNormalized, and HilbertMatrix know how to plot themselves, so that their .plot() method could be called to get static images. That might alleviate the need for a HilbertStatic class.
But I'm not sure how HilbertGUI would access/update this. Maybe we do need a HilbertStatic class to act as a plotting wrapper around HilbertMatrix et al, and it would have a bunch of knobs and switches exposed for HilbertGUI to tweak on the fly within the GUI.
You're right, it'll probably take some careful refactoring (and maybe a couple of rounds) . . . but I bet it would be worth it in the long run.
Given the current flexibility of the GUI class (i.e., plot from 1 to N curves and the flexible configuration), it seems that it would be useful to put core logic into a simpler base class from which the HilbertGUI and a proposed HilbertStatic classes could be derived. This way, we can run the GUI as is by putting the widgets, etc. in the HilbertGUI class and create static images by just plotting and/or saving the curves to an image.
Might take some careful refactoring, but it seems that this would make things much easier/cleaner. Would also simplify some of the current and future CL tool options such as "plot", "combine", "subtract", "ratio", etc.
Thoughts?