Code organisation

[akissinger]

Currently, most of the brains of ZX live are in rules.py, which contains a mix of graph editing code and graph rewrite rules and in MainWindow.__init__. I think this organisation could be improved.

Here are my suggestions:

• avoid re-implementing stuff. if it is PyZX, use it! if it is non-GUI, and pyzx doesn't have quite what we need, I would rather make the change in pyzx than create (nearly) duplicate functionality in ZX Live
• identify or implement a "model" object corresponding to each Thing ZX Live edits. I think there should be at least one model for graphs and one for proofs. If possible, we should use the pyzx BaseGraph as our main graph model
• create a "panel" corresponding to each mode that ZX Live can run in. I suggest implementing a GraphEditPanel for now which just does GUI graph editing (no ZX rules), with the idea that we'll add a ProofPanel later for rewrite. These can extend QWidget and be added to the mainwindow in a QTabWidget
• each GraphEditPanel should maintain its own undo stack (I'll make a separate issue about undo)
• graph editing commands should be implemented in the editor
• ZX rules should be implemented or used in a uniform way.

It might be worth breaking some of these into separate issues, but I think it's useful to have some design principles in one place. Feel free to comment here or on discord to discuss.

[y-richie-y]

identify or implement a "model" object corresponding to each Thing ZX Live edits. I think there should be at least one model for graphs and one for proofs. If possible, we should use the pyzx BaseGraph as our main graph model

Has this been done?

[jvdwetering]

I think we are now pretty consistently using the Model/View model. We don't have a model yet that describes a 'Proof', which would be something like a sequence of rewrite steps I guess?

[jvdwetering]

I think the stuff described here has now been done, so we could close this issue. Or keep it open as a reference for how stuff should be done in the future?

[RazinShaikh]

It's better to close this issue and move the code organization information to somewhere more accessible. How about in the readme?

[jvdwetering]

I think the standard for open source is to have a CONTRIBUTORS file or something like that. The README is just for people wanting to use the code, not develop it.

[jvdwetering]

I have now added a CONTRIBUTING.md file which contains the information from this issue that is still relevant. So we can close this now.