Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002491graphvizDotty/Lneato/Leftypublic2014-09-22 12:012014-10-15 12:04
Assigned To 
PlatformI686OSLinux / X11OS VersionFedora
Summary0002491: Example code does not function - at least not visually
DescriptionI have need of a lefty interface that is not unlike the code described as Appendix B.1 "Finite Automaton Simulator" in the (admittedly aged) DOTTY users guide entitled "Editing graphs with dotty". But after coding the example (w/some
minor tweaks to fit my data) and running it, the graph is produced, as expected,
into an X11/Xlib/XAW3d window using a default visual of 24-bit TrueColor.

According to the lefty code, the first graph node SHOULD be "filled" in "tan" with BlackPixel foreground and WhitePixel background. Pressing the select-mouse-button should modify this display to its next state position having the 2nd node in "tan" and the first node now in "lite-grey". Pressing the middle-mouse button should reverse this state transition, back to the original picture.

Instead, NO VISUAL FEEDBACK occurs at all. The picture remains constant with all nodes displayed in black-outline on white, non-filled, with ZERO changes as mouse interactions occur.

However, changes ARE observed in the lefty text window making table changes and
accurately depicting the changes in color and fill-state for individual nodes.

I rebuilt lefty (I am a retired Bell Labs programmer) stripping the code down
to the bare minimum (X11/XAW3D support only) to eliminate things like CAIRO, pango, libpng, et. al. to limit the list of things to examine. However, attempts at debugging on my own with virtually ZERO internal guidance has not been fruitful. My built version behaves EXACTLY as the original.

Thus I am stuck. Either, the problem is outside of lefty - (KDE Desktop, Xorg Server); or perhaps it is fixed in a newer version - but I could find no information in changelogs and/or bug reports that even comes close to describing anything about lost/missing/misapplied graph attributes. As a vague test of the external mechanisms, I modified the example code to re-activate the menu item that writes the current graph into a DOT-file. Subsequent use of DOTTY on this file CORRECTLY displays the proper filled/colored nodes as they should have been when written from the incorrectly-displayed example state.

This leads me to believe the error is truly within lefty/dotty and that despite
making the graph/lefty changes to its datastructure, SOMETHING neglects to interpret those changes and push them far enough through the software layers to reach AND successfully modify the X11 primitives as it does when initially reading the DOT description.
Steps To ReproduceExtract the script file "fa.lefty" and the two data files "" and "nfaexp.trans" from the attached tar.gz and place them into a convenient current working directory.
Then invoke with the command "lefty fa.lefty" and observe the created X11 window.
TagsNo tags attached.
VERSIONGraphviz 2.20.3 (circa 2009)
Attached Filesgz file icon leftybug.tar.gz (Attachment missing)
? file icon dotty_draw.lefty (Attachment missing)
? file icon dotty_layout.lefty (Attachment missing)

- Relationships

-  Notes
User avatar (0000825)
erg (administrator)
2014-09-24 16:38

From lefty:
the problem is that the change to make dotty use the xdot language broke
the ability to modify the graph immediately.
you now need to make a call to gt.layoutgraph (gt)
to make them take effect. but there'll be a flash as it redraws the graph.
User avatar (0000826)
vampm (reporter)
2014-09-25 20:37

Does this have something to do with the so-called "draws" lists ? I have noticed that there are functions that seem to manipulate what appears to be an encoded form of how to draw each element. For instance 'P' is a filled polygon, but a lower case type-'p' directive only draws a polygon outline. Is This the information that is returned from gt.layoutgraph() ? Shouldn't that information have been cached on return so that attribute changes (linewidth/color/etc) could be performed WITHOUT a round trip to the layout engine ? I've been searching for something that would tickle those lists, but so far have only found imperatives that seem to "empty" the draws lists but nothing that seems to NOTICE if an attr changed that would IMPLY a need for reconfiguring the draws --- or is this what you mean by "broken". What is xdot anyway ?
User avatar (0000827)
vampm (reporter)
2014-09-26 14:48
edited on: 2014-09-29 13:41

OK. Went back to reading and now understand (roughly) what xdot format is. And, as suspected, it has EVERYTHING to do with the "draws" list in the DOTTY scripts. What I dont understand is why unpacknodeattr() which is supposed to read fields that convey the *intent* of the drawing attributes and specifically convert them into a machine-usable form, doesn't also then CHECK those attributes AGAINST the drawlist instructions and modify those as well. I realize that changing a "shape" attribute might be impossible (as only the layout engine would know how and where to position each vertex describing it) but for simple color and/or fill changes, isn't simply toggling a draw.type from upper/lower case (for ellipse or polygon or color) along with maybe re-pointing the "color" reference ?

On a related note, is there some document that describes the INTENTIONS of the various data fields of the DOTTY scripts (beyond the [KN93] document that led me astray in the first place) ? It is difficult to follow the chain of events
in the various fields and ensure that modifications proceed in a logical fashion. For instance there is a "node.drawn" field. I can *GUESS* that what it might be is a speedup flag when doing a full redraw, but is it also used to ensure that certain modifications only happen while in an undrawn state ? Where can I go to find out what a field is INTENDED to do ?

Making a round-trip to the layout engine simply to get *IT* to reconfigure the "draws" list in accordance with the CURRENT attributes is dangerous besides wasteful! What if the engine chooses to make a positional change perhaps BECAUSE of an attr change (like linewidth) ? I'm trying to use LEFTY as a user interface for a vaguely flow-chart-like application and cant have it reconfiguring the picture whenever it wants.

User avatar (0000828)
vampm (reporter)
2014-09-29 13:39

I've done a root cause analysis and the only thing standing in the way of lefty being able to alter various drawing attributes is a disconnect between WHERE certain table entries are either PLACED or LOOKED for. Dotty claims that ORIGINAL attrs are placed in a "attr" table within a given node (or edge). Dotty further claims that as a result of this placement, the information is transported when communicating to the layout server.

The layout server (dot) is then invoked requesting output in the xdot format which, when returned, is then parsed by dotty, creating a "draws" table under each node (and edge). This is *WHEN* the disconnect occurs. When dotty processes the 'attr' tables (via the unpack*node|edge*attr() functions, they place their (possibly converted) results into new fields as SIBLINGS of the original tables. Xdot parsing instead places its attr-related results DIRECTLY inside the "draws" table it is simultaneously constructing. As a result of the addition of XDOT rendering I can only PRESUME that an entirely new drawing implementation was simultaneously added (conjecture on my part as I only have the one version of the code available).

So now we have a what amounts to a "self-contained" drawing system sitting BELOW an editor that was designed to PUSH things like attrs into their positions
to be picked up and used. Naturally because of WHERE the editor leaves its results they are NOT where the drawing functions expects to FIND them - they have no affect on the result. So, what can be done?

Oddly enough, the "draws" table and its contents is not TOTALLY unknown to dotty. There exist dotty functions to MOVE nodes and/or edges. These functions
blindly go and edit the results returned by xdot inside the "draws" table. This suggests that the already existing "unpack....attr()" functions simply did not go FAR enough in pushing their results to the appropriate place, and could be extended to do so.

Alternately, we could claim that in parsing the xdot output, it simply failed to find an AGREED UPON table location where BOTH it and dotty would expect the
data in question to be.

Lastly, there DOES appear to be at least some attempt on the part of the new drawing system to 'bridge' the two locations concerning, for instance, the use of color. Unfortunately, its implementation (involving the use of a temporary field called "nooverride") is such that it ALWAYS overwrites the values established by dotty and takes those from xdot every time.

SO - it appears that dottys inability to affect the results returned from XDOT is resolvable by addressing one or more of the above approaches. Such work would RESTORE a primary goal of the lefty program which was to serve as an interactive editor and/or a frontend GUI for applications that are graph-related.

I WOULD GREATLY APPRECIATE some one with more INSIGHT into the INTERNALS of the DOTTY scripts, and the possible RANGE of variations in xdot formats to comment
on the above proposed changes. Or point me to more detailed information than is apparently available on this site (i.e. design docs, rationales, etc.). I will be making SOME change for my own purposes. I am willing to submit my changes back (assuming I figure out how) but I don't want to start a war over my heading into a direction that has already been deemed "inappropriate" for reasons unknown to me.

As stated, GUIDANCE and/or additional KNOWLEDGE would be appreciated.
User avatar (0000829)
erg (administrator)
2014-09-29 14:03

lefty writes:

yeah, what they are saying is true.
if I find the time I'll check how hard it is.
User avatar (0000835)
vampm (reporter)
2014-10-14 17:06

After much finagling with the dotty scripts (and some private discussion with the lefty author) I have managed to adapt the dotty scripts to (IMHO) co-exist better to the ages-old change of using XDOT to convey layout results back to lefty. I really only have one issue remaining:

What causes XDOT to produce a FILLED RECTANGLE in addition to the bounding box description that it returns ? What attr did I supply (or fail to ?) that caused that behavior?

It becomes important, because unless the display widget background color is the same as the color that XDOT seems to choose at random for this filled area, ALL attempts at ERASING objects (as part of an attr change sequence) summarily fails because lefty is unaware of this newly colored layer between the screen objects and the widget background (in my case, some shade of grey).

I'm inclined to simply comment-out the function call that does drawing at the
"graph" level altogether - although if there is some kind of label, I guess
that would then disappear as well.

That brings me to my final point. As a newbie Graphviz-er I dont feel qualified to truely supply "patches" for what I have managed to eke out getting this working ENOUGH for my purposes. However, despite working from a non-current release, there could still be SOME benefit to be had from my changes, if only to suggest to the next person, that better integration IS possible. My changes
consists of roughly 40 modified/new lines of dotty scripting across 2 files.

The question is "do you want them?"

The changes are all marked/described within comments bearing my initials (making them easy to find as NOTHING is commented ANYWHERE). Between those and the notes in this bug report there is ample dissertation on where the problems lie. For that matter, given the apparent length of time that these features have lain dormant, my scripts may even BE current ones.

Anyway, I've attached them to this report just for completeness sake. As a "reporter"-classified user, I am unsure if there is anything remaining I can do with regard to moving this issue along. I dont see any way to edit the status of the report, or to be of further assistance. I suppose if someone were to be assigned I would be willing to revisit it with them, but beyond that I think I'm done. My changes work for me. Thank you for your attention.
User avatar (0000841)
erg (administrator)
2014-10-15 12:04

The initial fill is certainly necessary if the graph has a non-white background color. In the default white case, the fill is still done in certain cases depending on the output format. The color choice should not be random. It is either white or the color set via bgcolor. If you aren't seeing this, let me know.

One could make the case xdot should act like postscript, and do nothing if no background color is set. If you want to hack this into your code, add the bit GVRENDER_NO_WHITE_BG to the flags in render_features_xdot in plugin/core/gvrender_core_dot.c.

In any case, if the graph does use a background color, you'll will need be aware of that to refill the background if an object has moved.

I will pass your changes on to lefty for him to vet them. Thanks very much for these.

- Issue History
Date Modified Username Field Change
2014-09-22 12:01 vampm New Issue
2014-09-22 12:01 vampm File Added: leftybug.tar.gz
2014-09-24 16:38 erg Note Added: 0000825
2014-09-25 20:37 vampm Note Added: 0000826
2014-09-26 14:48 vampm Note Added: 0000827
2014-09-29 13:39 vampm Note Added: 0000828
2014-09-29 13:41 vampm Note Edited: 0000827 View Revisions
2014-09-29 14:03 erg Note Added: 0000829
2014-10-14 17:06 vampm Note Added: 0000835
2014-10-14 17:07 vampm File Added: dotty_draw.lefty
2014-10-14 17:08 vampm File Added: dotty_layout.lefty
2014-10-15 12:04 erg Note Added: 0000841

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker