Wish List time

Version 3.0 is in the can. A refresh of the web site is underway.

Time to open up the floor for your thoughts on what we should be working on next…

We have our own list here, but I think for now I’m not going to bias the discussion.

Please try to be detailed, pictures are always helpful…

Not sure if this exists… How about the ability to zoom fit like GoToolZooming for a rubber band, but instead zoom to selected object(s). Along with that perhaps a property for a Selection to include the overall bounds of the collection. I know these can already be calculated from our side, these are more like convenience features rather than new additions.

Another company has gone to market with a WPF version of their diagram control. I’d really like to see a Silverlight version of GoDiagram.

Also, the ability to zoom in and out with mouse wheel and move the selection around like in Google maps would be excellent end-user features.

Zooming in and out with control-wheel has been supported for many years. This follows longstanding Windows UI guidelines, such as in Internet Explorer.

Panning like in various mapping applications is supported by using the GoToolPanning tool in non-autopanning mode. The standard panning tool in each GoView in Windows Forms only supports auto-panning. (Click the middle mouse button.)

However that same predefined tool in Web Forms does manual panning, with the middle mouse button. You can enable manual panning in GoDiagram Web with the left mouse button by removing the rubber-banding selection tool, since that gesture would normally take precedence.

1. Most important - enable centering the diagram in the middle of the view (while using automatic layout)
2. I think getting all these greate objects you wrote in the sample applications like the Multiportsubgraph, the RecordNode, CollapsibleListGroup etc and make them as ready to use NATIVE GoObjects will help alot instead of letting the users to put hundreds of code lines into their application.
3. Put a lot of animation methods in your objects like: the animation link sample, fade in/out etc
  1. Enable rendering HTML in your text nodes or at least RTF
5. Enable users to type text on the GoObject itself and not in a textbox or at leaset let the user type text on a Transparent text box
6. while users type text resize the shape to fit to the new size in realtime

This is demonstrated by the SequentialFunctionChart sample. Look at the last few lines of the Form1_Load method, where after calling GoLayout.PerformLayout() it makes sure GoView.SheetStyle is set to some non-None value and then sets GoView.DocExtentCenter to the center of the GoDocument.Bounds.

4. Enable rendering HTML in your text nodes or at least RTF[/quote]
Do you know about the RichText class in Demo1? You could change it to inherit from GoText, so that you could use it in any of the predefined node classes that expect the use of a GoText as a label.

The centering technique is some kind of workaround. it behaves strange. if you have visual studio 2005/2008 and you start a new workflow project you can see how the diagram should look centered. in your solution the scrollbars behave strange - you can scroll even when its not needed (when you have a small diagram). i hope i was clear enough describing my thoughts. thanks.

I’m not sure if I understood you correctly, but it seems that Visual Studio 2008 has the same problems, and doesn’t even center the initial diagram!

Here’s what I got:

this is the state machine workflow. try the sequential workflow. you can do wild things with it and it always looks good. i try to do the same with GoDiagrams and the centering thing is one of the hardest things to achieve.

one more thing Walter. just put an ifElseActivity in microsoft workflow and tell me if i can such thing with GoDiagrams. it’s very hard to do! i’ll be glad to see sample code doing it. the blocks are allways simetrical and the automatic layout is very consistent.


It’s true that GoLayoutLayeredDigraph doesn’t try to balance the body of nodes and links below a node. That’s because the Sequential Workflows that one can draw are rather limited in graph structure.

(They can be balanced by aligning about the middle, but they can’t be symmetrical because obviously one branch of the IfElse can be much bigger than the other one.)

The power and generality of GoLayoutLayeredDigraph really isn’t needed for this kind of graph. We ought to improve the Flowgrammer sample in the same manner, since it has basically the same restrictions as the Sequential Workflow designer. It think it would be pretty easy to implement.

With hard work and your outstanding support i managed to achieve 95% of microsoft’s designer including the automatic layout of course and unlimited nested subgraphs. i also managed to make the inner subgraphs symetrical in any situation (see picture)

the centering is still a problem and the automatic reshape of the links gives me unexpected results.
  1. Better access to links. I didn’t see any way to get directly to links in the collection like: getting to link num 1 will be link=node.destination_links[0]
Correct my if i'm wrong but in your architecture i need to iterate the links collection until i get to the link i want to fetch.
hope i was clear

I’ve always wanted a hyperbolic graph. And a Silverlight version please.

Hi Jake,

I think a nice to have would be when expanding a collapsed node it renders transparent so that you may still see the object being covered up. Maybe GoDiagram can already do this?


[QUOTE=Rich Harrigan]Hi Jake,

I think a nice to have would be when expanding a collapsed node it renders transparent so that you may still see the object being covered up. Maybe GoDiagram can already do this?

Yes, as you can see in “abware”'s screen shot, he has set the GoSubGraph.Opacity so that the GoSubGraph.BackgroundColor is partly transparent. In that example, you can see how the greens of nested subgraphs are getting progressively darker.

Hyperbolic layout would be the bomb, as would a WPF/Silverlight version.

Print Selection would be a great-to-have.
I found/find the implementation of Context Menus on GoObjects to be very confusing. . .any way to support standard ContextMenu objects without all the hand-waving currently required?
I agree that indexed selection of objects would be great, as well as indexed Nodes and Links collections for the document.
But none of this is to say that the current product doesn't rock, because it does .