Collapse/expand is good. Might be even more valuable if an app could somehow identify some collection of streams/oplets as being part of some larger concept. e.g., when one has created a utility fn that takes some input streams, adds some flow operations, and creates some output streams, it would be good to be able to collapse/expand the function’s generated “sub-flow”.
Another mechanism that would be helpful in focusing in on a sub-region of a graph would be to enable defining a bounding region and then showing only the info in that region - i.e., left-click-drag a box. I’ve got an app in a Tuple Count view where, due to flow scaling, I can’t really see the oplets. There may be times when an overall zoom control would be desired. This isn’t one of them for me :-) I don’t want to have to scroll around to bring the oplets of interest into view. > On Mar 18, 2016, at 8:16 PM, May Wone <[email protected]> wrote: > > +1 on collapsing/expanding parts of the graphs, so it'll be easier to focus > on subgraphs. > > Anything that can help figure out how to map the graph component back to > the application would be helpful. For example, I'm finding stream tags > useful to correlate a specific oplet to the the functional call. > > On the longer term goal, I can see using a tree to visualize a chain of > functional calls (nodes) on TStreams objects (edges). > However, I'm trying to imagine how the tuple flow would integrate into this > tree. In particular, how union would be displayed. I need to think more. > > > > > On Thu, Mar 17, 2016 at 2:42 PM, Susan Cline <[email protected]> wrote: > >> I’ve been thinking about different visualizations for the topology graph >> based on Dan’s comments below. >> I’m wondering if a tree layout might be a bit better. >> >> Here is an example of a very basic d3 tree diagram: >> >> http://bl.ocks.org/d3noob/8324872 <http://bl.ocks.org/d3noob/8324872> >> >> Some of the things that we could add to this that would make the graph a >> bit more readable are: >> >> the ability to collapse downstream child nodes/streams >> the ability to collapse parent nodes (?) >> the ability to show the path to the parent node >> >> In tree diagrams we could make the size of the nodes uniform, so not as >> much visual focus would be on them. >> We could remove labels for the nodes altogether, and just label the >> streams. >> >> Thoughts on this? >> >> Susan >> >> >>> On Wed, Mar 9, 2016 at 2:33 PM, Dan Debrunner <[email protected]> >> wrote: >>> >>>> >>>> Somewhat related to this is there should be a view that represents how a >>>> developer coded their application, which is through the topology api, >> where >>>> (for the most part) oplets do not exist. I'm not sure what exactly this >>>> would look like, but it's a move away from having oplets as the first >> class >>>> objects, to having streams and windows as the first class objects. Maybe >>>> such a graph would look similar but the focus would not be on oplets, >> e.g. >>>> oplet names like OP_1 have no meaning to the application developer. >>>> >>>> We may in the future have the physical representation (oplets) be >> heavily >>>> transformed from the logical view (topology), so in that case having a >>>> logical view is much more useful, e.g. imagine an extreme case where the >>>> graph has been optimized down to a single oplet. >>>> >>>> See: https://github.com/quarks-edge/quarks/wiki/Quarks-Etiao-Runtime >>>> >>>> >>>> Dan. >>>> >> >>
