Presenting another node package: qt-dataflow

[Till Stensitzki]

Hello,
first thank you for making this nice package, i use it for internal data acquisition software.
Sadly, i did not know of the flownode part, so i did program my own node-framework: qtdataflow.

https://github.com/Tillsten/qt-dataflow

It differs slightly in its design: it is probably more flexible, but has less features. It is also
quite untested and the documentation is lacking. But the examples (including one using
a pyqtgraph directly) are quite self explaining. Maybe somebody has some use for it, i'll
try to answer any questions.

btw:
I also used pyqtgraphs qt.py file, how should i attribute/cite this?

greetings
Till Stensitzki


 

[Luke Campagnola]

On Sun, Feb 24, 2013 at 3:55 PM, Till Stensitzki <mail...@gmx.de> wrote:

Hello,
first thank you for making this nice package, i use it for internal data acquisition software.
Sadly, i did not know of the flownode part, so i did program my own node-framework: qtdataflow.

https://github.com/Tillsten/qt-dataflow

It differs slightly in its design: it is probably more flexible, but has less features. It is also
quite untested and the documentation is lacking. But the examples (including one using
a pyqtgraph directly) are quite self explaining. Maybe somebody has some use for it, i'll
try to answer any questions.

Interesting! Can you describe what you think is more flexible about your design? I'm always looking for ways to improve and I'm sure pyqtgraph's flowcharts have a lot of room to grow. I might try to integrate some of your code / design.

 

btw:
I also used pyqtgraphs qt.py file, how should i attribute/cite this?

You can just mention pyqtgraph in a comment at the top, that'd be good enough.

 

Luke

[Till Stensitzki]

Am Montag, 25. Februar 2013 00:59:04 UTC+1 schrieb Luke Campagnola:

Interesting! Can you describe what you think is more flexible about your design? I'm always looking for ways to improve and I'm sure pyqtgraph's flowcharts have a lot of room to grow. I might try to integrate some of your code / design.

After having a deeper look into pg-flowchart i have to say  the design is eerily similar.  Some
points which would make it maybe a little bit more flexible:
* hardcoded processing
* Node is QObject and by that it is  unpickable
* I don't think the bypass-stuff should be in a general Node class, because it does not sense for
  a lot of node-classes. Same for set_color.
* It is not clear where the node chooses it graphicsitem.
* Can i chose another view for a item?
* It is missing examples how to make your own nodes (this is the most important point).

Everything else should seems to be ok. If i have time I'll try to move my stuff to pyqt-flowchart (would
be one software project less to think about).

Some nice minor additions would be:
* nicer connections lines
* a toolbar from which one can drag and drop nodes.
* allowing for different types of connections.

 

You can just mention pyqtgraph in a comment at the top, that'd be good enough.

Will do either that or change to another pyside/pyqt importer. I am missing the ability to directly import stuff from
QtCore or QtGui. I think the galry has a (3rd-party) importer that allows direct imports.  

[Luke Campagnola]

On Wed, Feb 27, 2013 at 11:12 AM, Till Stensitzki <mail...@gmx.de> wrote:

Am Montag, 25. Februar 2013 00:59:04 UTC+1 schrieb Luke Campagnola:

Interesting! Can you describe what you think is more flexible about your design? I'm always looking for ways to improve and I'm sure pyqtgraph's flowcharts have a lot of room to grow. I might try to integrate some of your code / design.

After having a deeper look into pg-flowchart i have to say  the design is eerily similar.  Some
points which would make it maybe a little bit more flexible:
* hardcoded processing

Not sure what you mean here.. have you seen the EvalNode ?

 

* Node is QObject and by that it is  unpickable

Maybe you meant unpicklable? Each Node has a save/restore function, so in principle this could be used to define pickling behavior.

 

* I don't think the bypass-stuff should be in a general Node class, because it does not sense for
  a lot of node-classes. Same for set_color.

It's true that bypass does not make sense for all node types, but it is a common enough feature that I think inclusion in Node is reasonable. One might envision a BypassableNode subclass, but if we start breaking features out like that, then it becomes necessary to use multiple inheritance, which I usually try to avoid when working with Qt. 

 

* It is not clear where the node chooses it graphicsitem.

Node.graphicsItem(); it's there for subclasses to reimplement.

 

* Can i chose another view for a item?

You mean place the GraphicsItem in another view? Change its appearance? Move its control widget elsewhere?

 

* It is missing examples how to make your own nodes (this is the most important point).

See examples/FlowchartCustomNode.py  (and please ask if you want to see more features demonstrated there)

 

Some nice minor additions would be:
* nicer connections lines

Definitely agree there. The tricky part is making curved lines selectable in a user-friendly way. 

 

* a toolbar from which one can drag and drop nodes.

This would be nice. There's a context menu; I guess it wouldn't be too difficult to generate a toolbar or other kinds of structures. Perhaps a TreeWidget would be easier at first since all node types have names, but not icons (but this would be a good feature to add as well).

 

* allowing for different types of connections.

Can you expand on this? 

Luke

[Till Stensitzki]

Am Mittwoch, 27. Februar 2013 18:08:30 UTC+1 schrieb Luke Campagnola:

On Wed, Feb 27, 2013 at 11:12 AM, Till Stensitzki <mail...@gmx.de> wrote:

Not sure what you mean here.. have you seen the EvalNode ?

I'll have a look it. Atm i just not sure why there is a processing method
in flowchart.
 

Maybe you meant unpicklable? Each Node has a save/restore function, so in principle this could be used to define pickling behavior.

Yeah, but for pickling, no manual code is necessary (but generally, your solution is better for a lot of reasons).

It's true that bypass does not make sense for all node types, but it is a common enough feature that I think inclusion in Node is reasonable. One might envision a BypassableNode subclass, but if we start breaking features out like that, then it becomes necessary to use multiple inheritance, which I usually try to avoid when working with Qt. 

Understandable. I think it works ok as long you only have one Qt-parent.

 

You mean place the GraphicsItem in another view? Change its appearance? Move its control widget elsewhere?

The second, for example lets say you have your normal chart and an zoomed out overview for it. It would
be nice to replace some nodes just by symbols.
 

 

See examples/FlowchartCustomNode.py  (and please ask if you want to see more features demonstrated there)

Will do!
 

 

Definitely agree there. The tricky part is making curved lines selectable in a user-friendly way. 

Just subclass form QGraphicsPathItem, it gives a nice bounding box. See
https://github.com/Tillsten/qt-dataflow/blob/master/qtdataflow/view.py#L103
for a cubic line.

 

* a toolbar from which one can drag and drop nodes.

This would be nice. There's a context menu; I guess it wouldn't be too difficult to generate a toolbar or other kinds of structures. Perhaps a TreeWidget would be easier at first since all node types have names, but not icons (but this would be a good feature to add as well).

Just use a default icon if the node does not supply one? I gave node a get_toolbar_item-like method, defaulting to the normal graphicsitem .

 

* allowing for different types of connections.

Lets imagine someone want to make a Labview-clone (god beware!): some nodes return int, some others string.
Giving them different appearance and behavior in the gui would be nice. String-out nodes are only allowed to
connect to String nodes, different colors, highlighting, etc... 

Thanks again for pyqtgraph
Till Stensitzki

[Luke Campagnola]

On Wed, Feb 27, 2013 at 1:12 PM, Till Stensitzki <mail...@gmx.de> wrote:

Am Mittwoch, 27. Februar 2013 18:08:30 UTC+1 schrieb Luke Campagnola:

On Wed, Feb 27, 2013 at 11:12 AM, Till Stensitzki <mail...@gmx.de> wrote:

Not sure what you mean here.. have you seen the EvalNode ?

I'll have a look it. Atm i just not sure why there is a processing method
in flowchart.

Have a look here: http://pyqtgraph.org/documentation/flowchart/

The simple answer is that if you want to push a lot of data through the flowchart while maximizing efficiency and minimizing memory usage, a more complex approach is required.

You mean place the GraphicsItem in another view? Change its appearance? Move its control widget elsewhere?

The second, for example lets say you have your normal chart and an zoomed out overview for it. It would
be nice to replace some nodes just by symbols.

That's an interesting idea. QGraphicsView lets you view the same scene from multiple views, and the Node graphicsItem could be set to change its appearance depending on the zoom of the view..

Definitely agree there. The tricky part is making curved lines selectable in a user-friendly way. 

Just subclass form QGraphicsPathItem, it gives a nice bounding box. See
https://github.com/Tillsten/qt-dataflow/blob/master/qtdataflow/view.py#L103
for a cubic line.

Bounding boxes don't really work when the flowchart becomes more complex--too many overlapping boxes. The approach I had in mind is to use QPainterPathStroker to generate a conforming shape that extends a few pixels around the path.

 

 

* allowing for different types of connections.

Lets imagine someone want to make a Labview-clone (god beware!): some nodes return int, some others string.
Giving them different appearance and behavior in the gui would be nice. String-out nodes are only allowed to
connect to String nodes, different colors, highlighting, etc... 

I thought a lot about this when I started designing the flowcharts. Ultimately I never found a need for strictly-typed connections. Most nodes accept a wide range of different types and use duck-typing to determine if their inputs are valid. Right now, the suggested way to build flowcharts is to first load sample data onto the inputs of the chart, then as you add and connect nodes, you can immediately see whether the output of one node caused an error in the next (and why).

I do think this would be a useful feature in many situations, though. In general, Node should be allowed to interfere if an inappropriate connection is being made, and it should be possible to customize the appearance of terminals (it _is_ possible, but tedious). This would be fairly easy to implement.

Thinking towards LabView, though (god beware, indeed), some significant redesign would be necessary, particularly for adding looping and conditional constructs. Adding functions (embedding flowcharts inside flowcharts) is possible in principle (since Flowchart is a subclass of Node), but I have not really gone down that path yet.

 

Luke

[Till Stensitzki]

For now only one thing: 

Bounding boxes don't really work when the flowchart becomes more complex--too many overlapping boxes. The approach I had in mind is to use QPainterPathStroker to generate a conforming shape that extends a few pixels around the path.

 

I meant that QGraphicsPath implements a sensible shape automatically, try it!

[Luke Campagnola]

The area I find clickable is the shape() of the item, as if it were a closed path with the ends joined-the concave parts of the curve are filled in, and the convex parts have no padding.

On the other hand, using QPainterPathStroker turned out to be very easy :)   Will be in the next release.

(you can try it from here if you like: http://bazaar.launchpad.net/~luke-campagnola/pyqtgraph/inp/revision/267)

Thanks for the cubic spline idea!

Luke