On 24 October 2011 13:51, Rustom Mody wrote:

How does diagrams compare with graphviz?  If this is an inappropriate (type-wrong?) question thats ok :-)  Its just that when I last looked at graphviz I found the documentation somewhat impenetrable -- like much else in Hackage -- lots of types, no examples.

How is it now, better? If not, what kind of more documentation would you like? The difference between the two is: graphviz requires an external command to create the visualisations and is suited towards converting graph data into an image using various heuristics to try and make it look nice; diagrams seems to be more towards drawing specific images following specified rules. So, you could implement something like graphviz using diagrams as a backend, but you'd then need to have some transformation from a list of points+edges to actual 2D coords, etc. Hmmm... might be interesting to try and use dot/neato/etc. to do the layout of a graph, and then use diagrams for the actual visualisation... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 25 October 2011 04:25, Brent Yorgey wrote:

On Mon, Oct 24, 2011 at 03:46:26PM +1100, Ivan Lazar Miljenovic wrote:

...

Hmmm... might be interesting to try and use dot/neato/etc. to do the layout of a graph, and then use diagrams for the actual visualisation...

I agree!  This has been on my list of things-to-do-with-diagrams-eventually for quite a while. It shouldn't even be very hard since your graphviz bindings can so nicely round-trip a graph description through dot/neato/etc. (right?)

Yup, it can. It also has support for more easily adding and pulling out "custom" attributes if you want to be able to tag them with more information (albeit only with Text values at the moment); for example, I use this for the round-trip'ing to be able to distinguish multiple edges from each other. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 25 October 2011 16:02, Rustom Mody wrote:

On Mon, Oct 24, 2011 at 10:16 AM, Ivan Lazar Miljenovic wrote:

...

On 24 October 2011 13:51, Rustom Mody wrote:

...

How does diagrams compare with graphviz?  If this is an inappropriate (type-wrong?) question thats ok :-)  Its just that when I last looked at graphviz I found the documentation somewhat impenetrable -- like much else in Hackage -- lots of types, no examples.

How is it now, better?  If not, what kind of more documentation would you like?

Without claiming to have looked very hard, I looked up grahhviz in hayoo, gathered I should be looking at Data.GraphViz and tried clicking everything that looked reasonable here but still cant find an example of a graph :-) ie a graphviz graph in haskell.

Well, there are indeed examples in there, but not in Data.GraphViz: that module is aimed more at "how can I convert my existing data into a Dot representation", not constructing one by hand. As of the latest version (2999.12.*), there are indeed examples for anyone that wants them: * Sample graph in Dot representation used as a base case: http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Da... * Using the canonical representation: http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Da... * Using the graph representation: http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Da... * Using the Monadic representation (based upon the dotgen package): http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Da... The Data.GraphViz.Types module also has a short description of how to choose which representation. However, I'll add a note in Data.GraphViz telling people to look in Data.GraphViz.Types if they want to construct a Dot graph by hand.

Is this a complaint against graphviz or against hackage/cabal etc?? Dunno.

I'd say it's more a case of: to the maintainer, it's _obvious_ how to do stuff since they're intimately familiar with the details; as such, if something isn't clear let them know that you're confused by something (which at least in my case jogs me to go and add extra clarification on such matters)! -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 26 October 2011 02:17, Rustom Mody wrote:

In the Data.GraphViz.Types.Generalised page you have the starting line:

It is sometimes useful to be able to manipulate a Dot graph as an actual graph. This representation lets you do so...

Evidently some other context is needed to understand this line? [Sorry if I am dense]

It means that you can treat it as a graph data structure: add/delete nodes/edges, get neighbours of a node, etc. Whereas if you wanted to delete a node from the other representations, you would manually have to traverse the entire data structure explicitly to delete that node and any edge it may be in. The use case is is for manipulating existing Dot code better; generally speaking, if you are converting data _into_ a Dot graph, then you would do any such manipulations before you do the conversions. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Rustom Mody writes:

...

I remember (vaguely) a 'live page' ie where one could enter (into the browser) changes to the diagrams code and see the results immediately. Is that page there? (Or am I mixing up with something else?)

Maybe it was Péter Diviánszky's 'dia' (entirely different to 'diagrams') ? http://pnyf.inf.elte.hu/fp/Diagrams_en.xml

On Mon, Oct 24, 2011 at 08:21:30AM +0530, Rustom Mody wrote:

Thanks. This is attractive. I remember (vaguely) a 'live page' ie where one could enter (into the browser) changes to the diagrams code and see the results immediately. Is that page there? (Or am I mixing up with something else?)

You might also have been thinking of Luite Stegeman's "Wolfgang Lambda" project, which supports diagrams in this way (as well as many other things!). There was an early preview version of it up for a little while which a bunch of people saw, but it's not ready for release yet.

How does diagrams compare with graphviz? If this is an inappropriate (type-wrong?) question thats ok :-) Its just that when I last looked at graphviz I found the documentation somewhat impenetrable -- like much else in Hackage -- lots of types, no examples.

graphviz is a special-purpose tool for doing graph layout and visualization. diagrams is a general-purpose framework for drawing anything at all. As for documentation, you do realize that the graphviz package on Hackage is a set of bindings? So there's a lot of helpful documentation at http://www.graphviz.org/ . One of my goals with diagrams is to have excellent documentation, so if you find anything that is unclear or poorly documented, please file a bug report (http://code.google.com/p/diagrams/issues/list)! -Brent

On Sun, Oct 23, 2011 at 11:06:19PM -0700, David Barbour wrote:

Is there any way to `query` a diagram, i.e. associate data with each pixel for mouse clicks?

Yes. Every diagram has an associated 'query function', which associates a monoidal value to every point. By default it just returns True/False indicating whether the given point is in the interior of any shape, but you can use any monoid you like. I believe John Lato has been using this in conjunction with the support for rendering directly to a gtk widget to develop some sort of interactive graphical application (I don't know many details). For more info see http://projects.haskell.org/diagrams/manual/diagrams-manual.html#using-queri... -Brent

On Mon, Oct 24, 2011 at 11:55:53AM -0700, David Barbour wrote:

Thanks.

Diagrams package seems it could be promising for a declarative UI model - i.e. integration with functional reactive programming and similar models - so long as I'm willing to sacrifice `native` look and feel, which doesn't seem like a big problem.

Yes, I imagine it could. Not one of the use cases I personally had in mind -- but I've been hoping that people will find it useful for things I had not thought of.

A couple more questions: 1) Am I right in assuming that Diagrams does very little `occlusion` of its own - i.e. when rendering a soda-straw view of a complex diagram, or masking large areas with a rectangle or sphere? There won't be any competition or redundancy with an external index and backend (e.g. Cairo-GL layer) occlusion?

Right, diagrams currently doesn't do any sort of "culling", occlusion, etc., that's all up to the backend.

2) Is there support for Cairo-like linear and radial gradients?

Not yet, but it's on the todo list.

Also, it seems that for Cairo rendering, we cannot currently supply our own Cairo context.

...

renderDia Cairo (CairoOptions "foo.png" (PNG (100,100))) myDiagram

This section of your manual is incomplete, I admit, but from browsing the code it seems you provide a simplified interface that fully encapsulates the Cairo rendering. Is there any way to render a diagram within the Cairo stack? or leverage Cairo's own experimental backends (like OpenGL)?

You're right, currently there's no way do these sorts of things. However, there's no fundamental limitation here and adding this sort of functionality should not be hard, and I'd be quite open to extending the cairo backend in this direction. -Brent

On Mon, Oct 24, 2011 at 01:58:33PM -0700, Jason Dagit wrote:

On Sun, Oct 23, 2011 at 11:47 AM, Brent Yorgey wrote:

...

I am pleased to announce the release of version 0.4 of diagrams, a full-featured framework and embedded domain-specific language for declarative drawing.

What do you use for text support? I know at one point you were interested in my freetype2 binding (which is still very raw and immature), but you must be using gtk for font loading and rendering?

At the moment, text is completely delegated to backends. diagrams itself doesn't do any font loading or rendering at all. However, the obvious downside to this is that the framework itself has no idea how big a given piece of text is and can't position it relative to other things. On the todo list is to use your freetype2 binding (or something like it) to actually do more work within the framework itself, so it can position text correctly, convert text outlines into paths, and so on. -Brent