DynamicGravitySystems / DGP

Dynamic Gravity Processor
http://dgp.readthedocs.io/en/develop/
Apache License 2.0
7 stars 4 forks source link

Future of transform graphs #65

Open cbertinato opened 6 years ago

cbertinato commented 6 years ago

Just starting a thread for conversation here about how we'll go forward with the graph transforms. I am not completely comfortable with how closely flowcharts and nodes are tied to Qt.

That connection helps in that we don't really need to do anything to implement the graphical part. It hurts in that all processing is now tied to Qt.

The alternative would be to roll our own graphs, which is partially done in the old transform branch.

Advantages:

Disadvantages:

In the absence of a graphical interface, we could take a page from Dask's book and construct graphs as dictionaries:

{'x': 1,
 'y': 2,
 'z': (add, 'x', 'y'),
 'w': (sum, ['x', 'y', 'z']),
 'v': [(sum, ['w', 'z']), 2]}

While this is not as intuitive as the LabView-like graphical interface, it is minimal and clean. I am comfortable with not having a graphical interface, and I think that the users who would most be interested in this functionality, might not mind either.

We should still move forward with what has already been implemented, but let's continue this conversation for consideration in the next release after initial.

bradyzp commented 6 years ago

Chris, definitely share your concern with the intertwining of the transform graphs and Qt, this sounds like a good idea to investigate and implement in the future.

Just a thought too is that we could end up developing an adapter somewhere down the line that could translate from whatever graph implementation we design to create a pyqtgraph GUI representation (short of designing our own GUI to display/manipulate the graphs) if that makes sense.

Anyways definitely agree with the premise here, will think more on it after dealing with the current release issues.