It is by far not feature complete, but it now reached a state where I wanted to share this project with the community to discuss future development directions. For example,
if view proxies should also be represented as nodes (maybe with a different color);
if the visibility of proxies inside views should be handeled with an “Eye Icon” as in the pipeline browser or via edges between an output port and a view node;
if nodes should also contain the display properties;
and so on.
Here you can find the corresponding GitHub repository with more details:
Really nice feature!
A small question, are the node foldable ? This is the kind of view I could use to replace the current Pipeline editor and maybe Properties panel but that would be more convenient if we could also fold some nodes so they do not take too much space.
Hi Charles,
yes, nodes can be collapsed by clicking on the “- button” next to the “Properties” label (just like in the properties panel). I’m also experimenting with putting the display properties into the node as a differerent collapsable entry.
Really nice work @Jonas.Lukasczyk ! I will test it when I find the time !
if view proxies should also be represented as nodes (maybe with a different color);
It would make sense to have a way to show views as well
if the visibility of proxies inside views should be handeled with an “Eye Icon” as in the pipeline browser or via edges between an output port and a view node;
Definitely not via an edge between output port and view node. You should instead add a node for each representation, hence linking views and sources/filters. This node should be present if the representation has been created. If the representatino is hidden (eye is grey in the pipeline browser) the representation node should still be present but maybe greyed out to signify that it is not visible.
if nodes should also contain the display properties;
See above
In your Readme, you mention some changes to ParaView that were needed. I’d be happy to discuss these changes in a ParaView merge request.
I also agree that a representation node would be the right way to do it, but that will automatically blow up the node graph. I was thinking about handling representations implicitly as it is currently done in the properties panel based on the selected view. Of course this limits again every source/filter proxy to one representation (as it is currently in ParaView, right?).
Of course having a node for every proxy has the advantage that the properties are always shown at the correct node (source/filter/view/representation).
Definitelly not. I’d go the “blow up graph” way, while keeping easy way to show/hide specific node types or show only nodes that are connected directly to a specific sources.
eg :
source a
source b
view 1
view 2
source a in view 1 is rep 1
source b in view 1 is rep 2
source a in view 2 is rep 3
source b in view 2 is rep 4
full graph shows 8 nodes
sources only graph shows 2 nodes (source a, source b)
source a specific graph shows 5 nodes (source a, rep 1, rep 3, view 1, view 2)
view 1 specific graph shows 5 nodes (source a, source b, rep1, rep 2, view 1)
For my use case, I would keep the node size as small as possible and definitely not add further nodes for each representation.
The networks I regularly end up with look like this:
Hi Lutz,
this looks great! Nodes in my plugin are definitely too big. This is due to the way I create the property widgets (I use a paraview class for that since I did’t want to reimplement the entire UI generation). This is also the reason the properties panel looks exactly like the properties widget in the node. At least one can collapse the properties for now. But if all the functionality is there I will trim the fat where possible
Next I will add representation and view proxies. This will add a lot of stuff to the node graph, but as you suggested this issue should be solved by more interaction features by for example only showing representations of currently selected filters.
The node editor now contains view nodes (the active view is highlighted in orange).
Orange edges indicate which output ports are shown in which view (the orange edges are basically the eye icon). The idea here is that vertical lines (orange) are used for the visualization pipeline, and horizontal lines (blue) for the processing pipeline.
In the future one could also add a representation node in the middle, but I ran into some problems automatically generating the property widgets for representations. This worked out of the box for sources/filters/views, but I get a compile error when I try to do it with representations (so this is on hold for now). So currently one has to select a view and an object and then use the old “Display” panel. But I actually prefer to have that panel open anyway, as I also frequently use the “Information” or “MultiBlockInspector” panel.
Nodes can now be collapsed into three states: none, basic, and advanced options.
I added a dot-based layout algorithm to provide at least a somewhat sensible layout. This can also be used to extend the graph on the fly.
Next I will work on the “Apply” logic, and open a PR to fix the issue with the pqDoubleLineEdit visibility.
Hi all,
the NE now has all features I wanted to incorporate. So one can now operate PV without the pipeline browser and the properties panel. The NE is still completely standalone, so the PV source code remains untouched.
However, there remain two issues which will require some updates of the PV source code, but I need some input from the PV developers before I start working on a solution:
Display issue of pqDoubleLineEdit widgets
I tracked down the problem to line 125 of pqDoubleLineEdit.cxx: this->InactiveLineEdit->render(self, self->mapTo(self->window(), QPoint(0, 0)));
Here Qt is asked to draw the internal widget with the QPainter, but this is incompatible with the Canvas-Framework that is used to draw the Node Editor. See here: https://doc.qt.io/qt-5/qwidget.html#custom-widgets-and-painting
I don’t understand the necessity for the internal widget. The PV docu states it is used to draw a simplified version if the widget is not in focus, but why? When I change the code to always use the actual widget everything seems to be fine. So how should I proceed here?
Creation of proxies with multiple inputs
In this case PV always shows a dialog in which one has to choose the inputs. This can now be done more conveniently with the NE. So the question is what mechanism should be used to suppress this dialog if the NE is open. One possibility is to explicitly call for this dialog only if the pipeline browser asked to create such a filter. Right now the filter creation is a global thing. Any thoughts on this?
Please open a MR with the fix so I can take a look.
This may be more complex. You will need to add new methods to create a filter with multiple inputs directly without using the dialog. Definitely doable.
Wow, thanks for the quick feedback! I will open a PR for the first issue. But note that this will just circumvent the feature of pqDoubleLineEdit to draw a simplified version.
Hi everyone,
I noticed another issue. Some proxies have a property that controls a 3D widget (an interactive widget). These interactive properties are not synchronized like the other properties. For example, currently it is not possible to toggle the visibility of the interactive line widget of the elevation filter, since although the checkbox value is changed, the pqProxyWidget does not emit a PropertyChanged signal. What is the correct way of handling such interactive widgets? Do I have to synchronize this manually? If yes which class do I need to observe?
Have you considered going with a GitTree like graph instead of a pure node representation (e.g. GitKraken) ? It would keep the compressed representation of the actual pipeline, while being better at showing the connection between the different filters.
Cheers
Hi Jonathan,
thank you. Such a compressed view would be great, but then you can not “easily” change input connections or filter parameters which I was going for. To get a compressed overview I still use the old pipeline browser, but since you said it: I think this browser deserves a much needed visual update to be more like gitKraken.
