[instaviz-users] Order-preserving trees redux, and an interpreter question

[Glen Low]

Paul

On 09/05/2009, at 4:32 PM, Paul Weiss wrote:

> Hello all - I've fooled around a bit more with the DOT language, and  
> now I understand both parts of Ryan's response to my original email:
>
>> Graphviz syntax provides "ordering=out" but this never quite worked
>> right for me. In my graphs when I wanted to preserve node order, I
>> inserted invisible edges between them. This seemed to work more  
>> often.
>
> Using invisible edges to impose order on the graph "works." However  
> it's damn hard to use invisible objects within a direct-manipulation  
> interface! Operating directly on the .dot/.gv file is possible, but  
> requires a very costly round trip, not to mention that I had a sort  
> of acid flashback experience of hand-writing RUNOFF code on a VT52  
> at DEC in the late 70s. I think that figuring how to get  
> "ordering=out" working (even if it's busted in the reference  
> implementation) is the way to go, and bringing that up into the per- 
> graph attributes as a radio-button choice is the ticket.
>
> It occurred to me that - to keep the  discussion grounded in what my  
> real objective is - I can provide a straight-forward example:  
> Suppose Glen makes a graph for himself, where the tool first defines  
> three nodes, then the edges between them. I'm not so good at hand- 
> generating long hex UIDs, so I'll use the labels as the node  
> identifiers.
>
> allThatStandsBetweenMeAndWorldMastery -> orderPreservingTrees
> allThatStandsBetweenMeAndWorldMastery ->  
> implementingUndoAndRevertAndImmutable
>
> but then, because of the frequency and amplitude of the anguished  
> howls of his users, he decides to flip the implementation order of  
> the last two nodes; he certainly does not want the layout algorithm  
> to cause him to commit to the definition order simply because  
> there's no convenient way to reorder the child nodes. (The domain of  
> the example is just joking around, I hope obviously.)

I had a chat with the AT&T principals who know far more about the guts  
of the Graphviz engine than me. It seems I can write a routine to  
change the ordering of the nodes to get what you want, although  
catching all references to the node ID in the code might be tricky.

If I get it implemented, it will arrive as a Send to Front or Send to  
Back button in the Node Settings, which will put the node in the front  
in document order. Or some sort of list screen which lists all the  
nodes in document order and allows you to swap them around.
>

> On a different note, but resulting from my investigations, I loaded  
> both example graphs 1-2b (world_dynamics) and 1-3b (shells) from "A  
> Technique for Drawing Directed Graphs," Gansner et. al., AT&T Bell  
> Laboratories. Both of them rendered correctly in Instaviz, and 1-3b,  
> in particular, uses a lot of DOT language features which are not  
> generated by Instaviz. (I've also hand-coded a couple of very small  
> state machines which have self-loops.) That made me wonder if the  
> underlying interpreter in Instaviz accepts the entire DOT language;  
> can it lay out any well-formed DOT graph?

In terms of what can be done:

Graphviz > Instaviz viewing > Instaviz editing.

The main differences between Graphviz and Instaviz viewing are:

-- Instaviz doesn't understand HTML-like labels. So fancy complex  
labels won't render properly in Instaviz. (If there is a big need for  
this, I can fix this up, I need to get the expat library working in  
iPhoneOS.)
-- All the stuff that's outside of a node or edge belongs to the graph  
background. I'm not sure if Graphviz ever draws anything between  
drawing nodes and edges, or in front of nodes and edges, but these  
things would appear behind the nodes and edges. (This may affect  
subgraph rendering.)
-- Graphviz can incorporate external images. For now this doesn't  
happen in Instaviz, because I've got no support for listing or loading  
external images or putting them in a suitable spot for Instaviz to  
see. If there's a demand for that, I can create .gvd or .ivd  
directories which incorporate the .gv file and all supporting images,  
much like Apple does with .rtfd directories.
-- Graphviz has lots more renderers available, especially in Mac and  
Linux. This means more file formats you could export to.

The main differences between Instaviz viewing and Instaviz editing are:

-- You can only draw the basic shapes e.g. ellipse.
-- You can't draw self-loops. Mainly because I haven't figured out a  
good UI for them.
-- Instaviz can view all the Graphviz styles but the settings screen  
only shows a subset of them.
-- Instaviz editing uses UUID's for names but Instaviz can view graphs  
with other sorts of names.


> Congratulations on the release of Instavue, by the way; it's another  
> step towards the asymptote of automagic 2-way sync.

Yes, thanks! Hope you've checked out the new Windows version of  
Instavue.

iPhone and iPod backup files are convenient for reading, as Instavue  
does, but I suspect they are a pain to write if it is at all possible.  
Apple whacks a couple of crypto hashes on them to check that they  
haven't been modified. If only they supplied a nice two-way sync API  
to use...




Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen
twitter: pixelglow

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman-mail5.webfaction.com/pipermail/instaviz-users/attachments/20090512/c3a107e7/attachment.html