You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Flexibility for functions with variable number of inputs
Freedom to use just about any function available through NumPy, pandas, etc.
Flexibility in allocating processing tasks to workers if we ever implement async
Disadvantages:
No graphical interface
In the absence of a graphical interface, we could take a page from Dask's book and construct graphs as dictionaries:
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: